DietPi-Boot | "...rc.local..." terminal prefix at boot

[MichaIng]

Just a minor, but on VirtualBox VM (all Distros) the beautiful DietPi messages are corrupted by some terminal line prefix, until login request:

[MichaIng]

Maybe it is also good to keep this prefix, so user knows, that this is called within rc.local, or prior by systemd, kernel etc. But it mixes a bid, as after processing messages our OK/FAILED/INFO messages overwrite the whole line.

For rc.local it would be easy to overwrite the prefix by adding "\r\e[K" to banner and custom echos: https://github.com/Fourdee/DietPi/blob/testing/dietpi/func/dietpi-set_core_environment#L251-L272

[MichaIng]

I was playing around a bid:

• First I found, that this is no issue on Jessie, just Stretch and also Buster.
• Adding \r\e[K in front of all echo AND after all linebreaks inside, generally works.
• But rc.local seems to deeply adjust all output. Already that the timestamp etc. is also added after every linebreak within single echo call, like echo -e "hello\nworld\nunbeleavable".
• Also empty echo, echo '', even echo -e "\n" and empty lines, produced by an output echo -e "\nHeadline, empty line above is wanted!" get simply removed. This can already seen in screenshot above. I was able to force the empty line by adding a separate echo -e '\r\e[K" in front and at end of e.g. G_DIETPI-NOTIFY 3 command code, instead of the linebreaks within the existing echos.

But before adding all of this, also a bid overhead, just to suppress this few output prefixes, wouldn't it be possible to add the steps of /etc/rc.local just to dietpi/boot? Only issue I could imagine is, that somehow before rc.local is called, the screen get's reset (and not by dietpi-banner, I removed clear from there to check).
€: Found reason and solution: https://serverfault.com/a/800483

@Fourdee
What do you think about merging rc.local into the end of dietpi-boot? Otherwise at least dietpi-globals need to be loaded within rc.local to allow G_DIETPI-NOTIFY 😉. I also want to do some other minor adjustments then, using processing messages for ramlog and valid connection waiting e.g.

[Fourdee]

@MichaIng

What do you think about merging rc.local into the end of dietpi-boot? Otherwise at least dietpi-globals need to be loaded within rc.local to allow G_DIETPI-NOTIFY 😉. I also want to do some other minor adjustments then, using processing messages for ramlog and valid connection waiting e.g.

The reason for rc.local is to ensure this service/script runs at the very end of SystemD. Using the Type=idle method.

Main reasons for this:

• Allows all systemD services/processes to finish, before we run dietpi-services start
• Allows us to add a banner at the end of boot.

Regarding the Ramdisk file wait check:
~The following could be moved to boot (Run_Init section) without issue (failsafe to prevent user operations if RAMdisk fails)~:
EDIT: boot service depends on dietpi-ramdisk service, so it wont run if ramdisk fails.

I looked into MOTD in the past, but it does not allow for bash script exec (AFAIK):
https://wiki.debian.org/motd

at least dietpi-globals need to be loaded within rc.local to allow G_DIETPI-NOTIFY

Yep, good spot 👍

[MichaIng]

@Fourdee
Makes sense. Yeah I recognized a few systemd commands running after DietPi-Boot.

About DietPi-RAMDISK check, yes that seems not necessary anymore due to service dependencies. I also never saw a single "wait for..." output line, whether in DietPi-Boot, nor rc.local (both include the check loop).
If anyway rc.local includes the banner, then we could remove the one at the end of DietPi-Boot? Appears doubled short after each other, otherwise. If Kernel/Systemd output is anyway removed from screen due to allocation setting, mentioned in link above, then the boot-banner can't be seen anyway 😉.

Do these rc.local output prefixes also appear on other Stretch SBCs, or just native/VM?
As said, no issue on Jessie:

[MichaIng]

@Fourdee
Solved it:

• I was wondering what exactly makes the difference between e.g. dietpi-boot.service and rc-local.service. Why does the banner inside boot script comes without timestamp+service name prefix and rc-local has it.
• Finally it was just the name Oo. I moved rc-local.service to dietpi-prelogin.service (+disable/re-enabe), without changing it's content, nor the content of /etc/rc.local and the ugly prefixes were gone. I hate such in-transparent unique handling 😠. A simple service setting, enabling/disabling console output handling, would be much more reasonable.

Of course we could also just use another script file then: /DietPi/dietpi/prelogin instead of /etc/rc.local to free it for common use?

[MichaIng]

@Fourdee
Ah found the reason for the prefixes:

root@VM-Stretch:~# cat /lib/systemd/system/rc-local.service.d/debian.conf
[Unit]
# not specified by LSB, but has been behaving that way in Debian under SysV
# init and upstart
After=network-online.target

# Often contains status messages which users expect to see on the console
# during boot
[Service]
StandardOutput=journal+console
StandardError=journal+console

Commenting out the [Service] part, removed prefixes as well.

But actually I would prefer DietPi using an own service for it's pre login tasks, leaving /etc/rc.local and rc-local.service untouched. This would allow us easier/secure adjustments on update, especially if touched by user, and keep it transparent for users, which parts come from DietPi and which are distro default. What do you think?

[Fourdee]

@MichaIng

But actually I would prefer DietPi using an own service for it's pre login tasks, leaving /etc/rc.local and rc-local.service untouched. This would allow us easier/secure adjustments on update, especially if touched by user, and keep it transparent for users, which parts come from DietPi and which are distro default. What do you think?

Yep agree 👍

Just bear in mind rc.local is removed in stretch by default (alot of people still use it):
https://stackoverflow.com/questions/44797694/where-is-rc-local-in-debian-9-debian-stretch

So to avoid complaints, we should leave rc-local.service in, just move our stuff out to another service that has:

Before=rc-local.service
Type=idle

[Fourdee]

@MichaIng
What it your paypal address? Email it over to me if you can. New driving license should be back soon 😃

[MichaIng]

@Fourdee
Jep agree. I was already thinking, how to keep rc.local in place as well, in case of manual user additions. But I can't find any not too complicated reliable way to specifically remove our code from it. Especially since I found left moode additions in mine 😛: https://github.com/Fourdee/DietPi/blob/testing/dietpi/dietpi-software#L13381

Maybe safe a copy in home, dietpi_userdata or dietpi-backup (if existent) folder, inform user about it and just overwrite by pre Stretch default:

#!/bin/sh -e
#
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

exit 0

Then user can re add his own additions.

[Fourdee]

@MichaIng

Maybe safe a copy in home, dietpi_userdata or dietpi-backup (if existent) folder, inform user about it and just overwrite by pre Stretch default:

Yep, sounds the best method 👍
Would be impossible to safely clean the current one, too much risk involved in regards to user manual additions.

Patch file, could do a message, eg:
```
if (( $G_USER_INPUTS )); then

whiptail --title "Info" --msgbox "rc.local change info" --backtitle "$G_PROGRAM_NAME" 12 80

fi

[MichaIng]

@Fourdee
First commits done: https://github.com/Fourdee/DietPi/commits/rc-local_switch

Some questions:

• DietPi-Login waits for rc.local to finish: https://github.com/Fourdee/DietPi/blob/29ada9cd5bba442d41db6a97f2247faf188622d6/dietpi/login#L102-L126
  grep 'Active' | grep -ci -m1 '(exited)' should just work, if RemainAfterExit=yes is in service file, so I guess this was the actual reason? However the other check just does grep -ci -m1 'exited'), which also works on services without that setting: Main PID: 858 (code=exited, status=0/SUCCESS)
  - Does ExecStart=/bin/bash -c '/DietPi/dietpi/postboot' solve potential missing execution permissions, or why you usually use that for DietPi services?

ToDo

• [x] Login: Wait for dietpi-postboot.service
  - [ ] dietpi-bugreport: Collect /DietPi/dietpi/postboot.d/* included with "/boot/dietpi/*"
• [x] dietpi-set_core_environment:
  - [ ] Add chmod +x /DietPi/dietpi/postboot done by dietpi-ramdisk: https://github.com/Fourdee/DietPi/blob/rc-local_switch/dietpi/dietpi-ramdisk#L90
• [x] dietpi-autostart: After=...dietpi-postboot.service
• [ ] dietpi-software:
  
  
  
  • [ ] Does vncserver.service need adjustment? https://github.com/Fourdee/DietPi/blob/testing/dietpi/dietpi-software#L9508-L9523
  
  
  • [x] Add moode additions to /DietPi/dietpi/postboot.d/moode: https://github.com/Fourdee/DietPi/blob/testing/dietpi/dietpi-software#L12137-L12145
  
  
  • [x] Adjust comment: https://github.com/Fourdee/DietPi/blob/testing/dietpi/dietpi-software#L13705
  
  
• [x] Patchfile:
  
  
  
  • [x] Add moode additions in case
  
  
  • [x] ExecStart=/bin/bash -c
    
    - [ ] Add mkdir /DietPi/dietpi/postboot.d handled optionally now
    
    - [ ] Add chmod +x /DietPi/dietpi/postboot done by dietpi-ramdisk: https://github.com/Fourdee/DietPi/blob/rc-local_switch/dietpi/dietpi-ramdisk#L90
  
  
• [x] /DietPi/dietpi/postboot:
  
  
  
  • [x] Check for [ -d /DietPi/dietpi/postboot.d]
  
  
  • [x] chmod +x -R /DietPi/dietpi/postboot.d
  
  
• [x] Changelog entry

[Fourdee]

@MichaIng

DietPi-Login waits for rc.local to finish:

We can change it to wait for dietpi-postboot.service, as rclocal is now user optionally defined, we shouldnt need to wait for it.

But we do need to wait for our stuff to finish.

[MichaIng]

@Fourdee
Okay, and what you think how to check for it best?
Also make dietpi-postboot.service RemainAfterExit=yes (don't know about any resource usage with that) or leave it exiting and do
while (( ! $(systemctl status dietpi-postboot.service | grep -ci -m1 'code=exited, status=0/SUCCESS') ))
instead of
while (( ! $(systemctl status dietpi-postboot.service | grep 'Active' | grep -ci -m1 '(exited)') )) ?

---

Can you please have a look at vncserver.service as well: https://github.com/Fourdee/DietPi/blob/rc-local_switch/dietpi/dietpi-software#L9508-L9523
This rc.local.service is symlink to rc-local.service, okay but what is dietpi-service.service?

[Fourdee]

@MichaIng

Also make dietpi-postboot.service RemainAfterExit=yes (don't know about any resource usage with that) or leave it exiting and do

This basically tells SystemD that when it exists, flag it as successful status with "active". Get a nice green status icon :)

and do
while (( ! $(systemctl status dietpi-postboot.service | grep -ci -m1 'code=exited, status=0/SUCCESS') ))
instead of
while (( ! $(systemctl status dietpi-postboot.service | grep 'Active' | grep -ci -m1 '(exited)') )) ?

Either option looks good 👍 The first would be quicker, less pipe 😃

[Fourdee]

@MichaIng

Can you please have a look at vncserver.service as well

dietpi-service.service can be removed. This was the old ramlog/ramdisk in one service, "back in the day": https://github.com/Fourdee/DietPi/issues/122#issuecomment-160190399

[MichaIng]

@Fourdee
Do you think it is necessary to overwrite system rc-local?
https://github.com/Fourdee/DietPi/blob/testing/dietpi/func/dietpi-set_core_environment#L280-L324

It seems to be not in use on default systems any more and I would prefer to not touch any of those system files/services, as long as it is not necessary.

I would just backup+revert /etc/rc.local in patch_file, in case users started to use it since v6.0, and leave all of this untouched on new systems.

DietPi-PostBoot is configured to start before rc-local.service in case. This should assure compatibility: https://github.com/Fourdee/DietPi/blob/testing/dietpi/func/dietpi-set_core_environment#L233

[MichaIng]

@Fourdee
Maybe when using dietpi-set_core_environment on update, we can (optionally) be a bid more preserving, as at the moment at least cron settings and custom grub defaults get overwritten.

---

Btw. 👍 for 99-dietpi-posix-set-locale.sh. Previously I found our whiptail scripts still show broken layout when accessing via screen. Even that locales are set correctly within script, if not exported to environment, on dropbear > screen > dietpi-...

dropbear > unset LC_ALL > dietpi-config 🈯️
dropbear > screen > dietpi-config 🈴
dropbear > screen > dietpi-config > print locales from within script: en_GB.UTF-8 everywhere, but layout still broken 🤔.
dropbear > LC_ALL=en_GB.UTF-8 > screen > dietpi-config 🈯️

It seems like screen itself needs to be executed with LC_ALL/LANG set. This was greatly solved 99-dietpi-posix-set-locale.sh!

[Fourdee]

@MichaIng

~Ticket is now completed? Is https://github.com/Fourdee/DietPi/issues/1376#issue-286490161 resolved for VM?~

[Fourdee]

@MichaIng

Verified fixed on VMware with 6.3.

Needs another line before top banner line:

[Fourdee]

Hmm, as service is idle, it may run before or after login prompt appears. I can't find anyway to wait for login prompt to appear before systemD runs an idle service. Minor chance of misprint, I'll mark this as closed for now, we can reopen if it bugs us too much :)

[MichaIng]

@Fourdee
Jep resolved here also 👍. Interesting, I never faced the issue, that it got tty1 login print after/in between postboot (or prior rc-local). On all my machines, as far as I remember it always looked like your last screenshot: Debian GNU/Linux ... first line, and then our lines overprinting "DietPi Login:", so that you need to hit "return" one time again before you see <hostname> Login:.

I played around with the Before= After= settings, but actually I cannot even force Debians login promt ([email protected]; /lib/systemd/system/[email protected]) to appear after dietpi-postboot:

root@VM-Stretch:~# cat /lib/systemd/system/[email protected]
...
After=dietpi-postboot.service rc-local.service
...
root@VM-Stretch:~# cat /etc/systemd/system/dietpi-postboot.service
[Unit]
Description=DietPi-PostBoot
Requires=dietpi-boot.service dietpi-ramdisk.service
After=rc-local.service dietpi-boot.service dietpi-ramdisk.service dietpi-ramlog.service
Before=getty.service //tested [email protected] and [email protected] as well

[Service] //note, no Type=idle
RemainAfterExit=yes
ExecStart=/bin/bash -c '/DietPi/dietpi/postboot'
StandardOutput=tty

[Install]
WantedBy=multi-user.target

According to both service settings, postboot should start before tty1/login prompt, but it still looks the same as before, our lines at last 🤔. But of course we anyway don't wont this because of screen clearance, was just testing. Moreover it is good, that it does not work (usually, besides your exception above), as [email protected] wants to start After=rc-local.service and we want dietpi-postboot to start Before=rc-local.service, thus actually the login prompt should appear after dietpi-postboot, clearing our banner 😆. Maybe we should switch do After=rc-local.service and in case even After=getty.service [email protected] [email protected]? Has as said absolutely no effect on my VM, but could reduce chance of exceptions?