View Single Post
  #5   (View Single Post)  
Old 11th April 2018
egency egency is offline
New User
 
Join Date: Apr 2018
Posts: 8
Default

Thanks to everyone for taking the time.

@IdOp Thank you, having the names of the man pages related to this is quite help on its own. Like I mentioned I've never dealt with NetBSD before so I don't have the sort of sense of naming conventions and probable connections I do on Linux. So a starting point like that is gold.

@shep The mac is not mine, so fiddling with the boot options is rather frowned upon. That's partly what is causing this difficulty, the machines I have access to aren't mine and thus a lot of configurations that would have made this a great deal simpler aren't available to me. This does however provide an opportunity to build a fairly portable system and learn more about the boot process which I consider valuable outside this context too. Thanks for the link though!

@jggimi Your assumption about the USB drive is indeed correct, that is exactly that I'm hoping to achieve.

The ability to boot on 32bit is unfortunately rather important as it's a very common platform still where I'm from. This is a relatively simple case as I've never come across a 32bit UEFI machine and thus I don't consider this case necessary. I do come across a fair number of BIOS only and UEFI only 64bit machines. All of the machines are Intel architecture. We also don't have USB sticks larger than 32G.

Given the 32bit requirement I believe a 32bit userland (base? Not too clear on terminology differences from Linux) to be necessary, however as far as I know 64bit kernels will happily run 32bit user applications. This leads me to why I considered a 64bit kernel at all. According to some of the (vague) literature I have found UEFI firmware dislike booting 32bit kernels on 64bit machines. I do not know whether this is a firmware issue or a bootloader issue. If it is a bootloader issue, and the NetBSD bootloader doesn't have this issue, I will simply stick to 32bit for the entire system as it covers my needs.

With this in mind, I'm not entirely clear on what you mean about difficulty with compiling large applications. Do you mean that a 32bit OS running on a amd64 machine will have difficulty compiling applications? If so, would you mind giving me a quick explanation as to why as it seems counter intuitive. If you mean the other way around it makes sense however.

So, the boot architecture as I understand it, please correct me if I get something incorrect.

An MBR is created (most sources refer to this as a "protective MBR") which covers the whole disk. Within this structure the GPT table gets created. An "EFI boot" GPT partition is created and formatted as FAT. At this point I have some confusion as some sources state a legacy boot GPT partition should be created as well. I have yet to find any mention of this in any of the *BSD sources so I'm not clear on this.

With this in place a bootloader gets placed within the first 440 bytes. When booting GPT disks this loader seems to typically be called "mbrgpt" or similar. This in turn (as far as I can tell about *BSD boot architecture) loads the PBR loader. This part is also fuzzy for the same reason as above, does the PBR sit on the EFI partition or on a legacy boot partition?

Lastly, the PBR loader loads the main bootloader which then deals with the kernel. When booting on UEFI systems everything except for the main bootloader gets skipped as the firmware finds the EFI partition and loads whichever bootloader is appropriately named.

So, is my description of the architecture correct? And could you possibly clear up the part about the legacy boot partition?

I'm actually aware of OpenBSD doing this which is the primary reason why I decided to try this with NetBSD at all.
Reply With Quote