I fell into that trap once. ![]()
Reinstalled the core system to a new SSD, and restored a systemback snapshot.
This in theory gave me an exact copy of my previous system, in practice it could not bootâŚ
Took me a while to sort it out.
That was long ago.
Is this really true? I thought the UUID is bound to the partition, not to the filesystem. Just reformatting shouldnât change the UUID, even if done with mkfs.
But maybe Iâm wrongâŚ
Itâs the PARTUUID.
See blkid output before:
/dev/sdd1: UUID="548ed40e-636f-473a-8226-473f8a802a11" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="722186a3-01"
..and after formatting:
/dev/sdd1: UUID="ae0ef6bd-26f6-474d-bfc2-b9f176500f41" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="722186a3-01"
With gparted or mkfs?
With gparted.
Gonna try using mkfsâŚ
Edit: it changed it too.
root@nagygep-cin-13:/home/laco# blkid |grep sdd1
/dev/sdd1: UUID="ae0ef6bd-26f6-474d-bfc2-b9f176500f41" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="722186a3-01"
root@nagygep-cin-13:/home/laco# mkfs.ext4 /dev/sdd1
mke2fs 1.47.2 (1-Jan-2025)
/dev/sdd1 contains a ext4 file system
created on Thu Feb 5 11:33:10 2026
Proceed anyway? (y,N) y
Creating filesystem with 41822102 4k blocks and 10461184 inodes
Filesystem UUID: 09cfbe8d-7e0b-4005-88c8-1f6e1b4d2c05
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872
Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks):
done
Writing superblocks and filesystem accounting information: done
root@nagygep-cin-13:/home/laco#
root@nagygep-cin-13:/home/laco# blkid |grep sdd1
/dev/sdd1: UUID="09cfbe8d-7e0b-4005-88c8-1f6e1b4d2c05" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="722186a3-01"
root@nagygep-cin-13:/home/laco#
The PARTUID is unchanged
The UUID has changed.
Grub and fstab use the UUID ⌠so @kovacslt is right.
Thanks for checking.
Good to know. After thinking a bit, it seems logical, as formatting really changes the identity of the partition. I was wrong with my initial assumption.
Yeah. I have to revise my statement. in reply no 218
âRather than empty the filesystem with rm -r * , it is better to use gparted and reformat the partition. That way you get a new filesystem. That may help in cases where the filesystem itself has been corrupted.â
Rather I should say
- if you think the filesystem is OK and only the files are corrupted. empty the filesystem with
rm -r *. Then you can recover to the same filesystem UUID and grub will not be affected - if you think the kernel has gone beserk and damaged the filesystem, make a new filesystem with gparted or mkfs. You will then have to fix UUID,s in fstab and grub.cfg, before it will boot.
Is that correct now?
I think so, yes.