On 03/27/2015 09:05 AM, jdd wrote:

Le 27/03/2015 13:51, Anton Aylward a écrit :

...

This http://www.zdnet.com/article/hands-on-linux-uefi-multi-boot-part-2/ may be if interest to those who are just venturing into this direction for the first time.

notice that this article specifically states that it's not about secure boot, but secure botos installs perfectly with openSUSE

Indeed. You and I and most of the 'regulars' here are NOT, repeat NOT repeat NOT the target subjects of this article. Its not for old Linux/UNIX hands like us but for the people venturing into Linux, those who want to experiment with different systems rather than drilling deep into just one. Its saying "Come on in, the water's fine, don't believe the mis-information that various vested vendors promulgate about UEFI being difficult to work with, with its security features being an impediment and forcing you to use Windows". Yes there are Old hands who do multiboot too, but that's beside the point. You guys could write more sophisticated articles, but they would scare off the the kind of people this article is targeted towards. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Mar 27, 2015 at 7:05 AM, jdd wrote:

Le 27/03/2015 13:51, Anton Aylward a écrit :

...

This http://www.zdnet.com/article/hands-on-linux-uefi-multi-boot-part-2/ may be if interest to those who are just venturing into this direction for the first time.

notice that this article specifically states that it's not about secure boot, but secure botos installs perfectly with openSUSE

Because openSUSE has patched GRUB's chainloader module, it supports Secure Boot chainloading the Windows bootloader. So it's doing quite a good job. Right now Fedora and Ubuntu (and probably Debian by extension) don't carry this patch for unknown reasons (they're from 2012), so when Secure Boot is enabled, the GRUB entries for Windows fail with a confusing message. But even Fedora and Ubuntu have supported Secure Boot quite well for some time, I think Fedora may have been the first to do it actually. The Fedora + OS X dual boot is totally unique, I'm not aware of anyone else doing it they way they do, and it's quite user friendly to use. Meanwhile the GRUB OS X boot entries are basically permanently broken and so far upstream doesn't really care enough to inhibit their creation to avoid the problem (XNU kernel panics upon choosing them). So it could be better, but yeah it's not super scary. It's certainly not as bad as dual Linux distros multibooting, that really sucks. And grub2-mkconfig could do this better with minimal change, but again, essentially zero interest upstream or even among the distros. It's sorta like sport to clobber another distro's bootloading when doing an installation. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Mar 27, 2015 at 11:51 AM, Andrei Borzenkov wrote:

Secure Boot chainloading of the Windows bootloader does not need any patches. It is signed and will pass verification when loaded by standard EFI chainloader. Patches are needed to allow loading of non-signed (at least, by Microsoft or in general signed by keys unknown to firmware) EFI executable.

https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/grub2-se... With Secure Boot enabled, openSUSE GRUB's Windows menu entries work. On Fedora and Ubuntu, they don't work, unless Secure Boot is disabled and then the menu entries work. https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1091464 https://bugzilla.redhat.com/show_bug.cgi?id=1170245

...

But even Fedora and Ubuntu have supported Secure Boot quite well for some time, I think Fedora may have been the first to do it actually. The Fedora + OS X dual boot is totally unique, I'm not aware of anyone else doing it they way they do, and it's quite user friendly to use.

Could you attach grub.cfg from such a system? I do not see any patches specific to OS X in Fedora os-prober GIT.

They don't do it that way, it's done mainly with Fedora's mactel-boot and anaconda/blivet packages. They create an HFS+ volume to use as a faux EFI System partition; and do not use the actual FAT32 EFI System partition at all (neither does Apple). What this enables is a way to choose Fedora from the OS X > System Preferences > Startup Disk panel, which is where a user typically chooses to change OS's (between OS X versions, Windows, and now also Fedora). https://docs.google.com/a/colorremedies.com/file/d/0B_2Asp8DGjJ9eHFWYmFVQnkz... To revert, unfortunately no GUI option within Fedora to tell efibootmgr what to do; partly because Apple's firmware behaves differently from system to system, and some of them ignore NVRAM entires in favor of the HFS+ Volume Header which points to boot.efi. So, the only really reliable way right now to switch back to OS X is hold down option key and choose OS X from the firmware's built-in boot manager. I've suggested on upstream GRUB list that grub2-mkconfig should stop using these CSM-BIOS xnu modules to boot OS X, and instead chainload the Apple bootloader, but no one has volunteered to do this work.

