HP ProBook x360 11 G1 EE incompatible with grub

[Michel Bouissou]

Hi,

In some (south-west) regions of France, high-school students are
currently given (for free - I mean : from our taxes) HP ProBook x360 11
G1 EE (Education Edition) laptop computers.

These computers come with Windows 10 and an HP EFI BIOS v. 01.09 to
01.11 that has no support for legacy CSM boot mode.

I believe that either this UEFI BIOS has been purposely “locked against
grub”, or there is a serious bug.

After having disabled Secure boot, I have discovered that none of the
usual (curent, latest versions as of 2017/12) Linux live USB sticks
(among : Ubuntu, Mint, Debian, Manjaro, PartedMagic) was able to boot on
this machine.

All these live USB keys normally boot using grub.

Symptoms are as follows :

- UEFI BIOS selection displays the USB key as "Windows boot manager"
instead of the USB key make / model one is used to see on other machines ;

- Selecting this just causes the screen to go black with a blinking
cursor and... that's the end.

- After a while I discovered that a rEFInd key
( http://www.rodsbooks.com/refind/ ) IS ABLE to boot, and that it "sees"
the Linux key if both inserted at the same time.

- But trying to chain from rEFInd to the Linux key fails (black screen
of death with blinking cursor)

- Then I discovered that a Tails Linux key ( https://tails.boum.org )
boots easily with no problem at all on the machine... And this one boots
from syslinux.

- I also tested and found that rEFInd is also able to chain to a Tails
key properly.

- Then I made another experiment and try to "doctor" some Linux keys
that couldn't boot (namely : Parted Magic and Manjaro) to remove grub
from them and replace it with syslinux. It was not an easy task, but
once done, it allowed both distros to boot easily and seamlessly.

- It is worth specifying that, as soon as grub is replaced with
syslinux, the machine's BIOS doesn't call the key "Windows boot manager"
anymore, but properly displays its brand and model.

So I can tell being 100% sure that the HP ProBook x360 11 G1 EE
distributed to students in France will *NOT BOOT* any of the common,
grub-based, Linux USB keys, but that it will happily boot the same keys
when grub is replaced with syslinux.

I cannot tell for sure if this is a purposeful lock on the machine BIOS
or a serious bug somewhere, but I felt that it deserves to be
documented, reported and investigated.

Please copy me on replies, I'm not subscribed to this mailing-list.

Best regards.


ॐ

[adrian15]

1. How do you put exactly those live cds into the USB ?
Do you use the DD method or another one?

2. Can you please try Super Grub2 Disk Hybrid with the DD method?

https://sourceforge.net/projects/supergrub2/files/2.02s10-beta5/super_grub2_disk_2.02s10-beta5/super_grub2_disk_hybrid_2.02s10-beta5.iso/download

Does the menu appear for you?

3. And what about Rescatux with the DD method? Does the grub menu even
appear?

http://sourceforge.net/projects/rescatux/files/rescatux_0_51_b3/rescatux-0.51b3.iso/download

Rescatux has the same method of building than some Debian installation
disks (not the live ones).
And Super Grub2 Disk has the GNU/GRUB way of making the iso thanks to
grub-mkrescue and that's different from the Rescatux / Debian
installation implementation.

Thank you for your feedback.

Post by Michel Bouissou
Hi,
In some (south-west) regions of France, high-school students are
currently given (for free - I mean : from our taxes) HP ProBook x360 11
G1 EE (Education Edition) laptop computers.
These computers come with Windows 10 and an HP EFI BIOS v. 01.09 to
01.11 that has no support for legacy CSM boot mode.
I believe that either this UEFI BIOS has been purposely “locked against
grub”, or there is a serious bug.
After having disabled Secure boot, I have discovered that none of the
usual (curent, latest versions as of 2017/12) Linux live USB sticks
(among : Ubuntu, Mint, Debian, Manjaro, PartedMagic) was able to boot on
this machine.
All these live USB keys normally boot using grub.
- UEFI BIOS selection displays the USB key as "Windows boot manager"
instead of the USB key make / model one is used to see on other machines ;
- Selecting this just causes the screen to go black with a blinking
cursor and... that's the end.
- After a while I discovered that a rEFInd key
( http://www.rodsbooks.com/refind/ ) IS ABLE to boot, and that it "sees"
the Linux key if both inserted at the same time.
- But trying to chain from rEFInd to the Linux key fails (black screen
of death with blinking cursor)
- Then I discovered that a Tails Linux key ( https://tails.boum.org )
boots easily with no problem at all on the machine... And this one boots
from syslinux.
- I also tested and found that rEFInd is also able to chain to a Tails
key properly.
- Then I made another experiment and try to "doctor" some Linux keys
that couldn't boot (namely : Parted Magic and Manjaro) to remove grub
from them and replace it with syslinux. It was not an easy task, but
once done, it allowed both distros to boot easily and seamlessly.
- It is worth specifying that, as soon as grub is replaced with
syslinux, the machine's BIOS doesn't call the key "Windows boot manager"
anymore, but properly displays its brand and model.
So I can tell being 100% sure that the HP ProBook x360 11 G1 EE
distributed to students in France will *NOT BOOT* any of the common,
grub-based, Linux USB keys, but that it will happily boot the same keys
when grub is replaced with syslinux.
I cannot tell for sure if this is a purposeful lock on the machine BIOS
or a serious bug somewhere, but I felt that it deserves to be
documented, reported and investigated.
Please copy me on replies, I'm not subscribed to this mailing-list.
Best regards.
ॐ

[Michel Bouissou]

Hi,

Post by adrian15
1. How do you put exactly those live cds into the USB ?
Do you use the DD method or another one?

The non-working method was to use dd from the isos. (And yes I know how
to do it, I've done it for 20 years...)

Then I used unetbootin to obtain a key with a writable filesystem on
FAT32 instead of an ISO (but still not booting) that I could "fix"
easily with syslinux.

Post by adrian15
2. Can you please try Super Grub2 Disk Hybrid with the DD method?
https://sourceforge.net/projects/supergrub2/files/2.02s10-beta5/super_grub2_disk_2.02s10-beta5/super_grub2_disk_hybrid_2.02s10-beta5.iso/download

Yeah, but not this evening and most probably not before wednesday
evening at least - that's my son's machine and I won't have a chance to
play with it before.

Post by adrian15
Does the menu appear for you?

No. The very attemp to load grub results in a black screen with a _
cursor in the upper left corner, PERIOD.

Which means : no menu, no error message, not a single "grub" word.

Having the EFI try to load it, or trying to chain it from rEFInfd
produces the exact same result.

Post by adrian15
3. And what about Rescatux with the DD method? Does the grub menu even
appear?
http://sourceforge.net/projects/rescatux/files/rescatux_0_51_b3/rescatux-0.51b3.iso/download

I'll try to give this a shot asap...

Thanks for your help.

Kind regards.

ॐ

[Michel Bouissou]

Hi again,

Post by adrian15
2. Can you please try Super Grub2 Disk Hybrid with the DD method?
https://sourceforge.net/projects/supergrub2/files/2.02s10-beta5/super_grub2_disk_2.02s10-beta5/super_grub2_disk_hybrid_2.02s10-beta5.iso/download

I have downloaded Super Grub2 iso image per your link and burnt it on a
USB stick using dd.

Not having the machine that causes me trouble with me, I tried the Super
Grub2 stick on another one : An HP Pavilion Detachable X2 10-N123NF

On this machine is currently only installed Manjaro Linux in UEFI (64)
mode. (this machine is a tablet-like that seems to have no provision for
booting legacy/CSM).
It's booting with grub2. Works good. Never had any BIOS issue.

Now I have to report a serious issue with Super Grub2 on this machine :

- Super Grub2 boots to its menu (Showing version 2.02s10-beta5)

- I tried the "Print devices/partitions" option : Result : I get a
screen of output followed by a [MORE] prompt, but at this step the
computer is frozen. The usual "more" keys (Enter, space...) produce
nothing.  Had no other solution than power cycling the computer the hard
way.

- Reboot into the Manjaro OS to check that everything was still good (it
was), then reboot into Super Grub2

- Tried the "Detect and show boot methods" option : Screen went black
with the USB key access LED blinking fast, so I thought it was doing
something... But after 10 minutes it still was, and then I had no other
solution than to power-cycle the machine the hard way again.

- At reboot, got a bad message stating that the UEFI CMOS memory was
corrupt (scream !) so type press a key to fix it, which I did.

- Then the machine rebooted to a « Windows failed to start » error
message. After minutes of terror I discovered that all of my machine
UEFI settings (except for the administrator password) had been reverted
back to default settings (probably following the CMOS corruption) and
that the "Secure boot" option had been reactivated.

- After deactivating it the machine would accept to boot Manjaro again,
BUT while booting I noticed it doing unusual fsck stuff...

So I can say for sure that Super Grub2 did something really bad to this
machine - hadn't had a single UEFI CMOS corruption issue before, I don't
believe it to be a bare coincidence...

Hope that this information may be useful ?

ॐ

[adrian15]

Post by Michel Bouissou
Hi again,

Post by adrian15
2. Can you please try Super Grub2 Disk Hybrid with the DD method?
https://sourceforge.net/projects/supergrub2/files/2.02s10-beta5/super_grub2_disk_2.02s10-beta5/super_grub2_disk_hybrid_2.02s10-beta5.iso/download

I have downloaded Super Grub2 iso image per your link and burnt it on a
USB stick using dd.

Ok.

Post by Michel Bouissou
Not having the machine that causes me trouble with me, I tried the Super
Grub2 stick on another one : An HP Pavilion Detachable X2 10-N123NF

Ok.

Post by Michel Bouissou
On this machine is currently only installed Manjaro Linux in UEFI (64)
mode. (this machine is a tablet-like that seems to have no provision for
booting legacy/CSM).

An UEFI only machine. Nice.

Post by Michel Bouissou
It's booting with grub2. Works good. Never had any BIOS issue.

I understand. You are saying that it's booting with Manjaro's grub2.

Post by Michel Bouissou
- Super Grub2 boots to its menu (Showing version 2.02s10-beta5)

Nice.

Post by Michel Bouissou
- I tried the "Print devices/partitions" option : Result : I get a
screen of output followed by a [MORE] prompt, but at this step the
computer is frozen. The usual "more" keys (Enter, space...) produce
nothing.  Had no other solution than power cycling the computer the hard
way.

I think it's the first time I have this feedback with this option.

Post by Michel Bouissou
- Reboot into the Manjaro OS to check that everything was still good (it
was), then reboot into Super Grub2

Ok.

Post by Michel Bouissou
- Tried the "Detect and show boot methods" option : Screen went black
with the USB key access LED blinking fast, so I thought it was doing
something... But after 10 minutes it still was, and then I had no other
solution than to power-cycle the machine the hard way again.

I see. Well, sometimes, Super Grub2 Disk takes a while to find all the
installed Operating Systems. Do you have anything else than Manajaro in
your system? Maybe many EFI files or many ISO files at /boot/boot-isos/ ?

I also want to say that Super Grub2 Disk when using "Detect and..."
sources the installed grub.cfg files. Maybe that might be a problem in
some machines.

You can alternatively use the option: Boot Manually -> Operating Systems
so that in only searches kernels (and not sources grub.cfg files).

In such case do you happen to find also the UEFI CMOS memory corrupt
warning (that you describe in a moment) ?

Post by Michel Bouissou
- At reboot, got a bad message stating that the UEFI CMOS memory was
corrupt (scream !) so type press a key to fix it, which I did.

That does not make sense. As far as I know GRUB is read only in matter
of UEFI CMOS. I mean Super Grub2 Disk is just upstream GNU/GRUB with
some default build options.

I will have to ask GRUB gurus at grub-devel if GRUB is able to modify
UEFI entries by itself or not.

Post by Michel Bouissou
- Then the machine rebooted to a « Windows failed to start » error
message. After minutes of terror I discovered that all of my machine
UEFI settings (except for the administrator password) had been reverted
back to default settings (probably following the CMOS corruption) and
that the "Secure boot" option had been reactivated.

Well, that might be a consequence of you saying "Yes" when you are asked
to fix the UEFI CMOS memory. Not a Super Grub2 Disk consequence. But,
it's true, that it would be nice to know why your UEFI BIOS is detecting
that the UEFI CMOS is corrupt after Super Grub2 Disk is used.

Post by Michel Bouissou
- After deactivating it the machine would accept to boot Manjaro again,
BUT while booting I noticed it doing unusual fsck stuff...

Maybe it was mounted more than X days ago or N times?

Post by Michel Bouissou
So I can say for sure that Super Grub2 did something really bad to this
machine - hadn't had a single UEFI CMOS corruption issue before, I don't
believe it to be a bare coincidence...
Hope that this information may be useful ?

Yes, it's useful. I might try to build another Super Grub2 Disk beta in
the next weeks (busy working on Rescatux right now) that does not
'source grub.cfg files' by default on the "Detect and..." so that you
can test it.

In the meanwhile you could test all the options of the current SG2D
2.02s10-beta5 version, one after another, in the "Boot Manually" menu
till you find which one is the culprit.

In theory, if my suspicion is right the culprit option would be:
"grub.cfg - Extract entries".

Thank you for your feedback!

Keep me informed if you do more tests in this machine.
Feel free to make backups before using SG2D if you are too scared of the
UEFI CMOS corrupted warnings.

Post by Michel Bouissou
ॐ

adrian15

[Michel Bouissou]

Hi Adrian,

(Still about Super Grub2 key on HP Pavilion Detachable X2 10-N123NF, per
your request)

Post by Michel Bouissou
It's booting with grub2. Works good. Never had any BIOS issue.
I understand. You are saying that it's booting with Manjaro's grub2.

Yes. That's grub version 2.02.0-3 from Manjaro's original package,
installed on system.

(I had no trouble with installing other, earlier Linux versions also
using grub, such as Mint 17.x onto said system)

Post by Michel Bouissou

Post by Michel Bouissou
- Tried the "Detect and show boot methods" option : Screen went black
with the USB key access LED blinking fast, so I thought it was doing
something... But after 10 minutes it still was, and then I had no other
solution than to power-cycle the machine the hard way again.

I see. Well, sometimes, Super Grub2 Disk takes a while to find all the
installed Operating Systems. Do you have anything else than Manajaro in
your system? Maybe many EFI files or many ISO files at /boot/boot-isos/ ?

No. Manjaro is (currently) alone on the machine.

The machine has a (main) 32 GB eMMC on which the OS is installed, plus
an USB-connected HD in the detachable keyboard. This on is fully
encrypted so grub won't find anything there.

The EFI partition holds 3 directories :

- "Manjaro", containing grubx64.efi, which is the default boot entry

- "HP", containing subdirs "BIOS", "BIOSUpadte", "HP SUpport Framework"
and "SystemDiasg" : System manufacturer's stuff that I didn't dare
touching  ;-)

- "Boot", containing bootx64.efi, which I assume to be the original
Windows bootloader remains. I leave it there because I sometimes swap
Linux for Windows back and forth - using system clones I hold on the
additional encrypted HD.

The installed Manjaro's grub has only config entries for booting Manjaro
(2 kernels in normal or rescue mode). Very classic.

Post by Michel Bouissou
You can alternatively use the option: Boot Manually -> Operating Systems
so that in only searches kernels (and not sources grub.cfg files).
In such case do you happen to find also the UEFI CMOS memory corrupt
warning (that you describe in a moment) ?

5 minutes of black screen with blinking USB key LED. Then power cycle
the hard way. No UEFI corruption on reboot.

I have to add that the corruption I noticed the other day doesn'nt
necessarily happen *every* time : the first tim I had noticed SG2 die
into a black screen, I had rebooted and it was OK. It was on the 2nd
same attemp that the BIOS complained about CMOS corruption...

I have a supposition about the reason that may confuse SG2 on this
machine : it's « hard disk » is not a hard disk and is not called /dev/sd*

Being an eMMC, it's called /dev/mmcblk0, gpt partitioned and gdisk shows
it partitioned as :
- /dev/mmcblk0p1 : 260 MB EF00 EFI partition
- /dev/mmcblk0p2 : 16 MB "Microsoft reserved" that I didn't touch, it
being small
- /dev/mmcblk0p3 :  28 GB Linux main ext4 partition
- /dev/mmcblk0p4 : 1 GB Linux swap

But ls also shows :
- /dev/mmcblk0boot0
- /dev/mmcblk0boot1
- /dev/mmcblk0rpmb

I have no clue about these, which partitioning tools do not see, while
they do appear under /dev. When cloning the machine using clonezilla, it
complains not being able to read it, but just skips it.

Maybe SG2 doesn't like this kind of systems ?

(BTW how would it behave with a system running on /dev/nvme* ?)

Post by Michel Bouissou

Post by Michel Bouissou
- After deactivating it the machine would accept to boot Manjaro again,
BUT while booting I noticed it doing unusual fsck stuff...

Maybe it was mounted more than X days ago or N times?

No, this is ext4 with a “maximum mount count” set to -1 and “check
interval” to 0-none. So it doesn't usually fsck it.

Post by Michel Bouissou
In the meanwhile you could test all the options of the current SG2D
2.02s10-beta5 version, one after another, in the "Boot Manually" menu
till you find which one is the culprit.
"grub.cfg - Extract entries".

- Operating Systems : Black screen failure
- grub.cfg - Extract entries : Black screen failure
- grub.cfg - grub2 configuration file : Black screen failure
- menu.lst : Black screen failure
- core.img : Black screen failure
- Disks and Partitions (Chainload) : Black screen failure
- Bootable isos : Black screen failure

It shows a quite consistent behaviour when it comes to searching for
things on "disk"...

You see I had to power cycle it a number of times, but didn't see the
CMOS corruption happen again...

HTH.

Kind regards.

ॐ

[adrian15]

Post by Michel Bouissou
Hi Adrian,
(Still about Super Grub2 key on HP Pavilion Detachable X2 10-N123NF, per
your request)
(...)
I have a supposition about the reason that may confuse SG2 on this
machine : it's « hard disk » is not a hard disk and is not called /dev/sd*
Being an eMMC, it's called /dev/mmcblk0, gpt partitioned and gdisk shows
- /dev/mmcblk0p1 : 260 MB EF00 EFI partition
- /dev/mmcblk0p2 : 16 MB "Microsoft reserved" that I didn't touch, it
being small
- /dev/mmcblk0p3 :  28 GB Linux main ext4 partition
- /dev/mmcblk0p4 : 1 GB Linux swap
- /dev/mmcblk0boot0
- /dev/mmcblk0boot1
- /dev/mmcblk0rpmb
I have no clue about these, which partitioning tools do not see, while
they do appear under /dev. When cloning the machine using clonezilla, it
complains not being able to read it, but just skips it.
Maybe SG2 doesn't like this kind of systems ?
(BTW how would it behave with a system running on /dev/nvme* ?)

1) Maybe you could try to press: 'c'

And then run 'ls'
and tell us what Grub sees.

2) As an alternative you can try my former SG2D 2.02s9 release which had
implemented another search algorithm:
https://sourceforge.net/projects/supergrub2/files/2.02s9/super_grub2_disk_2.02s9/super_grub2_disk_hybrid_2.02s9.iso/download

I'm a bit out of clues without being able to debug this more.

adrian15

[Michel Bouissou]

Hi,

Post by adrian15
2. Can you please try Super Grub2 Disk Hybrid with the DD method?
https://sourceforge.net/projects/supergrub2/files/2.02s10-beta5/super_grub2_disk_2.02s10-beta5/super_grub2_disk_hybrid_2.02s10-beta5.iso/download
Does the menu appear for you?

I got a chance to test it : It does not boot.

The computer is able to display the key's brand/model (it doesn't show
"Windows Boot Manager")

But as soon as the key is selected as boot source : Black screen, cursor
in the upper left, game over.

Hope this helps.

Best regards.

ॐ

[adrian15]

Post by Michel Bouissou
Hi,

Post by adrian15
2. Can you please try Super Grub2 Disk Hybrid with the DD method?
https://sourceforge.net/projects/supergrub2/files/2.02s10-beta5/super_grub2_disk_2.02s10-beta5/super_grub2_disk_hybrid_2.02s10-beta5.iso/download
Does the menu appear for you?

I got a chance to test it : It does not boot.
The computer is able to display the key's brand/model (it doesn't show
"Windows Boot Manager")
But as soon as the key is selected as boot source : Black screen, cursor
in the upper left, game over.
Hope this helps.
Best regards.
ॐ

