Soquartz image does not read dietpi.txt from the config partition on first boot

[disconn3ct]

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=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

• Kernel version | uname -a

Linux dietpi 6.6.7 #1 SMP PREEMPT Fri Dec 15 21:33:33 UTC 2023 aarch64 GNU/Linux

• SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)

Quartz64 (aarch64)

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

Turing pi 2 board

• SD card used | (EG: SanDisk ultra)

16G onboard EMMC

Additional Information (if applicable)

• Software title | (EG: Nextcloud)
• Was the software title installed freshly or updated/migrated?
• Can this issue be replicated on a fresh installation of DietPi?

• Bug report ID | echo $G_HW_UUID

Steps to reproduce

First method:

1. Flash image to EMMC
2. Mount the config partition and replace dietpi.txt with a preconfigured one
3. Boot

Alternate method:
2. Mount the 700M root partition and replace /boot/dietpi.txt with the preconfigured one
3. Boot

Expected behaviour

• Hands-free installation should complete.

Actual behaviour

• In the first method, it runs with the default interactive dietpi.txt.
• In the alternate, it runs the automated installation successfully but it skips the partition resize. That causes it to fail due to lack of space during the package updates.

Extra details

• The same dietpi.txt works on CM4s and RPI4s. I can't be sure the image release is the same because the downloads are unversioned.

[MichaIng]

Can you check the log file:

cat /var/tmp/dietpi/logs/fs_partition_resize.log

[disconn3ct]

Possibly related to #6822

[disconn3ct]

# cat /var/tmp/dietpi/logs/fs_partition_resize.log                                                                              
Removed "/etc/systemd/system/local-fs.target.wants/dietpi-fs_partition_resize.service".                                                             
Disk /dev/mmcblk1: 14.59 GiB, 15665725440 bytes, 30597120 sectors                                                                                   
Units: sectors of 1 * 512 = 512 bytes                                                                                                               
Sector size (logical/physical): 512 bytes / 512 bytes                                                                                               
I/O size (minimum/optimal): 512 bytes / 512 bytes                                                                                                   
Disklabel type: dos                                                       
Disk identifier: 0x97d97bfa                                               
                                                                          
Old situation:                                                            
                                                                          
Device         Boot   Start     End Sectors   Size Id Type                
/dev/mmcblk1p1 *      32768 1579791 1547024 755.4M 83 Linux               
/dev/mmcblk1p2      1579792 1581839    2048     1M  c W95 FAT32 (LBA)     
                                                                          
/dev/mmcblk1p1:                                                           
New situation:                                                            
Disklabel type: dos                                                       
Disk identifier: 0x97d97bfa                                               
                                                                          
Device         Boot   Start     End Sectors   Size Id Type                
/dev/mmcblk1p1 *      32768 1579791 1547024 755.4M 83 Linux               
/dev/mmcblk1p2      1579792 1581839    2048     1M  c W95 FAT32 (LBA)     
                                                                          
The partition table has been altered.                                     
resize2fs 1.47.0 (5-Feb-2023)                                             
The filesystem is already 193378 (4k) blocks long.  Nothing to do!

[MichaIng]

Can you check this output:

lsblk -nrbo FSTYPE,LABEL /dev/mmcblk1 | tail -1

[disconn3ct]

vfat DIETPISETUP

[MichaIng]

And this returns "true", right?

[[ $(lsblk -nrbo FSTYPE,LABEL /dev/mmcblk1 | tail -1) == 'vfat DIETPISETUP' ]] && echo true

[disconn3ct]

# [[ $(lsblk -nrbo FSTYPE,LABEL /dev/mmcblk1 | tail -1) == 'vfat DIETPISETUP' ]] && echo true
true

[MichaIng]

Hmm, this is the condition in the script to copy configs from and the FAT partition. So this all looks like it should, and hence should work. No idea why it was skipped 🤔.

Is this still the first boot session? Hence is there still the journalctl showing the system logs from first boot? It should not be possible, but probably somehow the 2nd partition is detected way later, after the script ran already.

I'll try to replicate and add some more (debug) output to the script. However, based on what we see the only explanation is that the condition did not match did does match now according to your test.

[disconn3ct]

Interesting tidbits from startup journal:
Partitions are in place before userspace starts:

