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?
FRESH INSTALL.
Can this issue be replicated on a fresh installation of DietPi?
YES.
← If you sent a “dietpi-bugreport”, please paste the ID here →
Bug report ID | echo $G_HW_UUID
NO REPORT SENT.
Steps to reproduce
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.
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:
This should have not shown up on this screen, and should have
been displayed on the previous screen of scrolling services
starting.
If at the login prompt of: “DietPi login:” or logged in as
“root@DietPi:~#” , and I connect a USB device, I get the
following:
“Please hit to login”
“[ 1984.984873 usb 1-1.5.2.3: new low-speed USB device number 12 using dwc_otg”
“DietPi login: [ 1984.984873 usb 1-1.5.2.3: new low-speed USB device number 12 using dwc_otg”
“root@DietPi:~# [ 1984.984873 usb 1-1.5.2.3: 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.
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
I should be brought to the postboot script with no additional
delayed services.
“Please hit to login”
“DietPi login:”
Actual behaviour
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.
The only additional software that is installed us through the
DietPi-Software application is lxde, and samba client.
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.
#!/bin/bash
#DMESG CONSOLE OFF #DISABLE THE PRINTING OF MESSAGES TO THE CONSOLE.
dmesg -D
#DMESG CONSOLE ON #DISABLE ALL MESSAGES EXCEPT EMERGENCY PANIC MESSAGES TO THE CONSOLE.
dmesg -n 1
#DMESG CONSOLE ON #DISABLE ALL MESSAGES EXCEPT ALERT, CRITICAL, ERROR, WARNING MESSAGES TO THE CONSOLE. #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
#////////////////////////////////////
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.
/etc/sysctl.d/99-sysctl.conf
Reviewing the details of the file shows the following:
/etc/sysctl.d/99-sysctl.conf #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.
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 . 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.
. But interesting that the last value remains at