Solved Error loading operating system

[balanga]

This is on a ThinkPad X220:-

gpart show da1:-

=>       40  250069600  da1  GPT  (119G)
         40       1024    1  freebsd-boot  (512K)
       1064   20971520    2  freebsd-ufs  (10G)
   20972584  229097056       - free -  (109G)

gpart set -a lenovofix da1
bootcode -b /boot/pmbr -p /boot/gptboot -i 1 da1

lenovofix set on da1
partcode written to da1p1
bootcode written to da1

On bootup I get Error loading operating system.

Where does this msg come from? Is there something within freebsd-boot or the gpt boot partition and can I reinitialise these areas while leaving /dev/da1p2 in place

 

[SirDice]

Where does this msg come from?

That looks like a BIOS message.

can I reinitialise these areas while leaving /dev/da1p2 in place

Yes, just run that gpart bootcode command again.

 

[_martin]

On a contrary: $ find /usr/src/ -type f -exec grep -Hi "Error loading operating system" {} \;

./stand/i386/mbr/mbr.s:msg_rd:     .asciz "Error loading operating system"

It seems to be a mbr code. Can you share your hexdump -C -n 512 /dev/da1 ?

 

[balanga]

Can you share your hexdump -C -n 512 /dev/da1 ?

Here it is: (actually /dev/da0)

