Mageia forum

I just finished doing a test install on my main desktop system of Mageia 3 Beta 2, which immediately updated itself to Mageia 3 Beta 3 as it exited the install proceedure. I believe I learned a couple of things in doing that install and would like to pass along a couple of suggestions based on that experience.

1) The Mageia 3 installer seemed incapable of mounting a BtrFS partition during the initial install process (I initially chose BtrFS for the / partition and the installer moved forward but then gave an error message stating that it was unable to mount the partition). IF this is the case (this whole area probably needs to be looked at further), there should be something in the release notes to warn about possible problems on attempting to upgrade systems already containing BtrFS partitions. It looks like this sort of operation might simply not be supported at this point in time. But it needs to be stated clearly in advance if it is the case.

2) I attempted to upgrade to grub 2 during the install which failed with a somewhat cryptic error message. I then remembered that grub 2 bootloader, unlike grub 1, cannot be installed on an MBR. That means either you need to have EFI with room on the motherboard for the boot loader or you need dedicated space allocated on the drive for the boot loader. I think this information should also be included in the release notes for the final product as to what pre-conditions need to be met before upgrade to grub 2 can be supported. I am seeing how this, along with BtrFS could be a real potential nightmare for the devs in a chicken and egg sense as to how this transition eventually happens.

All in all this install adventure was a great experience. It was with a bit of trepidation that I embarked on an install of a beta product along side an existing Mageia 2 install on a production system. But everything, even the fails with the unsupported stuff went flawlessly and at the end I was able to boot back up into my main desktop system with no problem AND boot into the new beta install with no problem. But there are obvious and not so obvious gotcha's and I wouldn't recommend this approach for the novice.

I then remembered that grub 2 bootloader, unlike grub 1, cannot be installed on an MBR.

A small correction...in a normal BIOS system, grub2 can (and is usually) installed to the MBR. And it can be installed to its own partition too; however, Mageia's current grub2 (M3b3) has problem doing that (installing to own partition -and there's a bug report on this).

It's just that in UEFI system, there has to be a separate "grub-efi" partition and installation is slightly more complicated (just prepare/label the (GPT) partitions beforehand and it should be just as easy).

Cheers.

I just now pulled down the manual on grub to refresh my memory. You are correct, grub 2 CAN be installed "to MBR". But it seems the problem is that grub 2 is too large for MBR, so grub manual recommends leaving empty space on drive before the first partition to allow extra room for grub 2. grub manual recommends NOT to use any partition for grub2 due to concerns about filesystem remapping data for housekeeping reasons and grub data needs to be formatted raw in order to work properly. grub manual recommends at least 1MB free space before first partition. I did not do that which may be why grub 2 installation failed on my install. It did seem to be complaining about lack of space and a partition in the way or something of that sort. Here is the explanation from the grub manual explaining that "MBR install" is not really MBR install:

The partition table format traditionally used on PC BIOS platforms is called the Master Boot Record (MBR) format; this is the format that allows up to four primary partitions and additional logical partitions. With this partition table format, there are two ways to install GRUB: it can be embedded in the area between the MBR and the first partition (called by various names, such as the "boot track", "MBR gap", or "embedding area", and which is usually at least 31 KiB), or the core image can be installed in a file system and a list of the blocks that make it up can be stored in the first sector of that partition.

Each of these has different problems. There is no way to reserve space in the embedding area with complete safety, and some proprietary software is known to use it to make it difficult for users to work around licensing restrictions; and systems are sometimes partitioned without leaving enough space before the first partition. On the other hand, installing to a filesystem means that GRUB is vulnerable to its blocks being moved around by filesystem features such as tail packing, or even by aggressive fsck implementations, so this approach is quite fragile; and this approach can only be used if the ‘/boot’ filesystem is on the same disk that the BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive numbers.

The GRUB development team generally recommends embedding GRUB before the first partition, unless you have special requirements. You must ensure that the first partition starts at least 31 KiB (63 sectors) from the start of the disk; on modern disks, it is often a performance advantage to align partitions on larger boundaries anyway, so the first partition might start 1 MiB from the start of the disk.

GNU GRUB Manual 2.00~rc1

Of course GPT on the drive makes all this easier by allowing for a dedicated grub space. But currently the installer's disk partitioning tools do not yet support GPT. So GPT is yet another part of this puzzle of moving from the old technologies to the new, along with grub 2 and BtrFS.

Corrections again, George

grub manual recommends at least 1MB free space before first partition

Grub2 manual which you yourself quoted states

You must ensure that the first partition starts at least 31 KiB (63 sectors) from the start of the disk;

so it is 31KiB, not 1MB.

The 1MB mentioned in that manual states that the first partition will start 1MB anyway for partition alignment, so it means that (modern) hard drives have the first partition 1MB away from the start of the drive. [implying this shouldn't be a problem anyway]

Hope that explains. Cheers.

ps: when using gparted to partition drives, have you note the device tab where in default, it list as 'msdos'? This will result in getting the drive aligned, so the first partition will always be 1MB away from the start.

Oh, one more thing.....

..........generally recommends embedding GRUB before the first partition.......

means it is recommended that grub be installed to 'sda' (common misnomer as 'mbr') and not to its own partition (or other partitions) sdax
that is why there is always a warning when one tries to install to its own partition (to the effect "embedding to partition blocklist....")
So to install to its own partition, one need to use 'force' (grub-install --force /dev/sdax) and I always install any installation to its own partition myself.*

[note] which I cannot do for Mageia3b3, that's why I know there's a bug (but which I can easily rectify after installation)
and I always install to own partition because I have my own non-OS bootloader.

To summarise your issue with btrfs and from viewtopic.php?f=15&t=4571 ,

I don't think Mageia3 in its current form can be installed in a btrfs partition because grub-legacy is by default installed even if you choose grub2 (grub-legacy cannot handle btrfs).

Cheers!

Thanks for the clarifications.

However, it remains that the installer in my case was unable to install grub 2 to /dev/sdf on an msdos partitioned drive probably due to lack of space ... or maybe some other reason.

- George

You're welcome and I am glad you got Mageia working well (with ext4).

Cheers.

Problem installing Grub 2 is resolved. It was connected with the Mageia installer in any way. What actually happened is that even though I reformated from BtrFS to ext4, BtrFS left behind some random artifacts on the drive and that is what grub 2 did not like. Once that stuff was surgically removed, grub 2 installed uneventfully, so I am now booting fine with grub2. Now ... all I have left to do is to find a way to change the drive format from ext4 back to BtrFS, but that will be a project for another day. - George