Pmbootstrap: Provide a method to wait in the initramfs

Created on 8 Nov 2017  路  10Comments  路  Source: postmarketOS/pmbootstrap

From reading the chatlog, that would have been useful for ayr3s, because the booting process got stuck after killing the usb-shell telnet daemon and before starting sshd.

Idea: In the usb-shell hook, check for a new kernel parameter, and if it is present, simply wait forever (or drop to a shell?).

What do you think?

enhancement initramfs

Most helpful comment

I guess sh exits immediately, when there is no TTY attached (i.e. no user input is possible). After some research, it should be possible to test it like the following (not verified that this works):

if tty -s; then
    echo "Exit the shell to continue booting:"
    sh
else
    echo "No shell attached, looping forever."
    loop_forever
fi

The idea was to modify the behavior of the actual usb-shell hook and add a wait there, what you think?

馃憤

All 10 comments

Dropping to shell would be good for devices with a keyboard, and it would also make it very clear that the device isn't going to be progressing any further in the boot. I wonder if we could make it like systemd's console thing where we can continue booting normally if we then exit the shell?

Good idea! That would be as easy as:

echo "Exit the shell to continue booting:"
sh

馃槂

I would prefer a dedicated hook, because for isorec style devices the only way to change the kernel parameters is to rebuild the kernel (no boot.img).
The information about the device with keyboard is already in the deviceinfo, so should be easy to distinguish and drop to a shell for those

Good point with isorec, the extra hook makes more sense then.

About the keyboard, it is also possible to use a shell via serial port, so I recommend that we always open the shell when the hook is installed.

Way to connect to the device when only initramfs is working would be quite nice. What about using "volume up" key to keep the telnet active? Most devices have that one....

That would require that we can properly detect the button press and know which button is the volume up button. Wouldn't it be easier if it was always enabled with a hook? After all, it is for debugging the initramfs when other stuff is already failing.

I got stuck on this, I tried various solutions to make it work both on device and on qemu without any luck.

  • Working on qemu but not on device:
    a hook script with ollieparanoid's suggested code:
echo "Exit the shell to continue booting:"
sh

on the device the sh is not blocking and the execution continues.

  • possible solution for device:
    a hook script that starts another script that wait-forever and provide another script (e.g: /bin/pmos_confinue_boot that kills the wait-forever script and the execution continues.
    Since you have to connect through telnet to get the shell we can print a message there to explain how to continue boot.

I didn't managed to test it on a device with the hardware keyboard, if it works the qemu solution we can distinguish the 2 solution programmatically using the deviceinfo_keyboard variable.

As discussing in chat we considered that having a hook with the usb-shell that doesn't wait is kind of useless, because you can only connect to the device if there are errors. Instead if you add the hook it's because you want to debug it. The idea was to modify the behavior of the actual usb-shell hook and add a wait there, what you think? @ollieparanoid @craftyguy @PabloCastellano @MartijnBraam @ata2001 @PureTryOut ,...

I guess sh exits immediately, when there is no TTY attached (i.e. no user input is possible). After some research, it should be possible to test it like the following (not verified that this works):

if tty -s; then
    echo "Exit the shell to continue booting:"
    sh
else
    echo "No shell attached, looping forever."
    loop_forever
fi

The idea was to modify the behavior of the actual usb-shell hook and add a wait there, what you think?

馃憤

@ollieparanoid nice idea to check if there is a TTY attached. At this point I'm also thinking about not starting the telnet at all for that case, but only when there's no tty.
And maybe rename the hook in a more generic way like debug-shell or initramfs-debug-shell.
What you think?

I recommend to always start telnet, so it's also working when you attached a TTY in theory, but it is broken for some reason.
Renaming to debug-shell makes sense to me (initramfs-debug-shell would cause a very long package name postmarketos-mkinitfs-hook-initramfs-debug-shell).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

erhoof picture erhoof  路  4Comments

cmdr2 picture cmdr2  路  7Comments

pavelmachek picture pavelmachek  路  7Comments

schvabodka-man picture schvabodka-man  路  6Comments

zenety picture zenety  路  5Comments