Selecting "No" at UART Disable prompt disables UART anyway.

[nullstalgia]

Creating a bug report/issue

• I have searched the existing open and closed issues

Required Information

• DietPi version | 9.15

Steps to reproduce

1. During first time setup on a Raspberry Pi (I tried a 1B and 3), select Yes or No on the UART Disable prompt.
2. After setup completes, go to dietpi-config and observe it always being disabled.

It appears to ask the user, and then check the dietpi.txt for the same option.

When selecting Yes:

...
[ SUB1 ] DietPi-Set_hardware > serialconsole (disable)
[ INFO ] DietPi-Set_hardware | Disabling serial-getty on: /dev/serial0
[  OK  ] DietPi-Set_hardware | systemctl unmask serial-getty@serial0
[  OK  ] DietPi-Set_hardware | systemctl disable --now serial-getty@serial0
[  OK  ] DietPi-Set_hardware | Desired setting in /boot/config.txt was already set: enable_uart=0
[  OK  ] DietPi-Set_hardware | Setting in /boot/dietpi.txt adjusted: CONFIG_SERIAL_CONSOLE_ENABLE=0
[  OK  ] serialconsole disable | Completed
[ SUB1 ] DietPi-Set_hardware > serialconsole (disable)
[ INFO ] DietPi-Set_hardware | Disabling serial-getty on: /dev/serial0
[  OK  ] DietPi-Set_hardware | systemctl unmask serial-getty@serial0
[  OK  ] DietPi-Set_hardware | systemctl disable --now serial-getty@serial0
[  OK  ] serialconsole disable | Completed
[  OK  ] DietPi-Software | mount -o remount /var/log
...

When selecting No:

...
[ SUB1 ] DietPi-Set_hardware > serialconsole (disable)
[ INFO ] DietPi-Set_hardware | Disabling serial-getty on: /dev/serial0
[  OK  ] DietPi-Set_hardware | systemctl unmask serial-getty@serial0
[  OK  ] DietPi-Set_hardware | systemctl disable --now serial-getty@serial0
[  OK  ] serialconsole disable | Completed
[  OK  ] DietPi-Software | mount -o remount /var/log
...

What was expected:

The prompt should respect the user's most recent choice, and should not fall back to a config option if it just got an answer from the user directly.

[MichaIng]

This serial device node being disabled two times without further explaining output is somewhat misleading. I just enhanced it a bit, avoiding this doubled disabling and adding some informational prints as well: b6181b3

In your case, it is disabled since the /dev/serial0 node does not exist at all. This is unexpected on first boot on all but Raspberry Pi 5, which comes with an entirely new UART device node where we need to update our raspberrypi-sys-mods package for.

When you select "Yes" on the RPi 1B and 3, or re-enable the UART device in dietpi-config > Advanced Options > Serial/UART with the toggle at the bottom, then reboot, can you check whether it is really still missing?

ls -l /dev/serial0

The menu shows "ttyS0 (mini UART) device" on RPi 3 (all models with WiFi) or "ttyAMA0 (full UART) device" on RPi 1B (all models without WiFi). Setting it to on, after reboot, should enable the shown device node, and the udev rules from the raspberrypi-sys-mods package should create the /dev/serial0 symlink to the repective node.

[nullstalgia]

Hmm, I feel there's an extra layer of confusion on top of this.

I originally only meant the UART device itself being accessible by applications (as my eyes completely missed the use of it as a login console) and how I observed the device being set to Off, regardless of which option I chose. The device was always visible in the dietpi-config.

[nullstalgia]

Selecting Yes on Pi 3 (pre and post reboot):

root@DietPi:~# ls -l /dev/serial0
ls: cannot access '/dev/serial0': No such file or directory

Selecting No on Pi 3, enabling UART device (console still off), post-reboot:

root@DietPi:~# ls -l /dev/serial0
ls: cannot access '/dev/serial0': No such file or directory

[MichaIng]

I guess one of the recent kernel updates changed something around the UART devices, so that the /dev/serial* symlinks are not generated anymore with our outdated udev rules. However, if you do not want to use the UART device for serial console access anyway, the current buggy behaviour is actually perfect:

