Procedure:HostDiskMigration - Revision history

Ekeever1: /* bios boot migration */

2022-12-07T08:47:56Z

bios boot migration

← Older revision		Revision as of 08:47, 7 December 2022
Line 83:		Line 83:
	* grub2-install /dev/sdb		* grub2-install /dev/sdb
	* grub2-mkconfig -o /boot/grub2/grub.cfg		* grub2-mkconfig -o /boot/grub2/grub.cfg
	* dracut -f		* RHEL: dracut -f
			* Ubuntu: update-initramfs -u -k all
	** '''Make absolutely sure that the new disk /boot is mounted before entering chroot!'''		** '''Make absolutely sure that the new disk /boot is mounted before entering chroot!'''

Ekeever1: /* New disk preparation */

2022-07-21T22:52:17Z

New disk preparation

← Older revision		Revision as of 22:52, 21 July 2022
Line 9:		Line 9:
	= New disk preparation =		= New disk preparation =

	Standard partitions procedure:		== Standard partitions procedure ==

	* Hot install new disk in the host; It is recognized and appears in the /dev/sd* table		* Hot install new disk in the host; It is recognized and appears in the /dev/sd* table
Line 21:		Line 21:
	Note: In some cases (mainly older systems) the origin disk label may be DOS which cannot be used on >2T disks, in which case a GPT label must be used.		Note: In some cases (mainly older systems) the origin disk label may be DOS which cannot be used on >2T disks, in which case a GPT label must be used.

	LVM preparations procedure:		== LVM preparations procedure ==

	* install new disk		* install new disk
	* Copy disk partition table,		* Copy disk partition table,

Ekeever1 at 22:51, 21 July 2022

2022-07-21T22:51:50Z

← Older revision		Revision as of 22:51, 21 July 2022
Line 88:		Line 88:

	== uefi boot migration ==		== uefi boot migration ==

			See also: https://www.linuxbabe.com/command-line/how-to-use-linux-efibootmgr-examples

	grub2 will refuse to install. Check /boot/efi/EFI/redhat/ and a grub configuration should be seen. This is the actual grub configuration that is needed.		grub2 will refuse to install. Check /boot/efi/EFI/redhat/ and a grub configuration should be seen. This is the actual grub configuration that is needed.

Ekeever1 at 22:35, 21 July 2022

2022-07-21T22:35:31Z

@@ Line 75: / Line 75: @@
 If the system fstab does not already utilize UUID, it should be changed to do so. /dev/sd* are subject to changes depending on drive enumeration order and can render a system unbootable if an expected partition moves.
 * grub2-install /dev/sdb
@@ Line 82: / Line 86: @@
 At this point, check both /boot/grub2/grubenv and any existing grub2 config file to double-check that the root device is the uuid of the new disk's /.
 Upon reboot, monitor using ipmi remote control and order it to boot from the new disk and confirm the system comes up successfully. In event of failure, the original disk is available to fallback. Upon success, remove old disk and reboot system one more time to confirm it successfully brings itself up.
 [[Category:Procedures]]

Ekeever1 at 02:09, 21 July 2022

2022-07-21T02:09:46Z

← Older revision		Revision as of 02:09, 21 July 2022
Line 8:		Line 8:

	= New disk preparation =		= New disk preparation =

			Standard partitions procedure:

	* Hot install new disk in the host; It is recognized and appears in the /dev/sd* table		* Hot install new disk in the host; It is recognized and appears in the /dev/sd* table
Line 17:		Line 19:
	** We do not generally invoke special options with these so the mkfs process is simple		** We do not generally invoke special options with these so the mkfs process is simple

	Note: In some cases (mainly older systems) the origin disk label may be DOS which cannot be used on >2T disks, in which case a GPT label must be used and ~~there~~ is ~~no need~~ to ~~mark partition types~~.		Note: In some cases (mainly older systems) the origin disk label may be DOS which cannot be used on >2T disks, in which case a GPT label must be used.

			LVM preparations procedure:
			* install new disk
			* Copy disk partition table,
			** This will include partitions for EFI, /boot and the big one for LVM
			* <pre>vgcreate rhelb /dev/newdisk/lvm_partition</pre>
			** rhelb is the new volume name, presumably 'ubuntub' would be better for an ubuntu system.
			* Use <pre>lvdisplay</pre to show what's inside the old LVM
			* For each existing LV with name FOO,
			** <pre>lvcreate -L xxxG -n FOO rhelb</pre>
			** mkfs.zzz for the new /dev/mapper/rhelb_FOO

			The origin disk's underlying filesystem structure has now been duplicated on the target and copying can proceed as before.

	= Filesystem copy =		= Filesystem copy =