XNU loader works when used with i386-pc grub booted via CSM emulation. It was before my time but I suspect that is the environment where this loader was created and intended for. It fails when used on native EFI.

That's my understanding also. There is almost no use case now for either GRUB or any Linux using CSM-BIOS boot on a Mac. The performance (SSD speeds, battery life, heat generation) are all worse with CSM-BIOS to the point it's a big negative.

To fix it (assuming it can be fixed) requires someone who understands how XNU kernel works. Until someone steps in it remains this way.

Nope, just chainload Apple's bootloader. It's necessary anyway because Apple has moved to putting JHFS volumes into CoreStorage volumes, essentially their version of LVM. And there isn't any Linux or GRUB support for reading CoreStorage. And even if there is one day, it would also have to support Apple encryption scheme, since CoreStorage enables that too. I think it's easier to just give up and chainload Apple's bootloader. They change things every year so does someone really want to fix broken things every 12 months? Or just chainload their bootloader which will account for such changes?

...

So it could be better, but yeah it's not super scary. It's certainly not as bad as dual Linux distros multibooting, that really sucks. And grub2-mkconfig could do this better with minimal change, but again, essentially zero interest upstream or even among the distros.

grub is simply using whatever entries os-prober returns. Just modify os-prober to return EFI entry for OS X bootloader instead of native XNU loader. But os-prober is not part of grub, did you try to contact os-prober maintainers?

Yes, they basically don't care and there's no serious work being done on os-prober anymore to the degree upstream GRUB wants to replace it, but of course that also needs some work to make happen. But the above is not in relation to OS X, it's e.g. openSUSE first, followed by installing Fedora. Or Ubuntu. Or pretty much 2+ Linux distros. They all love to obliterate each other's bootloaders in favor of their own. And grub2-mkconfig creates new generic boot entries rather than using configfile to use existing distro specific grub.cfg. So what happens, invariably, with all distros, whether BIOS or UEFI, the user is presented with a grub menu that contains stale boot entries for other distros. If they boot distro B, and the kernel is updated, only that distro's grub.cfg gets updated, not the "main" one that's used by default when they boot. The multiboot Linux is just plain user hostile to the nth degree. It's really bad. And hilariously the tools to make the suffering much less, exist, mainly it's configfile and legacyconfigfile which can forward to the distro specific grub.cfg. And another option would be to get consensus on bootloaderspec. Yes both have some issues/problems, I don't think they're insurmountable. At least on (U)EFI it ought to be possible to wrap the existing GRUB file system modules into EFI filesystem drivers so any bootmanager can leverage them. And then going forward I think that's how they ought to be packaged anyway. http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ http://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ That's still a static configuration approach, but more sane than the one we have now that grub.cfg has become at least as much a sophisticate shell script, rather than a strict boot entry configuration file. Preferably dynamic discovery would be superior, like Apple's boot manager, gummiboot, and rEFInd. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sat, Mar 28, 2015 at 5:47 AM, Andrei Borzenkov wrote:

I tried to reproduce it (using QEMU with OVMF + Microsoft keys) but unfortunately Windows 2012 R2 preview image I downloaded fails to boot when secure boot is enabled.

It's possible to get a free Windows 8.1 Enterprise eval. It expires in 90 days from installation so it's useful for testing, and boots either BIOS or UEFI systems.

If you have Windows installation with working secure boot enabled, could you please send me \EFI\Windows archive?

I returned it a month ago, but I still have the EFI/ directory from the recovery media. It's a lot different than the EFI/ directory for an actual installation, but it still depends on Secure Boot so if that's useful let me know and I'll send that.

...

They don't do it that way, it's done mainly with Fedora's mactel-boot and anaconda/blivet packages. They create an HFS+ volume to use as a faux EFI System partition; and do not use the actual FAT32 EFI System partition at all (neither does Apple). What this enables is a way to choose Fedora from the OS X > System Preferences > Startup Disk panel, which is where a user typically chooses to change OS's (between OS X versions, Windows, and now also Fedora).