• The /dev/serial0 device is used in our case only to assure the primary UART device is used for serial console output on first boot, regardless which RPi model you boot with the image. If /dev/serial0 did exist, and you select "No" to keep the console enabled, it would be converted to the acutual primary console device node, /dev/ttyS0 in case of RPi 3. The console service prevents other uses of that device.
• Since /dev/serial0 does not exist, it is just disabled, leaving /dev/ttyS0 available for other uses.
• If you select "Yes", while strictly seen it asks about the serial console only, not about the UART device itself, it disables the device as well, which you might not want.

However, I wonder whether you want to use the mini UART ttyS0 at all, and not the full UART ttyAMA0 instead? On RPi 3 that one is always enabled. It is not the primary UART, since it is used by Bluetooth by default, but you can swap that if you do not use Bluetooth, or if weaker Bluetooth via mini UART is fine:

G_CONFIG_INJECT 'dtoverlay=miniuart-bt' 'dtoverlay=miniuart-bt' /boot/config.txt

That way /dev/ttyAMA0 becomes the UART device accessible via GPIO 14+15 (pins 8+10).

[nullstalgia]

I appreciate the vote of confidence, but you may be assuming a higher level of familiarity with the nuances of the Pi's than I actually have 😅. I can go into a little more detail as to how I got here.

The main reason I was pulling out my Pi's was to test my new serial terminal application in a resource-constrained environment (such as a Pi 1B, video example). During which I wanted to also make sure it worked with their built-in UART pins.

