Discussion:
Single Drive Fresh Install (mbr/grub2) Fails to boot (can boot existing from .iso??)
(too old to reply)
David C. Rankin
2016-10-29 02:58:27 UTC
Permalink
All,

After 7 years and 30+ installs, I thought I had seen it all. I have a new
(used) laptop, that I put a fresh 1T drive in, partitioned and loaded arch. The
laptop can't find the drive to boot? Huh? There is only a single drive in the
laptop, but it will only boot if booting from grub hd1 (instead of hd0).

The failure isn't a "grub prefix/root" problem, the problem is the laptop
cannot even find grub to begin with when it is booting on it's own. The only way
booting happens is to boot the installer (from USB) and then "Choose existing
OS" and edit the prefix (from 0 -> 1). Which itself is wonky, because booting
from USB creates the USB thumb-drive as /dev/sdb to begin with and the hard
drive as /dev/sda where it should be.

This is a strange laptop, it has 2 hard drive bays (HP Elite 8760w). The bios
is configured to scan both (as well as USB and PXE) for boot. I can boot the
install .iso without issue, install went fine, but in order to boot the new
install, I have to "Boot existing OS" from the .iso menu, then 'tab' and change

hd0 0

to

hd1 0

(I took the existing Win10 SSD out of the same bay I put this drive in - which
is also a simple mbr boot - no UEFI). The setup is dead simple (.iso is sdb below)

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 1 980M 0 disk
├─sdb2 8:18 1 40M 0 part
└─sdb1 8:17 1 792M 0 part
sr0 11:0 1 1024M 0 rom
sda 8:0 0 931.5G 0 disk
├─sda7 8:7 0 880G 0 part /home
├─sda5 8:5 0 500M 0 part /boot
├─sda1 8:1 0 1K 0 part
├─sda8 8:8 0 1G 0 part
└─sda6 8:6 0 50G 0 part /

and

$ sudo fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xff7d45aa

Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 1953525167 1953523120 931.5G 5 Extended
/dev/sda5 * 4096 1028095 1024000 500M 83 Linux
/dev/sda6 1030144 105887743 104857600 50G 83 Linux
/dev/sda7 105889792 1951383551 1845493760 880G 83 Linux
/dev/sda8 1951385600 1953525167 2139568 1G 82 Linux swap / Solaris

grub is installed to /dev/sda with

grub-install --target=i386-pc /dev/sda (no errors on install), and
grub-mkconfig -o /boot/grub/grub.cfg

I've searched for anything related to HP laptops or this model, but only find
issues failing to boot the install CD or the newer UEFI pages like

https://wiki.archlinux.org/index.php/HP_EliteBook_840_G1.

Has anyone encountered something similar? There is no longer a
/boot/grub/device.map file installed by grub2, but given the fact the bios isn't
seeing the drive at all for boot, I don't see how mapping hd0 to hd1 would make
a difference. Does anyone have a link or any idea what the issue may be? I'm
happy to send whatever additional information may be required. I'm ssh'ed into
the box right now, I just need to get the boot and plasma ironed out. Any ideas?
Thanks.
--
David C. Rankin, J.D.,P.E.
Juan Carlos Villegas Botero via arch-general
2016-10-29 03:58:26 UTC
Permalink
I'm not 100% sure that this is the solution, but if you are loading from
UEFI, the boot partition must be formatted using GPT:
https://wiki.archlinux.org/index.php/EFI_System_Partition
Post by David C. Rankin
All,
After 7 years and 30+ installs, I thought I had seen it all. I have a new
(used) laptop, that I put a fresh 1T drive in, partitioned and loaded arch. The
laptop can't find the drive to boot? Huh? There is only a single drive in the
laptop, but it will only boot if booting from grub hd1 (instead of hd0).
The failure isn't a "grub prefix/root" problem, the problem is the laptop
cannot even find grub to begin with when it is booting on it's own. The only way
booting happens is to boot the installer (from USB) and then "Choose existing
OS" and edit the prefix (from 0 -> 1). Which itself is wonky, because booting
from USB creates the USB thumb-drive as /dev/sdb to begin with and the hard
drive as /dev/sda where it should be.
This is a strange laptop, it has 2 hard drive bays (HP Elite 8760w). The bios
is configured to scan both (as well as USB and PXE) for boot. I can boot the
install .iso without issue, install went fine, but in order to boot the new
install, I have to "Boot existing OS" from the .iso menu, then 'tab' and change
hd0 0
to
hd1 0
(I took the existing Win10 SSD out of the same bay I put this drive in - which
is also a simple mbr boot - no UEFI). The setup is dead simple (.iso is sdb below)
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 1 980M 0 disk
├─sdb2 8:18 1 40M 0 part
└─sdb1 8:17 1 792M 0 part
sr0 11:0 1 1024M 0 rom
sda 8:0 0 931.5G 0 disk
├─sda7 8:7 0 880G 0 part /home
├─sda5 8:5 0 500M 0 part /boot
├─sda1 8:1 0 1K 0 part
├─sda8 8:8 0 1G 0 part
└─sda6 8:6 0 50G 0 part /
and
$ sudo fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xff7d45aa
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 1953525167 1953523120 931.5G 5 Extended
/dev/sda5 * 4096 1028095 1024000 500M 83 Linux
/dev/sda6 1030144 105887743 104857600 50G 83 Linux
/dev/sda7 105889792 1951383551 1845493760 880G 83 Linux
/dev/sda8 1951385600 1953525167 2139568 1G 82 Linux swap / Solaris
grub is installed to /dev/sda with
grub-install --target=i386-pc /dev/sda (no errors on install), and
grub-mkconfig -o /boot/grub/grub.cfg
I've searched for anything related to HP laptops or this model, but only find
issues failing to boot the install CD or the newer UEFI pages like
https://wiki.archlinux.org/index.php/HP_EliteBook_840_G1.
Has anyone encountered something similar? There is no longer a
/boot/grub/device.map file installed by grub2, but given the fact the bios isn't
seeing the drive at all for boot, I don't see how mapping hd0 to hd1 would make
a difference. Does anyone have a link or any idea what the issue may be? I'm
happy to send whatever additional information may be required. I'm ssh'ed into
the box right now, I just need to get the boot and plasma ironed out. Any ideas?
Thanks.
--
photo