Regarding this machine I think you are finding this behaviour:
* BIOS-only USBs do work well (The isolinux ones)
* UEFI USBs have problems (except the refind one)

So I want you to test:

1) The BIOS-only version of Super Grub2 Disk:
https://sourceforge.net/projects/supergrub2/files/2.02s9/super_grub2_disk_2.02s9/super_grub2_disk_i386_pc_2.02s9.iso/download

It should boot as it is BIOS-only based.

2) The UEFI (64bit)-only version of Super Grub2 Disk:
https://sourceforge.net/projects/supergrub2/files/2.02s9/super_grub2_disk_2.02s9/super_grub2_disk_x86_64_efi_2.02s9.iso/download

Depending on the iso partition design it might boot on your system

3) The UEFI (32bit)-only version of Super Grub2 Disk:
https://sourceforge.net/projects/supergrub2/files/2.02s9/super_grub2_disk_2.02s9/super_grub2_disk_i386_efi_2.02s9.iso/download

Just in case your system is one of those rare 32bit efi systems.

4) A manual UEFI disk based on SG2D standalone image

Format the USB as FAT32 and recreate on it these directories and files:
/EFI/BOOT/BOOTX64.EFI
/EFI/BOOT/APPLE.EFI
/EFI/BOOT/BOOTIA32.EFI

