Unfinished Services During Boot At Login Prompt

Creating a bug report/issue

Required Information

  • DietPi version | cat /boot/dietpi/.version

  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
    bullseye 0

  • Kernel version | uname -a
    Linux DietPi 5.15.76 - v7+ #1579 SMP Fri Nov 4 12:13:17 GMT 2022 armv71 GNU/Linux

  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
    RPi 2 Model B (armv71)

  • Power supply used | (EG: 5V 1A RAVpower)
    Generic 5V 3A Power Supply

  • SD card used | (EG: SanDisk ultra)
    SanDisk Ultra

Additional Information (if applicable)

  • Software title | DIETPI

  • Was the software title installed freshly or updated/migrated?

  • Can this issue be replicated on a fresh installation of DietPi?

← If you sent a “dietpi-bugreport”, please paste the ID here →

  • Bug report ID | echo $G_HW_UUID

Steps to reproduce

  1. When system boots up, running services do not complete loading
    until after the postboot script completes causing the following
    to be displayed:

    “Please hit to login”

    “[ 33.114944] cam-dummy-reg: disabling”

    I can press the return key, and prompted for the login, but the
    “[ 33.114944] cam-dummy-reg: disabling” should have not shown
    up on this screen, and should have been displayed on the previous
    screen of scrolling services starting.

  2. I rebooted the system, and if you press return after the prompt
    immediately, you are prompted with the DietPi login, and within
    minutes the logon prompt has text entered into the area:

    “DietPi login: [ 33.114944] cam-dummy-reg: disabling”

    This should have not shown up on this screen, and should have
    been displayed on the previous screen of scrolling services

  3. If at the login prompt of: “DietPi login:” or logged in as
    “root@DietPi:~#” , and I connect a USB device, I get the
    “Please hit to login”

    “[ 1984.984873 usb 1- new low-speed USB device number 12 using dwc_otg”

    “DietPi login: [ 1984.984873 usb 1- new low-speed USB device number 12 using dwc_otg”
    “root@DietPi:~# [ 1984.984873 usb 1- new low-speed USB device number 12 using dwc_otg”

    I have tried other users, and devices on the system with no change
    in behavior of what is being written to the screen after the
    postboot or login screen appears.

  4. I’ve commented out postboot to see if it is an issue with the
    script, receive the DietPi login immediately followed by the
    additional services being displayed.

Expected behaviour

  1. I should be brought to the postboot script with no additional
    delayed services.

    “Please hit to login”

    “DietPi login:”

Actual behaviour

  1. There needs to be either a delay in the startup to allow all
    remaining services to load prior to the postboot script running
    that causes the following to be displayed:

    “[ 33.114944] cam-dummy-reg: disabling”

    or have a feature of the postboot script to allow for a delay so
    that services can be ran prior to launching of the postboot script.
    Once the postboot script completes or the login screen is displayed,
    it needs to stay at that prompt until the user interacts with the system.

  2. The only additional software that is installed us through the
    DietPi-Software application is lxde, and samba client.

[ 33.114944] cam-dummy-reg: disabling

This is kernel message and not a service we start on our script

Thanks for the updated information.
I was able to narrow down the issue during the boot process via dmesg in the postboot script under /boot/dietpi/postboot. The timing of what is printed to the console overlaps the prompts on the screen when postboot completes its run. Testing dmesg options at the top of postboot allows the system to boot up normally, but still allows the printing of messages to the console respectively for specified messages. All of the following seems to work, except for when using warn in dmesg -l alert,crit,err,warn where as the warn option causes the overlapping of the printed messages to the console when postboot completes its run, and acts as if the dmesg options were not present in the postboot script to begin with. Instead of implementing dmesg options in every script, I have this load once allowing all scripts to run without unwanted printing of messages to the console. This option may not be for everyone, but does what I need it to do. If I have a certain script that needs printing of messages to the console, I can enable it exclusively using the dmesg command.


dmesg -D

dmesg -n 1

#dmesg --level=alert,crit,err,warn
#dmesg -l alert,crit,err,warn
dmesg -l alert,crit,err

# DietPi PostBoot Script
# Created by Daniel Knight / daniel.knight@dietpi.com / dietpi.com
# Info:
# - Location: /boot/dietpi/postboot
# - Handles install stage for pre-installed images (AlloGUI)
# - Network time sync, DietPi-Update check and DietPi-Services start on regular boot
# - Executes optional user scripts from: /var/lib/dietpi/postboot.d/
# - Prints login banner

It’s interesting, as I saw this just in the other topic: Network state filling up terminal

The default is, or should be, that only severity “err” or higher is printed to console, like with dmesg -n 4.

… checked again, indeed the default is to show everything up to info level and up wo warning is only the default with quiet flag in /boot/cmdline.txt.

Can you try this:

echo 'kernel.printk = 5 4 1 7' > /etc/sysctl.d/99-printk.conf

This leaves full boot-time verbosity (all but debug), but reduces regular console prints to warnings and worse. I hope this covers everything from login prompt on.

Checking the /etc/sysctl.d/ directory, I see that there is a file called 99-sysctl.conf.

Reviewing the details of the file shows the following:
#Uncomment the following to stop low-level messages on console
#kernel.printk = 3 4 1 3
kernel.printk = 3 4 1 3

When kernel.printk = 3 4 1 3 is uncommented, and the system rebooted, it boots as requested. This is what I want to see. This means that I do not need to use the dmesg command in the postboot script. Looking at other systems such as the OS from Raspberry PI, I see that this is uncommented as well. Seems like this needs to be uncommented by default on DietPI builds or an option through the DietPi-Launcher.

Does it work as well when you use:

kernel.printk = 5 4 1 7

The last value is for boot-time logging, which I by default want to be more verbose, to make it easier debugging boot/init issues.

The first value 5 means, all up to warnings are shown (all with higher severity/lower value than 5). That might still be too much, since warnings are the default log level (second value), but to mute device detection, network setup and Docker logs, it should be sufficient.

On RPi OS, if I’m not mistaken, the quiet kernel flag is set, which leads to …

kernel.printk = 4 4 1 7

which makes the dedicated sysctl entry a bit redundant, respectively leads to the strange behaviour that removing the quiet flag has no effect :thinking:. But interesting that the last value remains at 7 (just tested). … ah no, a little strange, but:

  • The quiet flag sets kernel.printk = 4 4 1 7 indeed but additionally omits boot messages (up to warnings).
  • kernel.printk = 4 4 1 7 only mutes everything up to warnings after boot has finished. Interestingly the last value has no effect at all in my case, which somehow makes sense since this is loaded after the boot partition has been mounted at much later boot stage, when very most of the kernel logs have been done already.

Okay, for now I’ll add kernel.printk = 5 4 1 7 to our default sysctl. Warnings IMO are still good to be recognised by users, and it does not affect full boot logs like quiet.

EDIT: Done: v8.12 · MichaIng/DietPi@328c3bd · GitHub

This works as well when I use:
kernel.printk = 5 4 1 7

Thanks @MichaIng @Joulinar

1 Like