Hello.
After updating to DietPI version 10 it seems that .bashrc is not loaded at login anymore as the ouput of ls is not colorized:
I can fix it by typing “bash” then it works
I have a very simple .bashrc
export LS_OPTIONS=‘–color=auto’eval “$(dircolors)”alias ls=‘ls $LS_OPTIONS’alias ll=‘ls $LS_OPTIONS -l’alias l=‘ls $LS_OPTIONS -lA’
DietPi version | 10.1.2
Distro version | bookworm 0
Kernel version | Linux pi5 6.12.62+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.12.62-1+rpt1~bookworm (2026-01-19) aarch64 GNU/Linux
Architecture | arm64
SBC model | RPi 5 Model B (aarch64) or (EG: RPi3)
Power supply used | Original Raspberry PI 5 power supply
SD card used | Lexar NM610 PRO NVME SSD
Software title | bash
Was the software title installed freshly or updated/migrated? updated to 10
Can this issue be replicated on a fresh installation of DietPi? unaware
Bug report ID | dacad5af-2f1d-4436-b31f-bfc833750c27
login via ssh
type ls to see that bashrc is indeed ignored as the output is not colorized
bashrc should be loaded therefore ls should be colorized
login via ssh
type bash
everything works
I’ve noticed that the default shell after login via ssh is “-bash”, with a leading dash:root@pi5:~# echo $0-bash
after typing “bash” the leading dash goes away and it becomes a full working shellroot@pi5:~# echo $0bash
I understand this is a trivial and possibly quite easy issue to fix so is definetly low priority yet I’d appreciate any help sent this way.
Cheers!
Jappe
17 March 2026 12:06
2
-bash means it’s the login shell, which does not automatically load .bashrc.
But you should have a .profile which cares about loading .bashrc:
# ~/.profile: executed by Bourne-compatible login shells.
if [ "$BASH" ]; then
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
fi
mesg n 2> /dev/null || true
I also did not encounter this issue when updating to v10.
My .profile is the same as yours, yet .bashrc it’s not loaded.
I tried adding a simple. ~/.bashrc at the beginning of the file, skipping the two if altogether, yet nothing changed. I guess .profile is also not loaded?
While normally I might be the one to mess around I actually took great care NOT to mess with this system at all: this raspberry is only used to host docker containers, it has basically no package installed, and its kept constantly (monthly?) updated. I did skip 10.0.0 but I made the jump to 10 at the first minor release.
Jappe
17 March 2026 16:07
4
Alright, let’s check some things
echo $HOME
ls -la $HOME
ls -la ~ | grep bash_profile
echo $-
grep $(whoami) /etc/passwd
I assume you use the same app to connect via SSH as before the update?
First of all, thank you for your help.
Yes, same app.
root@pi5:\~# echo $HOME
/root
root@pi5:\~# ls -la $HOME
total 120
drwx------ 7 root root 4096 Mar 17 16:02 .
drwxr-xr-x 18 root root 4096 Feb 22 00:56 ..
-rw------- 1 root root 6554 Mar 17 16:02 .bash_history
-rw-r–r-- 1 root root 637 Aug 9 2025 .bashrc
drwx------ 4 root root 4096 Jun 7 2025 .config
-rw------- 1 root root 68 Mar 17 15:27 .git-credentials
-rw-r–r-- 1 root root 242 Aug 8 2025 .gitconfig
drwxr-xr-x 2 root root 4096 Jun 5 2025 .inxi
-rw------- 1 root root 166 Mar 17 13:39 .lesshst
drwxr-xr-x 3 root root 4096 Nov 26 14:02 .local
-rw-r–r-- 1 root root 161 Mar 17 13:35 .profile
-rw-r–r-- 1 root root 75 Jun 28 2025 .selected_editor
drwx------ 2 root root 4096 Jul 15 2025 .ssh
drwxr-xr-x 2 root root 4096 Mar 3 12:41 .vim
-rw------- 1 root root 36508 Mar 17 13:35 .viminfo
-rw-r–r-- 1 root root 10 Jun 5 2025 .vimrc
-rw-r–r-- 1 root root 347 Dec 1 16:49 .wget-hsts
lrwxrwxrwx 1 root root 31 Aug 8 2025 Events.log → /opt/docker/openhab5/Events.log
lrwxrwxrwx 1 root root 32 Aug 8 2025 Openhab.log → /opt/docker/openhab5/Openhab.log
-rwxr-xr-x 1 root root 24 Dec 1 10:31 bash.sh
lrwxrwxrwx 1 root root 33 Dec 16 15:05 campanello.sh → /opt/docker/rsyslog/campanello.sh
lrwxrwxrwx 1 root root 25 Jun 5 2025 config.txt → /boot/firmware/config.txt
lrwxrwxrwx 1 root root 43 Jun 12 2025 docker-compose@.service → /etc/systemd/system/docker-compose@.service
-rw-r–r-- 1 root root 22 Jul 12 2025 log.sh
lrwxrwxrwx 1 root root 34 Aug 8 2025 openhab_conf → /opt/docker/openhab5/openhab_conf/
lrwxrwxrwx 1 root root 25 Dec 2 09:50 rsyslog → /opt/docker/rsyslog/data/
-rwxr-xr-x 1 root root 22 Jun 5 2025 sh.sh
-rw-r–r-- 1 root root 235 Jun 5 2025 stress.sh
root@pi5:\~# ls -la \~ | grep bash_profile
root@pi5:\~# echo $-
himBHs
root@pi5:\~# grep $(whoami) /etc/passwd
root:x:0:0:root:/root:/bin/bash
root@pi5:\~#
I don’t see anything weird, do you?
Jappe
18 March 2026 17:59
6
Yes, looks fine to me too: No .bash_profile which could interfere, also session started in interactive mode. ALso right shell and user, I have no idea why it’s failing
@MichaIng do you have any idea?
What is also weird is that your first ls output lists one file per line, but without the mode/owner/size stuff ls -l would list. So that shell seems to have some alias already.
Which SSH server and which SSH client do you use? Do you face the same when logging in at local console?
Also, do SSH logins show the DietPi banner? That would at least indicate /etc/bash.bashrc is loaded.
These commands should give some clarification:
env
alias
You could also set a test variable in ~/.profile to see whether it is loaded or not. Ah, and a more explicit test, whether it is a login shell:
shopt -q login_shell && echo 'login shell' || echo 'no login shell'
However, this affects /etc/profile and ~/.profile loading only. In an interactive non-login shell, /etc/bash.bashrc and ~/.bashrc would be loaded regardless.
