On Tue, Aug 31, 2021 at 4:37 PM Markus Falb <[email protected]> wrote:
> > > > On 30.08.2021, at 23:26, Brian C. Lane <[email protected]> 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 > [email protected] > https://listman.redhat.com/mailman/listinfo/kickstart-list
_______________________________________________ Kickstart-list mailing list [email protected] https://listman.redhat.com/mailman/listinfo/kickstart-list