*Juan Carlos Villegas Botero*
Director de Desarrollo, Micoworker
***@micoworker.com <mailto:***@micoworker.com> (+57) 312
3977780 <tel:%28+57%29%20312%203977780> www.micoworker.com
<http://www.micoworker.com> Skype: juankvillegas <#>
Juan Carlos Villegas Botero via arch-general
2016-10-29 03:59:57 UTC
Permalink
Sorry for the html response :S
Post by Juan Carlos Villegas Botero via arch-general
I'm not 100% sure that this is the solution, but if you are loading
https://wiki.archlinux.org/index.php/EFI_System_Partition
Post by David C. Rankin
All,
After 7 years and 30+ installs, I thought I had seen it all. I have a new
(used) laptop, that I put a fresh 1T drive in, partitioned and loaded arch. The
laptop can't find the drive to boot? Huh? There is only a single drive in the
laptop, but it will only boot if booting from grub hd1 (instead of hd0).
The failure isn't a "grub prefix/root" problem, the problem is the laptop
cannot even find grub to begin with when it is booting on it's own. The only way
booting happens is to boot the installer (from USB) and then "Choose existing
OS" and edit the prefix (from 0 -> 1). Which itself is wonky, because booting
from USB creates the USB thumb-drive as /dev/sdb to begin with and the hard
drive as /dev/sda where it should be.
This is a strange laptop, it has 2 hard drive bays (HP Elite 8760w). The bios
is configured to scan both (as well as USB and PXE) for boot. I can boot the
install .iso without issue, install went fine, but in order to boot the new
install, I have to "Boot existing OS" from the .iso menu, then 'tab' and change
hd0 0
to
hd1 0
(I took the existing Win10 SSD out of the same bay I put this drive in - which
is also a simple mbr boot - no UEFI). The setup is dead simple (.iso is sdb below)
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 1 980M 0 disk
├─sdb2 8:18 1 40M 0 part
└─sdb1 8:17 1 792M 0 part
sr0 11:0 1 1024M 0 rom
sda 8:0 0 931.5G 0 disk
├─sda7 8:7 0 880G 0 part /home
├─sda5 8:5 0 500M 0 part /boot
├─sda1 8:1 0 1K 0 part
├─sda8 8:8 0 1G 0 part
└─sda6 8:6 0 50G 0 part /
and
$ sudo fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xff7d45aa
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 1953525167 1953523120 931.5G 5 Extended
/dev/sda5 * 4096 1028095 1024000 500M 83 Linux
/dev/sda6 1030144 105887743 104857600 50G 83 Linux
/dev/sda7 105889792 1951383551 1845493760 880G 83 Linux
/dev/sda8 1951385600 1953525167 2139568 1G 82 Linux swap / Solaris
grub is installed to /dev/sda with
grub-install --target=i386-pc /dev/sda (no errors on install), and
grub-mkconfig -o /boot/grub/grub.cfg
I've searched for anything related to HP laptops or this model, but only find
issues failing to boot the install CD or the newer UEFI pages like
https://wiki.archlinux.org/index.php/HP_EliteBook_840_G1.
Has anyone encountered something similar? There is no longer a
/boot/grub/device.map file installed by grub2, but given the fact the bios isn't
seeing the drive at all for boot, I don't see how mapping hd0 to hd1 would make
a difference. Does anyone have a link or any idea what the issue may be? I'm
happy to send whatever additional information may be required. I'm ssh'ed into
the box right now, I just need to get the boot and plasma ironed out. Any ideas?
Thanks.
Juan Carlos Villegas Botero via arch-general
2016-10-29 04:03:11 UTC
Permalink
And I also think that I read somewhere that theboot partition (EFI) must
be the first one in the disk.
Post by Juan Carlos Villegas Botero via arch-general
Sorry for the html response :S
Post by Juan Carlos Villegas Botero via arch-general
I'm not 100% sure that this is the solution, but if you are loading
https://wiki.archlinux.org/index.php/EFI_System_Partition
Post by David C. Rankin
All,
After 7 years and 30+ installs, I thought I had seen it all. I have a new
(used) laptop, that I put a fresh 1T drive in, partitioned and loaded arch. The
laptop can't find the drive to boot? Huh? There is only a single drive in the
laptop, but it will only boot if booting from grub hd1 (instead of hd0).
The failure isn't a "grub prefix/root" problem, the problem is the laptop
cannot even find grub to begin with when it is booting on it's own. The only way
booting happens is to boot the installer (from USB) and then "Choose existing
OS" and edit the prefix (from 0 -> 1). Which itself is wonky, because booting
from USB creates the USB thumb-drive as /dev/sdb to begin with and the hard
drive as /dev/sda where it should be.
This is a strange laptop, it has 2 hard drive bays (HP Elite 8760w). The bios
is configured to scan both (as well as USB and PXE) for boot. I can boot the
install .iso without issue, install went fine, but in order to boot the new
install, I have to "Boot existing OS" from the .iso menu, then 'tab' and change
hd0 0
to
hd1 0
(I took the existing Win10 SSD out of the same bay I put this drive in - which
is also a simple mbr boot - no UEFI). The setup is dead simple (.iso is sdb below)
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdb 8:16 1 980M 0 disk
├─sdb2 8:18 1 40M 0 part
└─sdb1 8:17 1 792M 0 part
sr0 11:0 1 1024M 0 rom
sda 8:0 0 931.5G 0 disk
├─sda7 8:7 0 880G 0 part /home
├─sda5 8:5 0 500M 0 part /boot
├─sda1 8:1 0 1K 0 part
├─sda8 8:8 0 1G 0 part
└─sda6 8:6 0 50G 0 part /
and
$ sudo fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xff7d45aa
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 1953525167 1953523120 931.5G 5 Extended
/dev/sda5 * 4096 1028095 1024000 500M 83 Linux
/dev/sda6 1030144 105887743 104857600 50G 83 Linux
/dev/sda7 105889792 1951383551 1845493760 880G 83 Linux
/dev/sda8 1951385600 1953525167 2139568 1G 82 Linux swap / Solaris
grub is installed to /dev/sda with
grub-install --target=i386-pc /dev/sda (no errors on install), and
grub-mkconfig -o /boot/grub/grub.cfg
I've searched for anything related to HP laptops or this model, but only find
issues failing to boot the install CD or the newer UEFI pages like
https://wiki.archlinux.org/index.php/HP_EliteBook_840_G1.
Has anyone encountered something similar? There is no longer a
/boot/grub/device.map file installed by grub2, but given the fact the bios isn't
seeing the drive at all for boot, I don't see how mapping hd0 to hd1 would make
a difference. Does anyone have a link or any idea what the issue may be? I'm
happy to send whatever additional information may be required. I'm ssh'ed into
the box right now, I just need to get the boot and plasma ironed out. Any ideas?
Thanks.
Uwe via arch-general
2016-10-29 06:18:37 UTC
Permalink
Hi

Just to clarify: do you really boot from BIOS via MBR or do you use UEFI (and are therefore in need of GPT)?

For the latter I recommend creating a 1MB Bios-Boot-partition (ef02) with gdisk, some swap after that and, dependant on your personal needs, either the rest for system or a bit for system and the rest for home
David C. Rankin
2016-10-29 10:48:29 UTC
Permalink
Post by Uwe via arch-general
Hi
Just to clarify: do you really boot from BIOS via MBR or do you use UEFI (and
are therefore in need of GPT)?
For the latter I recommend creating a 1MB Bios-Boot-partition (ef02) with
gdisk, some swap after that and, dependant on your personal needs, either the
rest for system or a bit for system and the rest for home
100% MBR/BIOS BOOT no UEFI used by either the Win10 OS disk I took out, or the
new Arch disk I put it. I checked in windows with:

bcdedit /emum