During my very first attempt, I tried the Pi 1B (since if it works on that, it'll def work on a 3), and saw the Disabling serial-getty on: /dev/serial0 message when I clicked "No". I was a little confused, but after setup completed I just opened dietpi-config and enabled the /dev/ttyAMA0 device. I recorded my little video example, and forgot about the strange prompt for a day, without yet trying on my Pi 3.

The next day I was setting up my Pi 3 to use it's built-in Bluetooth to begin logging heart rate data with another one of my apps, when I came across the UART Console prompt once again. At that point is when I decided to experiment to see if an Issue would need to be opened, and saw that regardless of which option I chose, on both the Pi 1 and 3, both the Console and Device were always disabled.

Pi 1: "Yes", pre-reboot

root@DietPi:~# ls /dev/tty*
/dev/tty    /dev/tty12  /dev/tty17  /dev/tty21  /dev/tty26  /dev/tty30  /dev/tty35  /dev/tty4   /dev/tty44  /dev/tty49  /dev/tty53  /dev/tty58  /dev/tty62  /dev/ttyprintk
/dev/tty0   /dev/tty13  /dev/tty18  /dev/tty22  /dev/tty27  /dev/tty31  /dev/tty36  /dev/tty40  /dev/tty45  /dev/tty5   /dev/tty54  /dev/tty59  /dev/tty63
/dev/tty1   /dev/tty14  /dev/tty19  /dev/tty23  /dev/tty28  /dev/tty32  /dev/tty37  /dev/tty41  /dev/tty46  /dev/tty50  /dev/tty55  /dev/tty6   /dev/tty7
/dev/tty10  /dev/tty15  /dev/tty2   /dev/tty24  /dev/tty29  /dev/tty33  /dev/tty38  /dev/tty42  /dev/tty47  /dev/tty51  /dev/tty56  /dev/tty60  /dev/tty8
/dev/tty11  /dev/tty16  /dev/tty20  /dev/tty25  /dev/tty3   /dev/tty34  /dev/tty39  /dev/tty43  /dev/tty48  /dev/tty52  /dev/tty57  /dev/tty61  /dev/tty9

Selecting "No" gives identical results. And I forgot to screenshot it, but I checked, /dev/serial0 is never present in either choice.

---

And with the Pi 3, behavior is the same, but the device shown in dietpi-config is /dev/ttyS0 instead, still always disabled.

After enabling the device, I am able to Recieve and Transmit through Pins 8+10 via /dev/ttyS0. And enabling the console also works on /dev/ttyS0.

After running the G_CONFIG_INJECT command, it does indeed change to /dev/ttyAMA0. However I'm unsure what the benefits are, if this cripples Bluetooth in some way.

---

Long user-story short, I just wanted to use some UART pins and I was given a prompt at setup that was semi-related but ended up confusing/misinforming me, and maybe also seems to be a little bugged if I'm understanding you correctly. 😅

[MichaIng]

So you want to use Bluetooth on the RPi 3 + the UART device for an actual serial terminal. Yeah, then better let Bluetooth use ttyAMA0 as it does by default:

sed --follow-symlinks -i '/dtoverlay=miniuart-bt/d' /boot/config.txt

Then enable the primary UART device with the bottom option in dietpi-config, reboot, then enable the serial console on the now visible ttyS0 node in dietpi-config. As a side note: This forcefully lowers the GPU core frequency to 250 MHz (default otherwise is 400 MHz), since the mini UART baudrate is linked to the core frequency. This slows some GPU tasks, and also RAM performance a little on RPi 3, where the GPU core drives the memory bus.

Oh indeed, the primary UART device is disabled on first boot. That is not intended either. Also, with the new kernel stack, the secondary UART device, which is used by Bluetooth by default, is hidden, which can be toggled with dtparam=krnbt=off in /boot/config.txt it seems: https://www.raspberrypi.com/documentation/computers/configuration.html#primary-and-secondary-uart

Weird that this is not implied automatically if Bluetooth is fully disabled via dtoverlay=disable-bt, or in your case on the RPi 1 which does not even have onboard Bluetooth. Maybe because the secondary UART is not available via any GPIO pin by default. The readme states it disables autoprobing of the Bluetooth driver. So it sounds like the Bluetooth driver is removing the console device node when loaded, which makes sense. However, then there is no transparent reason why ttyS0 is ever missing on an RPi 1. The docs are partially contradicting, probably mixing old and new kernel stack information 🤔: https://www.raspberrypi.com/documentation/computers/configuration.html#configure-uarts
Looks like I need to experiment with my RPi 2 and Zero W to verify the behavior of dtoverlay=disable-bt, enable_uart= dtparam=krnbt=off, 'dtoverlay=miniuart-bt' in all their combinations, to get our first boot prompt and the information in dietpi-config right. For my reference, to compare results with expected behavor derived from device tree sources:

• https://github.com/raspberrypi/linux/blob/rpi-6.12.y/arch/arm/boot/dts/overlays/disable-bt-overlay.dts
  So this makes ttyAMA0 the primary UART, attaching it to the GPIO header, and it forcefully disables UART1/ttyS0 in turn, unless explicitly enabled and attached to GPIO pins (other than 14+15) with uart1 overlay (below).
• https://github.com/raspberrypi/linux/blob/rpi-6.12.y/arch/arm/boot/dts/overlays/miniuart-bt-overlay.dts
• https://github.com/raspberrypi/linux/blob/rpi-6.12.y/arch/arm/boot/dts/overlays/uart1-overlay.dts
• https://github.com/raspberrypi/linux/blob/rpi-6.12.y/arch/arm/boot/dts/broadcom/bcm271x-rpi-bt.dtsi
  So the krnbt parameter toggles Bluetooth without toggling or swapping any UART device. Seems like the hciuart.service then instead toggles this status, and can do so without requiring a reboot, using btuart > hciattach command. And that service explicitly requires /dev/serial1 to be present, hence is not only obsolete without defining dtparam=krnbt=off, but cannot even run. Something we can hence skip in our Bluetooth toggle functions.
  That parameter however does not have any effect on RPi 1, so indeed /dev/ttyS0 (/dev/serial1) is missing there since we set dtoverlay=disable-bt by default. This seems like an unintended side-effect on RPi kernel side, as one would expect this overlay to not have any effect on RPi models, which have no Bluetooth anyway. However, minor issue, since one cannot make reasonable use of this UART anyway on these models, unless explicitly attached to GPIO pins via uart1 overlay.