where:
BOOTX64.EFI and APPLE.EFI are:
https://sourceforge.net/projects/supergrub2/files/2.02s10-beta5/super_grub2_disk_2.02s10-beta5/super_grub2_disk_standalone_x86_64_efi_2.02s10-beta5.EFI/download
and where:
BOOTIA32.EFI is:
https://sourceforge.net/projects/supergrub2/files/2.02s10-beta5/super_grub2_disk_2.02s10-beta5/super_grub2_disk_standalone_i386_efi_2.02s10-beta5.EFI/download

5) (Short for: (5): Just skip it.)

Finally if the laptop is hardcoded to boot from Window when UEFI is
detected (as per the pendrives being detected as Windows Boot Manager)
you can try to use a pendrive that has an UEFI partition like (2)
described above.

So plug that pendrive into another computer and boot from Rescatux
0.41b1. Use the option "Fake Windows UEFI boot entry", select (This is
very important) the EFI partition present at your pendrive (not your
internal hard disk one) and then the BOOTX64.EFI one.
Then Rescatux will create a filename that mimicks the usual windows boot
file that it's find in internal or external windows hard disks.

Unfortunately this option it's going to affect your UEFI NVRAM on your
"Only Boot Rescatux here machine". So that means your UEFI boot entries
would be affected.

