Skip to content

Instantly share code, notes, and snippets.

@ceremcem
Last active October 13, 2017 22:55
Show Gist options
  • Save ceremcem/6b06d3954ddd53379afeee57e2c75330 to your computer and use it in GitHub Desktop.
Save ceremcem/6b06d3954ddd53379afeee57e2c75330 to your computer and use it in GitHub Desktop.

1. Prepare yourself

Everything may go wrong in this process. Make backups, prepare a live distribution that can connect to internet.

2. Prepare a new rootfs

Sync your current root filesystem to another location, eg. /NEW_ROOTFS

  1. Edit /NEW_ROOTFS/etc/fstab to mount proper devices
  2. Edit your rootfs synchronization tool (smith-sync, btrbk, dcs-tools, snapper, ...) config to backup between correct devices
  3. Edit /NEW_ROOTFS/etc/crypttab to reflect correct keys/entries
  4. Set NOCOW (chattr +C folder) attributes of folders if there were any (like Chromium's ~/.config/chromium, VM disk images, etc)

3. Prepare initrd

initrd.img is responsible for mounting the correct rootfs. Thus, new GRUB entry (or the bootloader entry you use now) should pass the NEW_ROOTFS strategy/devices to the initrd.

For example, a rootfs may be on a btrfs subvolume on a btrfs filesystem on a LVM volume on a LUKS partition. Now new entry should know about

  • New btrfs subvolume (if it is changed)
  • New LVM volume names (it is probably changed)
  • New LUKS partition UUID (it is absolutely changed)

This is a "new device" scenario where the strategy (btrfs_subvolume/btrfs/LVM/LUKS) is unchanged.

You may want to change the strategy, for example XFS/LUKS/RAID. If this is the case, initrd should also know about the correct mount order.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment