Boot from a backup created from an RPI3 running RaspbianOS 32 lite fails with "ALERT! PARTUUID=a1f2b077-02 does not exist. Dropping to a shell!"

[framps]

I created a backup successfully for the system mentioned in the issue title.

When I started the restored backup (restored with dd) I get

Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root file system device. 
...
ALERT! PARTUUID=a1f2b077-02 does not exist. Dropping to a shell!

I checked the backup image and get

sudo blkid
/dev/sdc1: UUID="BDDC-31AC" TYPE="vfat" PARTUUID="966ad0d3-01"
/dev/sdc2: UUID="b4f05dfa-8a60-47e8-a6f2-f923d6d339dc" TYPE="ext4" PARTUUID="966ad0d3-02"

There is indeed no PARTUUID a1f2b077-02.

shrink-backup.log In the debug log PARTUUID a1f2b077-02 is used. But the created backup image has PARTUUID="966ad0d3-02".

[UnconnectedBedna]

Please read https://github.com/UnconnectedBedna/shrink-backup/issues/40#issuecomment-2243840867 and continue conversation here about this topic. :slightly_smiling_face:

If the content of cmdline.txt is a1f2b077-02 you must have done some trickery, that just simply does not happen by itself. And the script can't make up PARTUUID:s, it's not smart enough, so it must have come from somewhere.. xD Can you run a fresh backup to confirm it still fails at boot?

[framps]

If the content of cmdline.txt is a1f2b077-02 you must have done some trickery,

Yes, in cmdline.txt and /etc/fstab of tha restored system a1f2b077-02 is used but the partuuid of the SD card is 966ad0d3-02 :thinking:

Ok. Now I execute a backup and restore again and document in detail what I do:

pi@raspberrypi-bookworm32-light:~ $ uname -a
Linux raspberrypi-bookworm32-light 6.6.28+rpt-rpi-v7 #1 SMP Raspbian 1:6.6.28-1+rpt1 (2024-04-22) armv7l GNU/Linux
pi@raspberrypi-bookworm32-light:~ $ cat /etc/os-release 
PRETTY_NAME="Raspbian GNU/Linux 12 (bookworm)"
NAME="Raspbian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

pi@raspberrypi-bookworm32-light:~ $ lsblk -f -o +partuuid,ptuuid
NAME        FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS    PARTUUID                             PTUUID
sda                                                                                                                                    89094449-425c-49b1-a0f8-901795f76635
├─sda1      ext4   1.0         94a61e86-27fa-450e-a93f-81f85d7ffa4a  143.5G    22% /backup        1a95df5f-2644-46ef-9182-a9b6ced248f4 89094449-425c-49b1-a0f8-901795f76635
└─sda2      ext4   1.0         946b0b1c-bdba-45a0-ac32-56354fdd69bb                               6ea82550-5bda-45b3-b4bd-1bfe96e83b4d 89094449-425c-49b1-a0f8-901795f76635
mmcblk0                                                                                                                                a1f2b077
├─mmcblk0p1 vfat   FAT32       BDDC-31AC                             413.7M    19% /boot/firmware a1f2b077-01                          a1f2b077
└─mmcblk0p2 ext4   1.0         b4f05dfa-8a60-47e8-a6f2-f923d6d339dc    3.8G    39% /var/hdd.log   a1f2b077-02                          a1f2b077
                                                                                   /                                                   

pi@raspberrypi-bookworm32-light:~ $ sudo ./shrink-backup -a -l  /backup/shrinkBackup.img 
## Debugging requested, writing to log file: ./shrink-backup.log
## Zoom speed NOT requested...
## Scanning filesystem and calculating...
#####################################################################################
# A backup will be created at /backup/shrinkBackup.img                              #
# ext4 filesystem detected on root                                                  #
# --------------------------------------------------------------------------------- #
# Write to logfile: true                                                            #
# Zoom speed requested: false                                                       #
# Autocalculate img root partition size: true                                       #
# Autoexpand filesystem at boot: true                                               #
# Use exclude.txt: false                                                            #
# Bootsector size: 515MiB                                                           #
# Estemated root usage: 2698MiB                                                     #
# Auto calculated size (root partition): 3617MiB                                    #
# Total img size: 4133MiB                                                           #
#####################################################################################
## Do you want to continue? [y/n] y