This option was designed to be used in the same machine where you want
to fix your boot. I hadn't thought of this specific scenario (Which it's
not very common by the way.).

Now you can plug the usb into the conflictive machine and see what happens.

Wait a moment... this "Fake Windows UEFI boot entry" option seems to be
broken on my rescapp current git head. Let me check Rescatux 0.41b1 one
second. Yeah, it's definitively broken. Probably it's broken in 0.51b3
too. This was useful :). Anyway I'm just talking aloud alone here.

Maybe (2) is not the right disk for doing this steps. Forgive me if it
doesn't make sense but this is a path to explore.

6) Ok, let's forget (5). Do not perform (5).
Now I want you to take the (4) pendrive and modify it a bit so that it
has two new files called:

EFI/Microsoft/Boot/bootmgr.efi
EFI/Microsoft/Boot/bootmgfw.efi

which its contents would be:
https://sourceforge.net/projects/supergrub2/files/2.02s10-beta5/super_grub2_disk_2.02s10-beta5/super_grub2_disk_standalone_x86_64_efi_2.02s10-beta5.EFI/download

7) If (6) does not boot properly please remove the bootmgfw.efi file
from that USB.


What are the results of 1,2,3,4,6 and 7 tests?


Thank you for your feedback!


adrian15

[hoan]