to dump the bootloader config. and confirmed it was NOT boot UEFI, but just
plain mbr/bios boot. The error I get from the laptop is "No Operating System
Found" and a FD03 code if I recall correctly. Then I put the arch iso usb in,
boot, choose the existing arch install, and I'm booted into a fine SDDM and
Plasma display (chuckling that some of the bugs I filed against kde4 are still
there in Plasma (e.g. 'konqueror --profile filemanagement' still launches with
the left 'drives/folders' pane collapsed against the file listings on the right
side.) Well, at least it is consistent :)

Another curious part of the drive/boot problem, is the HP "drive test" which
happily scans over the drive holding Arch, but will just never assign it a
number. For thoroughness, I tried configuring drive access as IDE from AHCI --
no help.

Maybe is this a hapless security feature that will prevent anyone without an
arch .iso from booting my system (that alone would bewilder the government for
days....)

As yet another test, I reinstalled the 128G windows drive, it continues to boot
fine. Any other thoughts?
--
David C. Rankin, J.D.,P.E.
Ralf Mardorf
2016-10-29 11:01:42 UTC
Permalink
Post by David C. Rankin
Any other thoughts?
Store the BIOS settings, turn of the computer, remove the CMOS battery,
set the jumpers to clear the CMOS RAM, wait a few seconds, set the
jumper back, turn on the computer, do not restore the BIOS settings,
perhaps it solved the issue. Then restore the BIOS settings ...

*?*

Regards,
Ralf
Ralf Mardorf
2016-10-29 11:16:06 UTC
Permalink
Post by Ralf Mardorf
Post by David C. Rankin
Any other thoughts?
Store the BIOS settings, turn of the computer, remove the CMOS battery,
set the jumpers to clear the CMOS RAM, wait a few seconds, set the
jumper back, turn on the computer, do not restore the BIOS settings,
perhaps it solved the issue. Then restore the BIOS settings ...
*?*
Regards,
Ralf
PS: Don't use the same battery again, replace it by a new battery, or
at least measure the voltage of the old battery under load, e.g.
measure with a resistor parallel to the multimeter.
Ralf Mardorf
2016-10-29 11:21:09 UTC
Permalink
Post by Ralf Mardorf
Post by Ralf Mardorf
Post by David C. Rankin
Any other thoughts?
Store the BIOS settings, turn of the computer, remove the CMOS
battery, set the jumpers to clear the CMOS RAM, wait a few seconds,
set the jumper back,
mount the battery, before turning on the computer ;),
Post by Ralf Mardorf
Post by Ralf Mardorf
turn on the computer, do not restore the BIOS
settings, perhaps it solved the issue. Then restore the BIOS
settings ...
*?*
Regards,
Ralf
PS: Don't use the same battery again, replace it by a new battery, or
at least measure the voltage of the old battery under load, e.g.
measure with a resistor parallel to the multimeter.
--
Death of ROXTerm
https://sourceforge.net/p/roxterm/discussion/422638/thread/60da6975/
kendell clark via arch-general
2016-10-29 11:24:52 UTC
Permalink
hi

This sounds like what I've been experiencing with sonar, a manjaro based
distro that's designed for accessibility. I just got a new, well new to
me anyway, dell precision workstation, and although the flash drive
boots and works fine, the installed system won't boot to the desktop. I
do get past the grub screen, but right as the display manager starts,
the screen turns black, and then goes all white, at which point the
system seems to hang. I've tried everything I can possibly think of,
including clearing the bios, installing in both bios and uefi modes,
nothing seems to work so I'm forced to use windows. This is with the
gnome and mate desktops, so it's clearly not the display manager or the
kernel, since we use the current lts kernel. I can provide specs if
needed, but the core specs are an intel core i5 3320m processor at 2.6
ghz, a radeon fire pro m6000 graphics card, and 8 gb of ram.


Thanks

Kendell Clark
Post by Ralf Mardorf
Post by Ralf Mardorf
Post by David C. Rankin
Any other thoughts?
Store the BIOS settings, turn of the computer, remove the CMOS battery,
set the jumpers to clear the CMOS RAM, wait a few seconds, set the
jumper back, turn on the computer, do not restore the BIOS settings,
perhaps it solved the issue. Then restore the BIOS settings ...
*?*
Regards,
Ralf
PS: Don't use the same battery again, replace it by a new battery, or
at least measure the voltage of the old battery under load, e.g.
measure with a resistor parallel to the multimeter.
Doug Newgard
2016-10-29 15:01:37 UTC
Permalink
On Sat, 29 Oct 2016 06:24:52 -0500
I do get past the grub screen
Meaning it's not the same issue at all. Don't hijack threads.
Patrick Burroughs (Celti)
2016-10-29 11:30:49 UTC
Permalink
On Sat, 29 Oct 2016 05:48:29 -0500
Post by David C. Rankin
Post by Uwe via arch-general
Hi
Just to clarify: do you really boot from BIOS via MBR or do you use
UEFI (and are therefore in need of GPT)?
100% MBR/BIOS BOOT no UEFI used by either the Win10 OS disk I took
bcdedit /emum
The laptop model you gave *does* use UEFI, but is early enough in HP's
endeavours to implement it that it's buggy as hell. I suggest you fire
up `msinfo32` in Windows and look for the “BIOS Mode” entry to confirm
you're in ‘Legacy’ mode and not UEFI mode.
Post by David C. Rankin
Another curious part of the drive/boot problem, is the HP "drive
test" which happily scans over the drive holding Arch, but will just
never assign it a number. For thoroughness, I tried configuring drive
access as IDE from AHCI -- no help.
That is likely a matter of partitioning and filesystems; the HP drive
test is a UEFI application and if you partitioned your drive as MBR and
filled it with filesystems it doesn't recognise, it might ignore it. I
can't confirm that, though; it's been far too long since I've ran Linux
on an HP laptop of that era.
Post by David C. Rankin
As yet another test, I reinstalled the 128G windows drive, it
continues to boot fine. Any other thoughts?
I suggest you double-check the partitioning and possible presence of
an EFI system partition on that Windows drive from within your Arch
install. If both msinfo and the partitioning confirm it's not UEFI,
then I suggest you a) make sure the firmware is up-to-date, and b)
comb through the firmware settings and make sure that it's fully in
Legacy/BIOS mode and not Hybrid UEFI/BIOS mode; the latter is the
cause of most such problems, in my experience.

~Celti
David C. Rankin
2016-10-30 06:34:02 UTC
Permalink
Post by Patrick Burroughs (Celti)
I suggest you double-check the partitioning and possible presence of
an EFI system partition on that Windows drive from within your Arch
install. If both msinfo and the partitioning confirm it's not UEFI,
then I suggest you a) make sure the firmware is up-to-date, and b)
comb through the firmware settings and make sure that it's fully in
Legacy/BIOS mode and not Hybrid UEFI/BIOS mode; the latter is the
cause of most such problems, in my experience.
Celti, Ralf,

Thank you. I cannot stand the limited bios that HP uses, it is an early
attempt at a graphical bios that is slow as Christmas to navigate. I've been
through every setting in the bios and there isn't any other setting that would
explain the issue. (I have confirmed the bios is the latest 2015 release by HP)