## Creating bootsector...
...
Number of files: 76,558 (reg: 62,310, dir: 7,086, link: 7,162)
Number of created files: 76,175 (reg: 61,931, dir: 7,082, link: 7,162)
Number of deleted files: 1 (dir: 1)
Number of regular files transferred: 61,584
Total file size: 3.90G bytes
Total transferred file size: 2.54G bytes
Literal data: 2.54G bytes
Matched data: 0 bytes
File list size: 2.69M
File list generation time: 0.003 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 2.55G
Total bytes received: 1.25M

sent 2.55G bytes  received 1.25M bytes  12.10M bytes/sec
total size is 3.90G  speedup is 1.53
## Rsync done...
## Please stand by...
## Finalizing filesystem...
/dev/loop0p2: /lost+found not found.  CREATED.

       75841 inodes used (32.76%, out of 231536)
          27 non-contiguous files (0.0%)
          63 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 68778/3
      699645 blocks used (75.55%, out of 926049)
           0 bad blocks
           1 large file

       61584 regular files
        7085 directories
           0 character device files
           0 block device files
           0 fifos
         347 links
        7162 symbolic links (7051 fast symbolic links)
           0 sockets
------------
       76178 files
## Remounting for autoexpansion...
## Mounting img root partition...
## Mounting img boot partition...
## Enabling fs-autoexpand...
## Raspberry pi detected...
## Raspberry pi filesystem autoresizing at boot...
## Backup done.
#####################################################################################
## Write to logfile: true                                                           #
## Autoexpand filesystem at boot: true                                              #
## Use exclude.txt: false                                                           #
## /backup/shrinkBackup.img is 4133MiB with a root partition of 3617MiB             #
## Please wait for the system to reboot after restoring an image with autoexpansion #
#####################################################################################
## Exiting and cleaning up...
## Please stand by...
## Done.
## Elapsed time: 05.07
pi@raspberrypi-bookworm32-light:~ $ 

[framps]

Debug log of the backup: shrink-backup.log

[framps]

pi@raspberrypi-bookworm32-light:~ $ lsblk -f -o +partuuid,ptuuid
NAME        FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS    PARTUUID                             PTUUID
sda                                                                                                                                    89094449-425c-49b1-a0f8-901795f76635
├─sda1      ext4   1.0         94a61e86-27fa-450e-a93f-81f85d7ffa4a  140.4G    23% /backup        1a95df5f-2644-46ef-9182-a9b6ced248f4 89094449-425c-49b1-a0f8-901795f76635
└─sda2      ext4   1.0         946b0b1c-bdba-45a0-ac32-56354fdd69bb                               6ea82550-5bda-45b3-b4bd-1bfe96e83b4d 89094449-425c-49b1-a0f8-901795f76635
sdb                                                                                                                                    
mmcblk0                                                                                                                                a1f2b077
├─mmcblk0p1 vfat   FAT32       BDDC-31AC                             413.7M    19% /boot/firmware a1f2b077-01                          a1f2b077
└─mmcblk0p2 ext4   1.0         b4f05dfa-8a60-47e8-a6f2-f923d6d339dc    3.8G    39% /var/hdd.log   a1f2b077-02                          a1f2b077                                                                                   /                           

/dev/sdb is the SD card which will get the restored image from /backup/shrinkBackup.img.

pi@raspberrypi-bookworm32-light:~ $ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 7.28 GiB, 7816085504 bytes, 15265792 sectors
Disk model: MassStorageClass
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Restoring the backup

pi@raspberrypi-bookworm32-light:~ $ sudo dd if=/backup/shrinkBackup.img of=/dev/sdb bs=2MiB
066+1 records in
2066+1 records out
4334165504 bytes (4.3 GB, 4.0 GiB) copied, 239.477 s, 18.1 MB/s

[framps]

Check of the restored image:

