Originally posted by fernie
View Post
Announcement
Collapse
No announcement yet.
The New Ubuntu 18.04 Server Installer Is Working Out Nicely
Collapse
X
-
Originally posted by fernie View Post
had one probook g640 Gsomething with that issue, but it works fine by creating custom boot entry in bios. Its common to debian based distros and how they handle the esp fat partition because of apt. It does not fail to install, HP bios just looks for something else to boot from.Originally posted by blacknovaYeah, I know, mine HP8770w didn't want to accept custom entry though. So I had to copy boot loader to place expected by bios for Ubuntu. Fedora installed and worked without issues though.
May be moving from Fedora to Debian as soon as the current Debian Testing is frozen, so any information you can share will be very very useful.
Comment
-
Some of older HP laptops has pecular quirk in their UEFI bios, they expect loader to be present in some standard locations. You can read about it here.The whole story is at: http://forums.linuxmint.com/viewtopic.php?f=46&t=164076 Anyway, here is a summary. Installed Linux Mint 16 KDE on an empty new SSD on this notebook, leaving Mint take the whole disk (with LVM and encryption). The BIOS was configured by myself to boot in Native UEFI mode, without CSM (default is to boot in legacy mode, Windows 7 Professional is pre-installed on my unit). Secure Boot is disabled. Exact notebook model is HP ProBook 450 G1 (E9Y21EA). Provided firmware was...
Comment
-
Originally posted by blacknova View PostSome of older HP laptops has pecular quirk in their UEFI bios, they expect loader to be present in some standard locations. You can read about it here.
I've had also desktop boards whose UEFI was totally brain dead and could only boot Microsoft bootloader (hardcoded position) or this standard default location.
/boot/efi/EFI/BOOT is the path if you have somehow booted into the linux system, EFI/BOOT is the actual path if you look at the EFI partition from another system.
Just take whatever is your bootloader and place it in that folder and rename it as bootx64.efi, then if the UEFI is especially stubborn move or rename the Microsoft loader (EFI/BOOT/Microsoft/Boot/bootmgr.efi) so it cannot find it (as I had a stupid HP envy 15 with AMD APUs from 2015 that still wanted to boot Windows first), and rely on your own bootloader (either grub or rEFInd or whatever) to actually chainload it if you want to boot into Windows again.
Afaik serious distros should have worked around this issue by doing this during the grub installation already. OpenSUSE does this for example, each time you install/update grub it creates the folder, and places there a copy of grub renamed as bootx64.efi so the braindead UEFIs can still boot the system. They also place the fallback.efi binary there too, (see link above for what it is)
Also according to the above link (and your personal experience) Fedora is doing the same too.
Can someone look in the folders I mention on a fresh Ubuntu 18.04 installation and confirm if also Ubuntu does this by default? If it does not I suggest harassing their grub package maintainers to implement this too.Last edited by starshipeleven; 28 April 2018, 06:33 AM.
Comment
-
I totally agree that a server installer wich doesn't support mdadm raid and lvm is a big lack.... I always installed desktops systems with madadm raid1 using the mini.iso ; but with 18.04 i am actually unable to find it.... installing ubuntu server and the desktop in annoying... anyone can tell me if the mini.iso exists for 18.04? thx
Comment
Comment