Bug#924053: live-build: UEFI shows grub> on HP250 G6 2SX60EA

[adrian15 <adrian15sgd@gmail.com>]

El 09/03/19 a las 13:46, Thomas Schmitt escribió:
>> 4) And, well, I might try an obvious patch that searches with regex both
>> /live/vmlinuz and /live/vmlinuz1 and give us more feedback about it.
> 
> Or a dedicated unique identification file path ?
> 
> An empty file in an alreay existing directory would cost 0 or 2048 bytes
> in the ISO.
> Even in a conservative 8.3 name it would be possible to expose 56 bit
> with a birthday paradox threshold of 256 million. A plain hex encoding
> could expose 44 bit of random id (~ 4 million children in the class).
> 
> If reproducibility is of concern, then the filename could be derived
> from some version-dependent strings like the ISO's volume id. All
> mangled through md5sum and tr 'a-f' 'A-F', the first eleven result
> characters would yield a quasi-unique DOS style file name.
> 
> 
> Have a nice day :)
> 
> Thomas

1)
Well, guess what happened... my obvious patch:
https://github.com/rescatux/live-build/commit/52bb32989078b9a724c13e73a0ac87673d728199

which basically replaces:

search --set=root --file /live/vmlinuz

by:

if ! search --set=root --file /live/vmlinuz ; then
	search --set=root --file /live/vmlinuz1
fi

does not boot in my computer because it's still finding /live/vmlinuz in
the internal hard disk.

Of course I could reverse the logic:

if ! search --set=root --file /live/vmlinuz1 ; then
	search --set=root --file /live/vmlinuz
fi

but who assures me that in the future there is an scenario where:

* Debian Live CD uses /live/vmlinuz
and
* HP internal disk Live CD uses /live/vmlinuz1

and it breaks again?

2) I think there is something different from Secure Boot enable boot to
non-Secure Boot that triggers this fallback to minimal grub.cfg scenario.

Else I would have found these problem when in one my tests I skipped the
overwriting of .efi files with the signed ones.

3) I'll try to code this dedicated unique identification file path that
you are proposing and see if it works better.

Then I want to compare grub hard disks / devices being detected with
Secure Boot enabled and Secure Boot disabled.

So that we can conclude if this fallback to minimal grub.cfg is
inevitable and attached to Secure Boot or if it's a Secure Boot bug itself.



adrian15
-- 
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/