For anyone trying to keep up with the rolling releases of 13.2, the 20140829
version id one to avoid if you are using secure boot (UEFI). Apparently,
the certificate included is invalid. Secure boot fails from the DVD and, in
my case, the most recent updates applied to an installed version of 13.2
will clobber the secure boot of any other versions of openSUSE. I also got
warnings of kernel conflicts using zypper to update.
Easiest recovery for me was to install a previously know good version (I
used the 13.1 DVD) over the latest 13.2.
Just wanted to alert anyone wanting to keep up with the rolling release that
the bleeding edge can get sharp sometimes
Well, okay, I did not update my UEFI secure-boot system today. I updated that yesterday and ran into the problem with a secure boot signature.
In my opinion, they should have held off releasing the newer “shim” until the signatures were all properly in place.
But, never mind. I disable secure-boot to get my system booted. Then I used “efibootmgr” to switch to booting opensuse 13.1 (installed in a different partition). Then, using the entry for “factory” in the 13.1 boot menu, I am able to secure-boot into factory. So all is well.
As for the kernel: this problem of different kernels using the same file name was already present in Tumbleweed. I don’t see it as a serious problem. But it does mean that I only have one bootable kernel. So it’s a failure of the multi-version system, since both installed kernel versions lead to the same bootable kernel file.
Back to the secure-boot thingy: if you copy the “shim.efi” from opensuse 13.1 into the EFI partition, to replace that installed by latest factory snapshot, that will probably allow booting. I admittedly have not tested that, though what I am doing is almost equivalent.
> Back to the secure-boot thingy: if you copy the “shim.efi” from
> opensuse 13.1 into the EFI partition, to replace that installed by
> latest factory snapshot, that will probably allow booting. I admittedly
> have not tested that, though what I am doing is almost equivalent.
>
I think what I accomplished by re-installing a known good version winds up
doing the same thing. Lesson I learned was to use the DVD boot if things go
south - the DVD of the Factory drop also fails the credential test and won’t
boot so a small delay to download the whole drop, burn it to DVD, then
update from it is likely a valid way to check - if you are anxious to keep
up - rather than an online update.
This looks like a one-off screwup. Gotta give the devs a little slack.
I can verify the “clobber other system”. I recently bought the latest HP 17.3 inch laptop with all the latest gizmo’s including a 1-Tbyte SDD/HDD hybrid disk (Win8.1), so I was anxious to install openSuSe. It’s a 17T_J1H37AV which leads to HP’s 17T_K000 CTO docs at HP online support. The 13.1 uefi install went well using the release notes & guides found here on the forum. Actually, it went so well that I decided to try “Factory” and installed just after the Dev’s went to the rolling releases. I was OK through the release that added “Binary is verified by the Vender Certificate” to the boot process. The release after that is the one that clobbered my system…
Long story made short: I tried every recovery technique that I could find to no avail and like you, went back to the “good” 13.1 install – and that even got my 13.2 back. I know UEFI is new stuff, but the openSuSe guides are from 12.3 era; they need updating by a UEFI expert for 13.2 GM release – there have been beau coup uefi changes since 12.3. I even had difficulty booting “Rescue CD’s” and could only boot 13.1 stuff; and found the DVD rescue to be the best for me.
This drill was worth doing on my part. I won’t be updating my 17T 13.2 install unless I know that the “Binary is verified by the Vender Certificate” – if I have to, I’ll wait for the beta & RC releases in the not too distant future https://progress.opensuse.org/projects/opensuse-13-2-release/roadmap#13.2_Beta_1 and then have a go at it.
In hindsight, One lesson learned is that I should have made a backup of the EFI Partition prior to installing 13.1, and then again, after the 13.1 install. Being it’s a VFAT partition, a simple “cp” would be an adequate backup IMHO.
To be safe, I would boot from a Rescue CD and:
fdisk -l
to find out where the disks are, and
mount /dev/sda2 /mnt
where sda2 is my efi partition (source)
mount /dev/sdb1 /media
my usb key partition (destination)
cp -avx /mnt /media
save the usb key
I think this would have saved me a lot of hair-pulling (to be able to replace a screwed-up EFI partition)
Aside: I would love to have some rescue CD’s, that boot UEFI…or make a key that would boot them; If you have some that work list them & I’ll give them a try.
The live rescue CDs for 12.3 (64-bit), 13.1 (64-bit) and factory (64-bit) should all be capable of UEFI boots. I been copying the iso to a USB (with the “dd_rescue” command), and booting that in UEFI mode.
The 12.3 and 13.1 live media (again, 64 bit only) should be able to boot with secure-boot enabled, except on systems that have a inadequate implementation of secure-boot. At present, the factory rescue media may not be able to handle secure-boot until the new version of “shim.efi” has the needed signatures.
That’s unlikely to help. The secure-boot problem is in the EFI partition, which is FAT.
However, maybe there’s a way of looking at a snapshot and retrieving an older version of “/usr/lib64/efi/shim.efi” and copying that into your EFI partition. Copying the “shim.efi” from an installed opensuse 13.1 system might be easier and is probably equivalent. I’m not sure if you have to also copy “grub.efi” at the same time.
I took that & copied the all contents of “/usr/lib64/efi” to my backup EFI usb key as root. Interestingly enough, it copied over as a backup just fine, but, I got a message that it was not going to write the "sym_link. I don’t know what, or where, that sym-link would have been; I’ll go looking when I have a chance. Nrickert have you noticed any sym_lincs in any of the the EFS partitions/folders that you have been looking at?
The “cp” command should just follow the links and copy the actual files (keeping the symlink name). But other commands such as “rsync” might try to reproduce the symlinks, and that won’t work on a FAT file system.
Of those, “boot.csv” is new for factory/13.2, and I don’t think it is really needed. It seems to be for recovery purposes.
“grubx64.efi” is for when you don’t install secure-boot support. And “shim.efi”, “grub.efi”, “grub.cfg” and “MokManager.efi” are for use when you do install secure-boot support (even if secure-boot is disabled).
My understanding is that it is for recovery purposes. Under some circumstances it will look for “boot.csv” and use that information to re-create the NVRAM entry (or entries).
Presumably this deals with the case where somebody replaces a defective mother board, and thereby gets a clean (empty) NVRAM so no boot entries in NVRAM even though they are in the efi partition on the disk.
> Presumably this deals with the case where somebody replaces a defective
> mother board, and thereby gets a clean (empty) NVRAM so no boot entries
> in NVRAM even though they are in the efi partition on the disk.
>
I also ran into this problem after updating the BIOS.
>
> whonea;2662098 Wrote:
>> For anyone trying to keep up with the rolling releases of 13.2, the
>> 20140829
>> version id one to avoid if you are using secure boot (UEFI).
>
> Secure-boot is working again, after the 20140904 snapshot (released
> today).
>
Heads-up appreciated - I’ll give this one a shot when I have some time to
check it out. Hopefully, the NetworkManger goat-rope has improved by now.
That has been the only real show stopper here - aside from the Secure-boot.
Time now to wring out the NM and file the appropriate bugs with details.
However, I have not tried an install from the latest iso. I used “zypper dup” to bring my system up to date.
The iso has always installed secure-boot support (since opensuse 12.3). The hangup has been that it was broken for a week or so, waiting for the new version of “shim.efi” to be signed. Now that “shim.efi” has the proper signatures, all should be well.
I scanned Ludwig Nussel’s http://lists.opensuse.org/archive/opensuse-factory/2014-09/msg00118.html "
New Factory snapshot 20140904 released! Changed packages:And saw that “==== shim ====” was included; but, I didn’t have time to search for the phrase that included the microsoft cert update – wasn’t sure what to look for…
Anyway, I installed the new 20140904 snapshot w/o any issues & now I can play with it.
This morning, I went back to the “==== shim ====” change and found a line
- Update microsoft.asc: shim signed by UEFI signing service, based
on code from "Tue Oct 1 04:29:29 UTC 2013".
So, looks like a search for " microsoft" would have found what I needed to assure a safe efi + secure boot update and not brick my laptop like in the beginning of this thread.
>
> dth2;2663829 Wrote:
>> Does the latest factory iso install a secure-boot option?
>
> It should.
>
> However, I have not tried an install from the latest iso. I used
> “zypper dup” to bring my system up to date.
>
> The iso has always installed secure-boot support (since opensuse 12.3).
> The hangup has been that it was broken for a week or so, waiting for the
> new version of “shim.efi” to be signed. Now that “shim.efi” has the
> proper signatures, all should be well.
>
Just to add a bit to what you said. The 13.2 update that bit me included
something that affected the kernel so a re-install of the boot code was
required. That’s where the bum certificate got pulled in. As I think I
mentioned earlier, attempting to install to a secure boot machine will fail
to boot the DVD at the beginning so you have some degree of protection from
bad certificate/boot file errors. That has become my SOP - burn the DVD and
try to boot it before updating. Broadband has spoiled me
