2

I'm trying to set up a laptop running Kali rolling to act as if it was running 'DeepFreeze". My goal is to be able to do the following:

  • Set up sda1
  • clone it to sda3 with Clonezilla as a "clean version" of sda1
  • use sda1 with a client
  • "revert" it by cloneing sda3 back over sda1 with Clonezilla.

Before Cloning The Partition:

I've got my drive partitioned like so:

- sda1 main partition to be "used"

- sda2 extended partition

--- sda5 swap partition

- sda3 backup partition ("clean" version of sda1, to be written over sda1 as needed)

- sda4 Clonezilla Live partition (used to copy sda3 over sda1 as needed)

After Cloning The Partition:

After using Clonezilla to clone sda1 over sda3, for some reason kali keeps telling sda3 to mount at /, and boots into sda3 instead of sda1. apparently booting into sda3 instead?

both sda1 and sda3 set to mount at /

I imagine this is caused by clonezilla copying the entire partition, including whatever is inside of sda1 that tells grub to boot from it.

My issue is, I have no idea how to stop this from happening.

Edits:

/etc/fstab content:

root@kali:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=20d4493c-5934-4633-998e-0c6dd970d4ad /               ext4    errors=remount-ro 0       1
# swap was on /dev/sda5 during installation
UUID=3f0d9a95-a494-4ffa-a071-aefcf3d377ed none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

blkid output:

root@kali:~# blkid
/dev/sda1: UUID="20d4493c-5934-4633-998e-0c6dd970d4ad" TYPE="ext4" PARTUUID="f69a4b07-01"
/dev/sda3: UUID="20d4493c-5934-4633-998e-0c6dd970d4ad" TYPE="ext4" PARTUUID="f69a4b07-03"
/dev/sda4: LABEL="Clonezilla" UUID="26bc43b4-b906-45e0-be27-eab166704de5" TYPE="ext4" PARTUUID="f69a4b07-04"
/dev/sda5: UUID="3f0d9a95-a494-4ffa-a071-aefcf3d377ed" TYPE="swap" PARTUUID="f69a4b07-05"
WorseDoughnut
  • 233
  • 1
    Could you share your /etc/fstab and the output of blkid. I assume that your root partition is mounted with the filesystem UUID which might be the same on the cloned disk. – Thomas Mar 22 '16 at 18:05
  • @Thomas Yup, edited onto bottom of OP – WorseDoughnut Mar 22 '16 at 18:52
  • I've also realized, that in this current state, I could deal with this by just designating sda1 as my "clean partition" and sda3 as the "usable partition", since I always boot into sda3 now. – WorseDoughnut Mar 22 '16 at 18:54

2 Answers2

3

Yes, your root partition is mounted with the filesystem UUID and both, the original and the cloned one have the same UUID. To work around this, you could comment the corresponding line and mount it with the /dev/sda1 path.

#UUID=20d4493c-5934-4633-998e-0c6dd970d4ad /               ext4    errors=remount-ro 0       1
/dev/sda1                                  /               ext4    errors=remount-ro 0       1

You also should check the grub configuration, as sometimes the UUID is used there, too. There should be something like root= which either specifies a UUID or a full path to a device.

Thomas
  • 6,362
  • Does it matter that I'm currently in sda3 when I edit this though? Or is it independent of the current partition? – WorseDoughnut Mar 22 '16 at 18:59
  • Also, if I then wanted to boot into sda3, i could just add an entry for it in /etc/grub.d/40_custom right? – WorseDoughnut Mar 22 '16 at 19:02
  • It's important that you edit only in your primary/source partition and sync afterwards. Otherwise the partitions will be out of sync somewhen. I hope a umount /dev/sda3 does help here to get rid of the wrong mount. – Thomas Mar 22 '16 at 19:03
  • Well, I added it to /etc/fstab and commented the other line, and it booted into sda1 the next time, but after adding it to the fstab in sda1 it only boots into sda3 again. – WorseDoughnut Mar 22 '16 at 19:09
  • Did you try to umount /dev/sda3 before editing /etc/fstab? Then verify that is was unmounted with df -hTa. – Thomas Mar 22 '16 at 19:11
  • No, and I wouldn't have been able to, it was mounted at / anyway – WorseDoughnut Mar 22 '16 at 19:12
  • / is mounted twice. Anyways, do the following. mkdir -p /mnt/tmpmount; mount /dev/sda1 /mnt/tmpmount. Then edit /mnt/tmpmount/etc/fstab and check /mnt/tmpmount/boot/grub2/grub.cfg. Then reboot. – Thomas Mar 22 '16 at 19:15
  • in /boot/grub/grub.cfg I'm just replacing every instance of the UUID with /dev/sda1 correct? – WorseDoughnut Mar 22 '16 at 19:34
  • Yes correct, and it should look like root=/dev/sda1. But it might be that it will be overwritten by the next e.g. kernel update when the grub configuration is rewritten. – Thomas Mar 22 '16 at 19:36
  • My only concern (haven't edited it yet) is that is has set root='hd0,msdos1' instead of the UUID. It has the UUID inthe file, but it's always found after search --no-floppy --fs-uuid --set-root – WorseDoughnut Mar 22 '16 at 20:21
  • Someone I asked earlier suggested forcing both sda1 and sda3 to identify with their partition GUID instead of their UUID. Would that route be more permanent? (I'm also concerned I'll have to reset my test machine if I fuck up my grub.cfg too badly). – WorseDoughnut Mar 22 '16 at 20:25
  • You can also try without editing grub. And yes, you can f**k up things. So always have a live Linux by your side to fix things again. – Thomas Mar 22 '16 at 20:39
  • 3
    if you have an /etc/default/grub (same as Debian) you probably also need to have GRUB_DISABLE_LINUX_UUID=true in it, otherwise update-grub will generate /boot/grub/grub.cfg entries with root=UUID=... instead of root=/dev/sda1. – cas Mar 22 '16 at 21:00
  • @cas wow that actually solved my issue completely, without ever having to edit anything else. Thanks to Thomas though for getting me thinking in the right direction. – WorseDoughnut Mar 23 '16 at 13:59
2

So while the answer by Thomas got me thinking along the right path, it was actually the comment on Thomas's answer by cas that solved my issue completely:

Before cloning the partition, i edited /etc/default/grub, and uncommented the line that said GRUB_DISABLE_LINUX_UUID=true and ran update-grub.

After cloning sda1 to sda3, Kali consistently boots into sda1, and gparted no longer shows sda3 as being mounted at /.

WorseDoughnut
  • 233
  • Does this also applies to BTRFS? I have possibly similar station and I am a bit scared to alter /etc/fstab ... For reference, here is my question: https://stackoverflow.com/questions/73959107/clonezilla-generates-disk-clone-with-wrong-unupdated-uuids – HX_unbanned Oct 05 '22 at 11:24