It appears both the bcdedit /enum and msinfo32 tests confirm it is using
Legacy boot. Checking msinfo32 reports

BIOS Mode Legacy

So I guess that leaves me with Ralfs solution of find the "Clear the CMOS"
jumper, clear the bios, replace the battery (I hope it is a standard 2032 or its
a trip to the battery store...)

I've never had another bios, in the probable 30 boxes I've had since '89 that
wouldn't just find the drive. Even the old RLL/MFM drives would come right up.
God, I hope this isn't a new problem generic with swapping SSD/Platter drives...
--
David C. Rankin, J.D.,P.E.
David C. Rankin
2016-11-03 07:45:14 UTC
Permalink
Post by David C. Rankin
So I guess that leaves me with Ralfs solution of find the "Clear the CMOS"
jumper, clear the bios, replace the battery (I hope it is a standard 2032 or its
a trip to the battery store...)
I think I have it figured out by process of elimination. I took another
drive and formatted it GPT and created a 1M bios_boot partition as shown
on the arch grub wiki. After grub install and reboot, exact same issue
"hard disk error 0F3" no operating system found. So with 2 new drives in
the laptop, neither would boot.

sda as the GPT/bios_boot configured drive, and sdb as the MBR configured
drive, no boot, but booting the install .iso from USB and "Boot Existing
OS" worked fine on both (with changes to either 'hd1 0' and 'hd2 0',
respectively.

So with further reading, it looks like this bios/laptop will actually
require a full UEFI partition scheme that the bios converts/boots in
Legacy mode via a bios_boot partition on the drive. That is a screwy way
of doing things, but makes sense given that the .iso has a full EFI
setup and boots with no problem whatsoever.

Question, for those familiar with UEFI schemes, since the .iso boots
fine, is there anything else I need to do other than following the Arch
grub wiki to construct the UEFI partition scheme and create the 1M
bios_boot partition? The wiki says the bios_boot partition can be
anywhere (partition number wise) as long as it lives in the first 2T of
space. Any other thoughts or tweaks to the UEFI setup I ought to try for
the next test?
--
David C. Rankin, J.D.,P.E.
Uwe Hametner
2016-11-03 20:44:44 UTC
Permalink
If you ever get your historic EFI to work while „that it's buggy as
hell“ {Patrick Burroughs (Celti), 29 Oct 2016} -- then where is the
point for doing a magic jump over to bios_grub if ever feasible in a
reasonable manner?

Though I lack some knowledge, where the wiki tells: at last 260 MiB are
required (ESP) on 4-KB-per-sector drives. W10 (sorry for adding this)
just takes 100 MiB on eMMC Flash Memory Drives, which also is the size
I chose for my latest linux install on a SSD.


General remark: Comments w/o errors are invalid.
Post by David C. Rankin
  So I guess that leaves me with Ralfs solution of find the "Clear
the CMOS"
jumper, clear the bios, replace the battery (I hope it is a
standard 2032 or its
a trip to the battery store...)
I think I have it figured out by process of elimination. I took another
drive and formatted it GPT and created a 1M bios_boot partition as shown
on the arch grub wiki. After grub install and reboot, exact same issue
"hard disk error 0F3" no operating system found. So with 2 new drives in
the laptop, neither would boot.
sda as the GPT/bios_boot configured drive, and sdb as the MBR
configured
drive, no boot, but booting the install .iso from USB and "Boot Existing
OS" worked fine on both (with changes to either 'hd1 0' and 'hd2 0',
respectively.
So with further reading, it looks like this bios/laptop will actually
require a full UEFI partition scheme that the bios converts/boots in
Legacy mode via a bios_boot partition on the drive. That is a screwy way
of doing things, but makes sense given that the .iso has a full EFI
setup and boots with no problem whatsoever.
Question, for those familiar with UEFI schemes, since the .iso boots
fine, is there anything else I need to do other than following the Arch
grub wiki to construct the UEFI partition scheme and create the 1M
bios_boot partition? The wiki says the bios_boot partition can be
anywhere (partition number wise) as long as it lives in the first 2T of
space. Any other thoughts or tweaks to the UEFI setup I ought to try for
the next test?
Simon Brulhart
2016-11-05 09:38:03 UTC
Permalink
I may be missing something, but is there a chance that the bios just
doesn't wait long enough for the disk to turn on?
On some laptops this sometimes happen to me when trying to boot an USB
harddisk. The disk isn't detected at all by the bios, but generally
rebooting with the disk already turned on fixes the issue.
I've also seen an option on some BIOSes to wait for a few additional
seconds at boot before enumerating drives, indicating that this may be a
common issue.

Simon
David C. Rankin
2016-11-07 17:34:44 UTC
Permalink
Post by Simon Brulhart
I may be missing something, but is there a chance that the bios just
doesn't wait long enough for the disk to turn on?
On some laptops this sometimes happen to me when trying to boot an USB
harddisk. The disk isn't detected at all by the bios, but generally
rebooting with the disk already turned on fixes the issue.
I've also seen an option on some BIOSes to wait for a few additional
seconds at boot before enumerating drives, indicating that this may be a
common issue.
Simon
Simon,

Thanks, but no, I eliminated that by choosing the boot options menu
(e.g. F9) on boot which allowed 30 seconds or so as I pondered the
options for the drives to spin up, no it is something quirky with this
laptop that I have to figure out, but I'm totally stuck.

I prepared a fresh summary of my ordeal in hopes of getting some
wisdom to help with this mystery. Here is the summary to date:

I need a miracle (or just some good help) to find out why I can boot
from the .iso and "Choose existing OS" just fine, but cannot get this
laptop to find and boot grub otherwise. (UEFI is *completely* disabled
in the BIOS and it boots win10 in Legacy mode fine) I have now exhausted
all that I can figure out based on my decade and a half of Linux use and
based on the wikis:

https://wiki.archlinux.org/index.php/GRUB
https://wiki.archlinux.org/index.php/EFI_System_Partition
https://wiki.archlinux.org/index.php/HP_EliteBook_840_G1 (uses EFI mode)

I have configured and tried simple MBR boot with the following setup:

# fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xff7d45aa

Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 1953525167 1953523120 931.5G 5 Extended
/dev/sda5 * 4096 1028095 1024000 500M 83 Linux
/dev/sda6 1030144 105887743 104857600 50G 83 Linux
/dev/sda7 105889792 1951383551 1845493760 880G 83 Linux
/dev/sda8 1951385600 1953525167 2139568 1G 82 Linux swap /
Solaris

grub isn't seen on boot, but popping the .iso on USB in, choosing
"Boot existing OS", hitting 'tab' and changing 'hd0 0' to 'hd1 0' boots
Arch fine.

I next tried with GPT and a 'bios_boot' partition:

# fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 00B6A48C-CBDB-4071-A1EC-97FA828A6C26