hello,

specific quoted

"So I can tell being 100% sure that the HP ProBook x360 11 G1 EE
distributed to students in France will *NOT BOOT* any of the common,
grub-based, Linux USB keys, but that it will happily boot the same keys
when grub is replaced with syslinux."

I am sure to interpret your result as this :

On any laptop wise,even with uefi boot alone ,you can boot any current
live iso by doing this.

Let me prove by an experiment ( sdb here is only used to boot grub via
bootx64.efi )

sudo qemu-system-x86_64 -m 1G -enable-kvm -bios OVMF64.fd /dev/sdb
-cdrom tails-amd64-3.3.iso

1 boot any grub uefi usb you have ; once presented with the grub menu :
do not validate any choice, type c to get into

grub console.Then type in grub shell

2 set root=(cd0)  ###to set root at cdrom as if it were booted from cd
3 syslinux_configfile /isolinux/isolinux.cfg    (the path position of
isolinux.cfg is distro dependent of course)
4 validate your choice in isolinux_config :tail
That's it
Replace tails.iso by any live_iso of your choice, including those i386
type ; use xorriso to find out where is isolinux.cfg 's path ...you get
booted.

Of course if one knows booting liveiso manually like this ,it's
certainly not difficult to include in a config file
and if that works,then certainly there are no "grub locking" whatever on
your laptop.