Grub includes grub-bless utility for OS X. I wonder, if this is exactly what is required.

Blessing is a function of HFS+, it won't work on FAT32. So a distribution would still need an HFS+ volume to use as a faux EFI System partition. It's an EFI System partition as far as linux is concerned, but the firmware thinks it's reading an OS X volume (hence the existance of mach_kernel and System/Library/CoreServices/boot.efi which is what the firmware expects in order to boot OS X). So it's kinda tricking the firmware.

...

I've suggested on upstream GRUB list that grub2-mkconfig should stop using these CSM-BIOS xnu modules to boot OS X, and instead chainload the Apple bootloader, but no one has volunteered to do this work.

I already told you that grub is using whatever os-prober returns. It is up to os-prober to return EFI chainloader entry.

Yeah and I already told you the os-prober folks don't care and have just short of abandoned os-prober. The Fedora packager can hardly get them to do anything at all, and this sounds way too major, not in their interest, and thus far not even something the Fedora packager is eager to fix separate from upstream. Who owns 30_os-prober? GRUB or the os-prober folks? Because the bogus OS X boot entries are created by the 30_os-prober script. Obviously if the system running grub-mkconfig is booted in EFI mode, it's completely wrong to produce a grub.cfg that uses xnu modules to try to boot OS X. Does os-prober determine whether the current system is booted in EFI vs with CSM? Or is that some other component? I don't know exactly how each component works, all I can tell you is the boot entries both upstream and downstream GRUBs create on Macs these days are wrong. They don't work. And that's because usually Macs are now booting in EFI mode these days, not with the CSM.

...

That's still a static configuration approach, but more sane than the one we have now that grub.cfg has become at least as much a sophisticate shell script, rather than a strict boot entry configuration file. Preferably dynamic discovery would be superior, like Apple's boot manager, gummiboot, and rEFInd.

I'm not happy with it either but no amount of "oh, this should be changed" is going to change it. Please suggest alternative.

It's a fair point, but there's no decent data on how many people really depend on multibooting and why. The most realistic answer is, multibooting is inherently painful, use VM's or containers instead. And so far that's where the efforts are being put, more so than on improving the reliability, standardization, and infrastructure needed to better support multibooting. That means distros will differentiate even more, diverging from any sense of a standard, while applications standardize so they can run on any the differentiated distros.

And do not forget that everything you named supports rather limited environment comparing with grub.

I'm completely aware. I note the complexity of GRUB is a direct consequence of essentially no standard or spec being followed by any Linux distro, therefore all of them become legitimate use cases that GRUB ends up supporting in one way or another. Which is why it is the way it is. The *simplest* OS's to boot? Windows and OS X. GRUB, gummiboot, sys/extlinux, rEFInd, they all can do that easily because there's at about two variations for each, not hundreds of variations like Linux distros permit. Absolutely, it's not GRUBs fault that it's as complicated as it is. It's the total lack of discipline, disguised as choice, by the Linux distros. And yet, for all of this supposed choice, there's still no clear separation between OS, OS updates, OS settings, applications, and user stuff. About the only thing well separated is user stuff, in /home. Everything else is littered across a bunch of directories. I think a fair 80% of linux users these days have other things to do than baby sit computers, and their layouts. They should be more stateless, self-healing, without tons of install options. Open source loves standards in almost all other context, but seems to hate it when it comes to package management, and supporting maybe at most 3-4 bootable layouts. The more time goes on, Linux distros are completely separate OS's that just so happen to share a kernel and maybe a DE. But the guts in between, ha well all bets are off there. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sat, Mar 28, 2015 at 2:08 PM, Andrei Borzenkov wrote:

В Sat, 28 Mar 2015 13:36:01 -0600 Chris Murphy пишет:

...

On Sat, Mar 28, 2015 at 5:47 AM, Andrei Borzenkov wrote:

...

I tried to reproduce it (using QEMU with OVMF + Microsoft keys) but unfortunately Windows 2012 R2 preview image I downloaded fails to boot when secure boot is enabled.