Device Start End Sectors Size Type
/dev/sda1 2048 4095 2048 1M BIOS boot
/dev/sda2 4096 1028095 1024000 500M Linux filesystem
/dev/sda3 1028096 105885695 104857600 50G Linux filesystem
/dev/sda4 105885696 1949282303 1843396608 879G Linux filesystem
/dev/sda5 1949282304 1951379455 2097152 1G Linux swap

same result, grub not found on its own, but booting from USB works fine.

Next, stranger things being possible, I decided to try a full UEFI
setup thinking maybe the Legacy mode for this laptop uses some contrived
boot scheme that requires the esp partition to be present. so I
re-partitioned the drive and went though the UEFI setup:

# fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 00B6A48C-CBDB-4071-A1EC-97FA828A6C26

Device Start End Sectors Size Type
/dev/sda1 2048 4095 2048 1M BIOS boot
/dev/sda2 4096 1028095 1024000 500M EFI System
/dev/sda3 1028096 105885695 104857600 50G Linux filesystem
/dev/sda4 105885696 1949282303 1843396608 879G Linux filesystem
/dev/sda5 1949282304 1951379455 2097152 1G Linux swap

Still, grub isn't seen on boot, but now "Choose existing OS" starts
grub, but then throws the error of "unrecognized partition type" (I
presume is due to the UEFI setup while UEFI is disabled in the BIOS)

So I'm stuck. This box boots from the iso perfectly. After "Choose
existing OS", I pull the USB drive, and the machine works flawlessly.
(I've got a full plasma/KDE5 setup installed with wpa_supplicant WPA
wifi, bluetooth, synaptics touchpad, ieee-1394, all working just fine,
etc.., e.g. I drafted this on kwrite and sent it via thunderbird from
this same darn box) I just can't get this box to find grub to save my life.

I need help figuring out how the .iso is booting in Legacy mode just
fine, while I can't do the same thing from the hard drive. If this box
can see and boot the .iso just fine, what could possibly explain it not
seeing grub on the hard drive? Anybody have any more ideas?
--
David C. Rankin, J.D.,P.E.
Rijul Gulati via arch-general
2016-11-07 17:56:22 UTC
Permalink
A quick suggestion : Why not try systemd-boot instead of grub? (Since now
arch is installed in UEFI) No harm trying ;)
Post by David C. Rankin
Post by Simon Brulhart
I may be missing something, but is there a chance that the bios just
doesn't wait long enough for the disk to turn on?
On some laptops this sometimes happen to me when trying to boot an USB
harddisk. The disk isn't detected at all by the bios, but generally
rebooting with the disk already turned on fixes the issue.
I've also seen an option on some BIOSes to wait for a few additional
seconds at boot before enumerating drives, indicating that this may be a
common issue.
Simon
Simon,
Thanks, but no, I eliminated that by choosing the boot options menu
(e.g. F9) on boot which allowed 30 seconds or so as I pondered the
options for the drives to spin up, no it is something quirky with this
laptop that I have to figure out, but I'm totally stuck.
I prepared a fresh summary of my ordeal in hopes of getting some
I need a miracle (or just some good help) to find out why I can boot
from the .iso and "Choose existing OS" just fine, but cannot get this
laptop to find and boot grub otherwise. (UEFI is *completely* disabled
in the BIOS and it boots win10 in Legacy mode fine) I have now exhausted
all that I can figure out based on my decade and a half of Linux use and
https://wiki.archlinux.org/index.php/GRUB
https://wiki.archlinux.org/index.php/EFI_System_Partition
https://wiki.archlinux.org/index.php/HP_EliteBook_840_G1 (uses EFI mode)
# fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xff7d45aa
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 1953525167 1953523120 931.5G 5 Extended
/dev/sda5 * 4096 1028095 1024000 500M 83 Linux
/dev/sda6 1030144 105887743 104857600 50G 83 Linux
/dev/sda7 105889792 1951383551 1845493760 880G 83 Linux
/dev/sda8 1951385600 1953525167 2139568 1G 82 Linux swap / Solaris
grub isn't seen on boot, but popping the .iso on USB in, choosing
"Boot existing OS", hitting 'tab' and changing 'hd0 0' to 'hd1 0' boots
Arch fine.
# fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 00B6A48C-CBDB-4071-A1EC-97FA828A6C26
Device Start End Sectors Size Type
/dev/sda1 2048 4095 2048 1M BIOS boot
/dev/sda2 4096 1028095 1024000 500M Linux filesystem
/dev/sda3 1028096 105885695 104857600 50G Linux filesystem
/dev/sda4 105885696 1949282303 1843396608 879G Linux filesystem
/dev/sda5 1949282304 1951379455 2097152 1G Linux swap
same result, grub not found on its own, but booting from USB works fine.
Next, stranger things being possible, I decided to try a full UEFI
setup thinking maybe the Legacy mode for this laptop uses some contrived
boot scheme that requires the esp partition to be present. so I
# fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 00B6A48C-CBDB-4071-A1EC-97FA828A6C26
Device Start End Sectors Size Type
/dev/sda1 2048 4095 2048 1M BIOS boot
/dev/sda2 4096 1028095 1024000 500M EFI System
/dev/sda3 1028096 105885695 104857600 50G Linux filesystem
/dev/sda4 105885696 1949282303 1843396608 879G Linux filesystem
/dev/sda5 1949282304 1951379455 2097152 1G Linux swap
Still, grub isn't seen on boot, but now "Choose existing OS" starts
grub, but then throws the error of "unrecognized partition type" (I
presume is due to the UEFI setup while UEFI is disabled in the BIOS)
So I'm stuck. This box boots from the iso perfectly. After "Choose
existing OS", I pull the USB drive, and the machine works flawlessly.
(I've got a full plasma/KDE5 setup installed with wpa_supplicant WPA
wifi, bluetooth, synaptics touchpad, ieee-1394, all working just fine,
etc.., e.g. I drafted this on kwrite and sent it via thunderbird from
this same darn box) I just can't get this box to find grub to save my life.
I need help figuring out how the .iso is booting in Legacy mode just
fine, while I can't do the same thing from the hard drive. If this box
can see and boot the .iso just fine, what could possibly explain it not
seeing grub on the hard drive? Anybody have any more ideas?
--
David C. Rankin, J.D.,P.E.
David C. Rankin
2016-11-07 20:07:56 UTC
Permalink
Post by Rijul Gulati via arch-general
A quick suggestion : Why not try systemd-boot instead of grub? (Since now
arch is installed in UEFI) No harm trying ;)
Nothing ventured, nothing gained...

Well, it is now apparent why UEFI is disabled, when enabling it in the
bios, you get a large warning that:

UEFI implementation in this bios is experimental and it is recommended
that you disable 'Disk Lock' (HP drive encryption) and Pre-Boot
Authentication before enabling UEFI.

So, I did. Then tried to boot, and it paused for a minute, moved the
cursor to about mid-screen, and then went though the Legacy boot order
and failed again with Disk Error '0F3' (no operating system found).

So, I stuck the USB back in, booted, chose existing, and I'm up and
running again -- and back to square-one on "Why does this box boot fine
from the .iso, but will not boot from the hard drive?"

