Subject says it all. Usually run headless, but on connection a monitor the kernel panics failing to find init. Mounted partition on a x86_64 box and the file system mounts fine and init is in /sbin as usual.

What happened to cause the kernel panic has scrolled off the top of the screen but the last line of the message is 'end kernel panic - not syncing: No working init found. ...'

I assume there is some issue with the boot process such that the root partition is not mounting.

Two question:
1. any easy fixes rather than starting over?
2. Was it my approach to updating that broke it?

I note that a post at https://www.linuxquestions.org/quest...2/#post6036376

Suggests I update by downloading packages from the SARPI site, does that just do core stuff and should I blacklist anything for slackpkg?

Did you follow instructions here Slackware ARM on a Raspberry Pi? "Install Slackware"

through step "• 10. Configuring the boot partition"?

Once you get the system up and running, you can do the steps mentioned in the link you posted.

Are you running Slackware ARM 14.2 or -current? Which version of 'slackpkg' are you using? Did you by any chance install/upgrade all available packages with 'slackpkg upgrade-all' or 'slackpkg install-new'? Including kernel, kernel-modules, kernel-headers, and kernel-source, etc.

I only install the kernel-headers pkg using 'slackpkg' and omit the rest. As pristine as they are, in the way that MoZes creates them, the official Slackware ARM kernels are not built to support the Raspberry Pi - this is why SARPi builds their own using the Raspberry Pi GitHub repository source.

Answers:
1. Yes, as you have already read about it, installing the SARPi kernel/modules/firmware system pkgs should fix this problem. The SARPi hacks pkg is optional, as always.
2. Without knowing which steps were taken, what was installed exactly (and overwritten), it's hard to say.
3. The SARPi system pkgs install the kernel, kernel modules, and boot-firmware required to boot the device and run Slackware ARM OS. The SARPi hacks pkg modifies '/etc/ssh/sshd_config' so that root can login remotely (e.g. for headless installation); adds RPi3/4 wireless firmware not present in official Slackware ARM source tree, and modifies '/etc/inittab' to prevent the 'INIT: Id "s0" respawning too fast' error (i.e. setting '/dev/ttyS0' serial port list entry to '/dev/ttyAMA0').
4. If installing the SARPi system pkgs solves your problem then you might want to think about adding the kernel, kernel-modules and kernel-firmware pkgs to your 'slackpkg' blacklist on the RPi3.

1 members found this post helpful.

I am sure I ran through this on my original install. It was working for several months. I'll have to mount the SD card on an x86_64 machine and do this part and see if it fixes things.

Current, slack version is showing 14.2+.

Draft, forgot to blacklist those. Now done.

I'm definitely a noob on the Pi with slackware. Been running it on x86 since 3.4 and it felt familiar on the Pi, but I was really back into the basic learning curve for this fundamental stuff on the Pi. Thank you.


I'll try installing again from x86_64 machine and see if it fixes it. Otherwise I could just backup the useful stuff and reinstall - but I'd rather try the fix route first, it seems better. Thanks.

Still failing to boot, still missing init.

Is it best to backup, do a fresh install and then recover the important bits?

None of this is critical for anything.

On another Slackware ARM installation, I would try something like this:

If that doesn't solve the problem then perhaps a backup and reinstall, as you've suggested, is the way to go. Other elements of the Slackware ARM OS may be borked too, depending on what has been previously installed/over-written/corrupted during the process.

[EDIT] Forgot to mention, I would also check that the root device entry in the 'cmdline.txt' file in the /boot partition points to the correct device/partition before installing any pkgs. Just in case the wrong settings are taking effect, thus causing '/sbin/init' not to be found.

1 members found this post helpful.

It is my single Slackware ARM system. I appreciate that most of the guys here likely end up with five per room after a while...

Any reason why it needs to be an ARM system? Surely installpkg, and its underlying dependencies are system agnostic? OR is this something to do with big and little endian?


Ah ha. When I tried this on x86_64 I did not mount boot. Tried it again with boot mounted... Still did not work.

cmdline.txt:
dwc_otg.lpm_enable=0 console=tty1 nofont root=/dev/mmcblk0p3 rootfstype=ext4 rootwait ro

Not familiar with RPi drive numbering. Looks like the third partition of whatever mmcblk0 is.

Sounds like I'll be going down the reinstall route.

I have one Slackware64 system available. I have several [dozen] Slackware ARM systems/images/installs available. I don't mess with the Slackware64 system much, once it's running it stays that way.

I can't say if installing Slackware ARM packages onto a Slackware ARM OS but doing it under Slackware x86 is OK - as I've never tried it. However, I can imagine if any of those packages are installed wrongly there could be serious consequences for the host OS as it runs on a different architecture.

'/dev/mmcblk0' is your sd card device name. Just like '/dev/sda' or '/dev/sdb' [etc.] is for your HDD/SSD/USB storage devices. '/dev/mmcblk0p1', '/dev/mmcblk0p2', '/dev/mmcblk0p3' [etc.] are partitions on that sd card device.

Yes, it would seem that something, somewhere, is royally screwed on your Slackware ARM installation. If your / partition is '/dev/mmcblk0p3' then you would need to do some more investigating into why '/sbin/init' couldn't be found. If it's easier just reinstall, as you say.

54 packages have post installation scripts that chroot into the OS to complete the setup. These will fail when run on a different architecture, so the package installation may be incomplete or broken in some way.

For example:
There are many more but none of would cause the OS not to boot though, so you could fix a system by installing the packages on an x86 then fix it by hand, or just reinstall the packages again once the ARM OS has booted.

1 members found this post helpful.

If you can't page up (shift+page-up) to view the kernel messages, attach a serial cable to it, open a serial connection from the x86 to it and log the terminal output.
Perhaps your root= parameter has changed, so init cannot be found? Or it could be that the initrd doesn't have the required modules, a mismatch between kernel and initrd.

That'll be why then.