pi@raspberrypi-bookworm32-light:~ $ sudo blkid
/dev/mmcblk0p2: UUID="b4f05dfa-8a60-47e8-a6f2-f923d6d339dc" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="a1f2b077-02"
/dev/mmcblk0p1: UUID="BDDC-31AC" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="a1f2b077-01"
/dev/sda2: UUID="946b0b1c-bdba-45a0-ac32-56354fdd69bb" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="6ea82550-5bda-45b3-b4bd-1bfe96e83b4d"
/dev/sda1: UUID="94a61e86-27fa-450e-a93f-81f85d7ffa4a" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="1a95df5f-2644-46ef-9182-a9b6ced248f4"
/dev/sdb2: UUID="b4f05dfa-8a60-47e8-a6f2-f923d6d339dc" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8b3caecd-02"
/dev/sdb1: UUID="BDDC-31AC" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="8b3caecd-01"

/dev/sdb uses PARTUUID 8b3caecd-01

pi@raspberrypi-bookworm32-light:~ $ sudo mount /dev/sdb1 /mnt
mount: (hint) your fstab has been modified, but systemd still uses
       the old version; use 'systemctl daemon-reload' to reload.
pi@raspberrypi-bookworm32-light:~ $ cat /mnt/cmdline.txt 
console=serial0,115200 console=tty1 root=PARTUUID=a1f2b077-02 rootfstype=ext4 fsck.repair=yes rootwait cfg80211.ieee80211_regdom=DE video=HDMI-A-1:1280x800M@60

cmdline.txt used PARTUUID a1f2b077-02 which is the PARTUUID of the active OS and used to create and restore the backup.

Same for /etc/fstab ...

pi@raspberrypi-bookworm32-light:~ $ sudo mount /dev/sdb2 /mnt
mount: (hint) your fstab has been modified, but systemd still uses
       the old version; use 'systemctl daemon-reload' to reload.
pi@raspberrypi-bookworm32-light:~ $ cat /mnt/etc/fstab
proc            /proc           proc    defaults          0       0
PARTUUID=a1f2b077-01  /boot/firmware  vfat    defaults,ro          0       2
PARTUUID=a1f2b077-02  /               ext4    defaults,noatime  0       1

# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that

So somehow the PARTUUID of the restored image doesn't match the PARTUUID of the system which was saved and restored.

pi@raspberrypi-bookworm32-light:/backup $ sudo losetup -P /dev/loop0 shrinkBackup.img
pi@raspberrypi-bookworm32-light:/backup $ sudo blkid
/dev/mmcblk0p2: UUID="b4f05dfa-8a60-47e8-a6f2-f923d6d339dc" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="a1f2b077-02"
/dev/mmcblk0p1: UUID="BDDC-31AC" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="a1f2b077-01"
/dev/sda2: UUID="946b0b1c-bdba-45a0-ac32-56354fdd69bb" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="6ea82550-5bda-45b3-b4bd-1bfe96e83b4d"
/dev/sda1: UUID="94a61e86-27fa-450e-a93f-81f85d7ffa4a" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="1a95df5f-2644-46ef-9182-a9b6ced248f4"
/dev/sdb2: UUID="b4f05dfa-8a60-47e8-a6f2-f923d6d339dc" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8b3caecd-02"
/dev/sdb1: UUID="BDDC-31AC" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="8b3caecd-01"
/dev/loop0p2: UUID="b4f05dfa-8a60-47e8-a6f2-f923d6d339dc" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8b3caecd-02"
/dev/loop0p1: UUID="BDDC-31AC" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="8b3caecd-01"

As you can see the backup image (/dev/loop0) already uses PARTUUID 8b3caecd-02.

I now will execute the same procedure with a 64bit lite image to check whether it's an issue with the 32bit version.

[UnconnectedBedna]

Reading the log file: 2024-07-22 22:19:36 [DEBUG] - LOCAL_BOOT_UUID=BDDC-31AC | LOCAL_ROOT_UUID=b4f05dfa-8a60-47e8-a6f2-f923d6d339dc | LOCAL_ROOT_PARTUUID=a1f2b077-02

The correct PARTUUID according to the lsblk you provided so there is nothing wrong with the script.