Thanks for the suggestion. I'll keep picking away, but if anybody has
any other thoughts or diagnostics to run to help explain this, I would
appreciate it.
--
David C. Rankin, J.D.,P.E.
Rijul Gulati via arch-general
2016-11-07 21:24:50 UTC
Permalink
I cannot say exactly what's causing this issue.

I'd suggest after enabling UEFI from BIOS, try re-installing grub2 and
regenerating grub2.cfg maybe?

If this did not work, try re-creating partitions (that is set ESP on
/dev/sda1 and set boot-flag ON on 1) . Also there is no need for BIOS boot
partition since ESP is already provided. Then install grub and boot?

Also, I see "customised boot" option for UEFI.
https://wiki.archlinux.org/index.php/HP_EliteBook_840_G1
Tried this? (If it's applicable for your system)
Post by David C. Rankin
Post by Rijul Gulati via arch-general
A quick suggestion : Why not try systemd-boot instead of grub? (Since
now
Post by Rijul Gulati via arch-general
arch is installed in UEFI) No harm trying ;)
Nothing ventured, nothing gained...
Well, it is now apparent why UEFI is disabled, when enabling it in the
UEFI implementation in this bios is experimental and it is recommended
that you disable 'Disk Lock' (HP drive encryption) and Pre-Boot
Authentication before enabling UEFI.
So, I did. Then tried to boot, and it paused for a minute, moved the
cursor to about mid-screen, and then went though the Legacy boot order
and failed again with Disk Error '0F3' (no operating system found).
So, I stuck the USB back in, booted, chose existing, and I'm up and
running again -- and back to square-one on "Why does this box boot fine
from the .iso, but will not boot from the hard drive?"
Thanks for the suggestion. I'll keep picking away, but if anybody has
any other thoughts or diagnostics to run to help explain this, I would
appreciate it.
--
David C. Rankin, J.D.,P.E.
David C. Rankin
2016-11-07 22:43:35 UTC
Permalink
Post by Rijul Gulati via arch-general
Also, I see "customised boot" option for UEFI.
https://wiki.archlinux.org/index.php/HP_EliteBook_840_G1
Tried this? (If it's applicable for your system)
Thanks Rijul,

I've been though the page several times. The setup itself wasn't
applicable to the 8760w as all UEFI was disabled (it was experimental
only from HP in my model laptop) so there are no paths in bootmgr, etc.
I may try and configure it that way, but with all UEFI disabled, there
is something else (probably simple) that is causing this to fail.

The bewildering part of this whole problem is "How the hell is the
.iso booting so easily, while I can't do the same thing from the hard
drive?" Especially since simply choosing to boot from the .iso works
flawlessly.

Everybody gets one of these issues every once in a while, this one is
mine -- and it's a doozie...
--
David C. Rankin, J.D.,P.E.
David C. Rankin
2016-12-31 09:14:32 UTC
Permalink
Post by David C. Rankin
Simon,
Thanks, but no, I eliminated that by choosing the boot options menu
(e.g. F9) on boot which allowed 30 seconds or so as I pondered the
options for the drives to spin up, no it is something quirky with this
laptop that I have to figure out, but I'm totally stuck.
I prepared a fresh summary of my ordeal in hopes of getting some
I need a miracle (or just some good help) to find out why I can boot
from the .iso and "Choose existing OS" just fine, but cannot get this
laptop to find and boot grub otherwise. (UEFI is *completely* disabled
in the BIOS and it boots win10 in Legacy mode fine) I have now exhausted
all that I can figure out based on my decade and a half of Linux use and
https://wiki.archlinux.org/index.php/GRUB
https://wiki.archlinux.org/index.php/EFI_System_Partition
https://wiki.archlinux.org/index.php/HP_EliteBook_840_G1 (uses EFI mode)
# fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xff7d45aa
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 1953525167 1953523120 931.5G 5 Extended
/dev/sda5 * 4096 1028095 1024000 500M 83 Linux
/dev/sda6 1030144 105887743 104857600 50G 83 Linux
/dev/sda7 105889792 1951383551 1845493760 880G 83 Linux
/dev/sda8 1951385600 1953525167 2139568 1G 82 Linux swap / Solaris
grub isn't seen on boot, but popping the .iso on USB in, choosing
"Boot existing OS", hitting 'tab' and changing 'hd0 0' to 'hd1 0' boots
Arch fine.
# fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 00B6A48C-CBDB-4071-A1EC-97FA828A6C26
Device Start End Sectors Size Type
/dev/sda1 2048 4095 2048 1M BIOS boot
/dev/sda2 4096 1028095 1024000 500M Linux filesystem
/dev/sda3 1028096 105885695 104857600 50G Linux filesystem
/dev/sda4 105885696 1949282303 1843396608 879G Linux filesystem
/dev/sda5 1949282304 1951379455 2097152 1G Linux swap
same result, grub not found on its own, but booting from USB works fine.
Next, stranger things being possible, I decided to try a full UEFI
setup thinking maybe the Legacy mode for this laptop uses some contrived
boot scheme that requires the esp partition to be present. so I
# fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 00B6A48C-CBDB-4071-A1EC-97FA828A6C26
Device Start End Sectors Size Type
/dev/sda1 2048 4095 2048 1M BIOS boot
/dev/sda2 4096 1028095 1024000 500M EFI System
/dev/sda3 1028096 105885695 104857600 50G Linux filesystem
/dev/sda4 105885696 1949282303 1843396608 879G Linux filesystem
/dev/sda5 1949282304 1951379455 2097152 1G Linux swap
Still, grub isn't seen on boot, but now "Choose existing OS" starts
grub, but then throws the error of "unrecognized partition type" (I
presume is due to the UEFI setup while UEFI is disabled in the BIOS)
So I'm stuck. This box boots from the iso perfectly. After "Choose
existing OS", I pull the USB drive, and the machine works flawlessly.
(I've got a full plasma/KDE5 setup installed with wpa_supplicant WPA
wifi, bluetooth, synaptics touchpad, ieee-1394, all working just fine,
etc.., e.g. I drafted this on kwrite and sent it via thunderbird from
this same darn box) I just can't get this box to find grub to save my life.
I need help figuring out how the .iso is booting in Legacy mode just
fine, while I can't do the same thing from the hard drive. If this box
can see and boot the .iso just fine, what could possibly explain it not
seeing grub on the hard drive? Anybody have any more ideas?
Sorry to bump this old thread, but I've done a bit of additional testing and I
need help to understand why Arch did not install required information
beginning at byte 3 of the NEWLDR MBR. A subsequent install of openSuSE (Leap
42.2) on the same box disclosed the differences in the MBR content for regions
of NEWLDR signature, LOADER physical drive and boot flag, CHS address of
LOADER, etc... throughout the initial 64 bytes of the MBR. This is what left
the laptop unable to boot Arch.

Specifically, the mbr installed by Arch using:

# grub-install --target=i386-pc /dev/sda
# grub-mkconfig -o /boot/grub/grub.cfg

is:

00000000 eb 63 90 00 00 00 00 00 00 00 00 00 00 00 00 00 |.c..............|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 80 01 00 00 00 |................|
00000060 00 00 00 00 ff fa 90 90 f6 c2 80 74 05 f6 c2 70 |...........t...p|
00000070 74 02 b2 80 ea 79 7c 00 00 31 c0 8e d8 8e d0 bc |t....y|..1......|
00000080 00 20 fb a0 64 7c 3c ff 74 02 88 c2 52 be 80 7d |. ..d|<.t...R..}|
00000090 e8 17 01 be 05 7c b4 41 bb aa 55 cd 13 5a 52 72 |.....|.A..U..ZRr|
000000a0 3d 81 fb 55 aa 75 37 83 e1 01 74 32 31 c0 89 44 |=..U.u7...t21..D|
000000b0 04 40 88 44 ff 89 44 02 c7 04 10 00 66 8b 1e 5c |***@.D..D.....f..\|
000000c0 7c 66 89 5c 08 66 8b 1e 60 7c 66 89 5c 0c c7 44 ||f.\.f..`|f.\..D|
000000d0 06 00 70 b4 42 cd 13 72 05 bb 00 70 eb 76 b4 08 |..p.B..r...p.v..|
000000e0 cd 13 73 0d 5a 84 d2 0f 83 d8 00 be 8b 7d e9 82 |..s.Z........}..|
000000f0 00 66 0f b6 c6 88 64 ff 40 66 89 44 04 0f b6 d1 |***@f.D....|
00000100 c1 e2 02 88 e8 88 f4 40 89 44 08 0f b6 c2 c0 e8 |***@.D......|
00000110 02 66 89 04 66 a1 60 7c 66 09 c0 75 4e 66 a1 5c |.f..f.`|f..uNf.\|
00000120 7c 66 31 d2 66 f7 34 88 d1 31 d2 66 f7 74 04 3b ||f1.f.4..1.f.t.;|
00000130 44 08 7d 37 fe c1 88 c5 30 c0 c1 e8 02 08 c1 88 |D.}7....0.......|
00000140 d0 5a 88 c6 bb 00 70 8e c3 31 db b8 01 02 cd 13 |.Z....p..1......|
00000150 72 1e 8c c3 60 1e b9 00 01 8e db 31 f6 bf 00 80 |r...`......1....|
00000160 8e c6 fc f3 a5 1f 61 ff 26 5a 7c be 86 7d eb 03 |......a.&Z|..}..|
00000170 be 95 7d e8 34 00 be 9a 7d e8 2e 00 cd 18 eb fe |..}.4...}.......|
00000180 47 52 55 42 20 00 47 65 6f 6d 00 48 61 72 64 20 |GRUB .Geom.Hard |
00000190 44 69 73 6b 00 52 65 61 64 00 20 45 72 72 6f 72 |Disk.Read. Error|
000001a0 0d 0a 00 bb 01 00 b4 0e cd 10 ac 3c 00 75 f4 c3 |...........<.u..|
000001b0 00 00 00 00 00 00 00 00 aa 45 7d ff 00 00 |.........E}...|
000001be

The one installed by openSuSE using the same commands is virtually identical
in all aspects, except for bytes 3 - 63 (zero-based). For some reason when
used with Arch, the grub-install failed to include bytes 3-63 in the mbr. Why?

00000000 eb 63 90 10 8e d0 bc 00 b0 b8 00 00 8e d8 8e c0 |.c..............|
00000010 fb be 00 7c bf 00 06 b9 00 02 f3 a4 ea 21 06 00 |...|.........!..|
00000020 00 be be 07 38 04 75 0b 83 c6 10 81 fe fe 07 75 |....8.u........u|
00000030 f3 eb 16 b4 02 b0 01 bb 00 7c b2 80 8a 74 01 8b |.........|...t..|
00000040 4c 02 cd 13 ea 00 7c 00 00 eb fe 00 00 00 00 00 |L.....|.........|
00000050 00 00 00 00 00 00 00 00 00 00 00 80 01 00 00 00 |................|
00000060 00 00 00 00 ff fa 90 90 f6 c2 80 74 05 f6 c2 70 |...........t...p|
00000070 74 02 b2 80 ea 79 7c 00 00 31 c0 8e d8 8e d0 bc |t....y|..1......|
00000080 00 20 fb a0 64 7c 3c ff 74 02 88 c2 52 be 80 7d |. ..d|<.t...R..}|
00000090 e8 17 01 be 05 7c b4 41 bb aa 55 cd 13 5a 52 72 |.....|.A..U..ZRr|
000000a0 3d 81 fb 55 aa 75 37 83 e1 01 74 32 31 c0 89 44 |=..U.u7...t21..D|
000000b0 04 40 88 44 ff 89 44 02 c7 04 10 00 66 8b 1e 5c |***@.D..D.....f..\|
000000c0 7c 66 89 5c 08 66 8b 1e 60 7c 66 89 5c 0c c7 44 ||f.\.f..`|f.\..D|
000000d0 06 00 70 b4 42 cd 13 72 05 bb 00 70 eb 76 b4 08 |..p.B..r...p.v..|
000000e0 cd 13 73 0d 5a 84 d2 0f 83 d8 00 be 8b 7d e9 82 |..s.Z........}..|
000000f0 00 66 0f b6 c6 88 64 ff 40 66 89 44 04 0f b6 d1 |***@f.D....|
00000100 c1 e2 02 88 e8 88 f4 40 89 44 08 0f b6 c2 c0 e8 |***@.D......|
00000110 02 66 89 04 66 a1 60 7c 66 09 c0 75 4e 66 a1 5c |.f..f.`|f..uNf.\|
00000120 7c 66 31 d2 66 f7 34 88 d1 31 d2 66 f7 74 04 3b ||f1.f.4..1.f.t.;|
00000130 44 08 7d 37 fe c1 88 c5 30 c0 c1 e8 02 08 c1 88 |D.}7....0.......|
00000140 d0 5a 88 c6 bb 00 70 8e c3 31 db b8 01 02 cd 13 |.Z....p..1......|
00000150 72 1e 8c c3 60 1e b9 00 01 8e db 31 f6 bf 00 80 |r...`......1....|
00000160 8e c6 fc f3 a5 1f 61 ff 26 5a 7c be 86 7d eb 03 |......a.&Z|..}..|
00000170 be 95 7d e8 34 00 be 9a 7d e8 2e 00 cd 18 eb fe |..}.4...}.......|
00000180 47 52 55 42 20 00 47 65 6f 6d 00 48 61 72 64 20 |GRUB .Geom.Hard |
00000190 44 69 73 6b 00 52 65 61 64 00 20 45 72 72 6f 72 |Disk.Read. Error|
000001a0 0d 0a 00 bb 01 00 b4 0e cd 10 ac 3c 00 75 f4 c3 |...........<.u..|
000001b0 00 00 00 00 00 00 00 00 e3 15 05 00 00 00 |..............|
000001be

