|
NetBSD Installation and Upgrading Have trouble getting NetBSD on your toaster? |
|
Thread Tools | Display Modes |
|
|||
Booting both UEFI and BIOS systems
Hi all, I've got a peculiar setup I'm trying to get right. Due to lack of my own computer I'm necessitated to hop between three different machines. The one is an ia32 BIOS machine, the next an amd64 BIOS machine and the last an amb64 UEFI Apple. As another important point, my internet is severely limited, I've been putting off downloading the install disk since it'll do very bad things to the rest of the month's internet availability. Hence, I would prefer downloading the right things the first time around, and also preferably as little as possible.
Jumping between these machines is driving me crazy. So, I'm hoping to create a live disk that'll boot on all three so that I can have a consistent development system. I, however, have no experience with NetBSD at all (this will be my first NetBSD install), so I'm appealing to people more well versed than myself for help. So far I found that NetBSD 8 has a UEFI capable, oddly though I've heard that the amd64 (not sure which version) refuses to install itself to a USB drive. I'm not sure whether I'll need a 64bit kernel, 32bit or both, though I'll definitely need the 32bit one. I can use syslinux to boot, however I would prefer to avoid that if possible. As far as I can tell the NetBSD boot... system? is fairly similar to syslinux in how it boots GPT on BIOS, I suspect (hope) that this indicates that booting both BIOS and UEFI from the same USB will be possible. I managed to get my hands on the man pages for NetBSD 8, so if I need to read up on anything that's not a problem. Also, I have no issues ending with a fairly minimal system, in particular, a lack of X11 doesn't bother me especially since it's fairly easy to fix after the fact. I'm also not afraid of manually poking around the disks should that be necessary. So, where do I start in order to figure this out? |
|
|||
I'm not sure about Apple's bios but my ASUS/Asrock sytems provide a "Boot Menu (F8)" option that will boot non UEFI installs. A quick web search:
https://support.apple.com/en-us/HT202796 |
|
||||
Hello and welcome. I'm not going to be any help with NetBSD, but perhaps I can help with the common configuration points among the 3 platforms, so that you only need one OS image that boots across them.
Assumption: you'll boot and use a USB-drive, so you can easily carry one USB device from machine to machine.
Last edited by jggimi; 11th April 2018 at 06:40 PM. |
|
|||
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. |
|
||||
UEFI booting relies on motherboard NVRAM entries directing the firmware to load specific .efi loaders located on the EFI system partition, OpenBSD uses $ESP/EFI/BOOT/BOOT{X64,IA32,AA64}.EFI and I presume the NetBSD does the same.
That location should be booted automatically in the absence of any UEFI boot entries in the firmware NVRAM, this is how the OpenBSD installer boots.
__________________
Are you infected with Wetiko? |
|
||||
Quote:
Quote:
i mentioned it in my first post above because it is an operational consideration. You will find application availability and application performance both to be better on 64-bit hardware. Quote:
http://fastly.cdn.openbsd.org/pub/Op.../miniroot63.fs I recommend looking at the 64-bit (amd64) installation media because the 32-bit (i386) media image does not have this dual-boot configuration. You will see two MBR partitions: a small EFI partition, and a larger OpenBSD partition. You will find 32-bit and 64-bit bootloaders in the EFI filesystem on the amd64 disk drive image. Last edited by jggimi; 12th April 2018 at 10:48 AM. Reason: clarity, typos, and lack of caffeine. |
|
|||
Hmm, thanks, I'll have to keep an eye out for whether I get compilation issues for anything important enough to warrant doing something about it. Good to know however, I wasn't aware of this thanks.
No need to apologize, the fault is my own. I assumed GPT based on my prior reading, all of which suggested that UEFI doesn't work without GPT if only due to never mentioning the alternative. This is however excellent news, it greatly simplifies the entire setup! So looking at the image you suggested, I noticed the two bootloaders in the EFI partition, but nothing on the main partition. Is this because the loader for normal MBR boot is written in the PBR of the main partition? Also incidentally it occurs to me that I'm assuming there is boot code in the MBR /and/ the PBR, is this actually correct? Further, does this then mean that the MBR boot code is agnostic of whether the machine is 32bit or 64bit or am I still missing something in this regard? In terms of practical installation of this system as far as I've been able to pick up from various sources the process goes something like: fdisk (EFI and NetBSD) -> disklabel (for the NetBSD slice) -> create the filesystems, at this point the NetBSD guide becomes a little fuzzy. I'm guessing one writes the MBR bootloader into the MBR and copies the EFI loaders to the EFI partition (I remember something about a "mbec" folder containing these, but I'll have to check to make sure). Is this high level overview reasonable? I suspect one could pick either MBR or EFI to install during the installation process and then set up the other as a post install step if sysinst cannot do both during the install process which may simplify the process. I have a few other questions at present, but I need to read the documentation first so I'll leave this as is for the moment. |
|
||||
Quote:
Quote:
As I noted above, the i386 install media disk images (*.fs) do not include EFI boot blocks, they are MBR-boot only. My conjecture is that there are no EFI-booting machines which are 32-bit only, so this sort of dual-boot facility is not required. Quote:
Quote:
|
|
|||
Quote:
On my ASrock motherboard, F9 and my ASUS F8. The corrrect key usually is briefly listed at the bottom of the screen during startup.. I do not own a MAC but a websearch says the "Option" key https://www.techradar.com/how-to/com...ur-mac-1305645. |
|
|||||
@shep, Oh, I must have misunderstood you in that case. I'm aware of the boot medium selection menu. I've used it to boot Linux before, that's partially what motivated the present endeavour. I can select the disk, all I need to do is configure the boot system correctly. The Mac I'm using has a rather strong dislike of BIOS based boot system and only does UEFI. Discounting the 32bit for a moment the other system I regularly have access to only does BIOS boot, hence my dilemma, and the possible solution that presents itself. I suppose if I couldn't manage to modify boot media at all the present solution would not have been on the cards at all (Linux makes this unreasonably difficult, hence the switch to BSD). I suspect I should have been clearer on this point in my original and subsequent posts. Thank you for the advice though, it's nice to have a community with as many helpful people as I've found here. It's a surprisingly rare find and I truly appreciate it.
@jggimi Quote:
Quote:
Quote:
Quote:
Quote:
|
|
||||
Step 1: test the amd64 install media you already have on all 3 workstations. The bootloader should boot (you see a boot> prompt) on all 3 systems, though the 32-bit-only machine will not be able to boot the kernel. If there is a failure to reach the boot> prompt on any of the systems, then this procedure is unlikely to work.
Step 2: Obtain and save the EFI bootloader files from the amd64 installation media image you already have, as they are not included with the i386 system you will be installing. Step 3: Become familiar and comfortable with the OpenBSD installation process, as these instructions will not detail those steps. My recommendation is to use i386 installation media, and practice. To ensure you do not inadvertently scribble on an existing workstation disk drive, always use the question mark "?" response to the question, "Which disk is the root disk?" as that is the drive you will install onto and overwrite. The install script will happily destroy the data on any drive you select. Step 4: when ready, reboot the installation media, but select the shell rather than the install script. Step 5: insert (or remove and reinsert) the USB drive you will be installing the system onto. Note this sd(4) device number in the kernel messages which appear on insertion. As this is dynamic, it might not be the same as the sd(4) drive number you used during step 3. Step 6: # cd /dev && sh MAKEDEV sdn where n = the sd(4) drive number obtained in Step 5. This is necessary because the installation media has limited capacity and does not come with a full set of device special files already defined.Step 7: # fdisk -b 960 -i -y sdn will create an MBR, reserving a small EFI boot partition, creating an OpenBSD MBR partition on the rest of the drive, flagging it as active/bootable. Step 8: # install will run the install script. When you select this disk as the root disk, the install script will display the MBR layout and ask you if you wish to use the whole disk, the OpenBSD area, or edit the MBR. Answer with the "o" prompt to use the OpenBSD area.Step 9: After installation has completed, your rebooted and running OpenBSD system should have an "i" disklabel partition, which is the as-yet unformatted EFI partition you created in Step 7. The drive number may have changed after installation, so the value of n may now be different than in earlier steps. Determine what the drive number is with mount(8) or df(1), and use # disklabel sdn to confirm the partition is defined. Then, use # newfs_msdos sdni to format the EFI partition as a FAT filesystem.Step 10: mount the newly formatted filesystem with # mount /dev/sdni /mnt and then create the boot directory structure with # mkdir -p /mnt/efi/boot Step 11: copy the 32-bit and 64-bit bootloader files you saved earlier into /mnt/efi/boot. Step 12: shutdown(8) this system, and take the USB drive to all your workstations. At each successful boot, have another beer. Last edited by jggimi; 13th April 2018 at 12:02 PM. Reason: step 9 is conducted from the booted, installed system |
|
||||
Now I can also answer your EFI/GPT question. The efifb(4) device existence is used by the install script for its default MBR or GPT decision. GPT is the default for EFI booting, but as we can see from the example installation media above, this is not a hard requirement. The MBR/EFI combination is normally intended for broadly bootable installation media. You are taking advantage of this flexibility for this custom installation.
Last edited by jggimi; 13th April 2018 at 12:24 PM. Reason: clarity |
|
||||
Finally, I'd like to address networking flexibility for your single-image, 3-workstation solution. Each system is likely to have different network interface connectors (NICs), and therefore, different drivers for these NICs. The installation system will have a hostname.if(5) file already provisioned. If DHCP is used to assign each workstation's IP address, then all you need to do is copy this file to another with the appropriate filename to match the NIC driver and device number. Wireless settings such as SSID names should be commented out or removed for wired NICs. If static IP addresses are used instead of DHCP, copy the file and edit accordingly.
|
|
|||
There may be another way to accomplish a portable development thumb drive.
Grub2 and some versions of Grub legacy can chainload efi. sysutils/grub is available in OpenBSD but I can not state from experience that it will chainload efi. NetBSD offers both Grub and Grub 2. https://www.rodsbooks.com/efi-bootlo...ub_legacy.html In this approach, you could format your drive into 4 partitions: 1) BIOS amd64 w/ grub/grub2It may be that EFI amd64 could be the first partition, with grub, because the GPT booting scheme has an embedded MBR. Edit: I just checked and OpenBSD grub is broken: fails with both clang and ports-gcc Last edited by shep; 13th April 2018 at 03:29 PM. |
|
|||
Quote:
Quote:
Okay, so I've gone through the FAQ a few times and I think between what you said and that I've got a fairly decent idea of what to do. It'll probably take me some time to get hold of the install ISO due to constraints on my internet. So once I've managed that and fiddled with it some I'll get back and report on how it went. Thank you, I really appreciate the help. |
|
|||
I forgot to mention, I did test the miniroot image on all the machines and it worked just fine.
I did a test installation to the USB yesterday and for some reason it was incredibly slow (ls takes about three seconds to finish as an example). I'm not sure what I missed. There was a boot message about firmware that I couldn't do anything about at the time but that shouldn't have /that/ much of an impact should it? Other than that the initial test went fine, I'll probably get around to doing the UEFI part later today to see whether that part works as well, so far I don't foresee any troubles though. |
|
||||
Flash memory isn't fast on OpenBSD. As a post-installation step, you may consider mounting FFS filesystems with the Soft Updates / Soft Dependencies option. See http://www.openbsd.org/faq/faq14.html#SoftUpdates
Quote:
|
|
|||
Quote:
On the upside the boot system works. Meh this rather sucks. |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Cannot Enter BIOS | ramib | OpenBSD General | 8 | 13th February 2015 11:06 PM |
Booting Linux using UEFI can brick Samsung laptops | J65nko | News | 2 | 11th February 2013 05:53 PM |
HOWTO: Update BIOS Using CD | vermaden | Guides | 7 | 14th March 2010 10:22 AM |
Flashing BIOS from freebsd | mc_i2020 | FreeBSD General | 7 | 28th July 2008 10:11 PM |
A couple of errors, which I believe are associated with the BIOS | Johnny2Bad | FreeBSD Installation and Upgrading | 1 | 15th May 2008 03:58 AM |