I would suspect the reason you get a new PARTUUID is because you dd on the same machine as you made the backup from, so linux maybe detects the conflict and changes it for you because you can not have 2 of the same unique identifiers in your devices. ESPECIALLY not the same as the root you are currently running.

Redo the dd on another machine and retry.

[framps]

I would suspect the reason you get a new PARTUUID is because

Sounds reasonable. But I just executed the same procedure with the 64 bit OS and get the identical PARTUUID on the backup (/dev/loop0).

pi@raspberrypi-boorkworm64-lite:~ $ sudo losetup -P /dev/loop0 /backup/shrinkBackup64.img
pi@raspberrypi-boorkworm64-lite:~ $ sudo blkid
/dev/mmcblk0p1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="91FE-7499" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="f8b36121-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="56f80fa2-e005-4cca-86e6-19da1069914d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="f8b36121-02"
/dev/sdb2: UUID="b4f05dfa-8a60-47e8-a6f2-f923d6d339dc" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="8b3caecd-02"
/dev/sdb1: UUID="BDDC-31AC" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="8b3caecd-01"
/dev/loop0p1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="91FE-7499" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="f8b36121-01"
/dev/loop0p2: LABEL="rootfs" UUID="56f80fa2-e005-4cca-86e6-19da1069914d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="f8b36121-02"
/dev/sda2: UUID="946b0b1c-bdba-45a0-ac32-56354fdd69bb" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="6ea82550-5bda-45b3-b4bd-1bfe96e83b4d"
/dev/sda1: UUID="94a61e86-27fa-450e-a93f-81f85d7ffa4a" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="1a95df5f-2644-46ef-9182-a9b6ced248f4"

So I think the restored image now will boot. Why this doesn't work on the 32 bit OS ... I don't know.

Will execute the restore now of the 64 bit OS to /dev/sdb.

[UnconnectedBedna]

Try rebooting the rpi3 if you haven't, then make a new img and loop that img ON ANOTHER MACHINE and check the partuuid. As you figured out, you don't need to write the img to see the uuid.

I hope you are aware you can use shrink-backup for this. sudo shrink-backup --loop /path/to/backup.img :smiley:

[framps]

The restored 64 image boots successfully even I used the same OS which I saved with shrink-backup to restore the backup. So it looks like there is some issue with shrink-backup and the 32 bit RaspbianOS lite. I still have some RPi2 in production which can run the 32 bit OS only.

I hope you are aware you can use shrink-backup for this. sudo shrink-backup --loop /path/to/backup.img

No. I wasn't because I frankly didn't understand what you meant with looping in the help text. Maybe you should write something like mount image to a loop device or similar to make this clear :wink:

[UnconnectedBedna]

No. I wasn't because I frankly didn't understand what you meant with looping in the help text. Maybe you should write something like mount image to a loop device or similar to make this clear 😉

No, I can't do that, because it doesn't get mounted, it gets looped. Mount you will have to do yourself afterwards if you want... xD

I don't think I can make it clearer than "Loop img file and exit"

And here comes the sucky part. This is not a bug, because rpi3 is not supported, and I am not sure I want to either, since I have no way to continuously testing it reliably.

But I WILL accept pr:s if you feel up to the task.. hint hint.

I won't close the issue, yet, in case you want to keep looking for a solution and use me as "support".

[framps]

No, I can't do that, because it doesn't get mounted, it gets looped.

:smile: Ok. You won :+1: Strictly speaking it's not a mount. I checked the losetup man page and it says

"losetup is used to associate loop devices with regular files or block devices,"

A loop device is usually used to access the partitions of an image file and thus you usually use losetup together with mount and that's why a lot of people use mount instead of associate. That's what rpi-clone for example does at the end of the backup image creation: Associate the backup image with a loop device and mount the boot and root partition so they can be easily accessed in a second window. Maybe that's a convenience enhancement for shrink-backup :wink:

This is not a bug, because rpi3 is not supported, and I am not sure I want to either, since I have no way to continuously testing it reliably.

It's a bug as long it's not documented RPI3 is not supported :wink: I think it's not an RPi3 issue but a 32 bit RaspbianOS issue. I'm quite sure it's possible to reproduce the issue on a RPi4 or RPi5 when you use RaspianOS 32. Frankly it doesn't make sense to run the 32 bit OS on this HW. But from a testing point of you can easily execute tests and maybe modify shrink-backup to support also 32 bit OS. Maybe it's a low hanging fruit.

[UnconnectedBedna]

It's a bug as long it's not documented RPI3 is not supported

Amiga and C64 is also not mentioned, should they be considered supported? xD What is mentioned in the README.MD is what is supported, nothing else. Edit Actually, now that I read it, it could probably do with an update on the wording. End edit It might work on other things too, for example I can use it on my btrfs arch install on my deskotp and laptop, but it's not very useful for that. (I have actually tried, wrote the img to a portable nvme, connected it to the usb and booted from it. Kinda blew my mind that it worked, but I would never use it for that)

If people come in with what they think is a bug, like you do, if they make a good case, I might implement support for whatever they are using. Done that for both dietpi and and special usecase in webmin, and then added that information on the readme. But since I have no way of even trying to find out why it fails on something that DEMANDS 32bit, I consider this a non supported issue.

Actually, now that I read it, I see that it is incorrect too, since f2fs does NOT support autoexpansion, I have to rephrase that and probably squeeze in 64bit somewhere. Something like:

Supported for 64-bit versions of Raspberry Pi os (bookworm and older), Armbian, Manjaro-arm, DietPi & ArchLinuxARM for rpi with ext4 or f2fs root partition but probably works on most SBC distributions. Autoexpansion works on all except f2fs.

Maybe it's a low hanging fruit.

Quite the opposite actually, for 2 reasons.

1. I don't think there is hardly anybody using 32-bit on a 64-bit processors, not even when emulating nowdays.
2. I have enough testing on each release as it is, I don't need more work unless it is actually useful for users...

But again, if someone finds out what this is about, feel free to inform me and if it's an easy fix, sure...

You never did what I asked though, witch was to reboot, make a fresh img, bring that img to another system, loop it and check the PARTUUID. Becasue I STILL believe there is something strange with your system, not the script, the script READS the PARTUUID correctly, and a dd, well, you know what a dd does, and after that, the PARTUUID is decided and the script never touches anything around it.

[framps]

Supported for 64-bit versions of Raspberry Pi os (bookworm and older), Armbian, Manjaro-arm, DietPi & ArchLinuxARM for rpi with ext4 or f2fs root partition but probably works on most SBC distributions. Autoexpansion works on all except f2fs.

:+1:

1. I don't think there is hardly anybody using 32-bit on a 64-bit processors, not even when emulating nowdays.

I wrote it's useless but I wanted to point out you can debug the 32 bit issue even if you don't have a 32 bit RPi - if you want support the old 32 bit RPis.

2. I have enough testing on each release as it is, I don't need more work unless it is actually useful for users...

I see your point. That's why I support RPis in raspiBackup only and added an --unsupported flag for users using another OS or HW. I have RPI2, RPI3 and RPi4 for tests but no Orange and other non Raspberry HW.

You never did what I asked though, witch was to reboot, make a fresh img, bring that img to another system, loop it and check the PARTUUID.

Will do now :wink:

[UnconnectedBedna]

I wrote it's useless but I wanted to point out you can debug the 32 bit issue even if you don't have a 32 bit RPi - if you want support the old 32 bit RPis.

No, I would not feel comfortable calling that supported. Supported would be if I had ran tests of the script on hardware that requires 32-bit, there can very well be differences.

I do own a rpi2, but it has been "lended out" (read indefinately) so I can't exactly rely on that for testing. And my rpi3 is a B+, so it's also 64 bit..

[framps]

Will do now

Bullseye :smile:

I checked the 32 bit image backup PARTUUID on my Linux desktop and it's identical to the PARTUUID of the system backed up. Then I restored the backup with dd on my Linux desktop to a SD card and finally booted the restored image on my RPi3 ... success :clap:

Looks like some mysterious things happen when there are identical PARTUUIDs on a system when a 32 bit OS is used.

