[arch-general] Single Drive Fresh Install (mbr/grub2) Fails to boot (can boot existing from .iso??)
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.
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.
-- photo *Juan Carlos Villegas Botero* Director de Desarrollo, Micoworker juancarlos@micoworker.com mailto:juancarlos@micoworker.com (+57) 312 3977780 tel:%28+57%29%20312%203977780 www.micoworker.com http://www.micoworker.com Skype: juankvillegas <#>
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.
And I also think that I read somewhere that theboot partition (EFI) must be the first one in the disk. On 10/28/2016 10:59 PM, Juan Carlos Villegas Botero wrote:
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 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)?
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.
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: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, 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 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.
-- Death of ROXTerm https://sourceforge.net/p/roxterm/discussion/422638/thread/60da6975/
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 On 10/29/2016 6:16 AM, Ralf Mardorf wrote:
On Sat, 29 Oct 2016 13:01:42 +0200, Ralf Mardorf 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,
On Sat, 29 Oct 2016 05:48:29 -0500, David C. Rankin wrote: 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 06:24:52 -0500
kendell clark via arch-general
I do get past the grub screen
Meaning it's not the same issue at all. Don't hijack threads.
On Sat, 29 Oct 2016 05:48:29 -0500
"David C. Rankin"
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... -- David C. Rankin, J.D.,P.E.
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? -- David C. Rankin, J.D.,P.E.
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?
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
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? -- David C. Rankin, J.D.,P.E.
A quick suggestion : Why not try systemd-boot instead of grub? (Since now
arch is installed in UEFI) No harm trying ;)
On Mon 7 Nov, 2016, 23:05 David C. Rankin,
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?
-- David C. Rankin, J.D.,P.E.
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. -- David C. Rankin, J.D.,P.E.
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)
On Tue 8 Nov, 2016, 01:38 David C. Rankin,
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.
-- David C. Rankin, J.D.,P.E.
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... -- David C. Rankin, J.D.,P.E.
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? -- David C. Rankin, J.D.,P.E.
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
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/... 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.
participants (10)
-
David C. Rankin
-
Doug Newgard
-
Juan Carlos Villegas Botero
-
kendell clark
-
Patrick Burroughs (Celti)
-
Ralf Mardorf
-
Rijul Gulati
-
Simon Brulhart
-
Uwe
-
Uwe Hametner