Does anybody have any idea why on this HP laptop, Arch would not write those
61 bytes to the mbr while using the same approach on suse would? Granted Leap
42.2 on suse is running the 4.4.36 kernel but also runs grub2-2.02~beta2 while
Arch has 2.02.beta3. I can't find anything there that points to a difference,
but after installing the boot loader to mbr multiple times with Arch, I can
confirm that it is zeroing the needed bytes 3-63 in the mbr. What/where else
to check?
--
David C. Rankin, J.D.,P.E.
David C. Rankin
2016-11-08 22:37:13 UTC
Permalink
Post by Patrick Burroughs (Celti)
I suggest you double-check the partitioning and possible presence of
an EFI system partition on that Windows drive from within your Arch
install. If both msinfo and the partitioning confirm it's not UEFI,
then I suggest you a) make sure the firmware is up-to-date, and b)
comb through the firmware settings and make sure that it's fully in
Legacy/BIOS mode and not Hybrid UEFI/BIOS mode; the latter is the
cause of most such problems, in my experience.
~Celti
Celti,

There isn't anything in /sys/firmware. Here is the current contents:

$ l /sys/firmware/
total 0
drwxr-xr-x 5 root root 0 Nov 8 04:53 .
dr-xr-xr-x 13 root root 0 Nov 7 14:00 ..
drwxr-xr-x 5 root root 0 Nov 8 04:53 acpi
drwxr-xr-x 3 root root 0 Nov 8 04:53 dmi
drwxr-xr-x 19 root root 0 Nov 8 04:53 memmap

