Number of partitions on /dev/mmcblk0

[jaapeldoorn]

Can the check on the number of partions on /dev/mmcblk0 be skipped? I do have only one partition on my SD card...

[framps]

Pleas provide the debug log.

[jaapeldoorn]

As requested:
raspiBackup.log

Thank you in advance for your support!

jaapeldoorn

[framps]

Ok. You have no normal partitioning used on a Raspberry.

20251022-165904 DBG 2200:              PARTUUID=52a38361-01  /boot/firmware  vfat    defaults          0       2
20251022-165904 DBG 2200:              PARTUUID=b3786e66-03  /               ext4    defaults,noatime  0       1
20251022-165904 DBG 2200:              PARTUUID=b3786e66-01  /mnt/myNAS      ext4    defaults
20251022-165904 DBG 2200:              PARTUUID="60129087-d7d8-4ede-a436-9e76397a3bfd"  /mnt/piNAS  ext4  defaults

Standard on a Raspberry is to have /boot/firmware and and /as the first two partitions on the device. The easiest solution (for me 😄 ) would be you change your setup and move / to PARTUUID=52a38361-02. Is there any reason you have to stick with your current setup?

[jaapeldoorn]

I do agree that my setup is not a typical ons for a RaspberryPi. I do have as much as possible of the OS on a physical hard drive to avoid crashes from the SD card.

sudo lsblk -o NAME,PARTUUID
NAME        PARTUUID
sda
`-sda1      60129087-d7d8-4ede-a436-9e76397a3bfd
sdb
|-sdb1      b3786e66-01
|-sdb3      b3786e66-03
`-sdb4      b3786e66-04
mmcblk0
`-mmcblk0p1 52a38361-01

As I want to avoid to many read/writes on the SD card I do not prefer your solution. Is there en alternative?

Jaap

[framps]

It's common folks move their complete OS to a HDD. But then they move both /boot and / to the HDD and /boot on first partition and / on second partition and no longer use an SD card. Do you have an RPi which doesn't support USB boot?

[jaapeldoorn]

Not sure. It running fine right now. In version 6.9.1. it worked with this setup. Was there any reason to change the logic?

[framps]

That's an important information it worked with 0.6.9.1 👍 .

You use an external root filesystem which is supported by raspiBackup for old Raspberries which don't support USB boot. This even can be used by Raspberries which support USB boot. Unfortunately external root filesystem is not part of the raspiBackup regression package :-(. In 0.7 there were major changes in this area and it looks like these changes screwed up the external root filesystem support :-(.

I already setup an environment and will fix the external root filesystem support which doesn't work any more. But nevertheless I suggest to copy the boot partition from SD card to your HDD, update the UUIDs and run without any SD card if you run an USB boot capable RPi ;-)

[jaapeldoorn]

Thank you. Testing today confirmed this changed from version 0.6.9.1 to version 0.7.0.

I've learned that my RPi can be changed to USB bootable. As my setup is a-typical I could not find a tutorial on the web for this situation.
Are you suggesting the following steps?

1. create a FAT partition on one of the HDD
2. copy the content of /boot to that new partion
3. retrieve the UUID of the new partition
4. add the new UUID to /etc/fstab
5. apply the logic to make the pi USB bootable (change config on both locations)
6. rebooting and startup from HDD

Are there any requirements on the size / location / etc of the FAT boot partition?

[framps]

Well, I have no clue what's your Linux experience.

The safetiest way would be to setup a new HDD: Create a FAT partition #1 of 512 MB and an ext4 partition #2. Then copy #1 from the SD card and #3 from your HDD to the new disk. Then either use my tool syncUUIDs to update the UUIDs in cmdline.txt and fstab or do it manually. Keep in mind you have to update both files, not just /etc/fstab.

You also can update your existing HDD but this requires careful repartitioning and much more.

[framps]

I created a bug report for you -> #930

[framps]

I spent some time in the issue and already created an untested fix. Unfortunately I'm right now in the final phase to publish next release of raspiBackup v0.7.1.2. It's too late to include the fix in next release because thoroughly tests are required.

So I suggest to either correct the partitioning or go backup to 0.6.9.1. Use option -V to restore the old release.

[jaapeldoorn]

Thank you for the quick investigation. Fully understand that this not can be included in the pending release.

[framps]

If you still run in your non standard environment would be great you test the current fix to create a backup and restore the backup later on.

curl -s https://raw.githubusercontent.com/framps/raspiBackup/master/scripts/raspiBackupDownloadFromGit.sh | bash -s -- int_930

[jaapeldoorn]

I did check this:

--- RBK0017I: Backup finished successfully
--- RBK0010I: RasPiServ3: raspiBackup.sh V0.7.1.2-int_930 - 2025-10-26 (5a92b93) stopped at Mon Oct 27 21:26:28 CET 2025 with rc 0
--- RBK0167I: Sending email
--- RBK0026I: Debug logfile saved in /mnt/piNAS/piBackup/RasPiServ3/RasPiServ3@debian13-rsync-backup-20251027-211148/raspiBackup.log

Thank you for your support!

[framps]

👍 Thank you very much for your test. The disabling of the check was the easy part. Please test also the restore if possible. The UUID update in your 3rd partition required much more changes 😉

[jaapeldoorn]

I did a check on the most important files. They were present in the backup. Will probably test the restore functionality during the transition to USB bootable Rpi. Timing tbd.

[framps]

Please check if the restored system boots. I had to update the UUID synchronization code because you use partition #3 instead of #2

[jaapeldoorn]

I will probably have time to do the restore tonight. Can you please help me out what the restore procedure is in my case? Last version of the /etc/fstab is

proc            /proc           proc    defaults          0       0
PARTUUID=b3786e66-02  /boot/firmware  vfat    defaults          0       2
PARTUUID=b3786e66-03  /               ext4    defaults,noatime  0       1
PARTUUID=b3786e66-01  /mnt/myNAS      ext4    defaults

(I probably succeeded in making the RPi USB bootable. Will have a final check later today).

[framps]

Just use the description on this page how to restore a backup with an external root partition.

[jaapeldoorn]

I've learned this week why I'm still using an SD card for the boot sector. In case multiple USB drives are connected the RPi will search on the first drive found. What the first drive will be is not always the same. So in case of USB boot the drive without the boot partition has to be removed until boot has been completed. So I returned back to the SD card boot.
Given all the challenges / errors / etc I decided to restore a full dd backup to that drive. So no raspibackup restore is scheduled for the upcoming period.

[framps]

That's true if both USB devices have a boot partition. Then it's unpredictable where the Raspberyy boots from - even there exist some tricks to disable an USB drive which has a boot partition. But if there is only one USB device with a boot partition it's the USB disk which will be used to boot the Raspberry 😉

[jaapeldoorn]

I don't think there were two boot partitions in the system at that time: It is a huge EXT4 partition with another label. My expectation is that RPi will only recognize FAT partitions as a boot partition.