BeagleBone Black doesn't boot with 3.18.0-bone1

Question

BeagleBone Black doesn't boot with 3.18.0-bone1

n-st opened this issue 10 years ago · comments

After installing 3.18.0-bone1 via the install-me script from https://rcn-ee.net/deb/wheezy-armhf/v3.18.0-bone1/, my BeagleBone Black no longer boots successfully.
U-Boot loads the new kernel from the internal MMC storage and runs it, but the kernel gets stuck at "Waiting for root device UUID=9c9c1270-ba24-41c3-abd1-3ce2336cc4dd...".
The only seemingly related issue I've been able to find so far doesn't apply here, since the required kernel options are set in the defconfig for 3.18.0-bone1.
The same problem also occured when I installed one of the 3.17.?-bone? kernels a while ago, but I'm not sure which version that was…
3.16 and earlier version have always worked fine.

Any ideas what might be causing this?
I can also provide a full boot log if that helps.

Robert Nelson · Answer 1 · Mon Dec 15 2014 08:17:15 GMT+0800 (China Standard Time)

Please pastebin.com your full serial bootup..

Nils Steinger · Answer 2 · Mon Dec 15 2014 08:18:25 GMT+0800 (China Standard Time)

Here you go: https://gist.github.com/n-st/99dfdd8ebf3304f8f8d1

I should add that I can list both the FAT partition with the kernel image and the ext3/4 (not sure at the moment) rootfs from U-Boot using fatls mmc 1:1 and ext4ls mmc 1:2.

Robert Nelson · Answer 3 · Mon Dec 15 2014 08:24:12 GMT+0800 (China Standard Time)

Thanks! So it is booting with the initrd...

Using an secondary microSD card, do the uuid's match?

ls -lh /dev/disk/by-uuid/

The uuid used is stored on the boot partition of the uEnv.txt..
Regards,

Nils Steinger · Answer 4 · Mon Dec 15 2014 08:28:28 GMT+0800 (China Standard Time)

I seem to have misplaced my spare SD card at the moment, but I went through this when the system became unbootable after installing the 3.17-bone kernel: A stock image booted from an external SD card was able to find the partitions on the internal MMC storage and the UUID of the rootfs matched the one expected by the kernel.

Nils Steinger · Answer 5 · Mon Dec 15 2014 08:45:04 GMT+0800 (China Standard Time)

Found the SD card, copied and booted this image.

root@beaglebone:~# ls -lh /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 15 Jan 1 2000 06a496b5-e486-40e0-a5f7-396040ea4e56 -> ../../mmcblk0p2
lrwxrwxrwx 1 root root 15 Jan 1 2000 1FB4-35F9 -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 15 Jan 1 2000 7F16-7C8B -> ../../mmcblk1p1
lrwxrwxrwx 1 root root 15 Jan 1 2000 9c9c1270-ba24-41c3-abd1-3ce2336cc4dd -> ../../mmcblk1p2

Nils Steinger · Answer 6 · Mon Dec 15 2014 09:04:50 GMT+0800 (China Standard Time)

Next test: Copied the contents of the internal MMC to the external SD card (bit-wise, with a few intermediate steps since it probably wouldn't be safe to overwrite the rootfs of a running system).
The BeagleBone boots from the SD card ("mmc0 is current device") and ends up hanging at the same "Waiting for root device" error.

Nils Steinger · Answer 7 · Mon Dec 15 2014 09:25:52 GMT+0800 (China Standard Time)

Next test: Using the stock image from before, flashed the SD card again and installed 3.18.0-bone1 there (after running out of space on the first attempt and resizing the 1.8 GB root partition).

The system boots flawlessly:

debian@beaglebone:~$ uname -r
3.18.0-bone1

That most likely means that this isn't a kernel bug after all and that I've just screwed up my system in some obscure way that only clashes with kernels v3.17 onwards, right?

In hindsight, that's really the very first test I should have run…

Another observation: The stock image with the 3.18 kernel actually powers off the BeagleBone after a regular shutdown command — something which never worked for me since I started using your kernel builds…
It does however cause a kernel panic in the process: https://gist.github.com/n-st/912e7ef5a7c804467653