versatile: Can't boot initramfses

Bug Description

Hi

On versatile, I can't boot initramfses:
[ 1.838592] Trying to unpack rootfs image as initramfs...
[ 1.846490] rootfs image is not initramfs (junk in compressed archive); looks like an initrd
[...]
[ 5.245581] RAMDISK: Couldn't find valid RAM disk image starting at 0.
[...]
[ 5.271581] No filesystem could mount root, tried: ext3 ext2 ext4 fuseblk

There are two distinct problems:
- for an unknown reason, the initramfs code can't open the initramfs; this is under qemu, so perhaps a qemu bug?
- the initrd code can't open the initramfs either because CONFIG_CRAMFS=m and not =y

Also, the RAMDISK_SIZE is a bit small for our initrds which are 11 MBs unpacked or so.

I'd appreciate some help in figuring out the first issue, but in any case we should set the other two configs.

Thanks,

BTW you can override RAMDISK_SIZE on the kernel cmdline wiht ramdisk_size=16384 for instance; but you would get a different error message if that was the issue.

Since this works on other platforms such as imx51, I suspect it's a qemu bug; I've sent a patch to the ubuntu kernel-team list to set CONFIG_CRAMFS=y and bump the default ramdisk size to 64 MB as on the other platforms as a workaround for now.

@Bryan: I hope you can help me debug the qemu loader issue; I'm not familiar with the contents of initrd versus initramfs, so I don't understand the failure.

The initramfs image is an optionally gzipped cpio archive (which must have been built with cpio --format=newc in order for the kernel to recognise it --- note this is not the default behaviour for cpio). The filesystem is unpacked into a ramfs or similar, so there is no special size restriction. The first user process to run in the initramfs is usally /init I believe.

[ 1.846490] rootfs image is not initramfs (junk in compressed archive); looks like an initrd

The kernel always falls back to assuming initrd if the ramdisk image doesn't look like a cpio archive (which is just a whole filesystem image which is dumped into a ramdisk block device, which must be big enough, and mounted).

If the initramfs image was built by hand, it might have been built wrongly; otherwise I guess there may be a kernel or qemu problem, or the image is truncated etc.

@Dave: Ack, I understand the same as you do so far. The initramfs is the output of building the "debian-installer" packages, and it allows setting in which format you want that file; I've put "initramfs" explicitly and checked the code which does call cpio -H newc back then, so I confirm that it's created correctly.

I've submitted a patch to add CONFIG_CRAMFS=y to make use of the fallback you mention (initrd in ramdisk block device) while we figure out what's wrong with initramfs.

I agree with you it's either a kernel or qemu bug, but given that I saw initramfs unpacking work on real imx51 boards' dmesgs (in other bug reports), I tend to believe it's a qemu issue, but I don't know enought of the format to look into it.

Thanks,

This bug was fixed in the package linux - 2.6.32-15.21

---------------
linux (2.6.32-15.21) lucid; urgency=low

[ Andy Whitcroft ]

* Revert "(pre-stable) drm/i915: Increase fb alignment to 64k"
* Revert "[Config] lenovo-sl-laptop -- enable"
* Revert "ubuntu: lenovo-sl-laptop -- git tip (b19a08f81f)"
* armel -- cramfs module will no longer be built
* d-i -- make all modules optional
* rename the debug packages to match archive standard
- LP: #527837
* lenovo-sl-laptop is no longer built

[ Colin Ian King ]

* Disable 4MB page tables for Atom, work around errata AAE44
- LP: #523112

[ Colin Watson ]

* ubuntu: dm-raid4-5: Depend on XOR_BLOCKS
* ubuntu: fsam7400: Depend on CHECK_SIGNATURE

[ Jesse Barnes ]

* SAUCE: drm/i915: don't change DRM configuration when releasing load
detect pipe
- LP: #488328

[ Loïc Minier ]

* [Config] armel Update versatile initrd configs
- LP: #524893
* SAUCE: [um] Don't use nx_enabled under UML
- LP: #524849

[ Manoj Iyer ]

* [Config] added new config option CONFIG_SR_REPORT_TIME_LIMIT

[ Mario Limonciello ]

* SAUCE: v3 - Add Dell Business Class Netbook LED driver

[ Rafael J. Wysocki ]