Ekeever1: Expand various things about the procedure.

2022-05-26T07:55:10Z

Expand various things about the procedure.

← Older revision		Revision as of 07:55, 26 May 2022
Line 14:		Line 14:
	** make sure to mark the /boot partition as bootable		** make sure to mark the /boot partition as bootable
	** mark the partition types as the same		** mark the partition types as the same
			* mkfs the same types of filesystem as on the origin disk
			** We do not generally invoke special options with these so the mkfs process is simple

			Note: In some cases (mainly older systems) the origin disk label may be DOS which cannot be used on >2T disks, in which case a GPT label must be used and there is no need to mark partition types.

	= Filesystem copy =		= Filesystem copy =
Line 19:		Line 23:
	* mkdir /mnt/tmp -p		* mkdir /mnt/tmp -p

	Once the copy of the partitions is ready, copy everything over at the filesystem level. ~~Generically, one~~ rsync will be needed for each partition		Once the copy of the partitions is ready, copy everything over at the filesystem level. One rsync will be needed for each origin partition

	* mount /dev/sdbX /mnt/tmp		* mount /dev/sdbX /mnt/tmp # X is the boot partiton
	* rsync -~~avxHAXS~~ /boot /mnt/tmp		* rsync -axHAXS /boot/ /mnt/tmp
	* umount /mnt/tmp		* umount /mnt/tmp

Line 29:		Line 33:
	# Theoretically this should be done using a liveusb to assure that the source FS is static,		# Theoretically this should be done using a liveusb to assure that the source FS is static,
	# however if the system is completely idle, all important services are stopped, etc,		# however if the system is completely idle, all important services are stopped, etc,
	# then only /var/log/* is likely to change. YMMV!</pre>		# then only /var/log/* is likely to change. YMMV! The last handful of log entries will be lost.</pre>

	* mount /dev/sdbY /mnt/tmp		* mount /dev/sdbY /mnt/tmp
	* rsync -~~avxHAXS~~ / /mnt/tmp		* rsync -axHAXS / /mnt/tmp
	** -> be sure that /mnt/tmp is mounted, baby, otherwise rsync will keep going until it crashes into the filesystem recursion limit		** -> be sure that /mnt/tmp is mounted, baby, otherwise rsync will keep going until it crashes into the filesystem recursion limit

	= ~~Boot preparation~~ =		Procedure for merging partitions (e.g. removal of separate /var/lib/docker partition). Note that src directory is /src/dir/ with a trailing / and not /src/dir.

			* mount /dev/sdbY /mnt/tmp # the new /
			* rsync -axHAXS /var/lib/docker/ /mnt/tmp/var/lib/docker

			= Make new disk bootable =

	Prepare for chroot:		Prepare for chroot:
	* umount /mnt/tmp		* umount /mnt/tmp
	* mount /dev/~~sdbX~~ /mnt/tmp		* mount /dev/sdbY /mnt/tmp
	* mount /dev/~~sdbY~~ /mnt/tmp/boot		* mount /dev/sdbX /mnt/tmp/boot
	* mount --~~bind~~ /sys /mnt/tmp/sys		* mount --rbind /sys /mnt/tmp/sys
	* mount -~~-bind~~ /proc /mnt/tmp/proc		* mount -t proc /proc /mnt/tmp/proc
	* mount --~~bind~~ /~~sys~~ /mnt/tmp/~~sys~~		* mount --rbind /dev /mnt/tmp/dev
			* chroot /mnt/tmp

	Grab all the block device IDs and drop them in fstab. At this point, the UUIDs of the new disk must be slipped in for the mount points of the old disk in the new filesystem,		Grab all the block device IDs and drop them in fstab. At this point, the UUIDs of the new disk must be slipped in for the mount points of the old disk in the new filesystem,
	* blkid >> ~~/mnt/tmp~~/etc/fstab		* blkid >> /etc/fstab
	* vi ~~/mnt/tmp~~/etc/fstab		* vi /etc/fstab

	If the ~~disk arrangement is simple (just sda)~~ it ~~may~~ be ~~possible~~ to ~~leave~~ /dev/sd* ~~unchanged in fstab, as upon removal of the old disk the new disk will become sda at next boot~~.		If the system fstab does not already utilize UUID, it should be changed to do so. /dev/sd* are subject to changes depending on drive enumeration order and can render a system unbootable if an expected partition moves.

	* chroot /mnt/tmp		* grub2-install /dev/sdb
	* grub2-install /dev/sdb
	* grub2-mkconfig -o /boot/grub2/grub.cfg		* grub2-mkconfig -o /boot/grub2/grub.cfg
	* dracut -f		* dracut -f
	** '''Make absolutely sure that the new disk /boot is mounted before entering chroot!'''		** '''Make absolutely sure that the new disk /boot is mounted before entering chroot!'''

			At this point, check both /boot/grub2/grubenv and any existing grub2 config file to double-check that the root device is the uuid of the new disk's /.

			Upon reboot, monitor using ipmi remote control and order it to boot from the new disk and confirm the system comes up successfully. In event of failure, the original disk is available to fallback. Upon success, remove old disk and reboot system one more time to confirm it successfully brings itself up.

	[[Category:Procedures]]		[[Category:Procedures]]

