Hello, I have a script that uses the PTUUID parameter to identify which drive I want to back up on my desktop system. There are 2 NVME drives on the system, and I have seen the drive designations get reversed on occasion. This script has just one 'savedisk' command line in it (shown below), and I have used it repeatedly with versions 3.2.0 and 3.1.2 without any problem.
However, on version 3.3.0, the script fails every time when PTUUID is used (failure messages shown below). If I simply replace the PTUUID= parameter in the script with the actual drive designation (nvme1n1), then it runs successfully again.
Here's what I'm seeing when using PTUUID with version 3.3.0-33:
Contents of script to execute (located at /home/partimag/ocs-desktop-nvme):
/usr/sbin/ocs-sr -q2 -c -j2 -z9p -i 0 -sfsck -senc -p command savedisk autoname-desktop-nvme-year-month-day-hour-img PTUUID=7C4D0B31-4279-49E1-A435-6B5039DE97AF
Script run results using the 3.3.0 boot disk:
user@cl-3.3.0-33:~$ sudo sh /home/partimag/ocs-desktop-nvme
Setting the TERM as linux
Starting /usr/sbin/ocs-sr at 2026-02-03 20:11:59 UTC... ********.
Clonezilla image dir: /home/partimag ********.
Shutting down the Logical Volume Manager
Finished Shutting down the Logical Volume Manager
The image name is: desktop-nvme-2026-02-03-20-img
The input device [PTUUID=7C4D0B31-4279-49E1-A435-6B5039DE97AF] does NOT exist in this machine!
We will not save this device [PTUUID=7C4D0B31-4279-49E1-A435-6B5039DE97AF]!
Press enter to continue!
No inputted devices found!
Program terminated.!!!
Output of fdisk -l /dev/nvme1n1:
Disk model: INTEL SSDPEKNU020TZ
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: gpt
Disk identifier: 7C4D0B31-4279-49E1-A435-6B5039DE97AF
Device Start End Sectors Size Type
/dev/nvme1n1p1 2048 1050623 1048576 512M EFI System
/dev/nvme1n1p2 1050624 210765823 209715200 100G Linux root (x86)
/dev/nvme1n1p3 210765824 630196223 419430400 200G Linux filesystem
/dev/nvme1n1p4 1259341824 1364199423 104857600 50G Linux filesystem
/dev/nvme1n1p5 630196224 1049626623 419430400 200G Linux filesystem
/dev/nvme1n1p6 1049626624 1259341823 209715200 100G Linux filesystem
/dev/nvme1n1p7 1364199424 1573914623 209715200 100G Linux filesystem
/dev/nvme1n1p8 1573914624 1993345023 419430400 200G Linux filesystem
Partition table entries are not in disk order.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Could you please give testing Clonezilla live a try? i.e., >= 3.3.1-29 or 20260202-*: https://clonezilla.org/downloads.php
This issue should have been fixed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello, I have a script that uses the PTUUID parameter to identify which drive I want to back up on my desktop system. There are 2 NVME drives on the system, and I have seen the drive designations get reversed on occasion. This script has just one 'savedisk' command line in it (shown below), and I have used it repeatedly with versions 3.2.0 and 3.1.2 without any problem.
However, on version 3.3.0, the script fails every time when PTUUID is used (failure messages shown below). If I simply replace the PTUUID= parameter in the script with the actual drive designation (nvme1n1), then it runs successfully again.
Here's what I'm seeing when using PTUUID with version 3.3.0-33:
Contents of script to execute (located at /home/partimag/ocs-desktop-nvme):
/usr/sbin/ocs-sr -q2 -c -j2 -z9p -i 0 -sfsck -senc -p command savedisk autoname-desktop-nvme-year-month-day-hour-img PTUUID=7C4D0B31-4279-49E1-A435-6B5039DE97AF
Script run results using the 3.3.0 boot disk:
user@cl-3.3.0-33:~$ sudo sh /home/partimag/ocs-desktop-nvme
Setting the TERM as linux
Starting /usr/sbin/ocs-sr at 2026-02-03 20:11:59 UTC...
********.
Clonezilla image dir: /home/partimag
********.
Shutting down the Logical Volume Manager
Finished Shutting down the Logical Volume Manager
The image name is: desktop-nvme-2026-02-03-20-img
The input device [PTUUID=7C4D0B31-4279-49E1-A435-6B5039DE97AF] does NOT exist in this machine!
We will not save this device [PTUUID=7C4D0B31-4279-49E1-A435-6B5039DE97AF]!
Press enter to continue!
No inputted devices found!
Program terminated.!!!
Output of fdisk -l /dev/nvme1n1:
Disk model: INTEL SSDPEKNU020TZ
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: gpt
Disk identifier: 7C4D0B31-4279-49E1-A435-6B5039DE97AF
Device Start End Sectors Size Type
/dev/nvme1n1p1 2048 1050623 1048576 512M EFI System
/dev/nvme1n1p2 1050624 210765823 209715200 100G Linux root (x86)
/dev/nvme1n1p3 210765824 630196223 419430400 200G Linux filesystem
/dev/nvme1n1p4 1259341824 1364199423 104857600 50G Linux filesystem
/dev/nvme1n1p5 630196224 1049626623 419430400 200G Linux filesystem
/dev/nvme1n1p6 1049626624 1259341823 209715200 100G Linux filesystem
/dev/nvme1n1p7 1364199424 1573914623 209715200 100G Linux filesystem
/dev/nvme1n1p8 1573914624 1993345023 419430400 200G Linux filesystem
Partition table entries are not in disk order.
Could you please give testing Clonezilla live a try? i.e., >= 3.3.1-29 or 20260202-*:
https://clonezilla.org/downloads.php
This issue should have been fixed.
Yes, I tried testing 3.3.1-29 and PTUUID does work in that version (as well as PARTUUID and UUID on a spot check) That's great, thanks!
And thanks again for Clonezilla too. It is very much appreciated!
Thanks for confirming the testing Clonezilla live is working there.