Dec 30 22:08:22 DietPi kernel: mmc_host mmc2: card is non-removable.  
Dec 30 22:08:22 DietPi kernel: mmc_host mmc2: Bus speed (slot 0) = 375000Hz (slot req 400000Hz, actual 375000HZ div = 0)
Dec 30 22:08:22 DietPi kernel: mmc1: SDHCI controller on fe310000.mmc [fe310000.mmc] using ADMA
Dec 30 22:08:22 DietPi kernel: mmc_host mmc2: Bus speed (slot 0) = 50000000Hz (slot req 100000000Hz, actual 50000000HZ div = 0)
Dec 30 22:08:22 DietPi kernel: mmc1: new HS200 MMC card at address 0001                                                                             
Dec 30 22:08:22 DietPi kernel: mmcblk1: mmc1:0001 58A431 14.6 GiB                                                                                   
Dec 30 22:08:22 DietPi kernel:  mmcblk1: p1 p2                                                                                                      
Dec 30 22:08:22 DietPi kernel: mmcblk1boot0: mmc1:0001 58A431 4.00 MiB                                                                              
Dec 30 22:08:22 DietPi kernel: mmcblk1boot1: mmc1:0001 58A431 4.00 MiB
Dec 30 22:08:22 DietPi kernel: mmcblk1rpmb: mmc1:0001 58A431 4.00 MiB, chardev (236:0)

It starts at least. (I skipped a bunch of generic startup services in the middle)

Dec 30 22:08:22 DietPi systemd[1]: Starting dietpi-fs_partition_resize.service - DietPi-FS_partition_resize...
Dec 30 22:08:22 DietPi systemd[1]: systemd-firstboot.service - First Boot Wizard was skipped because of an unmet condition check (ConditionFirstBoot
=yes).
....
Dec 30 22:08:24 DietPi systemd[1]: Started systemd-rfkill.service - Load/Save RF Kill Switch Status.
Dec 30 22:08:24 DietPi systemd[1]: dietpi-fs_partition_resize.service: Deactivated successfully.    
Dec 30 22:08:24 DietPi systemd[1]: Finished dietpi-fs_partition_resize.service - DietPi-FS_partition_resize.
Dec 30 22:08:25 DietPi systemd[1]: Reached target local-fs-pre.target - Preparation for Local File Systems.
Dec 30 22:08:25 DietPi systemd[1]: Reached target swap.target - Swaps.

It goes into the automated startup after that, with a systemd reload and password changes, etc.

[MichaIng]

All good. When you run the script just now, it works?

/var/lib/dietpi/services/fs_partition_resize.sh
lsblk /dev/mmcblk1

[disconn3ct]

Wow, yes. Worked fine.

# /var/lib/dietpi/services/fs_partition_resize.sh

The partition table has been altered.
Disk /dev/mmcblk1: 14.59 GiB, 15665725440 bytes, 30597120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x97d97bfa

Old situation:

Device         Boot Start     End Sectors   Size Id Type
/dev/mmcblk1p1 *    32768 1579791 1547024 755.4M 83 Linux

/dev/mmcblk1p1: 
New situation:
Disklabel type: dos
Disk identifier: 0x97d97bfa

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk1p1 *    32768 30597119 30564352 14.6G 83 Linux

The partition table has been altered.
resize2fs 1.47.0 (5-Feb-2023)
Filesystem at /dev/mmcblk1p1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/mmcblk1p1 is now 3820544 (4k) blocks long.

NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
mmcblk1     179:0    0 14.6G  0 disk 
└─mmcblk1p1 179:1    0 14.6G  0 part /

/dev/root 15G 710M 14G 6% /

[MichaIng]

Hmm, so why does it not detect the 2nd partition correctly when it runs on 1st boot 🤔. Will do some tests.

[disconn3ct]

I'm going to reflash it (alternate method still, using /boot/dietpi.txt) and run the resize from the console, see if I can get it to complete.

Wiping it again for testing later isn't a problem if you need it.

[MichaIng]

It worked well here with the testing image I just created, which adds some more debug information to the log:

root@SOQuartz:~# cat /var/tmp/dietpi/logs/fs_partition_resize.log
Removed "/etc/systemd/system/local-fs.target.wants/dietpi-fs_partition_resize.service".
[ INFO ] Detected root drive /dev/mmcblk0 with root partition 1
[ INFO ] Detected trailing DietPi setup partition /dev/mmcblk0p2
mount: /dev/mmcblk0p2 mounted on /tmp/tmp.yshnndojqZ.
'/tmp/tmp.yshnndojqZ/dietpi.txt' -> '/boot/dietpi.txt'
'/tmp/tmp.yshnndojqZ/dietpi-wifi.txt' -> '/boot/dietpi-wifi.txt'
umount: /tmp/tmp.yshnndojqZ (/dev/mmcblk0p2) unmounted
rmdir: removing directory, '/tmp/tmp.yshnndojqZ'

