Raspberry Pi 4 Misidentified After Messing Up The System

Troubleshooting
1

Creating a bug report/issue

I have searched the existing open and closed issues

Required Information

  • DietPi version | cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=18
G_DIETPI_VERSION_RC=1
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
G_LIVE_PATCH_STATUS[0]='applied'
  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
bookworm

I had to switch to bash for this instead of running the command in my custom shell (fish)

  • Kernel version | uname --all
Linux rpi4 6.12.47+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.47-1+rpt1~bookworm (2025-09-16) aarch64 GNU/Linux
  • Architecture | dpkg --print-architecture
arm64
  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
Generic Device (aarch64)

And here lies the issue!
I had to switch to bash for this instead of running the command in my custom shell (fish)

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

A smartphone charger (5V, 1.5A)

  • SD card used | (EG: SanDisk ultra)

Hikvision D1 64GB Memory Card

Additional Information (if applicable)

raspinfo.txt (63.0 KB)

❯ cat /etc/.dietpi_hw_model_identifier

22

❯ cat -A /proc/device-tree/model
Raspberry Pi 4 Model B Rev 1.1^@⏎

Steps to reproduce

  1. Uninstall a bunch of necessary packages

  2. Reboot the Raspberry Pi… it’s broken

  3. Fix boot issues by:

    a. mounting the SD card on a qemu-system-aarch64 VM

    b. Fiddling with config files (such as cmdline.txt and config.txt) in order to make the Raspberry Pi boot

    c. Continuing fixing after booting in rescue mode

Expected behaviour

DietPi indentifies the Raspberry Pi 4 as Raspberry Pi 4

Actual behaviour

DietPi indentifies the Raspberry Pi 4 as Generic Device (aarch64) + Mounting issues

Extra details

When I update the system or the kernel specifically, I have to execute the following command to avoid errors:

# sudo mount /dev/mmcblk0p1 /boot/firmware
  • Additional info (refer to the attached file for more)
❯ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
mmcblk0     179:0    0 58.2G  0 disk 
├─mmcblk0p1 179:1    0  128M  0 part 
└─mmcblk0p2 179:2    0 58.1G  0 part /
/etc/fstab contents 
# You can use "dietpi-drive_manager" to setup mounts.
# NB: It overwrites and re-creates physical drive mount entries on use.
#----------------------------------------------------------------
# NETWORK
#----------------------------------------------------------------


#----------------------------------------------------------------
# TMPFS
#----------------------------------------------------------------
tmpfs /tmp tmpfs size=1570M,noatime,lazytime,nodev,nosuid,mode=1777

#----------------------------------------------------------------
# MISC: ecryptfs, vboxsf, glusterfs, mergerfs, bind, Btrfs subvolume
#----------------------------------------------------------------


#----------------------------------------------------------------
# SWAP SPACE
#----------------------------------------------------------------
/var/swap none swap sw

#----------------------------------------------------------------
# PHYSICAL DRIVES
#----------------------------------------------------------------
PARTUUID=bc0a5264-02 / ext4 noatime,lazytime,rw 0 1
2

Yeah exactly. RPi models are detected based on the device tree files on the boot partition, and then further based on the hardware revision in /proc/cpuinfo, to allow swapping SD cards between RPi models without breaking device detection. But if no RPi device tree is present (those /boot/firmware/bcm*-rpi-*.dtb files), it applies a generic device tree identifier.

I think we should keep it that way, but not hard write that to /etc/.dietpi_hw_model_identifier. So once you boot on an actual RPi again, it will detect it again correctly. … yeah, I just changed it that way: dietpi-obtain_hw_model: never create missing /etc/.dietpi_hw_model_id… · MichaIng/DietPi@89d2ead · GitHub

Just remove that file and rerun the script:

/etc/.dietpi_hw_model_identifier
/boot/dietpi/func/dietpi-obtain_hw_model
source /boot/dietpi/func/dietpi-globals # load new variables to current shell session
1 Like
3