It's possible to get a free Windows 8.1 Enterprise eval. It expires in 90 days from installation so it's useful for testing, and boots either BIOS or UEFI systems.

I have Windows 8 eval (how exactly should it be different from 2012?) and it does not boot with secure boot enabled either.

...

...

If you have Windows installation with working secure boot enabled, could you please send me \EFI\Windows archive?

I returned it a month ago, but I still have the EFI/ directory from the recovery media. It's a lot different than the EFI/ directory for an actual installation, but it still depends on Secure Boot so if that's useful let me know and I'll send that.

Yes, please, send it.

...

...

Grub includes grub-bless utility for OS X. I wonder, if this is exactly what is required.

Blessing is a function of HFS+, it won't work on FAT32.

I know that I had to bless (using OS X tools) grub in ESP to be able to select it for booting. So it apparently works. May be it stores metadata somewhere in HFS+, do not know.

...

Obviously if the system running grub-mkconfig is booted in EFI mode, it's completely wrong to produce a grub.cfg that uses xnu modules to try to boot OS X. Does os-prober determine whether the current system is booted in EFI vs with CSM?

No. You are welcome to implement it. It is /usr/lib/os-probes/mounted/20macosx.

Well that's like telling a plant to water itself. In other words, it's not happening. It's easier to just hold the option key at boot time, and use the firmware's built-in boot manager. So not only is it difficult to get os-prober, or whatever, to do the right thing. It's like pulling teeth getting it to stop doing the wrong thing by writing out bogus menu entries that invariably cause the system to kernel panic when used.

Not to mention that to rely on how current system where configuration file is being created was booted is wrong as well. Boot method should be detected at run time; but this will make resulting grub.cfg even less readable and more difficult to parse.

Right. Well gummiboot and rEFInd do this correctly with OS X, they use dynamic discovery. So whoever was interested enough to make this work for OS X in the much more convoluted case of EFI booting OS X from a CSM execute GRUB 2, has apparently vanished and no one cares to either inhibit or fix things. And it's been like this for years after it was obsolete. Windows 10 ships this summer and makes Secure Boot mandatory. So pretty soon there's only

I do not have OS X (and am not OS X expert in any case) to test and nobody offered help to fix it. Either in form of providing detailed explanation what should be done (which files to check for, which files to load) or at least to test modifications.

I did all of that already, and you were even replying to that whole thread. The bottom line is that the xnu stuff either needs to be restricted to CSM-BIOS GRUB only, or ripped out, and optionally replaced with an entry that chainloads Apple's bootloader. I've tested this and it does work, even for Core Storage volumes, both encrypted and non-encrypted. https://lists.gnu.org/archive/html/grub-devel/2014-10/msg00044.html -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

...

If you have Windows installation with working secure boot enabled, could you please send me \EFI\Windows archive?

I just boot my efi capable laptop. from openSUSE: # efibootmgr -v BootCurrent: 0001 Timeout: 2 seconds BootOrder: 0001,0003 Boot0001* opensuse-secureboot HD(1,800,32000,ee46d80f-652e-45da-aa27-163d89dabf7d)File(\EFI\opensuse\shim.efi) Boot0003* Windows Boot Manager HD(1,800,32000,ee46d80f-652e-45da-aa27-163d89dabf7d)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...I................ ls /sys/firmware/efi/efivars/*Boot* /sys/firmware/efi/efivars/Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c /sys/firmware/efi/efivars/Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c /sys/firmware/efi/efivars/BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c /sys/firmware/efi/efivars/BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c /sys/firmware/efi/efivars/DefaultBootOrder-45cf35f6-0d6e-4d04-856a-0370a5b16f53 /sys/firmware/efi/efivars/FastEfiBootOption-b540a530-6978-4da7-91cb-7207d764d262 /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c here the complete content of /boot/efi (notice that /boot/efi have /boot/efi/EFI in it) http://dodin.org/owncloud/index.php/s/KJVSNxp9GjukayB jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, Mar 29, 2015 at 10:47 AM, Andrei Borzenkov wrote:

I would very interested to see full values of PK, KEK and db EFI variables from systems affected by mentioned bugs for a start.

