-
-
Notifications
You must be signed in to change notification settings - Fork 495
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Soquartz image does not read dietpi.txt from the config partition on first boot #6838
Comments
Can you check the log file: cat /var/tmp/dietpi/logs/fs_partition_resize.log |
Possibly related to #6822 |
|
Can you check this output: lsblk -nrbo FSTYPE,LABEL /dev/mmcblk1 | tail -1 |
|
And this returns "true", right? [[ $(lsblk -nrbo FSTYPE,LABEL /dev/mmcblk1 | tail -1) == 'vfat DIETPISETUP' ]] && echo true |
|
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 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. |
Interesting tidbits from startup journal:
It starts at least. (I skipped a bunch of generic startup services in the middle)
It goes into the automated startup after that, with a systemd reload and password changes, etc. |
All good. When you run the script just now, it works? /var/lib/dietpi/services/fs_partition_resize.sh
lsblk /dev/mmcblk1 |
Wow, yes. Worked fine.
|
Hmm, so why does it not detect the 2nd partition correctly when it runs on 1st boot 🤔. Will do some tests. |
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. |
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 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/ At least it is no bug with the scripts, but somehow a strange/slow detection of the 2nd partition of the eMMC. |
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:
|
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 🤔. |
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! |
Okay , I'll mark it as closed. Whatever the issue was 😄. |
This has popped back up again. Logging in via ssh drops into the first run configuration even though the dietpi.txt is configured. The same config on CM4 worked. (Unfortunately the download files are unversioned so I can't say specifically, but the cm4 download dates are mid-May.) Should I open as a fresh bug?
Edit to add, the manual steps earlier worked:
|
Hence the setup partition is not detected. It does see them now, right? lsblk -nrbo FSTYPE,LABEL /dev/mmcblk1 |
I hit it with ansible/etc so it isn't a clean install anymore, but nothing that would have affected partitions.
I can wipe it again as needed |
Ah, you removed the partition already. Not sure, would be interesting to know whether the label and filesystem are shown after the system booted, or whether it remains like this. Maybe some sort of race condition, but weird that a 2nd SD card partition is in such state while the 1st root partiton has been mounted already. |
Yah the manual run did that. |
I stood it up on the dev baseboard and it didn't happen. |
Maybe changed peripherals have some tiny effect on order/timing of hardware init, so I would not rule that out 100%. But great that it works now. Let me know when you face it again. We could then indeed test whether attaching/detaching other devices have any effect on it, maybe we find a pattern. At least I have no other idea so far. |
Creating a bug report/issue
Required Information
cat /boot/dietpi/.version
echo $G_DISTRO_NAME $G_RASPBIAN
uname -a
echo $G_HW_MODEL_NAME
or (EG: RPi3)Additional Information (if applicable)
echo $G_HW_UUID
Steps to reproduce
First method:
Alternate method:
2. Mount the 700M root partition and replace /boot/dietpi.txt with the preconfigured one
3. Boot
Expected behaviour
Actual behaviour
Extra details
The text was updated successfully, but these errors were encountered: