barfing on boot after update
 

It seems every time I update fc18, something pukes. I ran 'yum update' today, and got the errors below. I am hoping for

1. The standard kernel config line (I'm controlling boot from lilo in Slackware with EFI neutered)
2. A link to the howto on that emergency shell you're dropped into - dracut?
3. Any ideas on this?


BTW I also have "Permission Denied" errors in /var/log/messages for every service in /etc/rc.d/rc?.d/K*

I'm running and working again, but no wiser.

It runs on my slackware kernel - so I humped over the slackware modules and off we go. The print is miniscule, so I have difficulty reading anything - especially the console fonts.

Can someone assist me with the kernel command line, and I'll at least TRY that??

I've used linux since 1993, ran Fedora for years at one stage, and never disliked any system so much as this present iteration - f-18.

Bump


Can someone assist me with the kernel command line, and I'll at least TRY that??

Bumper
Once you drop into the dracut rescue shell, all hope is lost. There be dragons! When I installed fc? on a 2tb drive in Sep2011, it created a 60gb ext4 boot partition, containing grub and the kernel files (System.map, config, vmlinuz and initramfs), and a logical volume group using the rest of the disk containing lv_home, lv_root, lv_swap. Since then, negative comments on that configuration led me to believe that I need to have /usr on the same partition as /boot, and using a logical volume for swap isn't a smart idea.

There was a new version of grubby updated earlier this year. It changed the command-line options for /sbin/new-kernel-pkg, which is invoked as a post-installation script in the kernel rpm. I have rather poor brains for understanding the intricacies of an rpm build, I don't know post-install runs POSTIN or the post-installation part of ALL (which also contains the pre-uninstall script). The POSTIN script contains the line, "/sbin/new-kernel-pkg --package kernel --install kernel...." but there is no --package option any more. If you run `/sbin/new-kernel-pkg --package kernel` you'll get the help message with all of the options it knows( usage() ). I don't know what happens if there is an --install option after the disallowed --package option. Scanning the new-kernel-pkg script, have to wade through all the mkinitrd stuff at the top, the script proceeds to create a default initramfs file, using initrd-plymouth.img plus a lot of keyboard modules, but no LVM modules, its udev doesn't even create the ext4 device for the first partition. [Sorry, I tend to ramble due to an illness that's keeping me on the disabled list wearing a red t-shirt.]

I now have to invoke dracut manually after every new kernel install to create an initramfs which contains the missing modules. They're compiled into the kernel, but the kernel never gets loaded because the startup code can't find the root partition on the logical volume. You'd think it would at least create a /dev/sda1 containing the kernel and grub, but someone decided that isn't a smart idea. The POSTIN script merely gets the UUID of the root partition then gets stymied because it doesn't know about the volume group that Fedora created a year ago.

You didn't mention your setup, so I don't know if any of that helps. If you are booting using lilo, then you have to run mkinitrd to make an initrd image, not an initramfs, something like this works for me:

`mkinitrd -c -k $KernelVersion -m ext4 -f ext4 -r /dev/disk/by-uuid/e484a3ee-0889-4f13-82ba-60d95c147018 -o initrd-$KernelVersion.img.gz`

Notice that you don't want lilo to boot from the drive, just the root partition. I invoke lilo using symlinks in lilo.confimage=/boot/vmlinuz
=-=-=-snip---=-=-
boot=/dev/disk/by-uuid/c454a8ee-0849-4f13-88ba-60d93c147018
root=/dev/disk/by-uuid/c454a8ee-0849-4f13-88ba-60d93c147018

initrd=/boot/initrd
label=whatever menu entry you want
read-only
-==-=-=snip=-=-=-

Yes, thanks that does help and I can follow your wandering exactly. I have the policy that I don't want to spend 1/3 of my life learning software. My setup is a 60G SSD while UEFI is sorted out. I have set that up this way (Viewed From Slackware)
/home & /boot are common partitions to both systems. When I reported a bug, they had to build a vm to test what I was doing, because nobody in fedora had ever tested anything like this.
My Lilo is in Slackware. I realize from this thread that nobody has a clue what a Fedora install is really doing, which is amusing. My problem is that every time since day 1, I cannot run things on the Fedora kernel, but the slackware-huge kernel runs just fine. That needs no initrd. I have heard the argument for uuids and it doesn't apply in my case.

So the kernel is just 'root=' with no other options and my problem is I have to build an initrd. Correct?