Latest and greatest firmware:

$ pmq | grep firmware
linux-firmware 20161005.9c71af9-1

That matches the bios config of having only the Legacy boot enabled
and the UEFI mode completely disabled. This is downright baffling. I'm
writing this from tbird in plasma/kde installed on the 1T drive that is
working flawlessly -- the only issue is I have to boot from the .iso on
the USB and then "Choose existing OS" to boot this install on the hard
drive.

Totally bewildered. I don't see how Syslinux on the USB works and grub
is just being ignored on the hard drive. All windows has on it is the normal

bootmgr
BOOTNXT
BOOTSECT.BAK
BOOTBCD
BOOTSTAT.DAT
bootvhd.dll
en-us
bootmgr.exe.mui
memtest.ext.mui

I don't know if that tells you anything, but there is no efi folder
referenced by
https://msdn.microsoft.com/en-us/windows/hardware/commercialize/manufacture/desktop/boot-to-uefi-mode-or-legacy-bios-mode
and there is a bootmgr file which is used by Legacy MBR booting. So from
all indications, the windows drive is using nothing but good old MBR
booting.

There were a couple of threads I found discussing problems seeing the
larger SSD drives. I wonder if the size of the sata drive is causing the
problem itself. (that really makes no sense as I've not encountered any
reasonably recent bios that will not recognize a 1T drive -- but I'm
grasping at straws here)

Anybody have any other suggestions? Try syslinux for boot? Worst case,
I just keep booting from the USB, but that seems kind of whacky in 2016...
--
David C. Rankin, J.D.,P.E.
jeff.rollin via arch-general
2016-10-29 07:29:07 UTC
Permalink
AFAIK it needn't be the first one on the disk - if memory serves, my Linux laptop came with Windows installed and the UEFI boot partition on the second partition, and the first first few Linux-only installed kept that layout - but it must be VFAT and it must be flagged bootable. 

Sent from Samsung Mobile on O2
-------- Original message --------From: Juan Carlos Villegas Botero via arch-general <arch-***@archlinux.org> Date: 29/10/2016 05:03 (GMT+00:00) To: General Discussion about Arch Linux <arch-***@archlinux.org> Cc: Juan Carlos Villegas Botero <***@gmail.com> Subject: Re: [arch-general] Single Drive Fresh Install (mbr/grub2) Fails to boot (can boot existing from .iso??)
And I also think that I read somewhere that theboot partition (EFI) must
be the first one in the disk.
Post by Juan Carlos Villegas Botero via arch-general
Sorry for the html response :S
Post by Juan Carlos Villegas Botero via arch-general
I'm not 100% sure that this is the solution, but if you are loading
https://wiki.archlinux.org/index.php/EFI_System_Partition
All,
    After 7 years and 30+ installs, I thought I had seen it all. I have a new
(used) laptop, that I put a fresh 1T drive in, partitioned and loaded arch. The
laptop can't find the drive to boot? Huh? There is only a single drive in the
laptop, but it will only boot if booting from grub hd1 (instead of hd0).
    The failure isn't a "grub prefix/root" problem, the problem is the laptop
cannot even find grub to begin with when it is booting on it's own. The only way
booting happens is to boot the installer (from USB) and then "Choose existing
OS" and edit the prefix (from 0 -> 1). Which itself is wonky, because booting
from USB creates the USB thumb-drive as /dev/sdb to begin with and the hard
drive as /dev/sda where it should be.
    This is a strange laptop, it has 2 hard drive bays (HP Elite 8760w). The bios
is configured to scan both (as well as USB and PXE) for boot. I can boot the
install .iso without issue, install went fine, but in order to boot the new
install, I have to "Boot existing OS" from the .iso menu, then 'tab' and change
    hd0 0
to
    hd1 0
(I took the existing Win10 SSD out of the same bay I put this drive in - which
is also a simple mbr boot - no UEFI). The setup is dead simple (.iso is sdb below)
$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sdb      8:16   1   980M  0 disk
├─sdb2   8:18   1    40M  0 part
└─sdb1   8:17   1   792M  0 part
sr0     11:0    1  1024M  0 rom
sda      8:0    0 931.5G  0 disk
├─sda7   8:7    0   880G  0 part /home
├─sda5   8:5    0   500M  0 part /boot
├─sda1   8:1    0     1K  0 part
├─sda8   8:8    0     1G  0 part
└─sda6   8:6    0    50G  0 part /
and
$ sudo fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xff7d45aa
Device     Boot      Start        End    Sectors   Size Id Type
/dev/sda1             2048 1953525167 1953523120 931.5G  5 Extended
/dev/sda5  *          4096    1028095    1024000   500M 83 Linux
/dev/sda6          1030144  105887743  104857600    50G 83 Linux
/dev/sda7        105889792 1951383551 1845493760   880G 83 Linux
/dev/sda8       1951385600 1953525167    2139568     1G 82 Linux swap / Solaris
grub is installed to /dev/sda with
grub-install --target=i386-pc /dev/sda  (no errors on install), and
grub-mkconfig -o /boot/grub/grub.cfg
    I've searched for anything related to HP laptops or this model, but only find
issues failing to boot the install CD or the newer UEFI pages like
https://wiki.archlinux.org/index.php/HP_EliteBook_840_G1.
    Has anyone encountered something similar? There is no longer a
/boot/grub/device.map file installed by grub2, but given the fact the bios isn't
seeing the drive at all for boot, I don't see how mapping hd0 to hd1 would make
a difference. Does anyone have a link or any idea what the issue may be? I'm
happy to send whatever additional information may be required. I'm ssh'ed into
the box right now, I just need to get the boot and plasma ironed out. Any ideas?
Thanks.
Continue reading on narkive:
Loading...