Creating a bug report/issue
[Y] I have searched the existing open and closed issues
Required Information
- DietPi version |
cat /boot/dietpi/.version
G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=25
G_DIETPI_VERSION_RC=1
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
- Distro version |
echo $G_DISTRO_NAME $G_RASPBIAN
bookworm 0
- Kernel version |
uname -a
Linux iot-turing-node-1 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
- Architecture |
dpkg --print-architecture
arm64
- SBC model |
echo $G_HW_MODEL_NAMEor (EG: RPi3)
RPi CM 4 (aarch64)
- Power supply used | (EG: 5V 1A RAVpower)
Pi CM4 is mounted on a Turing Pi 2 board mounted in a Mini-ITX case with a 180w PSU
- SD card used | (EG: SanDisk ultra)
None - Install is to emmc
Additional Information (if applicable)
- Software title | (EG: Nextcloud)
dietpi-drive_manager
- Was the software title installed freshly or updated/migrated?
fresh install
- Can this issue be replicated on a fresh installation of DietPi?
Yes - multiple times on two different CM4s/SATA disks/board slots
← If you sent a “dietpi-bugreport”, please paste the ID here →
- Bug report ID |
echo $G_HW_UUID
Steps to reproduce
- Pi CM4 is installed on a Turing Pi 2 board in node slot 1 or 2. These slots have a MPCIE adapter installed with a 500GB SATA disk attached.
- Install Dietpi, either from BMC - Flash Node or via USB cable from a laptop
- Either during the installation process, or after installation is complete, use dietpi-drive_manager to transfer RootFS to the SATA disk.
- Select the SATA disk (/dev/sda)
- Select Transfer RootFS to the SATA disk.
- Format the disk as ext4
- After formatting, screen shows rsync being installed and a copy of the rootfs being copied to the SATA disk
- After copying there’s a mandatory reboot. On rebooting the system doesn’t come back online.
Expected behaviour
After the reboot the system should come back online with /boot on the emmc and / on the SATA disk (/dev/sda)
Actual behaviour
During the boot sequence the system gets to the point where it has to mount / to proceed further but it just waits forever.
Extra details
I’ve tried formatting as whole disk or partition - no difference.
I’ve tried a second Pi CM4 and SATA disk in the second Turing Pi Node slot - no difference
I’ve re-loaded Dietpi without doing Transfer RootFS. I can successfully mount /dev/sda and I can see the copy of the root FS on the disk so it appears that the copy succeeded and that the SATA disk isn’t corrupt. This also confirms that any necessary software/drivers to support the MPCIE connected SATA disk are also in place.
I’ve tried both Bookworm and Bullseye installs to check it’s not a recent Bookwork issue, but both behave the same way.
Using the Turing Pi BMC I can mount the Pi EMMC as a MSD. The OS appears to be intact. I’m not 100% sure about this but the content of /boot/cmdline.txt and /etc/fstab don’t look correct…
# cat cmdline.txt
root=PARTUUID=607b14ce-b9da-4df7-af49-09c255e9fa36 rootfstype=ext4 rootwait net.ifnames=0 logo.nologo console=tty1
# cat /mnt/node2/etc/fstab
# 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=1922M,noatime,lazytime,nodev,nosuid,mode=1777
tmpfs /var/log tmpfs size=50M,noatime,lazytime,nodev,nosuid
#----------------------------------------------------------------
# MISC: ecryptfs, vboxsf, glusterfs, mergerfs, bind, Btrfs subvolume
#----------------------------------------------------------------
#----------------------------------------------------------------
# SWAP SPACE
#----------------------------------------------------------------
#----------------------------------------------------------------
# PHYSICAL DRIVES
#----------------------------------------------------------------
PARTUUID=28a6ec92-02 / ext4 noatime,lazytime,rw 0 1
PARTUUID=28a6ec92-01 /boot vfat noatime,lazytime,rw 0 2
UUID=38311a99-3575-4626-b4f0-fefd857e4313 /mnt/38311a99-3575-4626-b4f0-fefd857e4313 ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount
If I’m reading that correctly, cmdline.txt thinks rootfs is on UUID=607b14ce-b9da-4df7-af49-09c255e9fa36 (SATA disk) but fstab thinks it’s on PARTUUID=28a6ec92-02 which is the second partition in emmc (boot is PARTUUID=28a6ec92-01). The UUID is definitely not the emmc, but I forgot to capture the PARTUUID for the SATA disk when repeating this to document here.
If I change the PARTUUID in cmdline.txt to 28a6ec92-02 to match fstab the system boots (it’s pingable) but I can’t connect by SSH (connection refused).
I’ve tried changing the fstab so that it matches the rootfs PARTUUID in cmdline.txt and then rebooting the CM4 but it still hangs on startup.
I’m out of ideas of what to try next. Suggestions are welcome!
A typical symptom for a system running Berryboot.