00000000  fc 31 c0 8e c0 8e d8 8e  d0 bc 00 7c be 1a 7c bf  |.1.........|..|.|
00000010  1a 06 b9 e6 01 f3 a4 e9  00 8a 31 f6 bb be 07 b1  |..........1.....|
00000020  04 38 2f 74 08 7f 75 85  f6 75 71 89 de 80 c3 10  |.8/t..u..uq.....|
00000030  e2 ef 85 f6 75 02 cd 18  80 fa 80 72 0b 8a 36 75  |....u......r..6u|
00000040  04 80 c6 80 38 f2 72 02  8a 14 89 e7 8a 74 01 8b  |....8.r......t..|
00000050  4c 02 bb 00 7c f6 06 bd  07 80 74 2d 51 53 bb aa  |L...|.....t-QS..|
00000060  55 b4 41 cd 13 72 20 81  fb 55 aa 75 1a f6 c1 01  |U.A..r ..U.u....|
00000070  74 15 5b 66 6a 00 66 ff  74 08 06 53 6a 01 6a 10  |t.[fj.f.t..Sj.j.|
00000080  89 e6 b8 00 42 eb 05 5b  59 b8 01 02 cd 13 89 fc  |....B..[Y.......|
00000090  72 0f 81 bf fe 01 55 aa  75 0c ff e3 be b9 06 eb  |r.....U.u.......|
000000a0  11 be d1 06 eb 0c be f0  06 eb 07 bb 07 00 b4 0e  |................|
000000b0  cd 10 ac 84 c0 75 f4 eb  fe 49 6e 76 61 6c 69 64  |.....u...Invalid|
000000c0  20 70 61 72 74 69 74 69  6f 6e 20 74 61 62 6c 65  | partition table|
000000d0  00 45 72 72 6f 72 20 6c  6f 61 64 69 6e 67 20 6f  |.Error loading o|
000000e0  70 65 72 61 74 69 6e 67  20 73 79 73 74 65 6d 00  |perating system.|
000000f0  4d 69 73 73 69 6e 67 20  6f 70 65 72 61 74 69 6e  |Missing operatin|
00000100  67 20 73 79 73 74 65 6d  00 90 90 90 90 90 90 90  |g system........|
00000110  90 90 90 90 90 90 90 90  90 90 90 90 90 90 90 90  |................|
*
000001b0  90 90 90 90 90 90 90 90  90 90 90 90 90 80 00 00  |................|
000001c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001d0  02 00 ee ff ff ff 01 00  00 00 af c2 e7 0e 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|

 

[zirias@]

It seems to be a mbr code. Can you share your hexdump -C -n 512 /dev/da1 ?

Well, the code in the MBR seems fine if it can print the message. But just maybe, writing bootcode restores (erroneously) the standard "protective MBR" partition table? If so, setting lenovofix after writing the bootcode could be the solution.

edit: ok, the hexdump proves otherwise, this is the "modified" protective MBR.

 

[_martin]

It almost seems you have weird mbr code - half MBR and half pMBR.
At least the offset at 0x1be indicates it's a fake partition (that's good). Note you are in GPT scheme, you don't need to set anything to active (that is a MBR prerequisite).

What is the FreeBSD version you're using (including architecture) ? Can you also paste the hd of the /boot/pmbr you're using ?

 

[zirias@]

It almost seems you have weird mbr code - half MBR and half pMBR.

The only thing "weird" here is that the protective partition starts at 0x1ce instead of 0x1be, which is exactly the effect of lenovofix.

GPT is fully backwards compatible to classic MBR. When booting with UEFI, you don't need any bootcode in the MBR, but if you want "legacy BIOS" boot, you of course need it. The hexdump shows exactly what's expected.

 

[balanga]

root@S05:~ # uname -a
FreeBSD S05 12.2-RELEASE-p4 FreeBSD 12.2-RELEASE-p4 GENERIC amd64

I have two disks, I'm actually booting from an MBR disk, and trying to get the GPT disk working.

Not sure what you are asking for here:-

Can you also paste the hd of the /boot/pmbr you're using ?

 

[SirDice]

hd(1) aka hexdump(1), UNIX people love short commands

 

[_martin]

Are the FreeBSD versions the same on both disks ? I don't know how gpart behaves internally but it seemed like it pushed the /boot/mbr and then overwrote the partition part definition with the proper fake GPT entry. So you have a mix.

Zirias: In MBR partition table start at fix offset, this is not optional. By definition it is 0x1be (446)

edit: Oh yes, hd is a fancy alias for hexdump -C.

 

[zirias@]

Zirias: In MBR partition table start at fix offset, this is not optional. By definition it is 0x1be (446)

And it DOES start there. It just happens the first entry is empty, and the second entry (at 0x1ce) contains the fake "protective partition". Again: this is exactly the effect of lenovofix, as documented in gpart(8).

I don't know how gpart behaves internally but it seemed like it pushed the /boot/mbr and then overwrote the partition part definition with the proper fake GPT entry.

No. /boot/pmbr contains an all-zero partition table. gpart(8) did exactly the documented thing here. I have no idea what causes the problem for the OP, but it's definitely not the contents of the MBR.

 

[_martin]

Zirias Ok. I understood it like the partition table starts at different offset, you meant the fake partition is different (part2).

I still think the bootcode is not correct. That's why there is the mbr and pmbr in the first place.
I suggest you try this:

I'd boot to the OS you're booting now. You mixed the da0 and da1, I'm assuming the name is changing during reboots. Once booted check the /boot/pmbr as I said. Make sure which disk is a GPT disk. For this example I'll use da0.
Do a backup, just in case:

• dd if=/dev/da0 of=da0_mbr_backup bs=512 count=1
• overwrite the mbr partially: dd if=/boot/pmbr of=/dev/da0 bs=1 count=432
• reboot

 

[zirias@]

I still think the bootcode is not correct. That's why there is the mbr and pmbr in the first place.

No, they are essentially misnomers. Both images have an empty partition table. gpart bootcode only installs the actual code and leaves the partition table alone. The difference is in the code itself. /boot/mbr looks for an active partition in the MBR partition table, /boot/pmbr looks for a GPT partition of type freebsd-boot. So, if you use GPT, you always install /boot/pmbr.

The contents of the MBR are not the problem here. PLEASE don't start tricky stuff with dd yourself (and btw, your suggested commands don't work, you can't read or write partial sectors with dd). gpart bootcode does the correct thing.

 

[_martin]

I don't know what's happening in balanga 's case for sure, I shared my opinion and steps that I'd take if I'd see the error. It's gut feeling, but that's about it.

I only wrote bootloader that boots off the MBR scheme before so I can't be sure 100%. I'm not up to checking the assembly code this late at night .
My reasoning: MBR scheme finds active partition, loads the first sector and jumps to it.
In GPT there's GPT header in LBA1 followed by the partition entries. I'm assuming pmbr code has to do at least some sort of parsing of these entries and hence code has to be different.

 

[zirias@]

I'm assuming pmbr code has to do at least some sort of parsing of these entries and hence code has to be different.

That's what I'm saying. The only difference is the code itself. Or, in other words, the only thing that could be wrong with OPs MBR is if he accidentally installed /boot/mbr instead of /boot/pmbr.

Of course, THIS is possible, I can't check the machine code from a hexdump either

But then, the way to fix this is not fiddling with dd (I'd consider this pretty dangerous!). The way to fix this is simply

gpart bootcode -b /boot/pmbr da1

So, basically where we were at the very beginning of this thread

 

[_martin]

Right, the partial write won't work on the actual disks -- that's true (I'm too much used to write to fake files loaded with mdconfig I didn't realized this). Still doable to prep the 512b file and push it there though.

That's why I did ask about the hd of /boot/pmbr in the beginning, it seems wrong. balanga did say he used gpart command to push /boot/pmbr though. So if he didn't do a mistake it's weird why mbr code is there. Maybe a disk mixup ? (da1 vs da0?)

 

[zirias@]

So if he didn't do a mistake it's weird why mbr code is there.

I still don't get what you mean? I can't tell whether this is code to find an active MBR partition or a freebsd-boot GPT partition. It should be the latter of course, and that's the code contained in /boot/pmbr…

What CAN be seen from the hexdump is that this is indeed a "correct" (with lenovofix) "protective MBR" partition table. So if the code is the one from /boot/mbr, it's just "human error". Fix it with a simple gpart bootcode command

 

[_martin]

Even by doing a kind of stupid side by side comparison with hd /boot/mbr /boot/pmbr and checking the error messages in it it seems like a mbr code.
I guess we need to see the contents of the pmbr, execute gpart bootcode -b /boot/pmbr daX and check it again with hd.

Lenovo fix with the fake partition is there already, so it's OK.

 

[zirias@]

Even by doing a kind of stupid side by side comparison with hd /boot/mbr /boot/pmbr and checking the error messages in it it seems like a mbr code.

Ah sure, didn't think of that although it's pretty obvious, as this max 446 bytes code probably doesn't change much. Indeed, it looks like the code in OP's MBR is the one to boot with MBR partitioning (IOW, the one from /boot/mbr).

I guess we need to see the contents of the pmbr, execute gpart bootcode -b /boot/pmbr daX and check it again with hd.

Probably not, cause, seriously, gpart bootcode does the correct thing. So, code from /boot/mbr in OP's MBR means he gave that file accidentally. Then it's an easy fix

 

[_martin]

Yeah, that's why I said it seems like a mix mbr/pMBR. Fake partition is there, it's just the code that doesn't fit. As balanga shared he did execute the command already I instinctively chose tool close to my heart - dd (next to bvi).
We'll see then. ;-)

 

[zirias@]

Yeah, that's why I said it seems like a mix mbr/pMBR. Fake partition is there, it's just the code that doesn't fit.

I think this whole misunderstanding indeed stems from this unfortunate misnomer. A "protective MBR" is just one with a fake MBR partition table marking the whole disk used, no matter what code it stores So, no "mix" here, just the wrong machine code for booting from GTP.

It would have been better to name the bootcode file for GPT e.g. /boot/gptmbr or something like this.

edit: dd is a nice tool for sure, but dangerous as well if you don't know exactly what you do. Overwriting just the code part of an MBR is something it can't do, so, there's a reason gpart(8) has this feature built in

 

[_martin]

Funny thing is we were talking about the same thing but misunderstood each other each step. .
I agree the naming could have been somewhat better.

Also true tools that are used for this should be used. I shared the steps I'd take should this happen to me. I'd verify I executed the correct command, check again and if that doesn't work I'd use dd (with prepped custom 512b block).

 

[balanga]

I guess it would be best to start again from scratch after zapping the various boot records because of residual debris....

If I simply do the following

gpart destroy -F daX
gpart create -s gpt daX
gpart add -t freebsd-boot -s 512k dax
gpart set -a lenovofix daX
gpart bootcode -b /boot/mbr  -p /boot/gptboot -i 1 daX

should this get me to a loader prompt?

If daX is da0, then /boot/gptboot will actually be /dev/da1/boot/gptboot.

 

[zirias@]

There's really no need to wipe anything. If you accidentally installed /boot/mbr in the MBR of a disk supposed to boot from GPT, all you have to do to fix it is gpart bootcode -b /boot/pmbr ada1

 

[_martin]

No, really no need to do that. Also -- beware -- you are using wrong -b file:

gpart bootcode -b /boot/mbr -p /boot/gptboot -i 1 daX

It has to be -b /boot/pmbr.
Nothing else needs to be fixed on that setup, just that bootcode.