Hendrik Boom <hendrik@???> wrote:
>
> My computer happily boots from one hard drive, although the operating system and all user data reside on another hard drive. It seems silly to have an entire hard drive taking up soace and power in the box when all I do with it is boot from it.
>
> I'd like to make it bootable from the same drive the OS an user data are on.
>
> How?
>
> And if I have more hard drives (coming soon) I'd like to be able to boot from any of them.
>
> I gather each drive I might wand to boot from has to have a working MBR and grub22 intallation.
>
> The drive it's booting from now is MBR-partitioned; the one I want to be able to boot from is a GPT drive.

OK, there’s a few gaps because I’m more used to doing this with blank drives so it’s easy to arrange the partitioning to suit. Plus, one or two steps might not be needed or might not be right since you already have a working bootable system.

My “recipe” for cloning a system is along these lines :

1) partition the target disk.
This is an area where I suspect the disagreements on what is “best” might give the emacs vs vi discussions a run for their money :D
Partly from habit, I still have a separate /boot partition. AIUI it’s no longer needed in many (most ? all ?) situations, but I figure it gives you a minimally bootable system (busy box on the initram-fs) with which to tackle repair on your root (/) partition should it ever be needed. At one time it was needed on “large” disks due to limitations of disk access by BIOS & first stage loader which could not access past the first 5??Mbyte of disk (and on older systems, something even smaller !).

After that, add all the other partitions as required. That may involved LVM and/or MD RAID depending on your requirements.

Create appropriate filesystems on each partition.

As you already have a system installed, this is the bit I’m not sure about. I believe it’s possible to shrink and move a partition so in principle it should be possible to make space for a /boot partition. Alternatively it should be just a matter of creating a /boot directory and copying the files into it :
check permissions on /boot
unmount it
mount it (ro) on a temporary mount point
copy the files from there to /boot
check the permissions are the same (IIRC the root point of a mounted filesystems takes the permissions of the directory it was mounted on).
unmount the temporary mount point


2) I copy all the files
This is the bit you’ll skip, but I mount the target filesystems on a temporary mount point (e.g. /target) - creating further mount points as needed so that I have the target tree identical to how it will be used. I typically use SSH for the copying - note that this can be from a different machine across the network using a temporary boot environment (e.g. live CD/USB) but make sure you use “—numeric-ids” or your permissions get scrambled (BTGTTS).


3) Update /etc/fstab on your target
Typically things will be slightly different, so you need your stab to reflect how things will be. This may be a case of changing IDs for partitions mounted by ID, there may be some layout changes (if you’ve changed your partitioning), etc, etc.


4) Update your grub config and initrams
Again, you might not need this step since you are (almost) keeping the same setup.

You now need an environment that’s going to be your target environment. To do this I use a set of commands I got from a mailing list a lot of years ago so I claim no credit for them :
mkdir /target
mount /dev/your-root-dev /target <- you’ve probably already done this in step 1 or 2
mount /dev/your-boot-dev /target/boot <- ditto
-> and mount anything else the target might need
mount --bind /dev /target/dev
mount --bind /sys /target/sys
mount --bind /proc /target/proc
mount --bind /run /target/run (recommended if you are using systemd)
chroot /target
grub-install /dev/your-grub-boot-device (may be grub2-install on some distro)


This is the point where I normally reboot ... and find I’ve missed a step :( Failing to change boot device in the BIOS is a good one to miss, or forgetting to set the bootable flag in the partition table, or a mistake in fstab, or ... So mutter to oneself and go back to the appropriate step and fix whatever you missed - though in some cases you may be able to use the rescue shell (Busybox from the initram) to manually mount filesystems, then continue booting to get into the full system, and then fix up what you missed.


As to the other details.

When you say “boot from any drive”, can you clarify just what you mean ? If your OS drive is missing then your system won’t be bootable even if you’ve installed grub on it.
What I tend to do is use raid so that both the boot loader and OS have resilience. Whether that’s level 1, 5, or 6 depends on the combination of drives etc I have, and can vary between OS and /boot.
As an example, one of the last machines I setup with “many” drives (some years ago now) has five identical drives.

For /boot I used RAID1 and the old (V0.90) metadata (superblock) format - that puts the md raid labelling at the end of the partition such that the start of the partition is identical to the same contents in a non-raid setup. This means that each member of the raid appears identical to the filesystem that is stored on the raid volume. This is another of those “I’ve always done it that way” things as GRUB can read raid volumes these days - at one time it couldn’t and so this was a way to work around that limitation. The default when creating an array is to use version 1.2 which puts some metadata at the start of the partition which means it can’t be read as a filesystem.

If you don’t plan on raiding your OS filesystem, then you gain little from installing grub on multiple drives - other than being able to boot if the BIOS has the wrong drive selected. But if you do, then AFAIK it’s just a matter of “grub install /dev/sdx” for whatever value of x the extra drive is.

And AFAIK you can mix and match MBR and GPT - as long as the GPT formatted disk has a "BIOS boot” partition on it. From one of my current home systems :
Device        Start       End   Sectors  Size Type
/dev/sda1      2048     22527     20480   10M BIOS boot
/dev/sda2     22528    227327    204800  100M Linux RAID
/dev/sda3    227328  42170367  41943040   20G Linux RAID
/dev/sda4  42170368  58947583  16777216    8G Linux RAID
/dev/sda5  58947584 234441614 175494031 83.7G Linux RAID
The arrays are /boot, /, swap, unused - this is just the OS and database on a mirrored pair of SSDs, with data being on some large spinning disks.

Hope this gives you some ideas, Simon