I saw you asked for feedback: I got lot of issues with raspiBackup when I kept the PARTUUID in the backup identical to the source. A lot of folks created a backup and plugged in the backup on the system which was backed up just to test the backup. As you already wrote - it's dangerous to have the same PARTUUIDs multiple times on a system and creates a lot of headache. That's why I finally decided to change the new PARTUUID generation default in the backup which was initially off to on.

[UnconnectedBedna]

So there never was anything wrong huh..? xD

Looks like some mysterious things happen when there are identical PARTUUIDs on a system when a 32 bit OS is used.

No, you did something strange, nothing has changed in regards to the rpi3 issue you posted about. It just "suddenly started working" witch means you did something different. If the user does strange things like that, it's on the user. Sorry... :innocent:

Maybe you misunderstand what the script is.

• The script is not: "here, have a pacifier and let me hold your hand for you, idiot proof - kinda script".
• The script Is: "a pretty simple way of making bootable img files from your system in a fraction of the tame it takes on other backup software, with the possibility of advanced usage".

Suddenly changing partuuid and things like that is absolutely NOT what the script is about. If that is something you are looking for, I suggest you turn towards something else because it will NEVER happen on this script, it totally goes against the mentality of cross platform and simplicity.

As an example, rpiOS is pretty alone with the usage of PARTUUID over "normal" UUID, how would I implement checks against that? It would all be a nightmare to maintain. If the script was for only one single distribution, maybe I could consider something like that, but it is still very unlikely.

When I asked the devs of rpiOS what the reason was, it was stated exactly like you did: "We got tons and tons of "bug reports" where users did not understand that they can not boot with 2 devices with the same PARTUUID connected at the same time, so we decided to force implement a change when using the autoexpansion in raspi-config". Ie, the users were dumb, we created a way to hide that fact by changing things without letting the user know. That kind of mentality will NEVER be acceptable in shrink-backup. THAT IS A PLEDGE.

Might sound strange, but to me it's a mentality thing, about shrink-backup never ever patting the user on the head because the user is dumb, even if I sometimes sometimes might think so.. :melting_face:

If the script doesn't work, the user is more than welcome to come here, read the README on the github to educate themselves, reading the wiki, or even ask a question in the discussions section. I will always be welcoming and trying to please, sometimes even implementing changes to make things easier to achieve. But the script will NEVER hold the users hand due to lack of knowledge.

[framps]

It just "suddenly started working" witch means you did something different.

Nope. I did not. Looks like you're not interested in any feedback :-(. I'm over and out now.

[UnconnectedBedna]

I am, but I am not willing to change things that will break things for others.

I try to go above and beyond explaining, like I did with both of your issues. Making tons of suggestions and spending hours analyzing, giving advice, teaching etc.

I even handed you the possibility and hinting multiple times that you or anybody else are welcome to create pull requests and I will accept them (assuming it does not break other actually supported use cases).

I'm sorry you feel that way, that giving you hours of my time trying to help was not enough for you.

This are the guidelines I follow: https://github.com/UnconnectedBedna/shrink-backup?tab=coc-ov-file#our-standards

Examples of behavior that contributes to a positive environment for our community include:

• Demonstrating empathy and kindness toward other people
• Being respectful of differing opinions, viewpoints, and experiences
• Giving and gracefully accepting constructive feedback
• Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
• Focusing on what is best not just for us as individuals, but for the overall community

[framps]

I'm sorry you feel that way, that giving you hours of my time trying to help was not enough for you.

I think we both misunderstand each other and I tried to explain why here

I also felt very uncomfortable with this issue because it's a very nasty issue. I agree it's not a good idea to have the same partitions with the same PARTUUID multiple times on different devices. But it finally worked on the 64 OS. So I tried again to backup and restore the 32 bit image on my RPi3 - and the PARTUUIDs were identical and the restores system booted successfully :smile:

So it looks like you are right I did something wrong when I tested shrink-backup with the 32 bit OS. Frankly I have no clue what I may have done wrong. Unfortunately I'm not able to reproduce the issue :cry:

Sorry you had to spend your space time on this invalid issue.