The real issue is the missing mount point for /boot/firmware within /etc/fstab. This would need to be added.

PARTUUID=bc0a5264-01 /boot/firmware vfat noatime,lazytime,rw 0 2
1 Like
4

Thank you all.

I deleted /etc/.dietpi_hw_model_identifier and added the fstab line (I’m not familiar with Linux FS structure in Raspberry Pi).

Although I ran /boot/dietpi/func/dietpi-obtain_hw_model, the removed file isn’t recreated

❯ ls /etc/.dietpi_hw_model_identifier
ls: cannot access '/etc/.dietpi_hw_model_identifier': No such file or directory

I even applied the changes per the commit but that didn’t work, either.

Nevertheless, after rebooting the login text indeed shows RPi 4.

 - Device model : RPi 4 Model B (aarch64)

Sourcing /boot/dietpi/func/dietpi-globals doesn’t work in fish unfortunately.

Another annoyance I faced is the weird red power LED blinking. It should stay on all the time without blinking. Sometimes it stays off for minutes. On the other hand, The green SD card activity indicator behaves as expected.

Resetting the LED configurations via dietpi-led_control or setting them manually wouldn’t fix it.

Info 
┌──────┤ DietPi-LED_control ├──────┐
│ Please select an LED to          │
│ configure its trigger:           │
│                                  │
│  Reset Reset all LED triggers    │
│  1     : ACT [mmc0]              │
│  2     : PWR [default-on]        │
│  3     : default-on [default-on  │
│  4     : mmc0 [mmc0]             │
│  5     : mmc0:: [mmc0]           │
│                                  │
│                                  │
│      <Select>      <Exit>        │
│                                  │
└──────────────────────────────────┘

# cat /etc/udev/rules.d/dietpi-led_control.rules
# Added by DietPi:
SUBSYSTEM=="leds", KERNEL=="ACT", ACTION=="add", ATTR{trigger}="mmc0"
SUBSYSTEM=="leds", KERNEL=="PWR", ACTION=="add", ATTR{trigger}="default-on"
5

removing this file will get you back to default.

6

Yes, that’s the what resetting from the menu does actually.
In fact, The file content I pasted is an attempt of manually setting it via the menu but none of the attempts is successful.

7

It appears there are issues with the phone charger. It’s time to get a proper PSU.

  • dmesg
[16946.637439] hwmon hwmon1: Undervoltage detected!     [16950.669443] hwmon hwmon1: Voltage normalised
[16964.784383] hwmon hwmon1: Undervoltage detected!
[16968.813434] hwmon hwmon1: Voltage normalised
[16970.829436] hwmon hwmon1: Undervoltage detected!     [16988.973475] hwmon hwmon1: Voltage normalised
[16990.989442] hwmon hwmon1: Undervoltage detected!     [17031.309432] hwmon hwmon1: Voltage normalised
[17095.821439] hwmon hwmon1: Undervoltage detected!     [17101.869441] hwmon hwmon1: Voltage normalised
[17115.981453] hwmon hwmon1: Undervoltage detected!
[17122.029424] hwmon hwmon1: Voltage normalised
  • vcgencmd get_throttled
throttled=0x50005
throttled=0x50000
8

Don’t use phone chargers. They are not reliable. Always use a regular PSU.

1 Like
9

No need to add the fstab entry, that is present already. But containers by default have no access to block devices hence cannot mount drives and basically ignore fstab. Hence when booting an image with a container engine, all filesystems need to be mounted on the host first.

On RPi /etc/.dietpi_hw_model_identifier does not exist and is not created intentionally, because one image can support multiple RPi models.

About the LEDs: not all drivers support all triggers properly. Some triggers will just not change anything, or do something unexpected. Annoying that they still expose those non-functional triggers in the sysfs API, but that’s how it is. Hence play a bit with the available triggers, otherwise reset and reboot always restores system/kernel defaults.

10

are you sure? It was missing in

No mount option for /boot/firmware

11

Oh interesting, then yes. How did that disappear?