* SAUCE: PM report driver and device suspend/resume times.

[ Surbhi Palande ]

* Revert "[Upstream] e1000e: enhance frame fragment detection"
- CVE-2009-4538
* Revert "[Upstream] e1000: enhance frame fragment detection"
- CVE-2009-4536

[ Tim Gardner ]

* [Config] Enabled CONFIG_LEDS_DELL_NETBOOKS=m
* SAUCE: (pre-stable) netfilter: xt_recent: fix buffer overflow
* SAUCE: (pre-stable) netfilter: xt_recent: fix false match

[ Upstream Kernel Changes ]

* Revert "(pre-stable) eCryptfs: Add getattr function"
* Fix potential crash with sys_move_pages
* futex_lock_pi() key refcnt fix
* futex: Handle user space corruption gracefully
* futex: Handle futex value corruption gracefully
* Fix race in tty_fasync() properly
* hwmon: (w83781d) Request I/O ports individually for probing
* hwmon: (lm78) Request I/O ports individually for probing
* hwmon: (adt7462) Wrong ADT7462_VOLT_COUNT
* ALSA: ctxfi - fix PTP address initialization
* drm/i915: disable hotplug detect before Ironlake CRT detect
* drm/i915: enable self-refresh on 965
* drm/i915: Disable SR when more than one pipe is enabled
* drm/i915: Fix DDC on some systems by clearing BIOS GMBUS setup.
* drm/i915: Add HP nx9020/SamsungSX20S to ACPI LID quirk list
* drm/i915: Fix the incorrect DMI string for Samsung SX20S laptop
* drm/i915: Add MALATA PC-81005 to ACPI LID quirk list
* usb: r8a66597-hcd: Flush the D-cache for the pipe-in transfer buffers.
* i2c-tiny-usb: Fix on big-endian systems
* drm/i915: handle FBC and self-refresh better
* drm/i915: Increase fb alignment to 64k
* drm/i915: Update write_domains on active list after flush.
* regulator: Fix display of null constraints for regulators
* ALSA: hda-intel: Avoid divide by zero crash
* CPUFREQ: Fix use after free of struct powernow_k8_data
* freeze_bdev: don't deactivate successfully frozen MS_RDONLY sb
* cciss: Make cciss_seq_show handle holes in the h->drv[] array
* ioat: fix in...

Loic-

I'm a bit unclear on how to reproduce this bug. If you're looking for me to assist with it, please provide a bit more information on how I might reproduce it. If, instead, this is your own stream of conscious notes and you're working on it, then that's fine too (I often use LP in that way ;-).

@Dustin: I'd love if you could assist on this bug; to reproduce, boot:
http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/

with qemu-system-arm -M versatilepb -cpu cortex-a8 -m 256 -kernel vmlinuz -initrd initrd.gz

what you will probably see is:
[ 1.866499] Trying to unpack rootfs image as initramfs...
[ 1.875076] rootfs image is not initramfs (junk in compressed archive); looks like an initrd
[...]
[ 5.347930] RAMDISK: Couldn't find valid RAM disk image starting at 0.

which means that the initramfs support doesn't work. (I also tried with a gunzipped initrd to no luck)

We want initramfs support as on the other plaforms, but that doesn't work for an unknown reason; apparently this work on real hardware, so likely specific to the qemu ARM loader.

NB: the latest linux upload has CONFIG_CRAMFS=y on armel, so the RAMDISK is likely to become mountable as an initrd; that's not what we want, but it's a good workaround for now...

Reopening the bug since:
- the patch was just a workaround to support the RAMDISK method, but doesn't fix initramfs support
- it actually doesn't work even with the patch :-(

qemu-system-arm -m 256 -drive file=lucid.img,media=disk -M versatilepb -cpu cortex-a8 -kernel linux-image-2.6.32-16-versatile_2.6.32-16.24/boot/vmlinuz-2.6.32-16-versatile -initrd initrd.gz -append 'rootdelay=20 root=/dev/ram0 console=ttyAMA0,115200' -nographic
[...]
[ 1.752156] type=2000 audit(0.495:1): initialized
[ 1.817340] Trying to unpack rootfs image as initramfs...
[ 1.824094] rootfs image is not initramfs (junk in compressed archive); looks like an initrd
[ 1.876329] Freeing initrd memory: 3640K
[...]
[ 25.265275] md: ... autorun DONE.
[ 25.270878] RAMDISK: Couldn't find valid RAM disk image starting at 0.
[ 25.291694] List of all partitions:
[ 25.292090] 0b00 1048575 sr0 driver: sr
[ 25.292315] 0800 1331200 sda driver: sd
[ 25.292514] No filesystem could mount root, tried: ext3 ext2 ext4 cramfs fuseblk
[ 25.292991] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
[...]

