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?
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.
echo "Exit the shell to continue booting:"
sh
on the device the sh is not blocking and the execution continues.
/bin/pmos_confinue_boot that kills the wait-forever script and the execution continues.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-shellhook 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).
Most helpful comment
I guess
shexits 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):馃憤