Bug#918863: reboot returns to Windows 10 on Lenovo X1

[Thomas Gaugler]

See  for a proof of concept.

Bug#918863: reboot returns to Windows 10 on Lenovo X1

[Bernhard Übelacker]

Hello Thomas,

Am 05.02.19 um 20:50 schrieb Thomas Gaugler:
...
> I thought to use the momentum around secure boot within Debian [2] for
> supporting it within win32-loader as well.
> 
> The basic idea is to replicate the following commands in win32-loader:
> $ # Copy /usr/lib/shim/shimx64.efi.signed from shim-signed package to
> $ # /boot/efi/EFI/debian/shimx64.efi
> $ sudo efibootmgr --create --label 'Debian GNU/Linux - Continue with
> install process' --loader '\EFI\debian\shimx64.efi'
> ...
> Boot0009* Debian GNU/Linux - Continue with install process ...
> $ sudo efibootmgr --bootnext 0009

In message [10] in points 1 and 3 I tried to describe how a manual
crafted grub2 efi image could be configured from a windows cmd.
Hope that it might be of some help.

Kind regards,
Bernhard

[10] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918863#10

Bug#918863: reboot returns to Windows 10 on Lenovo X1

[Thomas Gaugler]

The BOOTCFG_IsUEFI function in include/bootcfg.nsh could be used to 
detect the firmware type (legacy BIOS versus UEFI).


I thought to use the momentum around secure boot within Debian [2] for 
supporting it within win32-loader as well.


The basic idea is to replicate the following commands in win32-loader:
$ # Copy /usr/lib/shim/shimx64.efi.signed from shim-signed package to
$ # /boot/efi/EFI/debian/shimx64.efi
$ sudo efibootmgr --create --label 'Debian GNU/Linux - Continue with 
install process' --loader '\EFI\debian\shimx64.efi'

...
Boot0009* Debian GNU/Linux - Continue with install process ...
$ sudo efibootmgr --bootnext 0009

I have not yet investigated how ipxe.efi from the ipxe package could be 
chainloaded from either shim or grub2.


[2] 



 Original Message 

Le mardi, 15 janvier 2019, 17.39:00 h CET Bernhard Übelacker a écrit :

If such a system is detected, maybe a warning could be added?


Sure. I suggest this would be done very early, but have no clue how to detect
such a system. This would also make sense in time for buster. Could you work
on a patch? Thomas; an idea?


A short search led to function kernel32!GetFirmwareType [1].
That is said to be supported since windows 8.

This function is already used in include/bootcfg.nsh, but
can not see any user, maybe just a preparation for future use ...

Kind regards,
Bernhard

[1] 
https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-getfirmwaretype

Bug#918863: reboot returns to Windows 10 on Lenovo X1

[Bernhard Übelacker]

Am 04.02.19 um 13:42 schrieb Didier 'OdyX' Raboud:
> Le mardi, 15 janvier 2019, 17.39:00 h CET Bernhard Übelacker a écrit :
>> If such a system is detected, maybe a warning could be added?
> 
> Sure. I suggest this would be done very early, but have no clue how to detect 
> such a system. This would also make sense in time for buster. Could you work 
> on a patch? Thomas; an idea?

A short search led to function kernel32!GetFirmwareType [1].
That is said to be supported since windows 8.

This function is already used in include/bootcfg.nsh, but
can not see any user, maybe just a preparation for future use ...

Kind regards,
Bernhard

[1] 
https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-getfirmwaretype

Bug#918863: reboot returns to Windows 10 on Lenovo X1

[Didier 'OdyX' Raboud]

Le mardi, 15 janvier 2019, 17.39:00 h CET Bernhard Übelacker a écrit :
> Therefore I raise the question if win32-loader is really supposed
> to work on a secure boot EFI system?

No. This was never implemented. win32-loader needs a new maintainer who is 
willing to tackle exactly these types of problems, and I'm not that person. 
:-/

> If such a system is detected, maybe a warning could be added?

Sure. I suggest this would be done very early, but have no clue how to detect 
such a system. This would also make sense in time for buster. Could you work 
on a patch? Thomas; an idea?

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#918863: reboot returns to Windows 10 on Lenovo X1

[Bernhard Übelacker]

Hello Tom Brown, dear Maintainer,
I just tried to reproduce this on a amd64 qemu EFI VM.

>From your description is not clear if you received on reboot
the menu to select between "Windows 10" or
"Debian GNU/Linux - Continue with install process"?
If that is missing you might add the output of following command
running in an administrative/elevated cmd:

bcdedit /enum all > c:\bcdedit-enum-all.txt


Unfortunately I am not confident if grldr.mbr is still working,
at least when a firmware without CSM or secure boot comes into play.
Therefore I raise the question if win32-loader is really supposed
to work on a secure boot EFI system?
If such a system is detected, maybe a warning could be added?


I looked for a way to load e.g. an EFI grub image [2] from
{bootmgr} (Windows Boot Manager), but could not find a working way.
The most I found is this discussion [2].

The next possiblity would be to add an boot entry to the
firmware efi itself - unfortunately the firmware boot menu
would have to be opened by the user (at least in TianoCore).

So it might be needed to make at this stage grub already the
default - with the risk to leave the user with an unbootable system ...

Find in [3] some examples how to change the boot configuration.
This may make the system unbootable, just use in a test environment!!!
This is not intended as a workaround - just a possible way to improve
win32-loader.

Also with the debian installation the real grub was put
into place and working.
Unfortunately Windows decided at next it got booted to make
again our intermediate grub the default entry ???

Kind regards,
Bernhard


[1] Create EFI grub:
grub-mkimage -o grubx64-win32-loader.efi -O x86_64-efi --prefix /EFI/debian 
part_gpt part_msdos lvm fat ext2 chain boot configfile normal minicmd linux 
reboot halt search gfxterm gfxmenu efi_gop efi_uga video loadbios gzio 
video_bochs video_cirrus echo true loadenv ntfs exfat tftp http

[2] 
http://reboot.pro/topic/17655-boot-into-3rd-party-efi-application-via-bcd/page-3

[3]
# C:\Windows\system32>bcdedit /enum {bootmgr} | find "path"
# path\EFI\Microsoft\Boot\bootmgfw.efi

# mount ESP/EFI system partition as Z: (has to be a free drive letter)
mountvol Z: /S
mkdir Z:\EFI\debian
# create a grub.cfg
(
echo menuentry "Windows" {
echo search --file --no-floppy --set=root 
/EFI/Microsoft/Boot/bootmgfw.efi
echo chainloader /EFI/Microsoft/Boot/bootmgfw.efi
echo }
echo menuentry "Debian GNU/Linux - Continue with install process" {
echo search --file --no-floppy --set=root /win32-loader/linux
echo linux /win32-loader/linux vga=788 priority=low ---
echo initrd /win32-loader/initrd.gz
echo }
)> Z:\EFI\debian\grub.cfg
# copy the grub image from [1]
copy c:\root\grubx64-win32-loader.efi Z:\EFI\debian\grubx64-win32-loader.efi
# unmount ESP
mountvol Z: /D

# add a new boot entry to EFI firmware and make it default - found no way 
to create a proper firmware application 101f ...
bcdedit /copy {bootmgr} /d "Debian GNU/Linux - Continue with install 
process copy"
::Der Eintrag wurde erfolgreich in {4c28ffdd-16ba-11e9-8632-97f1cd5def39} 
kopiert.
set GUID={4c28ffdd-16ba-11e9-8632-97f1cd5def39}
bcdedit /set %GUID% path \EFI\debian\grubx64-win32-loader.efi
bcdedit /set {fwbootmgr} timeout 15
bcdedit /set {fwbootmgr} default %GUID%
bcdedit /deletevalue %GUID% device
bcdedit /deletevalue %GUID% locale
bcdedit /deletevalue %GUID% inherit
bcdedit /deletevalue %GUID% resumeobject
bcdedit /deletevalue %GUID% toolsdisplayorder
bcdedit /deletevalue %GUID% timeout

# Was just tested with EFI win10 64bit

Bug#918863: reboot returns to Windows 10 on Lenovo X1

[Tom Brown]

Package: win32-loader
Version: 0.8.3+deb9u1 +net

I have a new Lenovo X1 6th Gen running stock Windows 10. It has one
internal disk and 16GB Ram. The first thing I did with it was download and
run win32-loader. I didn't notice any errors, read the notice about
rebooting, waited eagerly for the installer to appear and instead rebooting
went right back to windows. I tried again selecting the text installation.
I tried rebooting using the windows start menu instead of letting win32-loader
do it. No luck. Here are the details copied from Debian-Installer loader:
Completed:

Created uninstaller: C:\win32-loader\Uninstall.exe
GET: http://deb.debian.org/debian/dists/stable//Release
GET: http://deb.debian.org/debian/dists/stable//Release.gpg
Extract: C:\Users\TB\AppData\Local\Temp\nsyA83C.tmp\gpgv.exe
Extract:
C:\Users\TB\AppData\Local\Temp\nsyA83C.tmp\debian-archive-keyring.gpg
Checking GPG signature on Release.
GET:
http://deb.debian.org/debian/dists/stable/main/installer-amd64/current/images//SHA256SUMS
Computing checksum for SHA256SUMS
11d5570a2b93fce413ec5a7bdc1e732210fc8f92e4171ee635f1a0830e862352 =
11d5570a2b93fce413ec5a7bdc1e732210fc8f92e4171ee635f1a0830e862352
GET:
http://deb.debian.org/debian/dists/stable/main/installer-amd64/current/images/netboot/debian-installer/amd64/linux
Computing checksum for linux
97cdc7a6c984f353d742bd6e992433f3a0c5caabff97e097c4688f409927cadb =
97cdc7a6c984f353d742bd6e992433f3a0c5caabff97e097c4688f409927cadb
GET:
http://deb.debian.org/debian/dists/stable/main/installer-amd64/current/images/netboot/debian-installer/amd64/initrd.gz
Computing checksum for initrd.gz
02ea00956ecdde0e4baa704fdad630d2e1e6284a9e643390c560f699409fc29a =
02ea00956ecdde0e4baa704fdad630d2e1e6284a9e643390c560f699409fc29a
Generating C:\win32-loader\grub.cfg
Extract: C:\win32-loader\cpio.exe
Extract: C:\win32-loader\gzip.exe
Appending preseeding information to C:\win32-loader\initrd.gz
Extract: C:\g2ldr
Extract: C:\g2ldr.mbr
Registering in BootMgr
Disabling NTFS compression in bootstrap files
Completed