<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 1, 2021 at 1:32 PM David Lehman <<a href="mailto:dlehman@redhat.com">dlehman@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Tue, Aug 31, 2021 at 4:37 PM Markus Falb <<a href="mailto:wnefal@gmail.com" target="_blank">wnefal@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 30.08.2021, at 23:26, Brian C. Lane <<a href="mailto:bcl@redhat.com" target="_blank">bcl@redhat.com</a>> wrote:<br>
> <br>
> On Thu, Aug 26, 2021 at 06:11:49PM +0200, Markus Falb wrote:<br>
> <br>
>> The solution is to activate the LVs in %pre<br>
>> It turns out that there is /dev/sda present but not the device files for /dev/sdaX.<br>
>> <br>
>> …snip<br>
>> %pre<br>
>> mknod /dev/sda2 b 8 2<br>
>> pvscan<br>
>> vgchange -ay<br>
>> %end<br>
>> snap…<br>
>> <br>
>> alternatively this oneliner is working too, interestingly<br>
>> <br>
>> …snip<br>
>> %pre<br>
>> parted /dev/sda unit MiB print<br>
>> %end<br>
>> snip…<br>
>> <br>
>> Note that with the parted command it is not necessary to vgchange afterwards.<br>
>> <br>
>> Is there a builtin kickstart command that accomplishes the same instead of some %pre?<br>
>> If not, why is %pre necessary? %pre was not necessary with RHEL7. Is this by design or is it a bug?<br>
> <br>
> This is a bug of some sort, as David said. The fact that parted print<br>
> fixed it makes me think that your storage is slow, since all parted does<br>
> is open/close the device and tell the kernel to rescan the partitions --<br>
> which should have already happened at boot time when the device<br>
> appeared.<br>
<br>
I am testing with a kvm VM created with Virtual Machine Manager on CentOS 7.<br>
The VM has a scsi disk (changing to IDE or SATA does not change the behaviour)<br>
<br>
I remember that I was trying “udevadm settle” in %pre and this was returning<br>
fast and that’s why I thought that it was not waiting for some slow udev event.<br>
<br>
I had another look.<br>
I added a sleep 600 and removed the parted from parted (600s should be<br>
plenty of time for detection)<br>
<br>
Here is my interpretation:<br>
<br>
The kernel *did* detect the partitions in early initramfs<br>
<br>
…<br>
Aug 31 14:19:50 localhost kernel:  sda: sda1 sda2<br>
Aug 31 14:19:50 localhost kernel: sd 0:0:0:0: [sda] Attached SCSI disk<br>
…<br>
<br>
If I add rd.break kernel parameter I can see that the devices are there.<br>
But after switching root (pivoting) they are gone. I do not know if this <br>
is expected or not.<br></blockquote><div><br></div><div>The lvs being gone is expected, but the partitions being gone is not expected.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
So while %pre is running sda1 and sda2 are not present given that I did<br>
not trigger udev with parted or similar.<br>
<br>
After %pre is finished it is detecting sda1 and sda2 again, and it is<br>
finding the VG and the LVs, but then it is stopping the VG (which is what<br>
I find strange) and throwing the error</blockquote><div><br></div><div>Stopping the the VG is a normal part of the process. The installer makes a</div><div>model of the storage and then deactivates it until it is needed. The partitions</div><div>should still be visible, however.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
<br>
…<br>
initramfs<br>
…<br>
Aug 31 14:19:50 localhost kernel:  sda: sda1 sda2<br>
Aug 31 14:19:50 localhost kernel: sd 0:0:0:0: [sda] Attached SCSI disk<br>
…<br>
pivot root filesystem<br>
…<br>
running pre (10 minutes sleep)<br>
…<br>
Aug 31 14:30:14 test kernel:  sda: sda1 sda2<br>
…<br>
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 '<br>
…<br>
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} …<br>
…<br>
Aug 31 14:30:21 test org.fedoraproject.Anaconda.Modules.Storage[1903]: Logical volume "root" given in logvol command does not exist.<br>
…<br>
<br>
If someone is interested, I created a gist with the kickstarts and logs at<br>
<a href="https://gist.github.com/610acf7379f48d0e5c38f4edb9cda176" rel="noreferrer" target="_blank">https://gist.github.com/610acf7379f48d0e5c38f4edb9cda176</a><br>
(you can clone it with git)<br>
<br>
I found no obvious error, but there is a lot of stuff and I could have<br>
missed something easily.<br></blockquote><div><br></div><div>I see in storage.log that it successfully looks up (get_device_by_name)</div><div>the lvm.vg1-root LV in its model shortly before the error occurs, which is</div><div>strange. I also do not see any failing calls to get_device_by_name for</div><div>the root LV once the initial scan has completed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Given that anaconda sees the LVs, do you still think that it is a kernel<br>
problem or the storage too slow?<br>
<br>
Best Regards, Markus<br>
and thanks too all who took the time answering.</blockquote></div></div></blockquote><div><br></div><div style="font-family:monospace,monospace" class="gmail_default">I know this is very old, but I am just getting back to readin list emails, and compared to other lists, this one does not have much traffic - which is good because kickstart is doing what is supposed to.</div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">To the OP, I had this same issue when using %pre to not only create arrays on storage controllers, but them trying to read them.  My only ever solution I could find that always worked was "partprobe" sprinkles through my scripts.  The good thing about partprobe is that it blocks and does not return until the kernel says it is ok.  In my case, creating the arrays through the BMC, etc manually would also fix it, but who wants to click all of those buttons in the slow ass BMC guis..</div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">Anyhow, putting a partprobe before every new disk call fixed it for me and all device nodes where properly populated by udev, etc afterward..</div><div style="font-family:monospace,monospace" class="gmail_default"><br></div><div style="font-family:monospace,monospace" class="gmail_default">-Greg<br></div></div></div>