Can't update kernel. Initramfs-update hangs.

[mintlars]

Got a problem which makes updating very difficult. When kernel is supposed to be updated, initramfs-update can't create any boot image because it gets stuck in some kind of module load loop. Running 'sudo update-initramfs -u -v' reveals that the process gets stuck on this line:

Adding module /lib/modules/3.5.0-21-generic/kernel/drivers/gpu/drm/savage/savage.ko

Ironically my system seem to be booting into the newer kernel version even though the boot image don't seem to generate (uname -r gives 3.5.0-21-generic). I found a launchpad bug here (https://bugs.launchpad.net/ubuntu/+s...ls/+bug/982514) which seem related, but no workaround has worked for me. Any ideas how to fix this?

System runs Kubuntu 12.10 on kernel version 3.5.0-21-generic. Also have a Nvidia-gpu on board.

Edit:
The workaround listed in https://bugs.launchpad.net/ubuntu/+s...ls/+bug/982514 works fine. Running this command solves the hickup:

sudo cp /lib/modules/[your kernel version here, in my case it's 3.5.0-21-generic]/kernel/drivers/gpu/drm/i915/i915.ko /lib/modules/3.5.0-21-generic/kernel/drivers/gpu/drm/i915/i915.ko.backup && sudo rm /lib/modules/3.5.0-21-generic/kernel/drivers/gpu/drm/i915/i915.ko

After this, I also found that the next kernel upgrade also gets stuck (upgrade to 3.5.0-23-generic in my case), but because the system can't find the i915 module anymore. To solve this just reverse the process above with this command:

sudo cp /lib/modules/[your kernel version here]/kernel/drivers/gpu/drm/i915/i915.ko.backup /lib/modules/[your kernel version here]/kernel/drivers/gpu/drm/i915/i915.ko

[Dutchman]

Savage is a video driver for S3 video cards. There's probably something wrong with the installation of the driver packages. Seeing you have nVidia anyway, you can safely remove the drivers.

sudo apt-get purge xserver-xorg-video-s3
sudo apt-get purge xserver-xorg-video-savage

As it looks like the kernel installed and updated properly despite the S3 driver problem, you probably don't need to do anything else, but it can't hurt to try the update again to make sure that the problem's gone.

[mintlars]

Thanks for the tip, though it didn't solve the problem. Now I've also removed all old kernel images hanging around on my system, but problem still remains.

[Dutchman]

Sorry it took so long to get back to this. I don't get to spend the time I'd like, work and other responsibilities take priority.

Seeing how the system seems to boot and work despite the initramfs problem, I wonder if there's something that's not working that perhaps you haven't come across yet, or it's a module / driver your system doesn't need so there hasn't been a problem. Even so, there should be a message somewhere from the kernel saying something's wrong. Have you taken a look through the output of dmesg for anything odd or that shows a failure?

If you're not familiar with dmesg, you can read the man page for it. There are other system logs you can check too, but generally dmesg is where I start as it shows all the boot messages and hardware configuration. If the kernel is having trouble with a module or something that should be getting loaded is missing, there will be a message from the kernel about it in the output of dmesg.

[SteveRiley]

Savage is a video driver for S3 video cards. There's probably something wrong with the installation of the driver packages. Seeing you have nVidia anyway, you can safely remove the drivers.

sudo apt-get purge xserver-xorg-video-s3
sudo apt-get purge xserver-xorg-video-savage

savage.ko comes from the package linux-image-extra-version-generic, so removing the X Server packages won't help.

Thanks for the tip, though it didn't solve the problem. Now I've also removed all old kernel images hanging around on my system, but problem still remains.

Have you tried creating a new initramfs instead of updating the existing one?

sudo update-initramfs -c -v

[mintlars]

savage.ko comes from the package linux-image-extra-version-generic, so removing the X Server packages won't help.


Have you tried creating a new initramfs instead of updating the existing one?

sudo update-initramfs -c -v

Tried running it, but update-initramfs won't recognize it as a valid command. It only gives the --help output.

[Dutchman]

See if this is any help: Fix a Failed initramfs Update.

[SteveRiley]

Tried running it, but update-initramfs won't recognize it as a valid command. It only gives the --help output.

That's odd. Here's my help output:

steve@t520:~$ [B]update-initramfs[/B]
You must specify at least one of -c, -u, or -d.

Usage: /usr/sbin/update-initramfs [OPTION]...

Options:
 -k [version]   Specify kernel version or 'all'
 -c             Create a new initramfs
 -u             Update an existing initramfs
 -d             Remove an existing initramfs
 -t             Take over a custom initramfs with this one
 -b             Set alternate boot directory
 -v             Be verbose
 -h             This message

-c is certainly a valid option.

[mintlars]

That's odd. Here's my help output:

steve@t520:~$ [B]update-initramfs[/B]
You must specify at least one of -c, -u, or -d.

Usage: /usr/sbin/update-initramfs [OPTION]...

Options:
 -k [version]   Specify kernel version or 'all'
 -c             Create a new initramfs
 -u             Update an existing initramfs
 -d             Remove an existing initramfs
 -t             Take over a custom initramfs with this one
 -b             Set alternate boot directory
 -v             Be verbose
 -h             This message

-c is certainly a valid option.

Yes, that's the output I get too, but it also says that...

lars@Burken:~$ update-initramfs -c -v
Create mode requires a version argument

UPDATE: If I run the command like this:

update-initramfs -c -v -k 3.5.0-21-generic

It runs properly and tries to create a new image, but it halts at the sam place as before. That is, when trying to add the module "/lib/modules/3.5.0-21-generic/kernel/drivers/gpu/drm/savage/savage.ko".

[SteveRiley]

What if you temporarily move that driver out of the way? Maybe the file is munged or something. I feel like I'm kind of guessing at this point.

sudo mv /lib/modules/3.5.0-21-generic/kernel/drivers/gpu/drm/savage/savage.ko /root

[mintlars]

What if you temporarily move that driver out of the way? Maybe the file is munged or something. I feel like I'm kind of guessing at this point.

sudo mv /lib/modules/3.5.0-21-generic/kernel/drivers/gpu/drm/savage/savage.ko /root

Seems like we got a hint there. I moved the savage.ko-file and did update-initramfs -c -v -k 3.5.0-21-generic again. Like before it halted again, but this time at the udl.ko module. After that I reset savage.ko to it's original position and ran the same command again, which again halted at savage.ko. Turns out though that savage.ko is the module that loads after udl.ko, so my interpretation is that it's not savage.ko that is the problem, but the one that is being loaded after that one. I don't know which one it is though. Any clue of how to find out?

[Dutchman]

udl.ko is another graphics driver, for the USB Display-Links graphic adapter. It's also located under '/lib/modules/3.5.0-21-generic/kernel/drivers/gpu/drm/'

I'm starting to wonder if you're '/etc/modprobe.d/blacklist-framebuffer.conf' file is corrupt or missing. I'm not sure if update-initramfs reads the files in /etc/modprobe.d or not when creating an initial ramdisk, but I would think it does so it would know what modules not to load. When I look at (both files in /lib/modules/3.5.0-21-generic) 'modules.dep' and 'modules.alias' these drivers are listed, and so far in searching on my system I can't find anywhere else where the kernel is instructed not to load them.

This is how my 'blacklist-framebuffer.conf' reads - running Kubuntu 12.10 with the 3.5.0-21 kernel:

# Framebuffer drivers are generally buggy and poorly-supported, and cause
# suspend failures, kernel panics and general mayhem.  For this reason we
# never load them automatically.
blacklist aty128fb
blacklist atyfb
blacklist radeonfb
blacklist cirrusfb
blacklist cyber2000fb
blacklist cyblafb
blacklist gx1fb
blacklist hgafb
blacklist i810fb
blacklist intelfb
blacklist kyrofb
blacklist lxfb
blacklist matroxfb_base
blacklist neofb
blacklist nvidiafb
blacklist pm2fb
blacklist rivafb
blacklist s1d13xxxfb
blacklist savagefb
blacklist sisfb
blacklist sstfb
blacklist tdfxfb
blacklist tridentfb
#blacklist vesafb
blacklist vfb
blacklist viafb
blacklist vt8623fb
blacklist udlfb

One of the other guys may know if this is read by update-initramfs, but either way I don't think it would hurt to look and see if it's blacklisted. And if you're interested, you can find the module loading order in '/lib/modules/3.5.0-21-generic/modules.order'

What made me think of the blacklist is when I looked at '/lib/modules/3.5.0-21-generic/initrd/' the only module there is vesafb, which you can see in my blacklist is the only one commented out.

[SteveRiley]

Yeah, I'm not convinced, now, that moving .so files out of the way is a solution, as I don't think that the savage.so file is the root of the problem.

What's the output of

grep . /sys/module/*/initstate

[mintlars]

grep . /sys/module/*/initstate

gives:

/sys/module/aesni_intel/initstate:live
/sys/module/aes_x86_64/initstate:live
/sys/module/asus_wmi/initstate:live
/sys/module/binfmt_misc/initstate:live
/sys/module/bluetooth/initstate:live
/sys/module/bnep/initstate:live
/sys/module/cifs/initstate:live
/sys/module/coretemp/initstate:live
/sys/module/cryptd/initstate:live
/sys/module/des_generic/initstate:live
/sys/module/dm_crypt/initstate:live
/sys/module/drm/initstate:live
/sys/module/drm_kms_helper/initstate:live
/sys/module/e1000e/initstate:live
/sys/module/eeepc_wmi/initstate:live
/sys/module/fscache/initstate:live
/sys/module/ghash_clmulni_intel/initstate:live
/sys/module/hid_generic/initstate:live
/sys/module/hid/initstate:live
/sys/module/hid_logitech_dj/initstate:live
/sys/module/i2c_algo_bit/initstate:live
/sys/module/i915/initstate:coming
/sys/module/joydev/initstate:live
/sys/module/kvm/initstate:live
/sys/module/kvm_intel/initstate:live
/sys/module/lpc_ich/initstate:live
/sys/module/lp/initstate:live
/sys/module/mac_hid/initstate:live
/sys/module/md4/initstate:live
/sys/module/mei/initstate:live
/sys/module/microcode/initstate:live
/sys/module/mxm_wmi/initstate:live
/sys/module/nls_utf8/initstate:live
/sys/module/nvidia/initstate:live
/sys/module/parport/initstate:live
/sys/module/parport_pc/initstate:live
/sys/module/pci_stub/initstate:live
/sys/module/ppdev/initstate:live
/sys/module/psmouse/initstate:live
/sys/module/rfcomm/initstate:live
/sys/module/serio_raw/initstate:live
/sys/module/snd_hda_codec_hdmi/initstate:live
/sys/module/snd_hda_codec/initstate:live
/sys/module/snd_hda_codec_realtek/initstate:live
/sys/module/snd_hda_intel/initstate:live
/sys/module/snd_hwdep/initstate:live
/sys/module/snd/initstate:live
/sys/module/snd_page_alloc/initstate:live
/sys/module/snd_pcm/initstate:live
/sys/module/snd_rawmidi/initstate:live
/sys/module/snd_seq_device/initstate:live
/sys/module/snd_seq/initstate:live
/sys/module/snd_seq_midi_event/initstate:live
/sys/module/snd_seq_midi/initstate:live
/sys/module/snd_timer/initstate:live
/sys/module/snd_usb_audio/initstate:live
/sys/module/snd_usbmidi_lib/initstate:live
/sys/module/soundcore/initstate:live
/sys/module/sparse_keymap/initstate:live
/sys/module/uas/initstate:live
/sys/module/usbhid/initstate:live
/sys/module/vboxdrv/initstate:live
/sys/module/vboxnetadp/initstate:live
/sys/module/vboxnetflt/initstate:live
/sys/module/vboxpci/initstate:live
/sys/module/vesafb/initstate:live
/sys/module/video/initstate:live
/sys/module/wmi/initstate:live

[SteveRiley]

I'm not sure if update-initramfs reads the files in /etc/modprobe.d or not when creating an initial ramdisk, but I would think it does so it would know what modules not to load.

Yes, initramfs-tools does read /etc/modprobe.d. Earlier this evening I added a module to the file /etc/initramfs-tools/modules and created a corresponding .conf file for it in /etc/modprobe.d. After updating my initramfs, I took it apart to see what happened. Sure enough, the .conf was included.

grep . /sys/module/*/initstate

Unforuntately, I have now forgotten why I asked you to run that! My apologies.

But as a next step: take a look at Launchpad bug 982514. Not that the bug necessarily applies to your situation. I'd suggest that you try what that person did: run htop while your initramfs is updating, and note the point where the process halts. Is yours stopping while in "hooks/framebuffer" or at some other point?