So you need to see the contents of efivars for this? Like, a complete hexdump -C for every "file" in efivars directory? There are definitely screwy things happening here, there are even fake boot entries now happening as kludges by some companies who can't otherwise figure out how to make standard methods work. So they work around their own bugs with fake boot entries. Idiots. And this is just one example of how some hardware must have NVRAM named entries as "Windows Boot Manager" even if those boot entries aren't Windows. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Chris Murphy composed on 2015-03-27 11:04 (UTC-0600):

It's sorta like sport to clobber another distro's bootloading when doing an installation.

Grub2 devs have a strong legacy of inviting this through their virtual insistence on installing to MBR on BIOS systems. There's no justification to touch any but / partitions with boot paraphernalia on a BIOS system when / is where bootloader goes. I can't see how that attitude can't have affected its behavior with UEFI. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Ruben composed on 2015-03-27 14:26 (UTC-0400):

Felix Miata wrote:

The following was speaking to upstream policy behind the state UEFI is in, not the substance of the OP, so what follows isn't about how UEFI works, or not.

...

Grub2 devs have a strong legacy of inviting this through their virtual insistence on installing to MBR on BIOS systems. There's no justification to touch any but / partitions with boot paraphernalia on a BIOS system when / is where bootloader goes. I can't see how that attitude can't have affected its behavior with UEFI.

This was nearly incomprehensible but...

where are you putting the partition table.

Same sectors it goes on all BIOS-compatible-partitioned HDs.

Your saying the grub developers insist on using the MBR in root, especially with a BIOS system.

No. They insist Grub2 belongs installed to MBR, instead of to root partition. Dire warnings emanate from diverse places when attempts are made to install to, or read docs about installation to, partitions, instead of to MBR, claiming unreliability of required block lists that make function from a partition possible.

Then you are saying that you don't need to touch root partitions with a MBR ??

You lost me.

Is that what "boot paraphernalia" because the boot loader is there.

I don't understand what this attempts to communicate either.

Now the last sentence is a double negative.

"I can't see how that attitude can't have affected its behavior with UEFI" may look that way, but "I can see how that attitude can have affected its behavior with UEFI." is not equivalent. IOW, in my eyes, it is unfathomable that traditional upstream grub developer attitude that it (virtually must) dictate the code contained within the MBR has not had (negative) impact on the state of grub-efi. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Mar 27, 2015 at 12:26 PM, Ruben wrote:

The permutations now with UEFI is broad. It is really a big PIA. You just keep hoping it goes away, but it doesn't because it is backed by industrial consortium(s) who hate your access to systems. It solves NOTHING. All the key parts of it that needed to be solved were solved with gpart.

Boot kits are a real problem, and Secure Boot does solve that problem. The new problem is the firmware itself is vulnerable, and the drive's firmware is vulnerable. And one of the solutions for this is Intel Boot Guard, which comes with its own pile of concerns. http://mjg59.dreamwidth.org/33981.html I think a much bigger part of the problem is this is still the dark ages of computer security, more so than companies who hate user access to systems. They're basically using hammers to fix problems that require the development of scalpels. There's no guarantee that will happen, so it's appropriate to remain skeptical and critical, but I wouldn't default to assuming all companies want to sabotage you either. I mean, ultimately that Intel or AMD or ARM CPU in your computer, and the board its on, is proprietary hardware. And if you don't trust the hardware, well then all bets are off anyway.

Distros approaches to solving the multiple hurdles is indeed different for each one. You can write a book on this topic and it does not go away with a wave of the hand.... it doesn't.

Yep you're right. It's just annoying. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Mar 27, 2015 at 12:10 PM, Felix Miata wrote:

Chris Murphy composed on 2015-03-27 11:04 (UTC-0600):

...

It's sorta like sport to clobber another distro's bootloading when doing an installation.

Grub2 devs have a strong legacy of inviting this through their virtual insistence on installing to MBR on BIOS systems.