Remarks
a I have no Macs nor HPwise ;that's why I emulate. Those funny beast
only recognise -at least at boot time- hfs/afs  or hpfs  and fat/ntfs
   The tails.iso was built as hpfs/ntfs awared while almost all other
distro are simply iso9660 awared ( Fedora lies apart with hfs awared)

b A laptop recognises refind/refit  does recognise grub : they are in
the same world.

c blackseen after validate enter on grub menu does not mean grub not
working !
To me grub is perfect ,the way we use it is only to blame.
Most of the time blackscreen is due to bad video driver not loaded in
time ,and this happens just after typing return to validate a line in
grub menu. But that is another story if the distro + kernel +
grub_hand_passing  has a mishap.

d I 've emulated isoimage on cdrom here, but it 's not a must .You can
emulate using -hdb live.iso in place of cdrom.Just set root
at (hd2) for ex. Use ls in grubshell to find out dynamically. I chose
cdrom to prove universality of liveiso oldpal 's HPA isolinuxbin
Remember syslinux on fat is just isolinux on iso9660 ; they all belong
to the old world bios legacy but stiil rock solid.

  Use grub's bootx64 or bootia32 ro boot.efi  then pass hands to kernel
using isolinux.cfg : grub  has finished its job here;
any bad behaviour after that belongs to distro's management of loading OS

