I wrote:
> I have five machines which were fresh-installed with F23 back in
> February and all have been booted successfully a few times since.
> Today, booting of all of them fails in exactly the same way: dracut
> says it can't find the disk filesystems. The kernel boots as it
> should, and of course that comes from the disk, but then dracut comes
> along and says it can't find any of the filesystems. Not the root or
> home filesystems which are on LVM or the boot filesystem on a primary
> disk partition.
>
> Everything on the disk is ok. I've checked by booting Anaconda from
> a thumb drive and mounting manually. Anaconda troubleshooting mode
> says it can't find the filesystems either ("you have no Linux
> partitions"), but running vgchange -ay and a few mounts gets a proper
> chroot image.
>
> There must be something that is causing both dracut and Anaconda to
> fail to find the filesystems. I've tried following the instructions
> on <https://fedoraproject.org/wiki/How_to_debug_Dracut_problems>, but
> that isn't helping:
>
> dracut:/# parted /dev/sda -s p
> sh: parted: command not found
> dracut:/# lvm vgscan
> File descriptor 98 (/dev/console) leaked on lvm invocation. Parent PID 2679: sh
> File descriptor 99 (/dev/console) leaked on lvm invocation. Parent PID 2679: sh
> Reading all physical volumes. This may take a while...
> dracut:/# lvm vgchange -ay
> File descriptor 98 (/dev/console) leaked on lvm invocation. Parent PID 2679: sh
> File descriptor 99 (/dev/console) leaked on lvm invocation. Parent PID 2679: sh
> dracut:/# blkid
> dracut:/#
>
> Note that when booted from the thumb drive, vgchange finds the LVM
> volumes just fine.
On 04/07/16 05:03 PM, Rick Stevens answered:
> Have you tried booting the previous kernel? It may be that the
> ramdisk for the new kernel is missing the LVM stuff for some reason.
> If the old kernel boots and finds things, bring it up and:
>
> dracut -f /boot/initramfs-<kernelversion>.fc23.x86_64.img
> <kernelversion>
>
> where "<kernelversion>" is the desired (new) kernel version. Then
> try the new kernel again. I've seen times where a new kernel install
> doesn't build a correct initramfs image. Never sorted out why, but
> I've used the above BFH on it and it seems to fix it (BFH = "big
> freaking hammer" for those who were curious).
Sorry it took me so long, Rick, but I did finally have a chance to try
your suggestion. The new ramdisk created by the dracut command contained
34 additional files that weren't in the original. Mostly stuff from
/usr/lib/modules but also a few files from /usr/lib/firmware. Using the
new ramdisk, the new kernel boots just like it should. So I can report
that you have saved me. Thanks!
I suspect the problem comes from the fact that the machine on which the
new kernel was built has a few differences from the one which would not
boot. Both are x86_64 machines but the build machine does not have the
Broadcom Ethernet ports that are in the target. Those were the firmware
files missing. There is probably some way I can tweak the build to
insure these files are initially included.
--
Dave Close
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
http://lists.fedoraproject.org/admin/lists/users@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
