Non-system disk on non-UEFI systems when booting from USB

I will immediately move to STABLE or RELEASE.
I would suggest starting with a -RELEASE version. You can easily keep it up to date using freebsd-update(8). Updating a -STABLE requires you to build from source. While the process is fairly straightforward it does require a bit of know-how and it's quite easy to end up with a broken or unstable system, especially if you're unfamiliar with how the FreeBSD code is managed.

Get your feet wet first on a -RELEASE. Once you've learned how to stay afloat you can have a go at -STABLE.
 
OK Thanks! I will try out both versions starting with RELEASE after the new MBR binary file has came to flash it with dd.
 
Ok. Don't worry SirDice, I well know this domain.

It was easier than I believed. The code source lies in /usr/src/stand/i386/mbr/mbr.s (12-0-RELEASE). In italic the removed instructions, in bold the text I added or modified:
Rich (BB code):
# Scan the partition table looking for an active entry.  Note that %ch is
# zero from the repeated string instruction above.  We save the offset of
# the active partition in %si and scan the entire table to ensure that only
# one partition is marked active.
#
main:   xorw %si,%si            # No active partition
        movw $partbl,%bx        # Partition table
        movb $0x4,%cl           # Number of entries
main.1: cmpb $0xA5,4(%bx)       # Type = FreeBSD?
        jne main.2              # No
#jg err_pt             # If 0x1..0x7f
#testw %si,%si         # Active already found?
#jnz err_pt            # Yes
        movw %bx,%si            # Point to FreeBSD partition
        jmp main.3
main.2: addb $0x10,%bl          # Till
        loop main.1             #  done
#testw %si,%si         # Active found?
#jnz main.3            # Yes
        int $0x18               # BIOS: Diskless boot
#
# Ok, we've found a possible active partition.  Check to see that the drive
# is a valid hard drive number.
#
main.3:  cmpb $0x80,%dl         # Drive valid?
Now, the mbr code doesn't verify anymore if there is one or more activated partition. It just searches for a BSD one and boots it.

A make inside /usr/src/stand/i386/mbr/ compiles and creates the new mbr in /usr/obj/usr/src/amd64.amd64/stand/i386.

As SireDice stated, you must replace only the 446 first bytes of the original mbr because there is the partition table behind. The file I attach here is the compiled mbr but just the first 446 bytes.

You can't directly fill /dev/sdb. Instead, you have to do that on the image file:
dd if=boot-mbr.txt of=image.img bs=446 count=1 conv=notrunc
After the image has been updated, you can flash your device. Just rewrite the first sector, the rest remaining the same:
dd if=image.img of=/dev/sdb bs=512 count=1

Let me know if this works or not.

PS: I activated the efi partition and got exactly the message you have. I patched the memstick image and it worked (in a VM).
 

Attachments

  • boot-mbr.txt
    446 bytes · Views: 169
Thanks for the MBR file! I have currently patched it, but I can't test at this moment because my electricity is off and I have school, and when I return back home, I only have a bit of time which I think is enough for testing before the electricity is off.

I will let you know, when I have tested it.
 
I tested this on my laptop, and it worked fine. It shows me the FreeBSD installation screen.

However on my PC, I performed the following tests:

With Legacy USB Support:

- USB RMD-FDD: Refuses to boot and prints this message:

Code:
Non-system disk
Press any key to reboot

Without Legacy USB Support:

- USB RMD-FDD: Although recognized, it will go straight to HDD.

I made sure that I have followed every single step correctly. Is the MBR file that is attached modified to reflect such changes? And why would my PC do the above?
 
I'm out of idea now. Try to repeat the procedure.
Compare the md5 of the modified mbr and the original one to be sure you have altered it.

dd if=original-image.img of=mbr.ori bs=512 count=1
dd if=modified-image.img of=mbr.mod bs=512 count=1
md5 mbr.ori && md5 mbr.mod
 
Ooops. It looks like that was my fault, because I assumed that we're going to create a new image which will overwrite my stick's MBR. I'm sorry.

I used the following commands on my rooted Android, assuming that FreeBSD13.0.img is the FreeBSD memstick image file:

busybox dd if=boot-mbr.txt of=FreeBSD13.0.img bs=446 count=1 conv=notrunc

and verified the MD5 checksums between the original and the modified images (md5sum on Android Termux), and the result is (Assume that original.img is the original image):

Code:
$ md5sum -b FreeBSD13.0.img
173f18f6d83c6099a49813e31f76950e  FreeBSD13.0.img
$ md5sum -b original.img
323e7035c1ed22e1912ce07b7671c583  original.img

and they were different, so I prepared the USB stick for my computer, because my electricity was off at the moment, by using this command on my rooted Android tablet that supports OTG:

busybox dd if=FreeBSD13.0.img of=/dev/block/sda bs=512 count=1

I checked the partition table, and saw that the efi partition has a boot flag.

Am I doing the whole procedure right?
 
It seems. If your Android commands do the same things than FreeBSD.

It's not normal that the efi partition is active. In the original image, it's the freebsd one which have the boot flag. I have not the same md5 as you but I understand why: I took the 2019/02/21 snapshot and not the 2019/02/28 one. But this makes no difference for this matter.

The important thing is the md5 of the mbr which you didn't give...

Finally, we proved that your PC loads and executes the mbr from the USB key. So there is no reason you get the same message as before.
 
Sums:
Code:
2dcc42bc849e871fdb4113bdc8ccdf18 boot-mod.txt
27534479da407e4a65db6f96f44715ff boot-orig.txt
 
This is actualy the boot code I provided (md5 correct) but I mean:
dd if=original-image.img of=mbr.ori bs=512 count=1
dd if=modified-image.img of=mbr.mod bs=512 count=1
md5 mbr.ori && md5 mbr.mod
 
I have deleted the post which only shows the boot-mbr.txt's sum and made a post with the information that you need. Refresh the page to see.
 
Lol. Still not the same md5. Maybe due to snapshot difference. Just verify that the mbr on the USB key has the same md5 as boot-mod.txt.
dd if=/dev/block/sda of=mbr.real bs=512 count=1
 
Code:
2dcc42bc849e871fdb4113bdc8ccdf18  boot-mod.txt
2dcc42bc849e871fdb4113bdc8ccdf18  boot-usb.txt
 
Message that I got when I tried to boot from USB in my old PC:
Code:
Non-system disk
Press any key to reboot
 
I have removed the EFI partition and set the FreeBSD one as bootable, but when I reboot and boot to USB (USB RMD-FDD), it only shows me a blinking underscore.

My BIOS has detected my flash drive as USB RMD-FDD, and when I looked at the documentation of my motherboard, it says that there are available USB boot modes:

  • USB HDD
  • USB FDD
  • USB CD/DVD
  • USB RMD-FDD
  • USB RMD-HDD
 
I looked at Unetbootin, and I made my USB using it for the last time, and it booted, until it stops on the message attached below

6203

Not only FreeBSD doesn't boot on my old PC, but the same message has appeared in my alternative laptop!
 
Back
Top