login chroot hooks

just a note / suggestion for possible future mods to dietpi.bash when running from chroot…

currently we hit this (assuming boot isn’t available);

. /boot/dietpi/func/dietpi-globals || { echo -e '[\e[31mFAILED\e[0m] DietPi-Login | Failed to load DietPi-Globals. Skipping DietPi login scripts...'; return 1; }

which is a lil scary… in future you might source a chroot specific library (to do some more custom diet-pi magic) or just exit a little friendlier… i.e. above this line;

[ -n "$debian_chroot" ] && return 1

etc. etc.

This is what happens when we make boot available (with no bindmounts)

│ [FAILED] Unknown install state/First run setup failed                                                                       │
│                                                                                                                             │
│ An error has occurred either during first run update or installs.                                                           │
│                                                                                                                             │
│ First run setup will now attempt to re-apply the last step, forced as interactive run.                                      │
│ If this repeatedly fails, please collect all terminal output and the content of                                             │
│ /var/tmp/dietpi/logs/dietpi-firstrun-setup.log if available and report this issue to:                                       │
│ https://github.com/MichaIng/DietPi/issues

/boot/dietpi/func/dietpi-banner: line 62: ((: == 20 : syntax error: operand expected (error token is "== 20 ")
 DietPi v8.1.2 : 05:06 - Fri 02/25/22
/boot/dietpi/func/dietpi-globals: line 1311: /dev/fd/63: No such file or directory
/boot/dietpi/func/dietpi-globals: line 1312: /dev/fd/63: No such file or directory
/boot/dietpi/func/dietpi-globals: line 1272: /dev/fd/63: No such file or directory
 - LAN IP : Use dietpi-config to setup a connection (NONE)
[  OK  ] DietPi-Login | Desired setting in /boot/dietpi.txt was already set: AUTO_SETUP_AUTOMATED=0


ping MichaIng
can you have a look pls

Well, if DietPi-Config cannot be loaded, then the login scripts won’t work either. On a regular system this most likely means that the dedicated /boot mount failed, which has serious implications and should be investigated before it causes further issues, like a kernel/bootloader installed below the /boot mount point and such. An error message is hence appropriate IMO. Would you have recognised the missing /boot mount without this error message?

If you do a chroot into an OS image, it is very common that various error messages about missing /dev, /proc, /sys and other host system kernel and system devices/tuneables, so additional ones shouldn’t scare you :stuck_out_tongue:. As always, to mute it, mount those dirs into the chroot or use systemd-nspawn to have a minimal set of those devices mounted into the chroot (more a light container) automatically.

The /dev/fd/63 error is caused by the ip command, right?

What do you want to achieve with this chroot? Knowing the use case, we may be able to adjust the login script or banner behaviour appropriately and e.g. prevent steps or scripts known to fail with the limited system access in the first place.

purpose of the post was to give the developers insight into certain use cases and error modes…

i’m not recommending or suggesting any specific change, that is a largely a subjective decision to be made by those who implement the functionality from the mentioned logic

if nothing is lost not running the logic → no changes required
if chroots would benefit from some of the logic → up to you to decide if, what and how to deal with that

just thought you might like that insight is all… ( i would ), if a day comes when one or few chrooty people or minirootfs.tar.gz is offered… you’ll better know where stuff can be tied in, cleaned up or extensified…

So what is your use case for the chroot in the first place?

Since DietPi scripts obviously depend on things which you did not make available in your particular chroot (which generally it is easily possible), it generally makes sense to show an error message to make you aware that something is missing. If you have a particular use case for your chroot, where you cannot make available this missing parts via bind mount but still want to use a DietPi image, then the whole purpose of the chroot would be important to understand, so we can see whether there are way to detect this use case and then skip or handle related missing parts gracefully. But it doesn’t make sense to skip various steps in DietPi scripts in chroots in general, as often, e.g. for testing, you probably exactly want to test those, or at least where it makes sense that you are made aware of things missing, like in your case the missing /boot mount.