1

Back story:

Since this might be a XY type of problem I'll briefly describe my original issue.

I have a RPi 4, connected to my router via ethernet. I don't have a monitor and a keyboard so I can only access it through SSH. I wanted to set the Pi up as a wireless access point for my network so I followed this guide https://www.raspberrypi.org/documentation/configuration/wireless/access-point-bridged.md

After the last reboot, I can no longer access it through SSH (and the access point doesn't work either but that doesn't matter for now). It doesn't show up as a connected device on my router either.

Normally this wouldn't be a problem. I'd just plug the SD card into my computer and change the relevant configuration files to reset what I did, but I'm running Windows and I can't open the ext4 partition.

I have tried other methods including installing Linux in a VM and trying to mound the SD card but I wasn't successful so now I have a different idea.

The question:

Since the boot partition is FAT32, I can open it just fine on my PC so I'm thinking there must be a way to write a command somewhere that would run on boot. I could write a script to modify the configuration files on the ext4 partition to regain SSH access. Is there a way to do this?

1
  • PC/Computer is hardware, whats interesting is what OS do you have on the machine? – Mats Karlsson Nov 1 '20 at 15:00
1

If your computer has a Windows OS, then you can install one of these:

1

Since the boot partition is FAT32, I can open it just fine on my PC so I'm thinking there must be a way to write a command somewhere that would run on boot. I could write a script to modify the configuration files on the ext4 partition to regain SSH access. Is there a way to do this?

The ideal way to do this would be to create a boot service that checks for a script on the boot partition and runs it if it exists.

Obviously hindsight is not much good in this context, but here's an approach that I believe should work -- this is from https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html to introduce the premise:

The kernel parses parameters from the kernel command line up to “--“; if it doesn’t recognize a parameter and it doesn’t contain a ‘.’, the parameter gets passed to init: parameters with ‘=’ go into init’s environment, others are passed as command line arguments to init. Everything after “--” is passed as an argument to init.

"Init" is the only process ever started by the kernel; normally it is systemd, and all other processes derive from that. However, it can be anything, and a common trick used to rescue a borked system is to try booting only a shell: init=/bin/bash.

So, edit /boot/cmdline.txt and change init=____ to init=/bin/bash. This file must remain all one line. To the end of that line, add:

-- -c /boot/myscript.sh

Space both sides of --. This will execute that script. You should set the path at the beginning of it:

export PATH=/bin:/sbin:/usr/bin:/usr/sbin

To have access to normal commands without having to provide a path for all of them. You can either also have it return everything to normal or else just do that yourself afterward. And log output to a file on the boot partition so you can check if it worked. Also at the top:

exec &> /boot/myscript.log

Will redirect output, so you can just use echo in the body.

You can't (and don't need to) use reboot or shutdown. The system will just go idle once the script has exited. This probably won't take more than a few seconds in total since most of the boot time is actually normal (systemd) init setting stuff up.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.