-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2016-03-24 at 12:24 -0700, John Andersen wrote:

On 03/24/2016 12:07 PM, Andrei Borzenkov wrote:

...

Отправлено с iPhone

...

...

Anybody got any ideas?

Mint kernel is signed by Mint key and openSUSE loader trusts only openSUSE key (surprise). Either disable secure boot or enroll Mint key using mokutil.--

Wow, what a nugget of valuable information to drop as an offhand comment. I hadn't even thought about THAT ramification of dual boot in the UEFI world.

No, the problem is that the OP is telling openSUSE grub to boot mint, in secure mode, and it can't, out of the box. Maybe openSUSE's grub would be able to chainload mint's grub (I don't know). The correct procedure on secure UEFI would be to use the UEFI native boot menu to choose which operating system to boot. The design of UEFI allows just that, booting dozens of different operating systems independently. Whatever the manfacturers implement, that's different. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEUEARECAAYFAlb0S4AACgkQtTMYHG2NR9VALwCgkp2b0b3lT7+/ScaU0u0KS4eQ EaEAmJez5tscfcUfy4gLZp7kdfZ3eKI= =fjy1 -----END PGP SIGNATURE-----

On Thu, Mar 24, 2016 at 3:18 PM, Dave Howorth wrote:

If the openSUSE installer is going to produce a menu that claims to be able to boot the mint system, then why doesn't it make sure that the menu entry actually works! Or at the very least produce a disgnostic to say that it won't work and why. Or even better, use the UEFI boot menu as Carlos suggests!!!

Yeah well, there's a lot of broken stuff in this area because no one really cares about it except for users who suffer. And those users look at the GRUB sausage making factory go, oh god, this is scary ugly, OK just quickly fix my small problem and then run away as fast as possible. Nothing gets fixed at the distro or GRUB upstream level. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thu, 2016-03-24 at 19:32 -0500, Neil Rickert wrote:

On 03/24/2016 01:59 PM, Dave Howorth wrote:

...

I had Mint installed on a machine, which also has W10, and it was all working fine. I installed Leap and that is working fine. When I reboot I get taken to openSUSE's boot menu, which is fine, and it reboots either Leap or W10 fine, but if I select the line for Mint it says

error: vmlinuz.... has invalid signature. error: you need to load the kernel first.

My reply is to the first message. But I'm commenting on several messages.

Thanks Neil.

If you disable secure-boot, then you should be able to boot Mint.

I'm trying to avoid that if I can.

Or, as Carlos suggested, boot Mint directly from the firmware. You can possibly hit F12 during boot, and select mint from the firmware menu. Or you can change the boot order from within Leap.

The firmware boot menu just shows Windows. I think that when I installed Mint, it showed both Windows and Mint, but I might have misremembered. Anyway, it now shows just Windows.

The command: "efibootmgr -v" will list the bootable systems, and give each a 4-digit number (perhaps a hexadecimal number).

Then: efibootmgr -n 0005 will cause entry 0005 to be booted on the next boot. This is a one-time change. Or: efibootmgr -o 0005 will permanently change the boot order, making entry 5 the default.

Thanks, that worked, so it now boots to Mint.

What you have found, is that opensuse cannot boot Mint in secure-boot mode. I suggest you check whether Mint can boot opensuse. When I last checked, it could. The boot process for Mint was less secure, in that it wasn't checking kernel signatures. (It was only checking the "shim" signature).

