Failing to boot mfsBSD for the first time
Closed this issue · 8 comments
I'm trying to use mfsBSD to install FreeBSD 13 on a Linux system due FreeBSD not being officially supported on the hosting provider. I've tried to follow instructions in here https://forums.freebsd.org/threads/how-to-install-freebsd-w-zfs-on-a-remote-server-from-a-linux-rescue-system.61842/ and using FreeBSD 13.0 instead of 11.1 like in the forum post.
However, when I'm trying to boot the first time, then this is what I see:
Here's also output of ?
I'm using VirtualBox VM-s of FreeBSD 13.0 to prepare the image and Ubuntu 20.04 to boot into and use dd to write image to the disk. Can it be that mfsBSD does not work well with VirtualBox for some reason?
How much RAM is on the server? Can you check my https://myb.convectix.com/DL/mfsbsd-13.1.img image ( source: https://forums.FreeBSD.org/threads/installing-freebsd-in-hetzner.85399/post-574863 ) - it works well for me.
I'm using VirtualBox VM-s of FreeBSD 13.0 to prepare the image and Ubuntu 20.04 to boot into and use
ddto write image to the disk. Can it be that mfsBSD does not work well with VirtualBox for some reason?
The problem is that you probably recorded from a live Linux system that started not from a live-CD, but from a harddrive sda
This is what the hdd partitions look like:
root@mfsbsd:~ # gpart show
=> 40 200688 ada0 GPT (6.0G) [CORRUPT]
40 472 1 freebsd-boot (236K)
512 4096 2 efi (2.0M)
4608 196120 3 freebsd-ufs (96M)
=> 40 200688 diskid/DISK-VBd95518d2-7f3012fe GPT (6.0G) [CORRUPT]
40 472 1 freebsd-boot (236K)
512 4096 2 efi (2.0M)
4608 196120 3 freebsd-ufs (96M)
@click0 yes, I did install Ubuntu on my VM and then tried to boot into mfsBSD. Are you saying that I should be using Linux rescue system instead?
Yes, this is still a working plan.
I understand that I would like to immediately install on top of a running Linux, but I'm still thinking how to fix it.
If you do not have Linux-rescue and want to write the MfsBSD image to a "live" disk with Linux, then we need to stop most of the system processes so that they do not write to us on the disk.
The following commands will help you:
wget https://myb.convectix.com/DL/mfsbsd-13.1.img -q -O -| cat | dd of=/dev/sda
Cat is needed to compensate for uneven download speed and protocol compression.
If everything is successful, then you need to reboot the system.
We need to do without regular system tools, such as reboot, because it calls sync, which overwrites the disk for us.
We use:
echo b > /proc/sysrq-trigger
I tested on Debian 11.
Upd.
I am persistently advised the key for dd - conv=fsync
After small tests, including interfering background processes, a clarification was made.
It is best to download the image file to a memory disk and then we write from it to a "live" disk with the system.
The conv=fsync option for dd helps control the write.
The command set now looks like this:
mkdir -p /tmp/ramdisk
chmod 777 /tmp/ramdisk
mount -t tmpfs -o size=150m myramdisk /tmp/ramdisk
cd /tmp/ramdisk && wget https://myb.convectix.com/DL/mfsbsd-13.1.img && dd conv=fsync if=/tmp/ramdisk/mfsbsd-13.1.img of=/dev/sda && echo b > /proc/sysrq-trigger
@click0 Aha, all of this makes a lot of sense. I didn't even think about these nuances. Booting into Linux recovery mode would be also possible at my hosting provider, but I didn't think it is a hard requirement thus didn't see any reason to boot into that mode in my VM where I was testing it out.
Tested out commands provided by you in the last comment on my Ubuntu 20 Virtualbox VM and it worked as expected. Running FreeBSD in that VM now. I can now try it out on my hosting provider too.
@olevole maybe you also want to update the forum post with the last changes done by @click0?
Thank you for helping me out with this problem!
Closing this issue now.