Doing a fresh netinstall in current cauldron on a system with a 1TB HDD (/dev/sda) and a 256GB SSD (/dev/sdb). / is on a /dev/sdbX partition, as is a BIOS BOOT partition. However, when the Summary displays, the choice for grub shows /dev/sda. If you leave this unchanged, bootloader installation will fail. If you select Configure for the boot choice, the resulting display flips to /dev/sdb, and if you save through the dialog back to Summary, the boot display is now /dev/sdb and bootloader installation works just fine. Noobs are not going to figure this out, and the SSD + HDD combo is more and more common.
I wonder if this is also valid for mga6 ? - if so, it deserves an entry in errata.
CC: (none) => fri
(In reply to Frank Griffin from comment #0) > Doing a fresh netinstall in current cauldron on a system with a 1TB HDD > (/dev/sda) and a 256GB SSD (/dev/sdb). > > / is on a /dev/sdbX partition, as is a BIOS BOOT partition. However, when > the Summary displays, the choice for grub shows /dev/sda. > > If you leave this unchanged, bootloader installation will fail. > > If you select Configure for the boot choice, the resulting display flips to > /dev/sdb So it flips to /dev/sdb without selecting /dev/sdb ? >, and if you save through the dialog back to Summary, the boot > display is now /dev/sdb and bootloader installation works just fine. > > Noobs are not going to figure this out, and the SSD + HDD combo is more and > more common. What decides that the SSD becomes /dev/sdb? If it were /dev/sda and the HDD were /dev/sdb, then the problem would be solved. CC'ing Documentation team, because doc.mageia.org is down and I can't check what our documentation says now. I think it says that /dev/sda is selected by default and that it explains how to change that and I also think that the instructions are clear enough for a n00b to understand. If this screen no longer selects /dev/sda by default, but the disk that contains the new root partition, other users will be bitten (users like me, who did a lot of installs to /dev/sdb, dev/sdc etc. while trusting that the bootloader would automatically be, as desired on /dev/sda. A change, if done, will need to be communicated very well. Maybe it would be better if installer would detect that the bootloader cannot be installed, and that it would then give the option to put the bootloader on a different disk. Or does that already happen? Frank, can you attach /root/drakx/report.bug.xz from an install on this system where it was tried to put the bootloader on /dev/sda ?
Assignee: bugsquad => mageiatoolsKeywords: (none) => NEEDINFOCC: (none) => doc-bugs, marja11
(In reply to Marja Van Waes from comment #2) > (In reply to Frank Griffin from comment #0) > > So it flips to /dev/sdb without selecting /dev/sdb ? > Exactly. > > What decides that the SSD becomes /dev/sdb? If it were /dev/sda and the HDD > were /dev/sdb, then the problem would be solved. > The assignment is done early in the install, and shows up that way when you do Custom Disk Partitioning. It's done automatically. > > Maybe it would be better if installer would detect that the bootloader > cannot be installed, and that it would then give the option to put the > bootloader on a different disk. Or does that already happen? Letting it install on /dev/sdb works fine. Not entering Boot Configuration and leaving it as /dev/sda fails. > > Frank, can you attach /root/drakx/report.bug.xz from an install on this > system where it was tried to put the bootloader on /dev/sda ? Will do.
Created attachment 10472 [details] report.bug.xz
(In reply to Marja Van Waes from comment #2) > > What decides that the SSD becomes /dev/sdb? If it were /dev/sda and the HDD > were /dev/sdb, then the problem would be solved. It is by default the chosen SATA plug on the MB > > CC'ing Documentation team, because doc.mageia.org is down and I can't check > what our documentation says now. I think it says that /dev/sda is selected > by default and that it explains how to change that and I also think that the > instructions are clear enough for a n00b to understand. > Our documentation doesn't say much, it lets the reader understand that the installer knows well were to install the boot loader and to not modify that unless knowing well what he is doing. For myself I am thinking that the boot loader can be installed on any drive. On my main computer I have two SSDs and the boot loader is on sdb, like /.
CC: (none) => lebarhon
This is a laptop, so the SATA order is as delivered by the manufacturer. The more interesting question is who decides to put /dev/sda on the Summary panel (which will not work, probably because there is no BIOS Boot partition there), and who decides to flip it to /dev/sdb when you actually go to configure it. IIRC disk letter assignment ued to have something to do with BIOS drive assignment.
In your logs, grub2 is automatically installed on sdb, so the issue is only when manually trying to configure bootloader?
CC: (none) => thierry.vignaud
No. The installer chooses /dev/sda for display in the Summary, and if this is not changed it causes errors during bootloader install when you move off of Summary. If you select Bootloader -> Configure, the Configure display has changed /dev/sda to /dev/sdb with no action by me, which is reflected when you OK through and return to Summary, i. e. Summary now shows /dev/sdb. Then install of the bootloader works. At no time did I alter any choice of disk. The choices were made and altered by Summary and Bootloader -> Configure with no input from me.
So, you're not under UEFI so technically the bootloader can be installed on any disk. The fact there's a BIOS boot partition on 2nd disk doesn't imply we must use it, it's there only b/c the disk uses the GPT layout BUT here /dev/sda also uses GPT but it doesn't have a BIOS boot part, so it must be excluded (else grub2 has no place to install) (please provide the grub2 error next time)
Keywords: NEEDINFO => (none)Summary: Installer picks wrong disk for grub2 => Installer picks wrong disk for grub2 when all disks use GPT layouts but not all have "BIOS boot partition"
Actually bootloader::allowed_boot_parts() already does the check. What I think is happening, on first install, bootloader::read_grub2() is used to create an empty grub conf and it doesn't set a default boot device yet. Which will be a problem in such situation.
Fixed in git
Resolution: (none) => FIXEDStatus: NEW => RESOLVED