Description of problem: Installer does not allow user to select a different (supportable) bootloader if they have a machine with RAID. This is an issue for people who are only trying out Mageia for the first time and already have, say, grub1 installed on their box for another OS. I can aver that grub1 does, in fact, work for RAID1 as I have my own hardware here configured precisely this way. I have never experienced a problem, so I assume this is a perfectly supportable configuration. (There was, in the past, a problem with grub2 not being able to detect existing operating systems installed with grub1 where both systems were on a RAID. This was due to a problem with the os-prober. As I have not tested this recently, I cannot assert whether it would be supportable. However, RAID with grub1 does work.) Defaulting to LILO is fine for systems with no other bootloader or no existing operating systems surviving the install. Perhaps there might be a warning for attempts to use grub2. But grub1 should be an option, at very least. Version-Release number of selected component (if applicable): Mageia-3-beta4-i586-DVD How reproducible: Very (tried it twice) Steps to Reproduce: 1. Install M3 with Mageia-3-beta4-i586-DVD 2. When get to screen with options to customize the system, select bootloader 3. No option to select grub1 or grub2 Reproducible: Steps to Reproduce:
bug confirmed on mageia 3 beta 4
CC: (none) => mnaud.free
Install mga3beta4 from same DVD, same scenario, and still no way to select grub1 or grub2 -- LILO is still the only choice. (When will this be corrected?) This time I tried to manually add the other partition in the LILO dialog of the summary. I get this error message: http://picpaste.com/63d0f4db1ed16327ffb62a0e115166a1.png Whatever the other problems with RAID and grub support issues, this should not be happening. It is informative, but not useful to me. Worse yet, it does not return me back to the LILO config; it just sends me along to the last step of the post-install. Interestingly, though, it did end up booting my other partition off the existing grub1. At least I didn't lose my precious original partition.
Assignee: bugsquad => thierry.vignaud
CC: (none) => bozonius
bug confirmed on mageia 3 RC1
Well, one "workaround" is to create 1 partition for /boot on each disk, then only use one of them as /boot (no raid) during install, and it will allow grub install, then after system is installed, change both partitions to be raid1 carrying /boot...
CC: (none) => tmb
Should this be release blocker?
Now that there is extended time to release date, I recommend a solution for this be included for M3GA. Specifically, I would like to see M3 installer check which bootloader is currently in use: grub1, grub2, or lilo. If one of these is already installed, use that, and add appropriate entries for the existing bootloader. Do not automatically "upgrade" the user to something other than what they already have (although politely asking first might be appropriate). If they do not already have a partitioned disk, then default to grub2 (since that is what people here seem to desire), but STILL allow the user to select a different choice. This seems sane and straightforward to me, and will prevent first-time users (and others) from breaking out in those awful cold sweats when they can no longer boot their original partitions.
I confirm this bug on recent cauldron (local mirror updated 3 days ago). I installed cauldron on a new computer with 2 HDD using boot.iso and my local mirror on disk. Each disk has a GPT partition table (created using cgpart from system rescue CD) with one small partition for /boot and a big partition to be used with LVM (/, /home, ...). From the installer, I created 2 RAID1 devices /dev/md0 and /dev/md1, the first being mounted as /boot, the other added to an LVM volume group for the other partitions. Install went fine, but, as reported, the installer forced lilo as bootloader with no choice of grub or grub2. The system simply doesn't boot (which is to be expected according to bug 5782, comment 6), failing quickly with an error related to a root partition not found. After that, I started the installer in rescue mode, mounted the partitions and chrooted to the installed system. I used grub-install to replace lilo with grub and created a menu.lst using the informations in lilo.conf. After that, the computer booted just fine (so the initrd is OK, it is only a lilo problem). So, I guess the installer is doing it just the wrong way, if /boot is a software RAID1 device it should propose only grub (and grub2?) and not lilo. And I think the same should be applied to the "Set up boot system" module in drakconf which also doesn't propose grub (neither text nor graphical) as a bootloader.
CC: (none) => r.h.michel+mageia
Is this one a simple fix or more involved than it appears? Would be good to include it in final if possible.
CC: (none) => mageia, mageia
CC: (none) => ennael1
This is definitely not just a simple fix. I personally dislike lilo and think we should drop support for it, but AFAIU, grub did not work with all raid configurations (e.g. does it work with raid5?) The reason lilo is used is because it can read the initrd of the raid partion whereas grub cannot. Certainly this has always been my understanding due to the comments in bug 5782. So using grub rather than lilo here would not even allow things to get as far as an initrd error because the initrd itself would not be readable by grub! Perhaps it's OK in raid1 but not other raids? Perhaps it does actually support mdraid but not dmraid etc. etc. I don't know the complexities here and there certainly isn't time to QA the various combinations. <rant> If you have a raid setup (as I do) I personally think it's a bad choice to support anything other than a separate /boot partition on a simple partition format (e.g. ext4 or FAT32). I think anything more complex requires overengineering of other components (e.g. grub or the monstrosity that is grub2) to compensate for this "choice". Things should be simpler and more defined. Restrict this artificial "choice" and just make users select a separate /boot in these scenarios. The amount of development effort and bug reports related to these kind of setups are really not worth the pain for the perceived benefits. </rant> Anyway, rant over :D This issue, sadly, will be very unlikely to be resolved for this release.
Well, grub (legacy, I have no experience with grub2) can definitely read the initrd and kernel from a software RAID1 partition with ext4 on it. This is what I did here to solve the lilo problem. But I read somewhere that it only support RAID1 partitions, not RAID0 nor RAID5. Some years ago I had seen that the RAID1 had to be created with metadata style 0.90 (mdadm --metadata=0.90), which is what I did for my previous computer (and it worked). On this new computer I created the md devices from the installer, but it seems they were both creates with 0.90 metadata, so I can't tell if the grub in current cauldron can read 1.2 metadata or not. I guess this is too late for mageia 3, anyway, I can try a new installation on this computer if you want. If this is delayed for mga4, I can try an install in a VM when there is something to test.
If a user already has a bootloader installed, it should not be modified or changed other than to add appropriate entries for the partition just installed or upgraded. Apparently, the user either likes the particular bootloader they are using, or otherwise may be working well for them. At very least, the installer should be asking permission to change it. Linux users don't like their linux partitions getting clobbered by installing a certain popular malware package that is commonly marketed as an operating system. Well, some linux users don't like their bootloaders getting clobbered by other types of installations, even if they are linux. Our distro should play nice with others, whatever that takes.
Another thing to consider, also, is that in some environments, particularly corporate ones, there may be very strict policies about upgrades and configuration changes in the I.T. area. Now, I don't know realistically how many companies are interested in supporting multiboot configurations in the first place, but we certainly don't want to make an existing machine in their network unbootable just because a user installed M3 on their desktop (with or without permission from I.T. and/or management). Take this as being a general admonition about this issue and others. I have worked in some VERY strict corporate IT environments and I have seen more than one or two vendors receive some severe retribution for their products not following best practices. We don't want our installations to be disruptive to demanding support departments.
*** Bug 10645 has been marked as a duplicate of this bug. ***
CC: (none) => adrien_d
This needs attention before M4, IMO.
it will be...
I still haven't heard what the implementation will be. I would like to be in the loop on that before any work is started. Our installer must honor whatever boot system the user already uses; there can be no switching it on them, at least not without the user's OK. There really shouldn't be any switching boot systems at all, IMO. If the user does not have any boot system installed we might suggest one, but offer any.
There is a work around to install Mageia 4 with LILO bootloader, and the /boot partition/file system on RAID1, and the other partions however, you want them. See the following topic/post on the Mageia forum. https://forums.mageia.org/en/viewtopic.php?f=8&t=7975#p49644
CC: (none) => hankivy
commit 5976acd282a1564ea4d3fd8b1c08bce240493194 Author: Thierry Vignaud <thierry.vignaud@...> Date: Mon Jul 4 17:42:41 2016 +0200 do not warn about no bootloader can boot RAID[^1] As grub2 can boot... (mga#11324) This should also fix mga#9524 And thus stop forcing obsolete metadata 0.90 format --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=5976acd282a1564ea4d3fd8b1c08bce240493194 Bug links: Mageia https://bugs.mageia.org/9524 https://bugs.mageia.org/11324
Closing
Status: NEW => RESOLVEDResolution: (none) => FIXED