Package: kmod Version: 6-1 Severity: important
I build custom kernels and use them primarily, but I always keep a
Debian kernel installed in case I do something stupid and my custom
kernel ends up unusable.
When kmod-6-1 became available on Sid, I installed it. There was no
reason to reboot at that time, but soon after I decided to test the
kernel update from linux-image-3.2.0-1-amd64 (upstream stable 3.2.7) to
linux-image-3.2.0-2-amd64 (upstream stable 3.2.9). At this point, I had
3 linux-image packages installed,
linux-image-3.2.0-1-amd64
linux-image-3.2.0-2-amd64
linux-image-3.2.9-3+dwlocal1
the latter being my latest custom kernel. I did a reboot to test
3.2.0-2, and was amazed to find that it would not complete the boot
process: I was dropped to the busybox prompt, and was able to scroll
back through the boot messages to find
ALERT: /dev/sda1 does not exist. Dropping to a shell!
Assuming the problem was limited to this newest Debian kernel, I decided
to reboot and prove to myself that the older Debian kernel was still
working. It didn't.
Now in panic mode, I rebooted again to try my custom kernel. It was
fine. I concluded that something else had been installed that was
causing Debian kernels to fail, leaving my own custom kernels
untouched. After a quick look at /var/log/aptitude, I noticed the
recent upgrade of kmod, from 5-2 to 6-1.
I have had enough experience with Sid that I learned to keep old
versions of important packages around; I sometimes clear out
/var/cache/apt/archives, so I regularly copy packages to a backup
directory. So I immediately backed up the 5-2 versions of 'kmod',
'libkmod2', and 'module-init-tools', and then downgraded them all back
to 5-2. Afterwards, I also ran
update-initramfs -k all -u
and then tried rebooting. Both Debian kernels now worked, and my custom
kernel was also still working.
Now, I have some customizations in place regarding GRUB2. Particularly
I have uncommented a line in /etc/default/grub:
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to
Linux
GRUB_DISABLE_LINUX_UUID=true
I do this because my custom kernels do not use an initrd, and attempting
to use the UUID magic for the root device will prevent them from
booting. I suspected that this GRUB option might be causing the
problem, until I listed the contents of a version of an initrd built
with kmod-5-2 installed and one built using version 6-1. I have
attached those two listings (listings.tar.gz), but the diff alone is
most revealing:
$ diff list-initrd.img-3.2.0-2-amd64+kmod-5-2.txt
list-initrd.img-3.2.0-2-amd64+kmod-6-1.txt
60,68d59
< lib/firmware/rtl_nic
< lib/firmware/rtl_nic/rtl8168e-1.fw
< lib/firmware/rtl_nic/rtl8168f-2.fw
< lib/firmware/rtl_nic/rtl8168d-1.fw
< lib/firmware/rtl_nic/rtl8168d-2.fw
< lib/firmware/rtl_nic/rtl8168e-3.fw
< lib/firmware/rtl_nic/rtl8168f-1.fw
< lib/firmware/rtl_nic/rtl8168e-2.fw
< lib/firmware/rtl_nic/rtl8105e-1.fw
146,147d136
< lib/modules/3.2.0-2-amd64/kernel/fs/nfs
< lib/modules/3.2.0-2-amd64/kernel/fs/nfs/nfs.ko
173,174d161
< lib/modules/3.2.0-2-amd64/kernel/fs/lockd
< lib/modules/3.2.0-2-amd64/kernel/fs/lockd/lockd.ko
178,181d164
< lib/modules/3.2.0-2-amd64/kernel/net/sunrpc
< lib/modules/3.2.0-2-amd64/kernel/net/sunrpc/auth_gss
< lib/modules/3.2.0-2-amd64/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko
< lib/modules/3.2.0-2-amd64/kernel/net/sunrpc/sunrpc.ko
204d186
< lib/modules/3.2.0-2-amd64/kernel/drivers/block/loop.ko
241d222
< lib/modules/3.2.0-2-amd64/kernel/drivers/ata/libata.ko
256d236
< lib/modules/3.2.0-2-amd64/kernel/drivers/ata/pata_atiixp.ko
272d251
< lib/modules/3.2.0-2-amd64/kernel/drivers/ata/ahci.ko
278,279d256
< lib/modules/3.2.0-2-amd64/kernel/drivers/ata/libahci.ko
< lib/modules/3.2.0-2-amd64/kernel/drivers/ata/pata_jmicron.ko
292d268
< lib/modules/3.2.0-2-amd64/kernel/drivers/usb/host/ehci-hcd.ko
301d276
< lib/modules/3.2.0-2-amd64/kernel/drivers/usb/storage/usb-storage.ko
309,310d283
< lib/modules/3.2.0-2-amd64/kernel/drivers/usb/core
< lib/modules/3.2.0-2-amd64/kernel/drivers/usb/core/usbcore.ko
318,319d290
< lib/modules/3.2.0-2-amd64/kernel/drivers/i2c/algos
< lib/modules/3.2.0-2-amd64/kernel/drivers/i2c/algos/i2c-algo-bit.ko
329,332d299
< lib/modules/3.2.0-2-amd64/kernel/drivers/hid/usbhid
< lib/modules/3.2.0-2-amd64/kernel/drivers/hid/usbhid/usbhid.ko
< lib/modules/3.2.0-2-amd64/kernel/drivers/hid/hid.ko
< lib/modules/3.2.0-2-amd64/kernel/drivers/hid/hid-apple.ko
365d331
< lib/modules/3.2.0-2-amd64/kernel/drivers/scsi/sr_mod.ko
451d416
< lib/modules/3.2.0-2-amd64/kernel/drivers/scsi/scsi_mod.ko
623d587
< lib/modules/3.2.0-2-amd64/kernel/drivers/net/ethernet/realtek/r8169.ko
689d652
< lib/modules/3.2.0-2-amd64/kernel/drivers/firewire/firewire-ohci.ko
691d653
< lib/modules/3.2.0-2-amd64/kernel/drivers/acpi/thermal.ko
All of the changes reveal that modules were no longer being added to the
initrd with 6-1 installed. Having painstaking crafted my own '.config'
file for my custom kernel, I can tell you that most of these changes
involved options I have built into my custom kernel directly. In short,
these modules do not exist in /lib/modules for my custom kernel because
they are built-in.
Previous versions of 'kmod' did The Right Thing: they caused
'update-initramfs' to include the modules which would be needed by a
Debian kernel into its corresponding initrd. The current version is no
longer doing that. I no longer believe that my local modifications in
/etc/kernel/ and /etc/default/grub are responsible, since kmod-5-2 works
while kmod-6-1 fails with the same settings in /etc.
(No change in behavior was observed when upgrading initramfs-tools from
0.100 to 0.101: only changing the version of 'kmod' causes a change in
system behavior.)
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (990, 'unstable'), (350, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.9-3+dwlocal1 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
listings.tar.gz
Description: GNU Zip compressed data
