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"
  • 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
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.

  • 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
  • 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
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 /.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.