[SOLVED] mkinitcpio error during kernel 2.6.37-6 package upgrade

archix · 2011-02-21 00:06:24

After upgrading to kernel26-2.6.37-6-x86_64, I failed after reboot (couldn't mount root and got dropped to the "you're on your own" prompt). Fortunately, the fallback kernel worked. I didn't look into it at the time (it was late), and I noticed a new kernel package the next day, so I updated again thinking maybe it was a bug that got fixed. Nope. Same problem after reboot, but I paid a little more attention this time and saw the errors below:

sudo pacman -U kernel26-2.6.37.1-1-x86_64.pkg.tar.xz
...snip...
checking package integrity...
(1/1) checking for file conflicts                  [######################] 100%
(1/1) upgrading kernel26                           [######################] 100%
>>> Updating module dependencies. Please wait ...
...snip...
==> Running command: /sbin/mkinitcpio -k 2.6.37-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img
:: Begin build
:: Parsing hook [base]
...snip...
:: Generating module dependencies
WARNING: Can't read module /tmp/mkinitcpio.WLY5Kx/lib/modules/2.6.37-ARCH/kernel/drivers/ata/pata_acpi.ko.gz: Exec format error
WARNING: Can't read module /tmp/mkinitcpio.WLY5Kx/lib/modules/2.6.37-ARCH/kernel/lib/libcrc32c.ko.gz: Exec format error
WARNING: Can't read module /tmp/mkinitcpio.WLY5Kx/lib/modules/2.6.37-ARCH/kernel/crypto/crc32c.ko.gz: Exec format error
WARNING: Can't read module /tmp/mkinitcpio.WLY5Kx/lib/modules/2.6.37-ARCH/kernel/arch/x86/crypto/crc32c-intel.ko.gz: Exec format error
:: Generating image '/boot/kernel26.img'...SUCCESS
==> SUCCESS

Since my root partition is btrfs, I require the libcrc32c module on load, and it looks like mkinitcpio couldn't manage to get it (and a few other modules) into my initrd. So I ran:

sudo /sbin/mkinitcpio -k 2.6.37-ARCH -c /etc/mkinitcpio.conf -g /boot/kernel26.img

again by hand, and it worked without errors. (Yeah, I'm a sudo person, in case you were wondering.)

Here are the relevant /etc/mkinitcpio.conf lines:

MODULES="dm_mod dm_mirror btrfs crc32c libcrc32c"
HOOKS="base udev autodetect pata scsi sata dmraid lvm2 filesystems"

I don't know squat about mkinitcpio and why it would work fine when run by hand but choke when run via pacman. Anyone have any ideas?

Last edited by archix (2011-02-21 18:35:46)

dedanna1029 · 2011-02-21 01:29:33

content removed by poster

Last edited by dedanna1029 (2011-02-21 01:46:52)

Vi0L0 · 2011-02-21 01:44:17

Read my post: coreutils 8.10 = fail on compressed btrfs @ x86_64
or just downgrade coreutils to 8.9 version

upstream bug report is here: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8001
looks like we would have to wait some time for a fix...

Last edited by Vi0L0 (2011-02-21 01:46:46)

archix · 2011-02-21 18:34:10

Vi0L0,

Clearly, we're hitting the same problem. Thanks for the links!

I'm a little concerned about btrfs w/compress now, but hey, I knew it was all 'experimental' when I began using it back on kernel 2.6.30. I'll try taking the -o compress off my mount and see if it helps. I wonder what else on my filesystem is silently suffering from failed copy w/compress enabled.

Vi0L0 · 2011-02-21 19:07:30

archix wrote:

I'm a little concerned about btrfs w/compress now, but hey, I knew it was all 'experimental' when I began using it back on kernel 2.6.30.

Well yes, but compress is a great option, with it btrfs is really much faster on my system - so i decided to downgrade coreutils instead of turning compression off.
Also compress is still in developement and ie in 2.6.38 kernel we can use new LZO compression - and that's another reason for me to believe that both kernel and coreutils devs won't leave this little although noisy bug unfixed for a long time.

archix · 2011-02-21 19:21:04

I removed -o compress, and things are working fine now. I agree that compress is a good option; I initially reformatted with btrfs because I figured that my CPU could gzip compress/decompress at a higher MB/sec rate than my disks could move the larger amounts of uncompressed data - but frankly I didn't run any benchmarks to make sure.

This is a fairly serious bug, even considering the experimental status of btrfs, since data corruption is about the worst kind of problem a filesystem can have. I think they'll get a fix in place for this in a reasonably short period of time. I'll have to monitor the two bug reports you mentioned and keep an eye out for an upstream fix that makes its way into Arch.

When I first installed btrfs, I fully expected to occasionally lose my whole FS due to some bug or another, but I have been quite impressed by how stable it has been - even given its experimental status - and I've grown accustomed to it working just fine day in and day out. I'll stick with it for now - but with compress off.

Thanks again for the info.

Vi0L0 · 2011-02-25 16:00:16

According to Ryan Hill's comment on http://bugs.gentoo.org/show_bug.cgi?id=353907#c16 which is sending us to http://lwn.net/Articles/429345/ - it looks like ext4 is also impacted by this bug, not only compressed btrfs!

Chris Mason from Oracle (funny, "magical" coincidence ;P ) said he's got a patch for btrfs and hes testing it. Hope to see it soon...
Edit: ahhh here it is http://www.mail-archive.com/linux-btrfs … 08577.html
Edit2: patches were merged with today's (26.02.2011) mainline kernel snapshot: 2.6.38-rc6-git6
it seems to work fine for me, so i guess it's [SOLVED] now

Last edited by Vi0L0 (2011-02-26 15:51:46)

Arch Linux

#1 2011-02-21 00:06:24

[SOLVED] mkinitcpio error during kernel 2.6.37-6 package upgrade

#2 2011-02-21 01:29:33

Re: [SOLVED] mkinitcpio error during kernel 2.6.37-6 package upgrade

#3 2011-02-21 01:44:17

Re: [SOLVED] mkinitcpio error during kernel 2.6.37-6 package upgrade

#4 2011-02-21 18:34:10

Re: [SOLVED] mkinitcpio error during kernel 2.6.37-6 package upgrade

#5 2011-02-21 19:07:30

Re: [SOLVED] mkinitcpio error during kernel 2.6.37-6 package upgrade

#6 2011-02-21 19:21:04

Re: [SOLVED] mkinitcpio error during kernel 2.6.37-6 package upgrade

#7 2011-02-25 16:00:16

Re: [SOLVED] mkinitcpio error during kernel 2.6.37-6 package upgrade

Board footer