[opensuse] leap install messed up mint
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. The machine has UEFI and is in secure mode and Mint was booting just fine using its own (well, Ubuntu's) grub so presumably has a good signature, so I'm currently thinking of this as an openSUSE problem. Anybody got any ideas? Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Отправлено с iPhone
24 марта 2016 г., в 21:59, Dave Howorth <dave@howorth.org.uk> написал(а):
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.
The machine has UEFI and is in secure mode and Mint was booting just fine using its own (well, Ubuntu's) grub so presumably has a good signature, so I'm currently thinking of this as an openSUSE problem.
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.-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 03/24/2016 12:07 PM, Andrei Borzenkov wrote:
Отправлено с iPhone
24 марта 2016 г., в 21:59, Dave Howorth <dave@howorth.org.uk> написал(а):
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.
The machine has UEFI and is in secure mode and Mint was booting just fine using its own (well, Ubuntu's) grub so presumably has a good signature, so I'm currently thinking of this as an openSUSE problem.
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. -- After all is said and done, more is said than done. -- 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 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, 2016-03-24 at 21:18 +0100, Carlos E. R. wrote:
-----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.
Exactly. Thanks to Andrei for giving me a hint (the name of the program that will hopefully be able to fix my problem once I have grokked it, since it doesn't seem to be the best documented program-I've-never-heard-of in the world). But ... 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!!! Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 24, 2016 at 3:18 PM, Dave Howorth <dave@howorth.org.uk> 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 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. If you disable secure-boot, then you should be able to boot Mint. 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 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. 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). 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. -- 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
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.
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. Anyway, you would get the same problem even if os-prober worked - Mint (Ubuntu) loader trusts only Mint (Ubuntu) keys.
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 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. -- 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
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.
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?
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?
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? That is, assuming that the very first Google hit searching for "mokutil" is not enough ... https://sourceware.org/systemtap/wiki/SecureBoot
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.
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
Le 27/03/2016 19:01, Dave Howorth a écrit :
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.
if, and only if, you installed mint and openSUSE on EFI mode, you can use the windows free app "easyefi" to build the uefi menu and choose the default boot http://dodin.info/wiki/pmwiki.php?n=Doc.UEFIBoot jdd -- 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
On Sun, Mar 27, 2016 at 9:54 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
27.03.2016 20:01, Dave Howorth пишет:
'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.
I hope it's not true also, it should be looked at though because the user is better off explicitly choosing to disable Secure Boot, so they know for sure they've opted out. A faked Secure Boot is a silent opt out, not good, and arguably very inappropriate. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, Mar 24, 2016 at 12:59 PM, Dave Howorth <dave@howorth.org.uk> 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.
The machine has UEFI and is in secure mode and Mint was booting just fine using its own (well, Ubuntu's) grub so presumably has a good signature, so I'm currently thinking of this as an openSUSE problem.
Anybody got any ideas?
Short version: I think you're best off using the firmware's built-in boot manager to choose Windows vs suse, vs Mint, rather than expecting the suse GRUB to boot Windows or Mint; or the Mint GRUB to boot Windows or suse. Long version: Basically the distros have a bunch of mutually incompatible forks of upstream GRUB. And they don't care about multiboot at all. That's why it's broken, and will likely remain broken or at least a bad experience for most users for the foreseeable future. If the distros cared, they'd agree to a boot standard or spec, and agree to a flag day where everyone starts supporting the new way. But as far as I can tell, the distros hate multiboot and would like it to go away but they have to at least put on something of a show they support Windows + distro X dual boot, or the users would get mad. But that's about it. Linux A + Linux B is the least likely combination to work. 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). But the built-in boot manager will let you pick those directly, rather than picking them through the grub menu. What you'll see when you pick the opensuse option is you'll get the opensuse GRUB menu. If you pick the Mint option, you'll see the Mint GRUB option. And if you pick Windows, there is no bootloader UI at all by default with Windows so that'll just boot directly into Windows. The gotcha is every UEFI firmware OEM has different F key shortcuts to get to the built-in boot manager. And the UI differs somewhat as well. So what works for one person won't necessarily work for another. On my NUC, F2 get me into firmware setup. F10 gets me to the boot manager menu. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 2016-03-27 at 22:54 -0600, Chris Murphy wrote:
On Thu, Mar 24, 2016 at 12:59 PM, Dave Howorth <dave@howorth.org.uk> 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.
The machine has UEFI and is in secure mode and Mint was booting just fine using its own (well, Ubuntu's) grub so presumably has a good signature, so I'm currently thinking of this as an openSUSE problem.
Anybody got any ideas?
Short version: I think you're best off using the firmware's built-in boot manager to choose Windows vs suse, vs Mint, rather than expecting the suse GRUB to boot Windows or Mint; or the Mint GRUB to boot Windows or suse.
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. The machine is an Acer XC-705 and I haven't had any luck searching for specific instructions; I can't see anything likely in the BIOS menus; and I'm not aware of a generic UEFI mechanism to edit the boot menu.
Long version: Basically the distros have a bunch of mutually incompatible forks of upstream GRUB. And they don't care about multiboot at all. That's why it's broken, and will likely remain broken or at least a bad experience for most users for the foreseeable future.
I'm inclined to agree with you about this too. :(
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
But the built-in boot manager will let you pick those directly,
But I only see Windows in this boot menu!!!
The gotcha is every UEFI firmware OEM has different F key shortcuts to get to the built-in boot manager. And the UI differs somewhat as well.
It's DEL for BIOS, F12 for boot manager, but I don't see any options to change the boot manager display Thanks, 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
On Mon, 2016-03-28 at 19:40 +0200, jdd wrote:
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...
That seems to do the same job as efibootmgr, or have I misunderstood? Cheers, Dave -- 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
On Tue, 2016-03-29 at 06:29 +0300, Andrei Borzenkov wrote:
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.
OK, sorry. # 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) # ls -lR /boot/efi/EFI /boot/efi/EFI/: total 5 drwxrwxr-x 2 root root 1024 Nov 5 15:27 Boot drwxrwxr-x 4 root root 1024 Nov 5 15:27 Microsoft drwxrwxr-x 4 root root 1024 Nov 5 13:55 OEM drwxrwxr-x 2 root root 1024 Mar 15 21:30 opensuse drwxrwxr-x 2 root root 1024 Jan 17 15:24 ubuntu /boot/efi/EFI/Boot: total 1129 -rwxrwxr-x 1 root root 1155424 Oct 30 02:39 bootx64.efi /boot/efi/EFI/Microsoft: total 5 drwxrwxr-x 42 root root 4096 Nov 5 15:27 Boot drwxrwxr-x 2 root root 1024 Nov 5 15:27 Recovery /boot/efi/EFI/Microsoft/Boot: total 4364 -rwxrwxr-x 1 root root 36864 Mar 28 18:22 BCD -rwxrwxr-x 1 root root 36864 Nov 5 15:27 BCD.LOG -rwxrwxr-x 1 root root 0 Nov 5 15:27 BCD.LOG1 -rwxrwxr-x 1 root root 0 Nov 5 15:27 BCD.LOG2 -rwxrwxr-x 1 root root 65536 Nov 5 15:27 BOOTSTAT.DAT drwxrwxr-x 2 root root 2048 Nov 5 15:27 Fonts drwxrwxr-x 3 root root 1024 Nov 5 15:27 Resources drwxrwxr-x 2 root root 1024 Nov 5 15:27 bg-BG -rwxrwxr-x 1 root root 4247 Jul 10 2015 boot.stl -rwxrwxr-x 1 root root 1155424 Oct 30 02:39 bootmgfw.efi -rwxrwxr-x 1 root root 1152864 Oct 30 02:39 bootmgr.efi drwxrwxr-x 2 root root 1024 Nov 5 15:27 cs-CZ drwxrwxr-x 2 root root 1024 Nov 5 15:27 da-DK drwxrwxr-x 2 root root 1024 Nov 5 15:27 de-DE drwxrwxr-x 2 root root 1024 Nov 5 15:27 el-GR drwxrwxr-x 2 root root 1024 Nov 5 15:27 en-GB drwxrwxr-x 2 root root 1024 Nov 5 15:27 en-US drwxrwxr-x 2 root root 1024 Nov 5 15:27 es-ES drwxrwxr-x 2 root root 1024 Nov 5 15:27 es-MX drwxrwxr-x 2 root root 1024 Nov 5 15:27 et-EE drwxrwxr-x 2 root root 1024 Nov 5 15:27 fi-FI drwxrwxr-x 2 root root 1024 Nov 5 15:27 fr-CA drwxrwxr-x 2 root root 1024 Nov 5 15:27 fr-FR drwxrwxr-x 2 root root 1024 Nov 5 15:27 hr-HR drwxrwxr-x 2 root root 1024 Nov 5 15:27 hu-HU drwxrwxr-x 2 root root 1024 Nov 5 15:27 it-IT drwxrwxr-x 2 root root 1024 Nov 5 15:27 ja-JP -rwxrwxr-x 1 root root 29024 Jul 10 2015 kd_02_10df.dll -rwxrwxr-x 1 root root 324960 Jul 10 2015 kd_02_10ec.dll -rwxrwxr-x 1 root root 13312 Jul 10 2015 kd_02_1137.dll -rwxrwxr-x 1 root root 211808 Jul 10 2015 kd_02_14e4.dll -rwxrwxr-x 1 root root 35168 Jul 10 2015 kd_02_15b3.dll -rwxrwxr-x 1 root root 38752 Jul 10 2015 kd_02_1969.dll -rwxrwxr-x 1 root root 29024 Jul 10 2015 kd_02_19a2.dll -rwxrwxr-x 1 root root 196448 Jul 10 2015 kd_02_8086.dll -rwxrwxr-x 1 root root 17248 Jul 10 2015 kd_07_1415.dll -rwxrwxr-x 1 root root 36704 Jul 10 2015 kd_0C_8086.dll -rwxrwxr-x 1 root root 15200 Jul 10 2015 kdstub.dll drwxrwxr-x 2 root root 1024 Nov 5 15:27 ko-KR drwxrwxr-x 2 root root 1024 Nov 5 15:27 lt-LT drwxrwxr-x 2 root root 1024 Nov 5 15:27 lv-LV -rwxrwxr-x 1 root root 1021792 Oct 30 02:39 memtest.efi drwxrwxr-x 2 root root 1024 Nov 5 15:27 nb-NO drwxrwxr-x 2 root root 1024 Nov 5 15:27 nl-NL drwxrwxr-x 2 root root 1024 Nov 5 15:27 pl-PL drwxrwxr-x 2 root root 1024 Nov 5 15:27 pt-BR drwxrwxr-x 2 root root 1024 Nov 5 15:27 pt-PT drwxrwxr-x 2 root root 1024 Nov 5 15:27 qps-ploc drwxrwxr-x 2 root root 1024 Nov 5 15:27 ro-RO drwxrwxr-x 2 root root 1024 Nov 5 15:27 ru-RU drwxrwxr-x 2 root root 1024 Nov 5 15:27 sk-SK drwxrwxr-x 2 root root 1024 Nov 5 15:27 sl-SI drwxrwxr-x 2 root root 1024 Nov 5 15:27 sr-Latn-CS drwxrwxr-x 2 root root 1024 Nov 5 15:27 sr-Latn-RS drwxrwxr-x 2 root root 1024 Nov 5 15:27 sv-SE drwxrwxr-x 2 root root 1024 Nov 5 15:27 tr-TR drwxrwxr-x 2 root root 1024 Nov 5 15:27 uk-UA drwxrwxr-x 2 root root 1024 Nov 5 15:27 zh-CN drwxrwxr-x 2 root root 1024 Nov 5 15:27 zh-HK drwxrwxr-x 2 root root 1024 Nov 5 15:27 zh-TW [snip] /boot/efi/EFI/OEM: total 5 drwxrwxr-x 42 root root 4096 Nov 5 13:55 Boot drwxrwxr-x 2 root root 1024 Nov 5 13:55 Recovery [snip] /boot/efi/EFI/opensuse: total 3392 -rwxrwxr-x 1 root root 1159776 Mar 17 22:01 MokManager.efi -rwxrwxr-x 1 root root 58 Mar 17 22:01 boot.csv -rwxrwxr-x 1 root root 155 Mar 17 22:01 grub.cfg -rwxrwxr-x 1 root root 975480 Mar 17 22:01 grub.efi -rwxrwxr-x 1 root root 178688 Mar 17 22:01 grubx64.efi -rwxrwxr-x 1 root root 1155520 Mar 17 22:01 shim.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 I snipped hundreds of lines of Microsoft files. Let me know if you think they are relevant. Cheers, Dave
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
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 (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
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 06:22 +0300, Andrei Borzenkov wrote:
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?
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.
-- 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
On Thu, Mar 31, 2016 at 11:16 PM, Dave Howorth <dave@howorth.org.uk> 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. 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. *shrug* from that spec all I see off hand is they have to honor boot order and next boot variables in NVRAM when there's a matching path to OSloader, but pretty much seems to leave them off the hook UI wise if their displayed boot list is incomplete. That's kinda silly... -- Chris Murphy -- 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 <dave@howorth.org.uk> 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
On Fri, 2016-04-01 at 12:21 -0600, Chris Murphy wrote:
On Thu, Mar 31, 2016 at 11:16 PM, Dave Howorth <dave@howorth.org.uk> 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.
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. *shrug* from that spec all I see off hand is they have to honor boot order and next boot variables in NVRAM when there's a matching path to OSloader, but pretty much seems to leave them off the hook UI wise if their displayed boot list is incomplete. That's kinda silly...
I think you're right. I haven't read the spec but I've seen that view stated elsewhere. It sounds like something the firmware engineer would do between noon and 1pm, or possibly between 2pm and 3pm. https://www.happyassassin.net/2013/05/03/a-day-in-the-life-of-a-firmware-eng... 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." Fortunately the UEFI spec does apparently require them to actually boot what they're told by efibootmgr, even if they won't display it. But one oddity is that if I tell it to boot ONLY mint (-o 0002), it does it once and then boots only openSUSE whilst the boot order returns to 0001,0000,0002. (openSUSE, Win10, Mint) I haven't figured out what's going on there. rEFInd, here I come. -- 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
* Dave Howorth <dave@howorth.org.uk> [04-01-16 16:58]: [...]
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."
Fortunately the UEFI spec does apparently require them to actually boot what they're told by efibootmgr, even if they won't display it. But one oddity is that if I tell it to boot ONLY mint (-o 0002), it does it once and then boots only openSUSE whilst the boot order returns to 0001,0000,0002. (openSUSE, Win10, Mint) I haven't figured out what's going on there.
My acer aspire 5 15 inch has f12 which provides a list of the *installed* eufi bootable systems. In this case two, win 10 and openSUSE Tw, and they work and are configurable via the linux system efibootmgr. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- 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 пишет:
Fortunately the UEFI spec does apparently require them to actually boot what they're told by efibootmgr, even if they won't display it. But one oddity is that if I tell it to boot ONLY mint (-o 0002), it does it once and then boots only openSUSE whilst the boot order returns to 0001,0000,0002. (openSUSE, Win10, Mint) I haven't figured out what's going on there.
According to UEFI spec boot manager is free to reorder (or rebuild) it as it sees fit. --><-- The platform firmware may add extra boot options or remove invalid boot options from the boot order list. --><-- There is no requirement that firmware actually preserves BootOrder. What you can try, is to list all options. efibootmgr -o 0002,0000,0001 May be in this case it will leave it alone (as there is nothing to add). -- 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
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. 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? 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'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
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
02.04.2016 14:38, Dave Howorth пишет: ...
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
...
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)?
Unfortunately yes. Normally it unhooks itself, but only if bootloader(1) uses standard EFI API to launch payload. But in this case bootloader(1) is using back door to start shim(2), so shim(1) remains.
I thought the whole purpose of chainloading was to pass responsibility to the other boot system?
Well, in theory yes.
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.
bor@bor-Latitude-E5450:~/src/shim$ dpkg-query -W shim shim 0.8-0ubuntu2
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.
The bug is exactly as you described - when loading Ubuntu shim/grub2 from openSUSE grub2, Ubuntu grub2 fails to launch kernel with message above. I would prefer bug report were opened by you in case there will be request for additional information or something to test.
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? -- 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
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&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.
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.
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.
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.
I'm a global mod of the forums, would you like me to find out?
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.
opensuse-community is not under openSUSE control. -- 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
02.04.2016 14:38, Dave Howorth пишет:
I'll do that. You'll need to tell me what the bug is so I can report it.
I submitted https://bugzilla.opensuse.org/show_bug.cgi?id=973745 You can add yourself to Cc and comment on it when you fixed bugzilla access. -- 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 <dave@howorth.org.uk> 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
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? -- 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 <arvidjaar@gmail.com> 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
Отправлено с iPhone
29 марта 2016 г., в 7:09, Chris Murphy <lists@colorremedies.com> написал(а):
On Mon, Mar 28, 2016 at 9:24 PM, Andrei Borzenkov <arvidjaar@gmail.com> 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.
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 <lists@colorremedies.com> написал(а):
On Mon, Mar 28, 2016 at 9:24 PM, Andrei Borzenkov <arvidjaar@gmail.com> 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, Mar 29, 2016 at 12:57 AM, Dave Howorth <dave@howorth.org.uk> wrote:
On Tue, 2016-03-29 at 08:44 +0300, Andrei Borzenkov wrote:
Отправлено с iPhone
29 марта 2016 г., в 7:09, Chris Murphy <lists@colorremedies.com> написал(а):
On Mon, Mar 28, 2016 at 9:24 PM, Andrei Borzenkov <arvidjaar@gmail.com> 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. 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. -- 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 <dave@howorth.org.uk> wrote:
On Tue, 2016-03-29 at 08:44 +0300, Andrei Borzenkov wrote:
Отправлено с iPhone
29 марта 2016 г., в 7:09, Chris Murphy <lists@colorremedies.com> написал(а):
On Mon, Mar 28, 2016 at 9:24 PM, Andrei Borzenkov <arvidjaar@gmail.com> 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
On Mon, Mar 28, 2016 at 11:44 PM, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
Отправлено с iPhone
29 марта 2016 г., в 7:09, Chris Murphy <lists@colorremedies.com> написал(а):
On Mon, Mar 28, 2016 at 9:24 PM, Andrei Borzenkov <arvidjaar@gmail.com> 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.
My recommendation is the same as when I first posted. Use the firmware's built-in boot manager. It solves all of these problems, the user doesn't have to get wrapped up in bootloader esoterics and workarounds. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (9)
-
Andrei Borzenkov -
Carlos E. R. -
Chris Murphy -
Dave Howorth -
jdd -
John Andersen -
Knurpht - Gertjan Lettink -
Neil Rickert -
Patrick Shanahan