You are not logged in.
Hello everyone,
I am going to try and be precise about the kind of problem I seem to have, but I am not even sure myself...
I bought an HP 8460p laptop and want to run Arch on it. My first attempt was to put my Arch-loaded SSD which I use in my regular laptop every day into that machine:
sudo parted -l
Modell: ATA Samsung SSD 840 (scsi)
Festplatte /dev/sda: 256GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: msdos
Disk-Flags:
Nummer Anfang Ende Größe Typ Dateisystem Flags
1 1049kB 267MB 266MB primary ext2
2 267MB 230GB 230GB primarySurprisingly, it does NOT boot. Instead, I get a BIOS-Message stating I should install an operating system. The error code is 3F0, which, when you google it, returns lots of results of frustrated Windows-Users assuming they experienced a hard drive failure and HP support people encouraging them to replace it. Although obviously, this is just not the case. By the way, I could reproduce the behaviour with another hard drive. Boots fine in my X200 tablet; won't boot on the HP.
Now what surprised me was that live images boot up just fine. I had a spare Ubuntu live CD that's ok. Also Arch and Ubuntu images on SD cards to the trick. So I figured, the reason might be that they support UEFI boot, which my MBR partitioning scheme does not.
NOTE: Unlike newer BIOSes which offer a legacy boot mode, the HP 8460p BIOS offers a UEFI boot mode that is marked experimental. So the usual way to boot up would be to execute the MBR. I thus tried the following: Activated the experimental feature for UEFI boot, dd'd the Arch Image to my internal disk and... it boots! My conclusion was that executing the MBR from SATA drives was for some reason broken.
I then did a lot of reading on how to properly install GRUB for UEFI machines and then came across the efivars, which should be available in a virtual file system after loading the respective kernel module - which I could not load. Another research session made clear that obviously, if you can't load the module, then you did not boot in UEFI mode (especially, since, in the live image, support is compiled into the kernel).
In order to be REALLY sure I was not on UEFI, I purposefully corrupted the boot sector on the arch image that would boot up fine:
sudo dd if=/dev/zero of=/dev/sdb bs=100 count=1...and it did not boot anymore (3F0), so it must have been reading the MBR all the time. I then figured I could have just turned off experimental UEFI support in BIOS and see if it would boot then - which it did (of course with a proper MBR). Another indicator the BIOS never actually did an UEFI boot.
So at this point I realized that there has got to be SOMETHING about live CD images that makes them boot on my machine, but I just can't figure out what it is. My plan was to mimic the partition/boot-up scheme on the live image and then just build my installation on top of that. The results of inspecting an image are as follows:
Fdisk says:
sudo fdisk -l
Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 0 1202175 1202176 587M 0 Empty
/dev/sdb2 252 63739 63488 31M ef EFI (FAT-12/16/32)So obviously, the live image's contents are in that (seemingly) empty partition, which is an iso-9660-image, the partitioning scheme is msdos and the boot loader is on the 31MB-EFI-partition. I now backed up the sdb2-partition, created a new msdos partition table on the disk, then a 31MB partition and then re-dd'd the backed up partition to the newly created one - hoping that it would reach grub and I could use the rest of my disk as I wish. However, it did not boot. I tried to set the flags {boot,esp} and {esp} respectively, but neither succeeds.
This is where I'm stuck. I'd be happy if anyone could give me advice as to how a live image boots and how I can take advantage from this for my purposes of simply booting up my system from the MBR of my hard drive.
Thanks in advance!
Last edited by archery1234 (2015-01-08 07:53:37)
Offline
I'm beginning to think I'm doing some sort of public mind sorting, but it seems to help. I actually found the solution. Wikipedia states:
Popular MBR code programs were created for booting PC DOS and MS-DOS, and similar boot code remains in wide use. These boot sectors expect the fdisk partition table scheme to be in use, and scans the list of partitions in the MBR's embedded partition table to find the only one that is marked with the active flag.[25] It then loads and runs the volume boot record (VBR) of the active partition.
None of the disks I tried to boot had the active flag set, yet my Thinkpad would boot them properly. Once I added the boot flag to my SSD an put it into the HP Laptop, it would boot, too. This defeats the assumption that the BIOS gives ultimate control to the code in the MBR. If this was the case, the hard drive would have had to boot on either none or both of the machines. I have no idea, though, in which way the BIOS of the HP could possibly interfere. Or maybe it does not interfer at all and my Thinkpad BIOS does, enabling the MBR to boot a boot-marked partition... whatever - it works.
Offline