Nic-wiki at 05:27, 1 October 2021

2021-10-01T05:27:26Z

← Older revision		Revision as of 05:27, 1 October 2021
Line 1:		Line 1:
	~~Testing~~		The host disk migration procedure is to be used in the event that
			* a host's disk is failing and it must be moved to a good disk
			* expanded host storage on the root disk is needed

			'''WARNING: This procedure is obviously not without risks, backups should be available first!'''

			If everything is done correctly, this process will be read-only from the original disk's perspective, however mistakes can be made and if grub is reinstalled wrong (or the wrong disk gets repartitioned) the results would be gruesome.

			= New disk preparation =

			* Hot install new disk in the host; It is recognized and appears in the /dev/sd* table
			* Format the new disk to have the same set of partitions as the old disk
			** If the new disk is larger, feel free to enlarge
			** make sure to mark the /boot partition as bootable
			** mark the partition types as the same

			= Filesystem copy =

			* mkdir /mnt/tmp -p

			Once the copy of the partitions is ready, copy everything over at the filesystem level. Generically, one rsync will be needed for each partition

			* mount /dev/sdbX /mnt/tmp
			* rsync -avxHAXS /boot /mnt/tmp
			* umount /mnt/tmp

			<pre># Next is the master filesystem copy
			# IMPORTANT:
			# Theoretically this should be done using a liveusb to assure that the source FS is static,
			# however if the system is completely idle, all important services are stopped, etc,
			# then only /var/log/* is likely to change. YMMV!</pre>

			* mount /dev/sdbY /mnt/tmp
			* rsync -avxHAXS / /mnt/tmp
			** -> be sure that /mnt/tmp is mounted, baby, otherwise rsync will keep going until it crashes into the filesystem recursion limit

			= Boot preparation =

			Prepare for chroot:
			* umount /mnt/tmp
			* mount /dev/sdbX /mnt/tmp
			* mount /dev/sdbY /mnt/tmp/boot
			* mount --bind /sys /mnt/tmp/sys
			* mount --bind /proc /mnt/tmp/proc
			* mount --bind /sys /mnt/tmp/sys

			Grab all the block device IDs and drop them in fstab. At this point, the UUIDs of the new disk must be slipped in for the mount points of the old disk in the new filesystem,
			* blkid >> /mnt/tmp/etc/fstab
			* vi /mnt/tmp/etc/fstab

			If the disk arrangement is simple (just sda) it may be possible to leave /dev/sd* unchanged in fstab, as upon removal of the old disk the new disk will become sda at next boot.

			* chroot /mnt/tmp
			* grub2-install /dev/sdb
			* grub2-mkconfig -o /boot/grub2/grub.cfg
			* dracut -f
			** '''Make absolutely sure that the new disk /boot is mounted before entering chroot!'''


	[[Category:Procedures]]		[[Category:Procedures]]

Nic-wiki at 05:05, 1 October 2021

2021-10-01T05:05:38Z

← Older revision		Revision as of 05:05, 1 October 2021
Line 1:		Line 1:
	Testing		Testing

	[[Category::Procedures]]		[[Category:Procedures]]

Nic-wiki: Created page with "Testing Category::Procedures"

2021-10-01T05:05:16Z

Created page with "Testing [[Category::Procedures]]"

New page

Testing

[[Category::Procedures]]