It might be that our vmlinuz is so big that it clobbers the initramfs space on unpack; I can't load vmlinux though (bug #534324) so can't easily confirm.

I'm afraid I need help from kernel folks to understand why initramfses and initrds don't work in qemu-system-arm with our linux/versatile kernels.

A qemu bug seems possible, but unlikely. I have other kernels and initrd gzipped cpio archivies that are very similar and run fine with qemu versatile. The only difference here is the cpu is cortex-a8 but this doesn't seem related to initrd processing.

I also took the initrd.gz and extracted it with gunzip and cpio and took the filesystem data and put the same data into an ext4 filesystem as described by https://wiki.ubuntu.com/ARM/RootfsFromScratch/QemuDebootstrap
then I could boot the kernel and filesystem just fine using:

qemu-system-arm -M versatilepb -cpu cortex-a8 -m 256 -kernel vmlinuz -hda rootfs.img -nographic -append "rootwait root=/dev/sda console=ttyAMA0,115200 init=/bin/sh rw"

Since this boots fine there is nothing wrong with the filsystem information itself.

qemu loader and ramdisk size don't seem related. The initrd is loaded by qemu after the kernel at 0x800000 so if there is any corruption the initrd file would overwrite the kernel, not the other way around.
The kernel size is only 0x2ca574

I think the next step is to look at the kernel configuration, I couldn't extract it using extract-ikconfig

What's the best way to get the kernel configuration?

Oh well, first guess was wrong. The kernel config is fine. The problem is with qemu. The kernel became too big for qemu.

Edit the qemu file source file hw/arm_boot.c

Change this define to something bigger:
-#define INITRD_LOAD_ADDR 0x00800000
+#define INITRD_LOAD_ADDR 0x00a00000

Rebuild qemu and the boot is fine.

This bug was fixed in the package qemu-kvm - 0.12.3-0ubuntu17

---------------
qemu-kvm (0.12.3-0ubuntu17) lucid; urgency=low

* qemu-debootstrap: test for basename part of 0ドル to enable build-arm-chroot
compat mode.
* New patch, arm-higher-initrd-load-addr, set INITRD_LOAD_ADDR to 0x00d00000
instead of 0x00800000 as to leave enough room for our piggish vmlinuz +
its decompressed counterpart; should fix initramfs and initrd support;
thanks Jason Andrews; LP: #524893.
-- Loic Minier <email address hidden> 2010年3月20日 10:30:21 +0100

This bug was fixed in the package linux - 2.6.32-18.27

---------------
linux (2.6.32-18.27) lucid; urgency=low

[ Chase Douglas ]

* SAUCE: Don't register vga16fb framebuffer if other framebuffers are
present
- LP: #527369

[ Loïc Minier ]

* [Config] armel/versatile: Set CRAMFS=m
- LP: #524893
* [Config] armel: Reset default command-line
- LP: #524893

[ Stefan Bader ]

* build/modules: Update d-i to reflect recent config changes
- LP: #546929

[ Upstream Kernel Changes ]

* (pre-stable) drm/nouveau: report unknown connector state if lid closed
- LP: #523072
* (pre-stable) Staging: rt2870: Add USB ID for Buffalo Airstation
WLI-UC-GN
- LP: #441990
* (pre-stable) iwlwifi: fix nfreed--
- LP: #545585
* (pre-stable) pata_via: Add VIA VX900 support
- LP: #548675
-- Stefan Bader <email address hidden> 2010年3月26日 18:39:42 +0100

So the QEMU patch is the relevant one here; the kernel changes were just attempts at fixing this bug which failed.

It would be nice if we could send this upstream, but I guess it needs testing / checking with other flavors than versatile.

Also, ideally, QEMU should compute the address instead of hardcoding it.