The partition table has been altered.
Disk /dev/mmcblk0: 119.38 GiB, 128177930240 bytes, 250347520 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdf614d0f

Old situation:

Device         Boot Start     End Sectors   Size Id Type
/dev/mmcblk0p1 *    32768 1579847 1547080 755.4M 83 Linux

/dev/mmcblk0p1:
New situation:
Disklabel type: dos
Disk identifier: 0xdf614d0f

Device         Boot Start       End   Sectors   Size Id Type
/dev/mmcblk0p1 *    32768 250347519 250314752 119.4G 83 Linux

The partition table has been altered.
resize2fs 1.47.0 (5-Feb-2023)
Filesystem at /dev/mmcblk0p1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 15
The filesystem on /dev/mmcblk0p1 is now 31289344 (4k) blocks long.

root@SOQuartz:~#

This is a Samsung EVO Select 128 MB MB-ME128KA/EU SD card. It is the Model-A Baseboard, which has no onboard eMMC. Which baseboard do you use?

I have a Quartz64 Model A with an eMMC socket, which I could test. The other way round, could you test it with an SD card? In case, use the image here, so the log contains more information: https://dietpi.com/downloads/images/testing/
Ah, of course with this image, a test on eMMC would be likewise interesting, to see the lsblk output (included in the log) if the 2nd partition is not detected.

At least it is no bug with the scripts, but somehow a strange/slow detection of the 2nd partition of the eMMC.

[disconn3ct]

Sorry for the delay, I wasn't able to get back as quickly as I'd hoped.

I flashed the nightly with dietpi.txt on DIETPISETUP and it looks like it worked. The install is still running, but:

# cat fs_partition_resize.log
Removed "/etc/systemd/system/local-fs.target.wants/dietpi-fs_partition_resize.service".
[ INFO ] Detected root drive /dev/mmcblk1 with root partition 1
[ INFO ] Detected trailing DietPi setup partition /dev/mmcblk1p2
mount: /dev/mmcblk1p2 mounted on /tmp/tmp.4AmXwr9tcD.
'/tmp/tmp.4AmXwr9tcD/dietpi.txt' -> '/boot/dietpi.txt'
'/tmp/tmp.4AmXwr9tcD/dietpi-wifi.txt' -> '/boot/dietpi-wifi.txt'
umount: /tmp/tmp.4AmXwr9tcD (/dev/mmcblk1p2) unmounted
rmdir: removing directory, '/tmp/tmp.4AmXwr9tcD'

The partition table has been altered.
Disk /dev/mmcblk1: 14.59 GiB, 15665725440 bytes, 30597120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdf614d0f

Old situation:

Device         Boot Start     End Sectors   Size Id Type
/dev/mmcblk1p1 *    32768 1579847 1547080 755.4M 83 Linux

/dev/mmcblk1p1: 
New situation:
Disklabel type: dos
Disk identifier: 0xdf614d0f

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk1p1 *    32768 30597119 30564352 14.6G 83 Linux

The partition table has been altered.
resize2fs 1.47.0 (5-Feb-2023)
Filesystem at /dev/mmcblk1p1 is mounted on /; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 2
The filesystem on /dev/mmcblk1p1 is now 3820544 (4k) blocks long.

[MichaIng]

Okay great, that is as it should be. Aside of using the new image, you did everything exactly as before? Not sure what solved it, since I did not change anything but the debug output. Probably there was a little quirk with the image, or the newer kernel shipped a fix/enhancement for the eMMC driver 🤔.

[disconn3ct]

Aside of using the new image, you did everything exactly as before?

100%. For completeness, here's the really long version. Twice before opening the bug, I tossed the emmc onto the reader and flashed it with rpi imager. After flashing I mounted, copied the config to the config partition, unmounted, removed it from the reader and installed it on the board. Power on via the turing web ui, wait for ssh to appear on the static IP. On the first failure, I just powered it down and reflashed as above. On the second, I got the serial console working and saw the interactive install (or maybe it was the interactive take-over.)

For the third try I put the dietpi.txt in place on both partitions. It ran the automated setup but skipped the resize.

Using the new image, I flashed with rpi, copied to the config partition only and it worked fine.

Thanks!

[MichaIng]

Okay , I'll mark it as closed. Whatever the issue was 😄.