From joe_wulf at yahoo.com Wed Sep 1 15:54:40 2021 From: joe_wulf at yahoo.com (Joe Wulf) Date: Wed, 1 Sep 2021 15:54:40 +0000 (UTC) Subject: RHEL84 ISO with ks.cfg errors out unable to find installation source References: <1797594179.1840224.1630511680722.ref@mail.yahoo.com> Message-ID: <1797594179.1840224.1630511680722@mail.yahoo.com> I've tailored an original RHEL84 ISO; adding a ks.cfg and updating the isolinux.cfg and grub.cfg to support doing the kickstart from the ISO.Anaconda boots, runs the pre-installation scripts (successfully; to generate the partition table), it starts automated install...., it saves the storage configuration..., it checks the storage configuration... Then it stops, and presents the "Installation" menu of numbered items 1-8.@ #3 [!] Installation source; this is reported ----->? (ERROR SETTING UP SOFTWARE SOURCE). I select '3' which gives me options for choosing an installation source type of 1) CD/DVD; 2) local ISO file; 3) Network.Neither '1' nor '2' do any good ('1' simply refreshes the 'menu'; and '2' states "No mountable devices found'.? I've nothing set up for the network.The ISO remains viable and mounted.? I've checked the Packages directories, in the booted VM, for both AppStream and BaseOS---they have all the content, with full-looking filenames. I've gone through the RHEL 8 docs for anaconda, kickstart and advanced installation.... I've not been able to get past this.My build environment is Centos7, and has been working well to use the same process to build RHEL7.9 custom ISOs without any problems. In the booted (but halted VM), I've verified the isolinux.cfg and boot.cfg and ks.cfg are present, and have the right content.I've verified the path(s) for things in the booted environment match up to what I've configured things to use. In the 'append' and 'linuxefi' lines, I've alternated between 'inst.ks=cdrom:' and 'inst.ks=hd:LABEL=' without noticing and productive difference. Using 'blkid -v' on the original and new ISO's, I've verified the volumeID's match.I use genisoimage with standard options per the RH documentation to build the new ISO from a copy of the source content. The 'append' line in isolinux.cfg is:append initrd=initrd.img inst.stage2=hd:LABEL=RHEL-8-4-0-BaseOS-x86_64 inst.ks=cdrom:/isolinux/ks/ks.cfg The 'linuxefi' line in grub.cfg is:linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=RHEL-8-4-0-BaseOS-x86_64 inst.ks=hd:LABEL=RHEL-8-4-0-BaseOS-x86_64:/isolinux/ks/ks.cfg The contents of the ks.cfg are:text cdrom repo --name "RHEL 84 AppStream" --baseurl=file:///run/install/repo/AppStream/ repo --name "RHEL 84 BaseOS"??? --baseurl=file:///run/install/repo/BaseOS/ keyboard --vckeymap=us --xlayouts=us lang en_US.UTF-8 %include /run/install/repo/isolinux/ks/include/01_timezone authselect --kickstart --passalgo=sha512 --usecache --useshadow selinux --enforcing services --disabled=bluetooth --enabled=auditd,chronyd,rsyslogd,sshd logging --level=info %include /run/install/repo/isolinux/ks/include/05_RootAndUsers %include /run/install/repo/isolinux/ks/include/10_networks network --hostname=ajstlablvbld53.dev.local %include /tmp/PART_Firmware_include firewall --enabled --service=ssh eula --agreed firstboot --disabled sshpw --username="root" --iscrypted $6$GZ7BkMOtQ.xm6x64$JoEpC1tadSS7924sZhpg5GDTkCtIq6mytyBqUGGAazpQ0puaL1enjOokZu4SUsJeHEzDLLtmNVEi75r8gTpwz1 halt skipx %packages %include /run/install/repo/isolinux/ks/include/packages_include %end %post%end -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe_wulf at yahoo.com Wed Sep 1 17:48:28 2021 From: joe_wulf at yahoo.com (Joe Wulf) Date: Wed, 1 Sep 2021 17:48:28 +0000 (UTC) Subject: RHEL84 ISO with ks.cfg errors out unable to find installation source In-Reply-To: <1722444913.1872593.1630515590449@mail.yahoo.com> References: <1797594179.1840224.1630511680722.ref@mail.yahoo.com> <1797594179.1840224.1630511680722@mail.yahoo.com> <1722444913.1872593.1630515590449@mail.yahoo.com> Message-ID: <1806876881.1898979.1630518508281@mail.yahoo.com> The RHEL84 custom boot does see/find/use the ks.cfg, as the %pre section runs successfully, and generates the partition table file in /tmp. This is the exact same code (for %pre, anyway) I've used in recent RHEL7.x ISO builds without problems.? I've followed the Red Hat RHEL 8 docs for Anaconda, as well as for Kickstart, and Performing An Advanced RHEL Installation. I am just blown away by how hard it is to simply fully boot through to the end of the ks.cfg.? I had none of these issues/problems with RHEL5.x, 6.x and 7.x. I've carefully looked over both repo lines in ks.cfg and verified the paths are correct.I've provided the relevant lines from isolinux.cfg and grub.cfg (which are simple and straightforward).Boots of either firmware present the same stubborn error state. I've wondered if my building a RHEL84 ISO on a Centos7 VM could be the issue (how to know for sure?); not that it should matter though. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlehman at redhat.com Wed Sep 1 18:25:03 2021 From: dlehman at redhat.com (David Lehman) Date: Wed, 1 Sep 2021 13:25:03 -0500 Subject: Reinstall and keep data LV In-Reply-To: <4C87CC5E-8714-4531-B55E-8A8A94DB5904@gmail.com> References: <4C87CC5E-8714-4531-B55E-8A8A94DB5904@gmail.com> Message-ID: On Tue, Aug 31, 2021 at 4:37 PM Markus Falb wrote: > > > > On 30.08.2021, at 23:26, Brian C. Lane wrote: > > > > On Thu, Aug 26, 2021 at 06:11:49PM +0200, Markus Falb wrote: > > > >> The solution is to activate the LVs in %pre > >> It turns out that there is /dev/sda present but not the device files > for /dev/sdaX. > >> > >> ?snip > >> %pre > >> mknod /dev/sda2 b 8 2 > >> pvscan > >> vgchange -ay > >> %end > >> snap? > >> > >> alternatively this oneliner is working too, interestingly > >> > >> ?snip > >> %pre > >> parted /dev/sda unit MiB print > >> %end > >> snip? > >> > >> Note that with the parted command it is not necessary to vgchange > afterwards. > >> > >> Is there a builtin kickstart command that accomplishes the same instead > of some %pre? > >> If not, why is %pre necessary? %pre was not necessary with RHEL7. Is > this by design or is it a bug? > > > > This is a bug of some sort, as David said. The fact that parted print > > fixed it makes me think that your storage is slow, since all parted does > > is open/close the device and tell the kernel to rescan the partitions -- > > which should have already happened at boot time when the device > > appeared. > > I am testing with a kvm VM created with Virtual Machine Manager on CentOS > 7. > The VM has a scsi disk (changing to IDE or SATA does not change the > behaviour) > > I remember that I was trying ?udevadm settle? in %pre and this was > returning > fast and that?s why I thought that it was not waiting for some slow udev > event. > > I had another look. > I added a sleep 600 and removed the parted from parted (600s should be > plenty of time for detection) > > Here is my interpretation: > > The kernel *did* detect the partitions in early initramfs > > ? > Aug 31 14:19:50 localhost kernel: sda: sda1 sda2 > Aug 31 14:19:50 localhost kernel: sd 0:0:0:0: [sda] Attached SCSI disk > ? > > If I add rd.break kernel parameter I can see that the devices are there. > But after switching root (pivoting) they are gone. I do not know if this > is expected or not. > The lvs being gone is expected, but the partitions being gone is not expected. > > So while %pre is running sda1 and sda2 are not present given that I did > not trigger udev with parted or similar. > > After %pre is finished it is detecting sda1 and sda2 again, and it is > finding the VG and the LVs, but then it is stopping the VG (which is what > I find strange) and throwing the error Stopping the the VG is a normal part of the process. The installer makes a model of the storage and then deactivates it until it is needed. The partitions should still be visible, however. > > > ? > initramfs > ? > Aug 31 14:19:50 localhost kernel: sda: sda1 sda2 > Aug 31 14:19:50 localhost kernel: sd 0:0:0:0: [sda] Attached SCSI disk > ? > pivot root filesystem > ? > running pre (10 minutes sleep) > ? > Aug 31 14:30:14 test kernel: sda: sda1 sda2 > ? > Aug 31 14:30:15 test org.fedoraproject.Anaconda.Modules.Storage[1903]: > DEBUG:blivet: DeviceTree.handle_device: name: lvm.vg1-root > ; info: {'DEVLINKS': > '/dev/disk/by-uuid/9c60e33e-03e0-42c4-a583-868f4fd1b2b4 ' > ? > Aug 31 14:30:15 test org.fedoraproject.Anaconda.Modules.Storage[1903]: > INFO:program:Running [36] lvm vgchange -an lvm.vg1 --config= devices { > preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] } log {level=7 > file=/tmp/lvm.log syslog=0} ? > ? > Aug 31 14:30:21 test org.fedoraproject.Anaconda.Modules.Storage[1903]: > Logical volume "root" given in logvol command does not exist. > ? > > If someone is interested, I created a gist with the kickstarts and logs at > https://gist.github.com/610acf7379f48d0e5c38f4edb9cda176 > (you can clone it with git) > > I found no obvious error, but there is a lot of stuff and I could have > missed something easily. > I see in storage.log that it successfully looks up (get_device_by_name) the lvm.vg1-root LV in its model shortly before the error occurs, which is strange. I also do not see any failing calls to get_device_by_name for the root LV once the initial scan has completed. > > Given that anaconda sees the LVs, do you still think that it is a kernel > problem or the storage too slow? > > Best Regards, Markus > and thanks too all who took the time answering. > > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list at redhat.com > https://listman.redhat.com/mailman/listinfo/kickstart-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe_wulf at yahoo.com Wed Sep 1 21:09:03 2021 From: joe_wulf at yahoo.com (Joe Wulf) Date: Wed, 1 Sep 2021 21:09:03 +0000 (UTC) Subject: [SOLVED] Re: RHEL84 ISO with ks.cfg errors out unable to find installation source In-Reply-To: <1806876881.1898979.1630518508281@mail.yahoo.com> References: <1797594179.1840224.1630511680722.ref@mail.yahoo.com> <1797594179.1840224.1630511680722@mail.yahoo.com> <1722444913.1872593.1630515590449@mail.yahoo.com> <1806876881.1898979.1630518508281@mail.yahoo.com> Message-ID: <1309853061.2000647.1630530543468@mail.yahoo.com> I reviewed the Red Hat documentation for performing a standard installation, and in there it explained about needing an 'inst.repo=' assignment on both the 'append' line for BIOS boots, and on the 'linuxefi' line for UEFI boots.? That suddenly made things a whole lot better. Thanks for those who looked at this for me and with me.... I greatly appreciated your help. -Joe On Wednesday, September 1, 2021, 01:48:28 PM EDT, Joe Wulf wrote: The RHEL84 custom boot does see/find/use the ks.cfg, as the %pre section runs successfully, and generates the partition table file in /tmp. This is the exact same code (for %pre, anyway) I've used in recent RHEL7.x ISO builds without problems.? I've followed the Red Hat RHEL 8 docs for Anaconda, as well as for Kickstart, and Performing An Advanced RHEL Installation. I am just blown away by how hard it is to simply fully boot through to the end of the ks.cfg.? I had none of these issues/problems with RHEL5.x, 6.x and 7.x. I've carefully looked over both repo lines in ks.cfg and verified the paths are correct.I've provided the relevant lines from isolinux.cfg and grub.cfg (which are simple and straightforward).Boots of either firmware present the same stubborn error state. I've wondered if my building a RHEL84 ISO on a Centos7 VM could be the issue (how to know for sure?); not that it should matter though. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: