Hi
I did a f24 installation using swraid on 4TB disks (predefined swraid because I am still unhappy with complex tasks and the level disk abstraction in anaconda, but thats not the point).
I was not able to write bios boot twice (sda and sdb), it was only written on sda (there is plenty of space on sdb as well). Anaconda partitioner did not allow to define two biosboot partitions.
Now I want to make the setup fully redundant (booting even without sda) and so I need to setup biosboot on sdb as well.
With gparted I can create the 1 MB partition on sdb but it does not support type bios boot. blivet does not support creating a 1MB partion on sdb as far as I can see.
Any other tools to write biosboot partions?
Workaround might be: create an unformatted partition in gparted and copy biosboot to it (dd from sda-partition or is there a source file anywhere in the filesystem?)
Are there any grub2 actions required afterwards?
Any other ideas?
Greetings Oliver
On 07/18/2016 12:05 PM, Oliver Paukstadt wrote:
I did a f24 installation using swraid on 4TB disks (predefined swraid because I am still unhappy with complex tasks and the level disk abstraction in anaconda, but thats not the point).
I assume you are using raid on the individual partitions and not the whole disk?
I was not able to write bios boot twice (sda and sdb), it was only written on sda (there is plenty of space on sdb as well). Anaconda partitioner did not allow to define two biosboot partitions.
Yes, anaconda has to draw a line somewhere on how complicated it can get. The installer needs to be very fully tested, so it needs to be feasible for a human to do so.
Now I want to make the setup fully redundant (booting even without sda) and so I need to setup biosboot on sdb as well.
With gparted I can create the 1 MB partition on sdb but it does not support type bios boot.
Since you are creating a bios boot partition, you must be using the non-GPT partition table. In that case, there is no actual type for a "bios boot" partition. Look at what gparted identifies the partition on sda as. However, was there anything else you wanted to keep already on the drives? If not, then you could just reformat and repartition the entire drive and you shouldn't need the bios boot partition at all. With any current partitioning tools, there is a gap between the MBR and the first partition with enough space to store the required data.
Workaround might be: create an unformatted partition in gparted and copy biosboot to it (dd from sda-partition or is there a source file anywhere in the filesystem?)
You could probably dd it from sda.
Are there any grub2 actions required afterwards?
You will need to grub2-install to /dev/sdb.
Use gdisk, partition type code EF02. Do this on both disks, install normally, post install do
grub2-install /dev/SDA /dev/and
Done.
--- Chris Murphy
On Mon, 2016-07-18 at 20:04 +0000, Chris Murphy wrote:
Use gdisk, partition type code EF02. Do this on both disks, install normally, post install do
grub2-install /dev/SDA /dev/and
Done.
Setting the partition type using gdisk was the necessary step to make grub2-install happy.
I will come back if the reboot-tests fail ;-)
Greetings Oliver
On Mon, Jul 18, 2016, 1:40 PM Samuel Sieb samuel@sieb.net wrote:
Since you are creating a bios boot partition, you must be using the non-GPT partition table.
BIOS Boot is where the core.img is embedded when using GPT partitioning with BIOS firmware.
--- Chris Murphy
On 07/18/2016 01:07 PM, Chris Murphy wrote:
On Mon, Jul 18, 2016, 1:40 PM Samuel Sieb <samuel@sieb.net mailto:samuel@sieb.net> wrote: Since you are creating a bios boot partition, you must be using the non-GPT partition table.
BIOS Boot is where the core.img is embedded when using GPT partitioning with BIOS firmware.
Sorry about that, that is one combination I have not had any reason to use, so I didn't recognize it.
However, I would still suggest doing RAID over the entire drive instead of partition by partition because that would solve this entire issue. You wouldn't have to worry about getting grub installed on the second drive or dealing with creating extra partitions.
On Mon, Jul 18, 2016 at 5:18 PM, Samuel Sieb samuel@sieb.net wrote:
On 07/18/2016 01:07 PM, Chris Murphy wrote:
On Mon, Jul 18, 2016, 1:40 PM Samuel Sieb <samuel@sieb.net mailto:samuel@sieb.net> wrote: Since you are creating a bios boot partition, you must be using the non-GPT partition table.
BIOS Boot is where the core.img is embedded when using GPT partitioning with BIOS firmware.
Sorry about that, that is one combination I have not had any reason to use, so I didn't recognize it.
However, I would still suggest doing RAID over the entire drive instead of partition by partition because that would solve this entire issue. You wouldn't have to worry about getting grub installed on the second drive or dealing with creating extra partitions.
I don't think that's a supported configuration. For sure it's not a layout the installer will create. It's probably a violation of the UEFI spec, except when the firmware itself understands the on-disk RAID format and can assemble the RAID in the pre-boot environment. Otherwise you end up with this big fat lie: The member drives are in fact RAID members first, and should not be individually recognizable; but by putting the RAID metadata at the end of the disk so that it doesn't conflict with the partition scheme, member drives are seen as individuals as if they aren't RAID members, hence the lie, and can in fact become inconsistent should any of those partitions be mounted and modified prior to RAID assembly.
The only really safe ways to do this? Firmware assembled RAID, or conventional partitioning with either LVM RAID or mdadm metadata version 1.2 (the default). This prevents the individual member devices from being recognized prior to RAID assembly.
I think Fedora 25 will bring a new feature to the installer that supports LVM RAID, which makes things a lot more flexible in the direction you're suggesting. Every device has a conventional partition scheme, each gets a bootloader (this is totally broken on UEFI right now still), and an mdadm v 1.2 partition for /boot, and then the largest partition is LVM. From that large LVM pool, each LV can have its own RAID level from 0 through 6. So you don't have to mess around with disk partitioning (MBR or GPT) to create different levels of RAID from that pool, and they can be mixed and matched.
-
Chris Murphy -
Oliver Paukstadt -
Samuel Sieb