Sorry for the html response :S

On 10/28/2016 10:58 PM, Juan Carlos Villegas Botero wrote:

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

On 10/28/2016 09:58 PM, David C. Rankin wrote:

...

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.

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

On Sat, 29 Oct 2016 05:48:29 -0500, David C. Rankin wrote:

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

On Sat, 29 Oct 2016 13:16:06 +0200, Ralf Mardorf wrote:

On Sat, 29 Oct 2016 13:01:42 +0200, Ralf Mardorf wrote:

...

On Sat, 29 Oct 2016 05:48:29 -0500, David C. Rankin wrote:

...

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 ;),

...

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.

On Sat, 29 Oct 2016 05:48:29 -0500 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:

On 10/29/2016 01:18 AM, Uwe via arch-general wrote:

...

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 out, or the new Arch disk I put it. I checked in windows with:

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.

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.

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

On 10/29/2016 06:30 AM, Patrick Burroughs (Celti) wrote:

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...

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.

Am Donnerstag, den 03.11.2016, 02:45 -0500 schrieb David C. Rankin:

On 10/30/2016 1:34 AM, David C. Rankin wrote:

...

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?

On 11/05/2016 04:38 AM, Simon Brulhart wrote:

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?

On 11/07/2016 11:56 AM, Rijul Gulati via arch-general wrote:

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.

On 11/07/2016 03:24 PM, Rijul Gulati via arch-general wrote:

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...

On 11/07/2016 11:34 AM, David C. Rankin wrote:

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?

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.@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.@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?