I'm having trouble with this step. I'm now running Mint, but running its os-prober (well, Ubuntu's) only shows Windows. It doesn't even show Mint itself, let alone openSUSE. I gather there is something called os-prober-efi but it's not part of the Mint repositories so I'm not sure whether I need to use that or use some flag to the Mint os-prober, or something else?

Another possibility is to create your own kernel signing key, and sign the Mint kernel yourself. I was doing that for a while. I no long have Mint installed. But I do have Kaos installed, and I'm signing that kernel with my own key so that I can boot it with secure-boot.

Hmm, that seems like more moving parts than I'd ideally like. I'm looking for the closest approximation of 'just works out of the box' that I can find. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sat, 2016-03-26 at 21:22 +0300, Andrei Borzenkov wrote:

26.03.2016 14:59, Dave Howorth пишет:

...

I'm having trouble with this step. I'm now running Mint, but running its os-prober (well, Ubuntu's) only shows Windows. It doesn't even show Mint itself,

The purpose of os-prober is to look for other installed OS, so of course it won't show OS instance it runs under.

Thanks. That seems an odd restriction, but anyway it's not the point. So how can I discover the information I need for Mint's grub to try to boot openSUSE to see if Neil's suggestion works?

...

let alone openSUSE. I gather there is something called os-prober-efi but it's not part of the Mint repositories so I'm not sure whether I need to use that or use some flag to the Mint os-prober, or something else?

It is quite possible that "normal" os-prober is not prepared to handle tricks openSUSE plays with btrfs. We carry rather extensive btrfs patch for it.

Are these tricks documented anywhere? Would my problems go away if I reinstalled openSUSE using some other more mature filesystem for root?

Anyway, you would get the same problem even if os-prober worked - Mint (Ubuntu) loader trusts only Mint (Ubuntu) keys.

Are you saying Neil is wrong or that his information is outdated? That it is definitely not worth trying his suggestion?

...

...

Another possibility is to create your own kernel signing key, and sign the Mint kernel yourself. I was doing that for a while. I no long have Mint installed. But I do have Kaos installed, and I'm signing that kernel with my own key so that I can boot it with secure-boot.

Hmm, that seems like more moving parts than I'd ideally like. I'm looking for the closest approximation of 'just works out of the box' that I can find.

As I already told you, you can enroll key used by distribution to sign kernels. This should be enough to do just once and if you enroll both openSUSE and Mint (Ubuntu) keys, you should be able to boot both using shim.

This is supposed to work with mokutil, using

mokutil --import file.der

OK, and as I already said, mokutil seems to have appalling documentation. What is file.der? I know as little as I can get away with about booting and less than I should about certificates.

This adds UEFI variable that contains request to MokManager to enroll certificate into boot-time database (this database is not accessible after bootloader has finished, so two stage process). On next boot shim should launch MokManager.efi, which will ask you password (which was set using mokutil --password) and import keys. These imported keys should be used by every shim, shipped by every distribution.

Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, 2016-03-27 at 14:17 +0300, Andrei Borzenkov wrote:

27.03.2016 13:37, Dave Howorth пишет:

...

On Sat, 2016-03-26 at 21:22 +0300, Andrei Borzenkov wrote:

...

26.03.2016 14:59, Dave Howorth пишет:

...

I'm having trouble with this step. I'm now running Mint, but running its os-prober (well, Ubuntu's) only shows Windows. It doesn't even show Mint itself,

The purpose of os-prober is to look for other installed OS, so of course it won't show OS instance it runs under.

Thanks. That seems an odd restriction, but anyway it's not the point. So how can I discover the information I need for Mint's grub to try to boot openSUSE to see if Neil's suggestion works?

os-prober is not related to Neil's suggestion in any way. What he suggested was that you use your firmware ("BIOS") boot menu to select what OS to boot. Assuming your firmware offers this possibility in the first place. Or to flip default boot menu entry - again, in firmware, not in bootloader menu.

He did suggest using efibootmgr to control what is booted, but as I've said the EFI boot menu only displays Windows so that's no good to me as a long-term solution, only as a stopgap way to boot Mint to try other things.

...

...

...

let alone openSUSE. I gather there is something called os-prober-efi but it's not part of the Mint repositories so I'm not sure whether I need to use that or use some flag to the Mint os-prober, or something else?

It is quite possible that "normal" os-prober is not prepared to handle tricks openSUSE plays with btrfs. We carry rather extensive btrfs patch for it.

Are these tricks documented anywhere? Would my problems go away if I reinstalled openSUSE using some other more mature filesystem for root?

That depends on your definition of "documented". Interested parties could certainly read patch to find out what it does.

Anyway, I said "possible" - I cannot say what was the problem without seeing log of os-prober run on Mint. But I already had evidences of other distributions failing to detect openSUSE on btrfs.

And what "matureness" of btrfs or lack thereof has to do with it?

You said '"normal" os-prober is not prepared to handle tricks openSUSE plays with btrfs'. I took that to mean that os-prober can handle other file systems, so if I reinstall openSUSE on ext4 or reiserfs say then I might be able to persuade Mint's os-prober to give me the information I think I need to try using its grub to boot openSUSE, which would solve my problem.

...

...

Anyway, you would get the same problem even if os-prober worked - Mint (Ubuntu) loader trusts only Mint (Ubuntu) keys.

Are you saying Neil is wrong or that his information is outdated? That it is definitely not worth trying his suggestion?

How is it related to what Neil was saying? He suggested to add each OS loader to firmware menu directly, while os-prober adds "foreign" kernels to bootloader menu of specific OS. You already tried to add Mint kernels to openSUSE bootloader; why do you expect different result when adding openSUSE kernel to Mint bootloader?

It seems you only read part of Neil's message. Here is the relevant part again: 'I suggest you check whether Mint can boot opensuse. When I last checked, it could. The boot process for Mint was less secure, in that it wasn't checking kernel signatures. (It was only checking the "shim" signature).' That is what I am trying to do.

...

...

...

...

Another possibility is to create your own kernel signing key, and sign the Mint kernel yourself. I was doing that for a while. I no long have Mint installed. But I do have Kaos installed, and I'm signing that kernel with my own key so that I can boot it with secure-boot.

Hmm, that seems like more moving parts than I'd ideally like. I'm looking for the closest approximation of 'just works out of the box' that I can find.

As I already told you, you can enroll key used by distribution to sign kernels. This should be enough to do just once and if you enroll both openSUSE and Mint (Ubuntu) keys, you should be able to boot both using shim.

This is supposed to work with mokutil, using

mokutil --import file.der

OK, and as I already said, mokutil seems to have appalling documentation.

Documentation does not appear out of nowhere. Are you willing to contribute good documentation after you managed to get it working?

I'm willing to contribute good documentation when I understand something. I'm very much hoping that I won't need to understand any more than how to import a key.

That is, assuming that the very first Google hit searching for "mokutil" is not enough ... https://sourceware.org/systemtap/wiki/SecureBoot

Yes, I saw that link. I didn't bother reading it since it appears to be about something different. Even having read it, I'm no wiser.

...

What is file.der?

This is public part of certificate used to sign loader and kernel, packaged in binary format. Assuming Mint is based on Ubuntu you probably could simply try Canonical certificates from http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/...

Otherwise you have to contact Mint community and ask them where to find it. If you can't, openSUSE key is shipped with grub2 package in /usr/lib64/efi/*.der.

Neil explained why he thought trying to get openSUSE to boot Mint was futile, unless I got the kernel signed, so it seems likely to be easier to get Mint to boot openSUSE, which is why I want to understand how to get its os-prober to detect openSUSE or otherwise get whatever I need to put in its grub configuration. Can I just copy some details from openSUSE's grub?

...

I know as little as I can get away with about booting and less than I should about certificates.

...

This adds UEFI variable that contains request to MokManager to enroll certificate into boot-time database (this database is not accessible after bootloader has finished, so two stage process). On next boot shim should launch MokManager.efi, which will ask you password (which was set using mokutil --password) and import keys. These imported keys should be used by every shim, shipped by every distribution.

Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

27.03.2016 20:01, Dave Howorth пишет:

...

...

...

...

let alone openSUSE. I gather there is something called os-prober-efi but it's not part of the Mint repositories so I'm not sure whether I need to use that or use some flag to the Mint os-prober, or something else?

It is quite possible that "normal" os-prober is not prepared to handle tricks openSUSE plays with btrfs. We carry rather extensive btrfs patch for it.

Are these tricks documented anywhere? Would my problems go away if I reinstalled openSUSE using some other more mature filesystem for root?

That depends on your definition of "documented". Interested parties could certainly read patch to find out what it does.

Anyway, I said "possible" - I cannot say what was the problem without seeing log of os-prober run on Mint. But I already had evidences of other distributions failing to detect openSUSE on btrfs.

And what "matureness" of btrfs or lack thereof has to do with it?

You said '"normal" os-prober is not prepared to handle tricks openSUSE plays with btrfs'. I took that to mean that os-prober can handle other file systems, so if I reinstall openSUSE on ext4 or reiserfs say then I might be able to persuade Mint's os-prober to give me the information I think I need to try using its grub to boot openSUSE, which would solve my problem.

That's rather brute force solution. Could you make available log of os-prober run - run os-prober and post /var/log/syslog during duration of os-prober run.

...

...

...

Anyway, you would get the same problem even if os-prober worked - Mint (Ubuntu) loader trusts only Mint (Ubuntu) keys.

Are you saying Neil is wrong or that his information is outdated? That it is definitely not worth trying his suggestion?

How is it related to what Neil was saying? He suggested to add each OS loader to firmware menu directly, while os-prober adds "foreign" kernels to bootloader menu of specific OS. You already tried to add Mint kernels to openSUSE bootloader; why do you expect different result when adding openSUSE kernel to Mint bootloader?

It seems you only read part of Neil's message. Here is the relevant part again:

'I suggest you check whether Mint can boot opensuse. When I last checked, it could. The boot process for Mint was less secure, in that it wasn't checking kernel signatures. (It was only checking the "shim" signature).'

That is what I am trying to do.

I'd rather avoid using distribution that fakes secure boot and allows to run arbitrary binary. I hope that is not true.

...

...

...

...

...

Another possibility is to create your own kernel signing key, and sign the Mint kernel yourself. I was doing that for a while. I no long have Mint installed. But I do have Kaos installed, and I'm signing that kernel with my own key so that I can boot it with secure-boot.

Hmm, that seems like more moving parts than I'd ideally like. I'm looking for the closest approximation of 'just works out of the box' that I can find.

As I already told you, you can enroll key used by distribution to sign kernels. This should be enough to do just once and if you enroll both openSUSE and Mint (Ubuntu) keys, you should be able to boot both using shim.

This is supposed to work with mokutil, using

mokutil --import file.der

OK, and as I already said, mokutil seems to have appalling documentation.

Documentation does not appear out of nowhere. Are you willing to contribute good documentation after you managed to get it working?

I'm willing to contribute good documentation when I understand something. I'm very much hoping that I won't need to understand any more than how to import a key.

...

That is, assuming that the very first Google hit searching for "mokutil" is not enough ... https://sourceware.org/systemtap/wiki/SecureBoot

Yes, I saw that link. I didn't bother reading it since it appears to be about something different. Even having read it, I'm no wiser.

...

...

What is file.der?

This is public part of certificate used to sign loader and kernel, packaged in binary format. Assuming Mint is based on Ubuntu you probably could simply try Canonical certificates from http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/...

Otherwise you have to contact Mint community and ask them where to find it. If you can't, openSUSE key is shipped with grub2 package in /usr/lib64/efi/*.der.

Neil explained why he thought trying to get openSUSE to boot Mint was futile, unless I got the kernel signed, so it seems likely to be easier to get Mint to boot openSUSE, which is why I want to understand how to get its os-prober to detect openSUSE or otherwise get whatever I need to put in its grub configuration. Can I just copy some details from openSUSE's grub?

Yes; actually menu entry from openSUSE grub2 should work as is. Or you can simply go to grub2 command line and try to load openSUSE kernel manually, just to verify whether it will be accepted at all (you do not even need to supply correct parameters at this point, it does not matter whether it boots).

...

...

I know as little as I can get away with about booting and less than I should about certificates.

...

This adds UEFI variable that contains request to MokManager to enroll certificate into boot-time database (this database is not accessible after bootloader has finished, so two stage process). On next boot shim should launch MokManager.efi, which will ask you password (which was set using mokutil --password) and import keys. These imported keys should be used by every shim, shipped by every distribution.

Cheers, Dave

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Le 28/03/2016 19:33, Dave Howorth a écrit :

That makes sense to me. Sadly, the firmware boot menu is only showing Windows and I have no idea how to edit it or persuade it to edit itself.

boot windows, use easyefi.exe... already said jdd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

28.03.2016 20:33, Dave Howorth пишет:

...

If you use 'tree -L 3 /boot/efi' you should see that there are multiple GRUBs on your system. There'll be a Windows directory and bootloader, and two GRUBs, one in a suse directory and the other in a Mint directory (something like that, I'm not sure what the exact names are).

I can see those in /boot/efi/EFI. And I can see all three as options in efibootmgr

So show output of "efibootmgr -v" to us finally. I think the simplest solution in your case is to chainload Mint shim which is signed by Microsoft and so is guaranteed to pass signature verification, but we need to know how it is called. Output of "ls -lR" /boot/efi would be helpful las well.

...

But the built-in boot manager will let you pick those directly,

But I only see Windows in this boot menu!!!

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

29.03.2016 09:52, Dave Howorth пишет:

# efibootmgr -v BootCurrent: 0001 Timeout: 2 seconds BootOrder: 0001,0000,0002 Boot0000* Windows Boot Manager HD(1,800,32000,2d6563ec-fd02-4309-bc44-3b5343fc88f2)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.}...r................ Boot0001* opensuse-secureboot HD(1,800,32000,2d6563ec-fd02-4309-bc44-3b5343fc88f2)File(\EFI\opensuse \shim.efi) Boot0002* ubuntu HD(1,800,32000,2d6563ec-fd02-4309-bc44-3b5343fc88f2)File(\EFI\ubuntu \shimx64.efi)

...

/boot/efi/EFI/ubuntu: total 3439 -rwxrwxr-x 1 root root 1271672 Jan 17 15:24 MokManager.efi -rwxrwxr-x 1 root root 121 Jan 17 15:24 grub.cfg -rwxrwxr-x 1 root root 958328 Jan 17 15:24 grubx64.efi -rwxrwxr-x 1 root root 1289424 Jan 17 15:24 shimx64.efi

OK, so create on openSUSE file /boot/grub2/custom.cfg with content menuentry "Mint bootloader" { set root=hd0,1 chainloader /EFI/ubuntu/shimx64.efi } and reboot. You should get this menu entry, and hopefully selecting it will bring up Mint boot menu. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

29.03.2016 23:16, Dave Howorth пишет:

On Tue, 2016-03-29 at 21:16 +0300, Andrei Borzenkov wrote:

...

29.03.2016 09:52, Dave Howorth пишет:

...

# efibootmgr -v BootCurrent: 0001 Timeout: 2 seconds BootOrder: 0001,0000,0002 Boot0000* Windows Boot Manager HD(1,800,32000,2d6563ec-fd02-4309-bc44-3b5343fc88f2)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.}...r................ Boot0001* opensuse-secureboot HD(1,800,32000,2d6563ec-fd02-4309-bc44-3b5343fc88f2)File(\EFI\opensuse \shim.efi) Boot0002* ubuntu HD(1,800,32000,2d6563ec-fd02-4309-bc44-3b5343fc88f2)File(\EFI\ubuntu \shimx64.efi)

...

...

/boot/efi/EFI/ubuntu: total 3439 -rwxrwxr-x 1 root root 1271672 Jan 17 15:24 MokManager.efi -rwxrwxr-x 1 root root 121 Jan 17 15:24 grub.cfg -rwxrwxr-x 1 root root 958328 Jan 17 15:24 grubx64.efi -rwxrwxr-x 1 root root 1289424 Jan 17 15:24 shimx64.efi

OK, so create on openSUSE file /boot/grub2/custom.cfg with content

menuentry "Mint bootloader" { set root=hd0,1 chainloader /EFI/ubuntu/shimx64.efi }

and reboot. You should get this menu entry, and hopefully selecting it will bring up Mint boot menu.

It brings up:

error: disk 'hd0,1' not found.

When I correct it to hd1,1 it loads Mint's grub but when that tries to load Mint, it says:

Bootloader has not verified image. System is compromised

Oh! Are you able to boot Mint at all with secure boot enabled? Try efibootmgr -n 0002 This /should/ set one time boot option for next reboot only to Mint loader, so no openSUSE will be involved. Are you able to boot it this way?

(n.b. paraphrased because the system switches off before I can type the message into the mail).

So no banana yet. Dave

I'll keep trying my other options.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Wed, 2016-03-30 at 07:34 +0100, Dave Howorth wrote:

On Tue, 2016-03-29 at 21:16 +0300, Andrei Borzenkov wrote:

...

...

...

OK, so create on openSUSE file /boot/grub2/custom.cfg with content

menuentry "Mint bootloader" { set root=hd0,1 chainloader /EFI/ubuntu/shimx64.efi }

and reboot. You should get this menu entry, and hopefully selecting it will bring up Mint boot menu.

It brings up:

error: disk 'hd0,1' not found.

When I correct it to hd1,1 it loads Mint's grub but when that tries to load Mint, it says:

Bootloader has not verified image. System is compromised

Oh! Are you able to boot Mint at all with secure boot enabled? Try

efibootmgr -n 0002

This /should/ set one time boot option for next reboot only to Mint loader, so no openSUSE will be involved. Are you able to boot it this way?

Yes, that works just fine.

...

...

(n.b. paraphrased because the system switches off before I can type the message into the mail).

So no banana yet. Dave

I'll keep trying my other options.

Well I finally got something to work. What a pain. I created a chainloader entry in Mint for openSUSE and that works. I've no idea whether this is optimum but this is what I've got: menuentry "openSUSE bootloader" { insmod chain insmod btrfs set root=(hd1,1) chainloader /EFI/opensuse/shim.efi } I'm disappointed that Acer haven't seen fit to reply to my query to them about editing the machine's boot menu. I may try installing rEFInd to get single stage multi-booting rather than chainloading. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2016-04-01 at 12:21 -0600, Chris Murphy wrote:

On Thu, Mar 31, 2016 at 11:16 PM, Dave Howorth wrote:

...

I'm disappointed that Acer haven't seen fit to reply to my query to them about editing the machine's boot menu. I may try installing rEFInd to get single stage multi-booting rather than chainloading.

Understand any legit firmware bug is going to have to find its way up to engineering, and there's usually a thick filtering layer between user and engineering. What I'd expect is, engineering will take weeks to months to get the code fixed, assuming it's a model they're actively supporting with firmware updates. And then support will ask you to update your firmware once they get informed from engineering and website folks that there's an update available.

Support should answer with something as soon as possible, which was what was asked for. Then they can determine if it is a bug, a user error, a solvable problem... whatever. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlb+wooACgkQtTMYHG2NR9XC9ACeJ8BsiZwjEC92OLsAxlZ41tUi Cj4AoIwV4wL0SdPDFzrJnexokguIAV+g =I5zL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 2016-04-01 at 21:57 +0100, Dave Howorth wrote:

Acer did come back to me now, with a classic 'support' answer:

"This unit is been manufactured with Windows 10 operating system.There are no specific option in the BIOS to choose boot operating system and also Acer has not released any BIOS update with the firmware upgrade to enable users to choose boot operating system.

"Windows 10 is set as the default boot operating system as the unit is manufactured with it."

Argh :-( You could retort that they are breaking the UEFI standard and return the unit. Or for using unfair practices against competitors. Or you could install two windows and ask them how to boot them. - -- Cheers, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlb+4fkACgkQtTMYHG2NR9Vu6QCfe59syYhTxICujIlyj0fVMlxQ EpoAnj1IsrcLev4U7ayepy+XgaIquU3b =8meS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

01.04.2016 23:57, Dave Howorth пишет:

rEFInd, here I come.

Does it support secure boot? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

01.04.2016 21:21, Chris Murphy пишет:

What I'd probably do is take a cell phone screen shot of the boot manager menu showing only Windows; show the contents of tree -L 3 /boot/efi to show the ESP filesystem tree; show the contents of efibootmgr -v; and then point out that it's not conforming to UEFI spec section 3 regarding the Boot Manager.

Really? --><-- The boot manager can also, at its own discretion, provide an administrator with the ability to invoke manual maintenance operations as well. Examples include choosing the order of any or all load options, activating or deactivating load options, initiating OS-defined or platform-defined recovery, etc. --><-- Where do you see requirement that boot manager *must* offer interface to select anything? The only thing that is required is --><-- Boot Manger is also required to honor the priorities set in BootOrder variable. --><-- Which it obviously does in this case. It is also required to --><-- not, under normal operation, automatically remove any correctly formed Boot#### variable currently referenced by the BootOrder or BootNext variables. --><-- which it also does not do. So vendor implementation is fully compliant with spec. UEFI defines mechanism, not policy. Mechanism is various variables holding desired boot options. Policy - how these options are selected - remains at implementer's discretion. Which is one of reasons why relying on firmware boot manager for anything is so unreliable. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sat, 2016-04-02 at 09:38 +0300, Andrei Borzenkov wrote:

01.04.2016 08:16, Dave Howorth пишет:

...

On Wed, 2016-03-30 at 07:34 +0100, Dave Howorth wrote:

...

On Tue, 2016-03-29 at 21:16 +0300, Andrei Borzenkov wrote:

...

...

...

OK, so create on openSUSE file /boot/grub2/custom.cfg with content

menuentry "Mint bootloader" { set root=hd0,1 chainloader /EFI/ubuntu/shimx64.efi }

and reboot. You should get this menu entry, and hopefully selecting it will bring up Mint boot menu.

It brings up:

error: disk 'hd0,1' not found.

When I correct it to hd1,1 it loads Mint's grub but when that tries to load Mint, it says:

Bootloader has not verified image. System is compromised

Oh! Are you able to boot Mint at all with secure boot enabled? Try

efibootmgr -n 0002

This /should/ set one time boot option for next reboot only to Mint loader, so no openSUSE will be involved. Are you able to boot it this way?

Yes, that works just fine.

...

...

(n.b. paraphrased because the system switches off before I can type the message into the mail).

So no banana yet. Dave

I'll keep trying my other options.

Well I finally got something to work. What a pain. I created a chainloader entry in Mint for openSUSE and that works. I've no idea whether this is optimum but this is what I've got:

menuentry "openSUSE bootloader" { insmod chain insmod btrfs set root=(hd1,1) chainloader /EFI/opensuse/shim.efi }

I was meant to answer earlier, sorry for delay.

The error message you get when you try to chainload Ubuntu shim from openSUSE shim comes from shim itself. As far as I can tell looking at code, it is a bug in shim which is hit when you are doing something like this

shim(1) -> bootloader(1) -> shim(2) -> bootloader(2) -> kernel

The problem is that shim(1) hooks into EFI services but it has no information about bootloader(2), so when bootloder(2) attempts to launch kernel, shim(1) thinks kernel was not verified and blocks this attempt.

I kind of understand what you're saying, but not completely. You're saying that shim(1) is still involved even after it chainloads shim(2)? I thought the whole purpose of chainloading was to pass responsibility to the other boot system?

Now code that does it (at least, code that contains error message you see) appeared in shim 0.9. At least my copy of Ubuntu 14.04 has shim 0.8. Could you verify what shim version you have?

I don't know how to do that and searching the intertubes hasn't helped. The openSUSE shim is whatever comes with Leap 42.1 and the ubuntu shim is whatever comes with Mint 17.3.

If Mint has shim 0.8 it probably explains why chainload in opposite direction works, but that also means that it will most likely stop working when shim in Mint/Ubuntu is updated.

I suggest you open at least openSUSE bug report; the code in question comes partially from SUSE developer, so we have good chances to get it fixed. Please tell bug number here so I could comment on it.

I'll do that. You'll need to tell me what the bug is so I can report it. Before that, you'll need to tell me how to login. I type my username and tell it I've forgotten my password. It says my security question is my mother's maiden name in german, which seems most unlikely, and I don't remember what email address I signed up with a long time ago. And my browser remembers nothing because you've changed your security domain. So I'm stuck. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sat, 2016-04-02 at 17:21 +0300, Andrei Borzenkov wrote:

02.04.2016 14:38, Dave Howorth пишет:

...

Before that, you'll need to tell me how to login. I type my username and tell it I've forgotten my password. It says my security question is my mother's maiden name in german, which seems most unlikely, and I don't remember what email address I signed up with a long time ago. And my browser remembers nothing because you've changed your security domain. So I'm stuck.

I'm not sure what "it" you mean here. Please show exact URL you use and explain steps leading to this error. Do you have SUSE/Novell account?

I have an old SUSE/Novell account, yes. And my username djh is still recognized.

From https://en.opensuse.org/openSUSE:Submitting_bug_reports I go to http://bugzilla.opensuse.org/ and click on login to https://bugzilla.opensuse.org/index.cgi?GoAheadAndLogIn=1 which redirects to https://login.microfocus.com/nidp/idff/sso?id=6&sid=10&option=credential&sid=10&target=https://esp.microfocus.com/LAGBroker?%22https://bugzilla.opensuse.org/index.cgi?GoAheadAndLogIn=1%22 and click on Forgot Password to https://www.suse.com/selfreg/jsp/forgotPassword.jsp which opens a new window and enter my username and click on continue, I then get the German language prompt and then I have to resize the window (which SUSE opened remember!) because it is opened the wrong size and doesn't have a scroll bar to get to the bottom of the window, which I need to do to see the link forgot all to https://www.suse.com/selfreg/jsp/forgotPassword.jsp# and when I click on that it wants the email I used when I signed up. It doesn't accept my current addresses and I have no idea when I signed up or what email address I was using at the time.

Cheers, Dave BTW, if I try to access https://opensuse-community.org/ Firefox says Your connection is not secure The owner of opensuse-community.org has configured their website improperly. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Op zaterdag 2 april 2016 21:51:55 CEST schreef Andrei Borzenkov:

02.04.2016 18:59, Dave Howorth пишет:

...

On Sat, 2016-04-02 at 17:21 +0300, Andrei Borzenkov wrote:

...

02.04.2016 14:38, Dave Howorth пишет:

...

Before that, you'll need to tell me how to login. I type my username and tell it I've forgotten my password. It says my security question is my mother's maiden name in german, which seems most unlikely, and I don't remember what email address I signed up with a long time ago. And my browser remembers nothing because you've changed your security domain. So I'm stuck.

I'm not sure what "it" you mean here. Please show exact URL you use and explain steps leading to this error. Do you have SUSE/Novell account?

I have an old SUSE/Novell account, yes. And my username djh is still recognized.

How do you know it if you cannot login?

...

From https://en.opensuse.org/openSUSE:Submitting_bug_reports I go to http://bugzilla.opensuse.org/ and click on login to https://bugzilla.opensuse.org/index.cgi?GoAheadAndLogIn=1 which redirects to https://login.microfocus.com/nidp/idff/sso?id=6&sid=10&option=credential&s id=10&target=https://esp.microfocus.com/LAGBroker?%22https://bugzilla.open suse.org/index.cgi?GoAheadAndLogIn=1%22 and click on Forgot Password to https://www.suse.com/selfreg/jsp/forgotPassword.jsp which opens a new window and enter my username and click on continue, I then get the German language prompt and then I have to resize the window (which SUSE opened remember!) because it is opened the wrong size and doesn't have a scroll bar to get to the bottom of the window, which I need to do to see the link forgot all to https://www.suse.com/selfreg/jsp/forgotPassword.jsp# and when I click on that it wants the email I used when I signed up. It doesn't accept my current addresses and I have no idea when I signed up or what email address I was using at the time.

Well, I doubt anyone on this list will be able to help you. If you want to restore access to your old account, you need to contact Novell or SUSE customer service; otherwise just register again.

Or a forums global mod to read this ... :-)

...

Cheers, Dave

BTW, if I try to access https://opensuse-community.org/ Firefox says

Your connection is not secure

The owner of opensuse-community.org has configured their website improperly.

-- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Op zaterdag 2 april 2016 16:59:40 CEST schreef Dave Howorth:

On Sat, 2016-04-02 at 17:21 +0300, Andrei Borzenkov wrote:

...

02.04.2016 14:38, Dave Howorth пишет:

...

Before that, you'll need to tell me how to login. I type my username and tell it I've forgotten my password. It says my security question is my mother's maiden name in german, which seems most unlikely, and I don't remember what email address I signed up with a long time ago. And my browser remembers nothing because you've changed your security domain. So I'm stuck.

I'm not sure what "it" you mean here. Please show exact URL you use and explain steps leading to this error. Do you have SUSE/Novell account?

I have an old SUSE/Novell account, yes. And my username djh is still recognized.

But that one's not yours ....... Found it You'll receive a private email in a couple of minutes

From https://en.opensuse.org/openSUSE:Submitting_bug_reports I go to http://bugzilla.opensuse.org/ and click on login to https://bugzilla.opensuse.org/index.cgi?GoAheadAndLogIn=1 which redirects to https://login.microfocus.com/nidp/idff/sso?id=6&sid=10&option=credential&sid =10&target=https://esp.microfocus.com/LAGBroker?%22https://bugzilla.opensuse .org/index.cgi?GoAheadAndLogIn=1%22 and click on Forgot Password to https://www.suse.com/selfreg/jsp/forgotPassword.jsp which opens a new window and enter my username and click on continue, I then get the German language prompt and then I have to resize the window (which SUSE opened remember!) because it is opened the wrong size and doesn't have a scroll bar to get to the bottom of the window, which I need to do to see the link forgot all to https://www.suse.com/selfreg/jsp/forgotPassword.jsp# and when I click on that it wants the email I used when I signed up. It doesn't accept my current addresses and I have no idea when I signed up or what email address I was using at the time.

Cheers, Dave

BTW, if I try to access https://opensuse-community.org/ Firefox says

Your connection is not secure

The owner of opensuse-community.org has configured their website improperly.

-- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, Mar 29, 2016 at 12:52 AM, Dave Howorth wrote:

# efibootmgr -v BootCurrent: 0001 Timeout: 2 seconds BootOrder: 0001,0000,0002 Boot0000* Windows Boot Manager HD(1,800,32000,2d6563ec-fd02-4309-bc44-3b5343fc88f2)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.}...r............. ... Boot0001* opensuse-secureboot HD(1,800,32000,2d6563ec-fd02-4309-bc44-3b5343fc88f2)File(\EFI\opensuse \shim.efi) Boot0002* ubuntu HD(1,800,32000,2d6563ec-fd02-4309-bc44-3b5343fc88f2)File(\EFI\ubuntu \shimx64.efi)

This looks reasonable. Can you confirm this system has the latest firmware updates from the manufacturer? There are a lot of bugs with enumeration, but it really should scan the EFI system partition to properly enumerate the built-in boot manager menu. It might also help if you took a cell phone photo and put it up somewhere, just because the UI for this is different for each firmware implementation. On the Intel NUC I have with American Megatrends firmware, it's a separate F key to get to the boot manager, than it is firmware setup, than it is firmware updates, then for network boot. So multiple F keys, all at the splash screen that appears before GRUB.

...

...

...

But the built-in boot manager will let you pick those directly,

But I only see Windows in this boot menu!!!

Sad. Seems like a bug. It should work, according to the UEFI spec, but there are lots of bugs. It's definitely worth while making certain the firmware is up to date. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Mon, Mar 28, 2016 at 9:24 PM, Andrei Borzenkov wrote:

28.03.2016 07:54, Chris Murphy пишет:

...

Long version: Basically the distros have a bunch of mutually incompatible forks of upstream GRUB.

How it is relevant in this case at all?

It's the superset position, the ultimate cause for all bootloading madness on Linux. It's not the user's fault they're so often confused about something that should be so basic and reliable. The GRUB2 multiboot experience handed to us by distros is basically crap and it's not really possible to overstate that. This is marginally less crap with upstream GRUB. But it's actually nearly pleasant with systemd-boot (gummiboot) and rEFInd. So it's not like it's a technical problem, or really that difficult seeing as not many people were involved in those other bootloaders in comparison to GRUB2. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 2016-03-29 at 08:44 +0300, Andrei Borzenkov wrote:

Отправлено с iPhone

...

29 марта 2016 г., в 7:09, Chris Murphy написал(а):

...

On Mon, Mar 28, 2016 at 9:24 PM, Andrei Borzenkov wrote: 28.03.2016 07:54, Chris Murphy пишет:

...

Long version: Basically the distros have a bunch of mutually incompatible forks of upstream GRUB.

How it is relevant in this case at all?

It's the superset position, the ultimate cause for all bootloading madness on Linux. It's not the user's fault they're so often confused about something that should be so basic and reliable. The GRUB2 multiboot experience handed to us by distros is basically crap and it's not really possible to overstate that.

This is marginally less crap with upstream GRUB. But it's actually nearly pleasant with systemd-boot (gummiboot) and rEFInd. So it's not

So rEFInd or systemd-boot will ignore file signature and allow you to load and launch anything you through at them? Otherwise please explain how using different boot loader would change anything here.

How about checking the signature and then asking the user whether they want to ignore a broken/missing signature, rather than deciding for them what is or isn't safe? At least that way I would have a system that booted nicely whilst I looked for a solution to make the nag message go away (e.g. "missing signature, do you really want to boot?") Cheers, Dave

...

like it's a technical problem, or really that difficult seeing as not many people were involved in those other bootloaders in comparison to GRUB2.

-- Chris Murphy

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Tue, 2016-03-29 at 10:52 -0600, Chris Murphy wrote:

On Tue, Mar 29, 2016 at 12:57 AM, Dave Howorth wrote:

...

On Tue, 2016-03-29 at 08:44 +0300, Andrei Borzenkov wrote:

...

Отправлено с iPhone

...

29 марта 2016 г., в 7:09, Chris Murphy написал(а):

...

On Mon, Mar 28, 2016 at 9:24 PM, Andrei Borzenkov wrote: 28.03.2016 07:54, Chris Murphy пишет:

...

Long version: Basically the distros have a bunch of mutually incompatible forks of upstream GRUB.

How it is relevant in this case at all?

It's the superset position, the ultimate cause for all bootloading madness on Linux. It's not the user's fault they're so often confused about something that should be so basic and reliable. The GRUB2 multiboot experience handed to us by distros is basically crap and it's not really possible to overstate that.

This is marginally less crap with upstream GRUB. But it's actually nearly pleasant with systemd-boot (gummiboot) and rEFInd. So it's not

So rEFInd or systemd-boot will ignore file signature and allow you to load and launch anything you through at them? Otherwise please explain how using different boot loader would change anything here.

How about checking the signature and then asking the user whether they want to ignore a broken/missing signature, rather than deciding for them what is or isn't safe? At least that way I would have a system that booted nicely whilst I looked for a solution to make the nag message go away (e.g. "missing signature, do you really want to boot?")

Because that'd be writing a vulnerability into the bootloader making it easy to defeat Secure Boot. All someone needs now is to get access to your grub.cfg and just code it to blindly accept any unsigned kernel and even lie to you onscreen with a message that it's signed and safe to boot. The entire point of secure boot is to make this hard for an attacker, which means it'll be hard for you to thwart also.

I don't know enough to be sure, but are you sure that is really true? grub is signed, I believe, so that can't be modified and if the only options are 'refuse to boot' or 'only boot after a warning' then it's fairly safe, surely? And perhaps it's possible to code it so the 'refuse to boot' option is secure, e.g. by providing a separate grub.efi?

The simplest and safest solution to your problem is use the firmware built-in boot manager to select the distro, and by doing that the shim+grub combination for that distro is used to boot. An alternative to this is use efibootmgr to change the boot order or set a boot next (one-time) and then reboot.

That does sound like a nice idea, but unfortunately as I think I've already said, the firmware boot menu only shows Windows. So it won't work. My suspicion is that something in the openSUSE install has upset it, so I'm going to reinstall Mint's boot components and see if that fixes it. I also discovered that btrfs support is not installed by default in Mint, so now I've installed it, perhaps Mint will discover openSUSE and its grub will be able to boot everything. Or failing that, I'm coming around to Neil's view that secure boot simply isn't worth the price. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org