Post by Michel Bouissou
Hi,
In some (south-west) regions of France, high-school students are
currently given (for free - I mean : from our taxes) HP ProBook x360 11
G1 EE (Education Edition) laptop computers.
These computers come with Windows 10 and an HP EFI BIOS v. 01.09 to
01.11 that has no support for legacy CSM boot mode.
I believe that either this UEFI BIOS has been purposely “locked against
grub”, or there is a serious bug.
After having disabled Secure boot, I have discovered that none of the
usual (curent, latest versions as of 2017/12) Linux live USB sticks
(among : Ubuntu, Mint, Debian, Manjaro, PartedMagic) was able to boot on
this machine.
All these live USB keys normally boot using grub.
- UEFI BIOS selection displays the USB key as "Windows boot manager"
instead of the USB key make / model one is used to see on other machines ;
- Selecting this just causes the screen to go black with a blinking
cursor and... that's the end.
- After a while I discovered that a rEFInd key
(http://www.rodsbooks.com/refind/ ) IS ABLE to boot, and that it "sees"
the Linux key if both inserted at the same time.
- But trying to chain from rEFInd to the Linux key fails (black screen
of death with blinking cursor)
- Then I discovered that a Tails Linux key (https://tails.boum.org )
boots easily with no problem at all on the machine... And this one boots
from syslinux.
- I also tested and found that rEFInd is also able to chain to a Tails
key properly.
- Then I made another experiment and try to "doctor" some Linux keys
that couldn't boot (namely : Parted Magic and Manjaro) to remove grub
from them and replace it with syslinux. It was not an easy task, but
once done, it allowed both distros to boot easily and seamlessly.
- It is worth specifying that, as soon as grub is replaced with
syslinux, the machine's BIOS doesn't call the key "Windows boot manager"
anymore, but properly displays its brand and model.
So I can tell being 100% sure that the HP ProBook x360 11 G1 EE
distributed to students in France will*NOT BOOT* any of the common,
grub-based, Linux USB keys, but that it will happily boot the same keys
when grub is replaced with syslinux.
I cannot tell for sure if this is a purposeful lock on the machine BIOS
or a serious bug somewhere, but I felt that it deserves to be
documented, reported and investigated.
Please copy me on replies, I'm not subscribed to this mailing-list.
Best regards.
ॐ
_______________________________________________ Help-grub mailing list

[Michel Bouissou]

Hi Hoan,

Post by hoan
Let me prove by an experiment ( sdb here is only used to boot grub via
bootx64.efi )
sudo qemu-system-x86_64 -m 1G -enable-kvm -bios OVMF64.fd /dev/sdb
-cdrom tails-amd64-3.3.iso
1 boot any grub uefi usb you have ; once presented with the grub menu

On this machine, booting « any grub USB key I have » will *never* make
me « presented with the grub menu ».

As soon as the USB key is selected as boot source from the UEFI system,
black screen, cursor in the upper left, game over.

You're talking about the theoretical behaviour in a VM. I'm talking
about an actual machine that is on my son's desk.

Kind regards.

ॐ