No, the 440 bytes of code in the MBR differ mainly in whether the jump defers to the active bit for a partition entry in the MBR; or if it ignores the active bit in favor of a jump to an explicit LBA. The syslinux/extlinux way of doing this is the former, same as the DOS and Windows bootloader. GRUB uses the later approach, jumping to a stage2/core.img typically in the MBR gap on BIOS. But this has nothing to do with clobbering. The problem is distros assume, and have no good way to ask the user, whether to replace the first 440 bytes of code. That's part of the stomping. The real problem though is grub2-mkconfig doesn't assemble a new "master" grub.cfg using configfile to point to all existing distro grub.cfgs. Instead, we get a new grub.cfg with either generic entries (that sometimes don't boot) or are simply missing; and if the distro updates the kernel, this grub.cfg doesn't get updated because it can't. configfile would fix that. But it requires enough interest by distros to solve the problem to implement this. So maybe it sounds like I'm blaming upstream GRUB, and I am somewhat because grub-mkconfig is theirs; but I also blame the distros, maybe more, because they could do a better job cooperating but basically when a user wants to use something else too, they don't care, not their problem to play nice in the same sandbox.

There's no justification to touch any but / partitions with boot paraphernalia on a BIOS system when / is where bootloader goes.

This is a very old debate, and the GRUB developers insist that block lists on ext aren't reliable, and while the ext developers say the problem GRUB developers are referring to is possible, it's unlikely and therefore GRUB developers are overreacting. But all you have to do is defrag boot and there's a great chance GRUB core.img gets moved (all or in part) and then totally breaks boot. So it's a rare problem, but a high penalty problem. And they avoid it by putting core.img in its own place. Which I think is not a bad idea. XFS it's a non-starter because there is no bootloader pad for XFS, so you could never put a bootloader there. Btrfs is yet again different, it has a massive 64KB bootloader pad.

I can't see how that attitude can't have affected its behavior with UEFI.

Totally orthogonal. GRUB upstream provides tools, it's a buffet of ingredients, meant to be consumed mainly by distros, not users. So inevitably we end up with distro specific GRUBs that are significantly altered with a lot of patching to the point they're considerably different. If you file a bug or post a bug inquiry on any of the GRUB lists, almost invariably you're asked to test with upstreams version because they have zero control or interest in sorting out what downstream hacks have done. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Mar 27, 2015 at 1:36 PM, Felix Miata wrote:

Chris Murphy composed on 2015-03-27 13:16 (UTC-0600):

...

Felix Miata wrote:

...

...

Grub2 devs have a strong legacy of inviting this through their virtual insistence on installing to MBR on BIOS systems.

...

No, the 440 bytes of code in the MBR differ mainly in whether the jump defers to the active bit for a partition entry in the MBR; or if it ignores the active bit in favor of a jump to an explicit LBA. The syslinux/extlinux way of doing this is the former, same as the DOS and Windows bootloader. GRUB uses the later approach, jumping to a stage2/core.img typically in the MBR gap on BIOS. But this has nothing to do with clobbering.

My meaning of clobbering is broader than that implicit in the thread, including "clobbering" by Windows installers. When they don't like MBR content, they don't ask, they simply write there as they please.

That's true. Every OS is pretty self-centered, and it's not crazy to assume that the user, by virtue of installing an OS, that it wants its installer to make that OS bootable by default. That it doesn't ask is unfortunate, but then BIOS was never designed for multiboot. UEFI is. Someone once told me of an old old old BSD bootloader, that in merely 440 bytes would ask the user which primary partition to "boot" i.e. read and execute the code in the first sector at the starting address for that partition. So it could have supported 4 OS's, without going to more extreme lengths

When dependence on jump to active is retained, the worst that happens when Windows is inevitably reinstalled is the active flag got moved and needs to be moved back, a very simple process regardless of what is bootable, very much simpler than a Grub repair.

Nah, actually the only thing you need to do to restore Windows after installing GRUB is write the syslinux mbr.bin to LBA 0. GRUB's grub-install doesn't change the active bit, it simply writes jump code to those first 440 bytes, ignoring the partition map entirely. But all of this is actively transitioning into ancient magic. GRUB is pretty much magic, it does a crap load of things, that otherwise only the linux kernel (and maybe an initramfs) can do, and typically in just 35KiB of code. It's incredibly capable. syslinux/extlinux/gummiboot - much much simpler to learn and understand and fix. BUT extremely narrow use cases. The gummiboot use case is so narrow that right now it requires the kernel on the same volume, which in effect must be FAT32 (whatever fs the firmware supports), and of course only UEFI. I guess my biggest complaint is that none of the bootloaders really put in a lot of effort to settle on one configuration file format. Gummiboot supports bootloaderspec, which makes sense since it's written by the same people so +1 there. And GRUB can read syslinux/extlinux configs, as well as all versions of GRUB current and legacy, so +3 for them, but then grub-mkconfig doesn't use that! Bha! -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Fri, Mar 27, 2015 at 5:46 PM, Felix Miata wrote:

Chris Murphy composed on 2015-03-27 16:27 (UTC-0600):

...

Felix Miata wrote:

...

...

When dependence on jump to active is retained, the worst that happens when Windows is inevitably reinstalled is the active flag got moved and needs to be moved back, a very simple process regardless of what is bootable, very much simpler than a Grub repair.

...

Nah, actually the only thing you need to do to restore Windows after installing GRUB is write the syslinux mbr.bin to LBA 0. GRUB's grub-install doesn't change the active bit, it simply writes jump code to those first 440 bytes, ignoring the partition map entirely.

That too is presumptuous. This is about multiboot. Multiboot does not mean exclusively 1 Windows and 1 Linux, or 1 Mac and 1 Linux, or 1 Windows and 2 Linux. I expect to see the same boot menu and 4-40+ choices choices on every boot, until such time as I change them myself, or direct something else to do so.

I was just confused. I thought that you were suggesting reverting to a Windows only boot. But after re-reading it you're talking about how to fix it after Window is reinstalled and steps on LBA 0's 440 bytes of bootloader code. Well with syslinux/extlinux it's fairly easy, just change the active bit, the Microsoft code in the MBR is OK. For GRUB yeah you have to do grub-install *shrug* not terribly controversial. More experienced users can probably figure out how to replace only boot.img (what was stage1 in the MBR) but that's rather unnecessary usually.

When did any Grub version or Linux installer start handling 0x0A or HPFS 0x07 partitions correctly? I've never seen it.

I don't even know to what degree GRUB is sensitive to partition type codes. I think it pretty much just defers to the configuration file's device and partition values, and tries to read the contents for the requested path-to-file, or in the case of chainloader it just starts reading code at the specified offset. There's a handful of things GRUB 2.02 can't read even once core.img gives it full ability to read all of its modules on demand. LVM RAID, LVM thin provisioning, Btrfs raid56. And probably some obscure file systems. It's a long list of what it does read from. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Fri, 27 Mar 2015 19:46:15 -0400 Felix Miata пишет:

When did any Grub version or Linux installer start handling 0x0A or HPFS 0x07 partitions correctly?

Not before someone explains what "correctly" means. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

В Sat, 28 Mar 2015 02:41:29 -0400 Felix Miata пишет:

Andrei Borzenkov composed on 2015-03-28 08:15 (UTC+0300):

...

Fri, 27 Mar 2015 19:46:15 -0400 Felix Miata composed:

...

...

When did any Grub version or Linux installer start handling 0x0A or HPFS 0x07 partitions correctly?

...

Not before someone explains what "correctly" means.

It's been a very long time since I considered such issues.

And why did you need to bring it up NOW?

From what little I remember, correctly would include, but not necessarily be limited to: 1-0x0A: It contains no "filesystem" usable by any FOSS, Mac or Windows tools. Do not proceed based upon the fact that what it does contain can be mistaken for a supported FAT filesystem. If it exists, and has a boot flag on it set, and the MBR code jumps to the primary with the active flag is set, it is a primary bootloader. Chainloading it from Grub Legacy breaks its primary functionality.

We were speaking about grub2. Why did you need to bring the issue with grub legacy up NOW?

2-0x07: It isn't NTFS. Don't proceed based upon an assumption that it is. It should never find its way into any fstab as a type ntfs. Tools intended for use with NTFS filesystems will corrupt it.

What has it to do with GRUB? Where does grub assume 0x07 partition to be NTFS? Why did you need to bring it up NOW?

If you want more detail

No, I do not need more detail about grub legacy, thank you very much. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org