kernel panic on boot

[angel6700]

Hello,

a couple of days ago, after an update that included firmware using pacman, my pi does not boot. I get this error after 2 secons of power on:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown block(0,0)

I have checked the partitin and it is ok.
The root parameter in cmdline.txt is pointing to the correct partition.
I can boot with the kernel_emergency.img image without error.

What can be happening?

Thanks.

[spennig]

Same here. The firmware is b0rken. Revert to the previous firmware and it boots just fine.

[angel6700]

Thank you spenning,
but wher can I find the correct version?
In raspberry pi github there is only the last one (from today, but does not work (for me).

regards,

[pepedog]

Older packages can be found in /var/cache/pacman/pkgs
Make sure you pick a linux-raspberrypi and raspberrypi-firmware of similar dates
pacman -U /path/to/package
or on a working other Linux system with card mounted, as root and not as sudo
cd /pathtothe rootfs
tar xf var/cache/pacman/pkgs/rasp<hit-tab-key-twice-here-for-files>
and
tar xf var/cache/pacman/pkgs/linux-rasp<hit-tab-key-twice-here-for-files>
Then you copy files out of boot from that media to root of fat32 partition

It would be helpful to find out which kernel and firmware caused the problems
Always sync before reboot to finish writes

[angel6700]

Thank you,

I will try and post the results later. I recently made a pacman -Rcc... I only hope it was not so recently...

And yes, I always do a sync before reboot.

BTW, why are only me having this problem?, we all have the same hardware. Or can be just the make-model of SD card. Samsung class 10 8GB.

Thanks a lot for your help.

[pepedog]

In one way I'm glad it's just you (or a few), or does this mean arch is unpopular?
I will get kernel and firmware rebuilt

[spennig]

This firmware update contemporaneous with 3.2.27-12-ARCH+ (notably the first 512MB release?) was the only time I've had such a problem. Fortunately, I'd rsync'ed the Pi to a backup machine prior to the update, and the -11 start.elf boots -12 just fine.

@angel6700, you can find a start.elf (the 192/64 split version that will boot 3.2.27-12-ARCH+) at http://www.seyrsnys.myzen.co.uk/rpi/start.elf (md5sum : 95f3b4d4e11f1fd4f48f82a32d3edc93), if you trust random binary blobs from internet strangers.

[spennig]

In summary:

raspberrypi-firmware-20121017-1 : Will not boot 3.2.27-12-ARCH+
raspberrypi-firmware-20121013-1 : Boots (inter alia 3.2.27-12-ARCH+)

raspberrypi-firmware-20121017-1/arm192_start.elf and the upstream firmware (@21:00 2012-10-20, using the upstream rpi-update ( Hexxeh/AndrewS) script) have the same md5sum (and won't boot -12).

[drirr]

I had the same problem, though I can't say anything about the kernel error as I'm running my pi headless.

The follwing upgrade made my rpi (rev 1.0) stop booting:

Code: Select all

[2012-10-18 17:44] upgraded linux-raspberrypi (3.2.27-11 -> 3.2.27-12)
[2012-10-18 17:44] upgraded raspberrypi-firmware (20121013-1 -> 20121017-1)

I tried just changing the split to 224M first to see if that would help as I'm normally running the stripped down 240M split. Seeing how that didn't fix it I just manually downgraded the packages (by untaring the old packages).

[spennig]

Initially, today's updates didn't help me.

Then I removed the now obsolete (as I'm now fully migrated to systemd) init=/bin/systemd left over in cmdline.txt, and it all works again. Solved, for me at least.

[mckorr]

I can boot with the kernel_emergency.img image without error.

Gah, I missed this part of the thread! Already started flashing a fresh image to start from the ground up

[krprescott]

I had the same problem after upgrade, and after verifying my raspbian booted with the new firmware, I started trying removing things from cmdline.txt
If you remove sdhci-bcm2708.cycle_delay=1000 from cmdline.txt this made my system boot normally.
I am not sure what that parameter does, but the new firmware apparently doesn't need it.

[StMichel]

I also had this problem and tried to find out what went wrong for these couple of days. I got new firmware from github and placed it to /boot, but that did not help me. Finding this thread and the following hint got me running again.

Initially, today's updates didn't help me.

Then I removed the now obsolete (as I'm now fully migrated to systemd) init=/bin/systemd left over in cmdline.txt, and it all works again. Solved, for me at least.

Now all is fine. It is however rather interesting that removing the parameter has not been recommended anywhere — or I just have not seen it.

[angel6700]

I had the same problem after upgrade, and after verifying my raspbian booted with the new firmware, I started trying removing things from cmdline.txt
If you remove sdhci-bcm2708.cycle_delay=1000 from cmdline.txt this made my system boot normally.
I am not sure what that parameter does, but the new firmware apparently doesn't need it.

This made the trick for me !!
Thank you.
I think that, as this parameter was included by us, (instructed by pacman). Probably dome people didn't follow it and so, they do not have problems now...
I also removed the init parameter.

Thank you all.

[pepedog]

Ah. Previous version had note to add that upon upgrade, then there was the reversion.

[sdjf]

I will get kernel and firmware rebuilt

Does this mean there will be a completely new v6h image shortly?

[pepedog]

If there was, it wouldn't be because of this. Only need a newer rootfs if there isn't something that can't be over come (like hard float move), difficult to overcome (like glibc upgrade), or quantity of updates. Or by popular request.
I was contemplating making netcfg included to make static wired or wireless easier, in next rootfs

[sdjf]

Thanks Pepedog. Do not count my question as a request for new image - just trying to decide when to download the image and I think I had better wait in case there is a newer one by the time I get my Pi.

[drirr]

Ah. Previous version had note to add that upon upgrade, then there was the reversion.

So the parameter "sdhci-bcm2708.cycle_delay=1000" shouldn't be used anymore? Just upgraded my rev 1.0 with hynix RAM wouldn't boot anymore. Had to mount the sd-card in my PC and get rid of it. The install file for the kernel still tells you to add the parameter.

[pepedog]

Blast, I was looking in the firmware PKGBUILD for this to remove

[davian]

Bump..

I can confirm that after upgrade I can no longer boot my Raspberry in Arch. I've tried editing cmdline.txt and adding and removing the init parameter "sdhci-bcm2708.cycle_delay=1000" with no success. The thing won't boot.

What I did was wipe my sd-card, fetch latest iso. Ran dd to write a new filesystem, after that the system boots. But then I ran pacman -Suy to do an upgrade and then a reboot, after that it doesn't boot anymore.

So something is broken for sure.

[davian]

It seems that raspberrypi-firmware-20121021-1 is the packedge to blame. I've created an issue on Git hub https://github.com/archlinuxarm/PKGBUILDs/issues/289.

Doing # pacman -Suy --ignore raspberrypi-firmware works for now.

[angel6700]

Hello,

I can say that (at least for me), removing these kernel parameters from cmdline.txt, it boots even after the pacman -Syu:
init=/bin/systemd
sdhci-bcm2708.cycle_delay=1000

[pepedog]

@Davian, can you post your cmdline.txt please

[davian]

Sure,

# cat cmdline.txt
sdhci-bcm2708.enable_llm=1 sdhci-bcm2708.sync_after_dma=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 loglevel=2 root=/dev/mmcblk0p2 init=/bin/systemd rootfstype=ext4 rootwait gpu_mem=16