DaemonForums  

Go Back   DaemonForums > NetBSD > NetBSD Installation and Upgrading

NetBSD Installation and Upgrading Have trouble getting NetBSD on your toaster?

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 11th April 2018
egency egency is offline
New User
 
Join Date: Apr 2018
Posts: 8
Default 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?
Reply With Quote
  #2   (View Single Post)  
Old 11th April 2018
IdOp's Avatar
IdOp IdOp is offline
Too dumb for a smartphone
 
Join Date: May 2008
Location: twisting on the daemon's fork(2)
Posts: 1,027
Default

Hello, and welcome to the forum!

I probably can't be much help with your main questions, since I've never dealt with UEFI, GPT or made a NetBSD live CD. A tiny part of getting started might be to read the man pages for boot(8), mbr(8), gpt(8) and some of the references in them.

When it comes to dealing with limited bandwidth, there's one idea that I've used worth throwing out there. If you have a portable WiFi access device (e.g., cell phone or tablet) or can borrow one, and can get to a decent public WiFi AP, then you can use that to download an install iso. That will have "everything" on it so it's a convenient download. Once you bring it home and copy it to a real computer, you can then download a (small) checksum file via a more trusted connection and verify the iso.
Reply With Quote
  #3   (View Single Post)  
Old 11th April 2018
shep shep is offline
Real Name: Scott
Arp Constable
 
Join Date: May 2008
Location: Dry and Dusty
Posts: 1,503
Default

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
Reply With Quote
  #4   (View Single Post)  
Old 11th April 2018
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

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.
  • If you must use the 32-bit only platform, then you must use a 32-bit OS.

    64-bit capable machines can boot in 32-bit. But not the other way 'round. You may have trouble with some applications. 32-bit x86 CPUs have fewer, smaller registers, limitations on memory, and other restrictions which might limit your OS's ability to deploy large and complex applications like Chrome, Firefox, or LibreOffice. Usually, the problem is compiling them, not running them if they have been successfully compiled.
  • Use an MBR on the booting drive, adding an EFI boot partition.

    The EFI partition (FAT-formatted, containing EFI boot-blocks stored as files) is necessary for booting via EFI.
  • Also install MBR/PBR boot blocks.

    In this way, the drive will be bootable from both EFI or MBR platforms.
Edited to add: The OpenBSD install media disk drive image is created this way, so that the media is bootable on the largest spectrum of systems.

Last edited by jggimi; 11th April 2018 at 06:40 PM.
Reply With Quote
  #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
  #6   (View Single Post)  
Old 11th April 2018
Head_on_a_Stick's Avatar
Head_on_a_Stick Head_on_a_Stick is offline
Real Name: Matthew
Bitchy Nerd Elitist
 
Join Date: Dec 2015
Location: London
Posts: 461
Default

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?
Reply With Quote
  #7   (View Single Post)  
Old 12th April 2018
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Quote:
Originally Posted by egency View Post
...as far as I know 64bit kernels will happily run 32bit user applications...
This is not the case for all operating systems.
Quote:
...With this in mind, I'm not entirely clear on what you mean about difficulty with compiling large applications.
Some very large applications (browsers, office automation) have grown in complexity and extended their dependency requirements, whereby successful compilation is often difficult. Compilers must often work around register limitations. Sometimes, the application porters must switch compilers, or find other workarounds.

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:
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.
This was not my recommendation, and I apologize for any misunderstanding. I did not recommend using a GPT.
  • I recommended a real Master Boot Record, with a real Master Boot program linked to a real Partition Boot Record, which is what is commonly described as "Legacy boot." i also recommended an EFI boot partition be created in the MBR partition table. This permits booting by MBR-only systems, EFI-only systems, or systems that can boot both.
  • A "protective" MBR created when a GPT is provisioned merely prohibits MBR-only systems from using the drive.
To see what this looks like in practice, download an OpenBSD installation media image for amd64, such as the 4 MB file:

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.
Reply With Quote
  #8   (View Single Post)  
Old 12th April 2018
egency egency is offline
New User
 
Join Date: Apr 2018
Posts: 8
Default

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.
Reply With Quote
  #9   (View Single Post)  
Old 12th April 2018
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Quote:
Originally Posted by egency View Post
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?
Yes. On an x86, MBR booting platform:
  1. The BIOS loads and executes the MBR boot program from the MBR sector (LBA 0)
  2. The MBR program loads the PBR boot block from the first sector of the flagged/active partition defined in the MBR partition table.
  3. The MBR program executes the PBR program.
In OpenBSD, thie PBR program is the first stage bootloader, biosboot(8), This first stage is installed into the PBR block via the installboot(8) program, which also links the location of the second stage bootloader boot(8) from the address where it is stored in an FFS filesystem. This second stage program is the one that produces OpenBSD's boot> prompt, and which can accept interactive commands such as kernel selection.
Quote:
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?
To my understanding, on OpenBSD, both the i386 and amd64 architectures share the same 32-bit biosboot() and boot() programs.

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:
...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 can tell you step-by-step how to install an OpenBSD system onto USB-attached storage with these capabilities. But I have no NetBSD experience, and cannot provide NetBSD-equivalent provisioning commands.
Quote:
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.
On OpenBSD, the amd64 install script will provision a zeroed drive with GPT partitioning if an EFI frame buffer efifb(4) is discovered, otherwise it will provision an MBR. Therefore, the admin configuring an MBR with an EFI boot partition will need to manually provision these prior to running a standard installation.
Reply With Quote
Old 12th April 2018
shep shep is offline
Real Name: Scott
Arp Constable
 
Join Date: May 2008
Location: Dry and Dusty
Posts: 1,503
Default

Quote:
@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.
It is possible during startup to select a boot device without making any BIOS changes. This would be a much easier route to take.

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.
Reply With Quote
Old 12th April 2018
egency egency is offline
New User
 
Join Date: Apr 2018
Posts: 8
Default

@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:
which also links the location of the second stage bootloader boot(8) from the address where it is stored in an FFS filesystem.
This actually makes sense, and after some reading of the manuals it seems like it calculates the second stage upfront so that it need not depend on filesystem specific drivers, meaning that 440 bytes would be more than enough with this approach.

Quote:
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.
Actually according to my reading this isn't entirely true, however as far as I can tell 32bit UEFI systems are so rare as to be practically extinct. It seems to be a thing where the majority of the benefits of UEFI get nullified by the 32bit architecture hence exceedingly few of these types of systems got produced.

Quote:
I can tell you step-by-step how to install an OpenBSD system onto USB-attached storage with these capabilities. But I have no NetBSD experience, and cannot provide NetBSD-equivalent provisioning commands.
I appreciate your offer and I think I'll take you up on it. UEFI seems to be part of the 8.0 release (which is currently in pre-release from what I can tell), so I think becoming more familiar with BSDs in general via OpenBSD would present a shorter learning curve than going from Linux to BSD, which will put me in a better position to work out how to do it in 8 pre-release, or alternatively, after it is actually released. Thank you.

Quote:
Therefore, the admin configuring an MBR with an EFI boot partition will need to manually provision these prior to running a standard installation.
This seems to be similar in principle to what was going through my head. Provided that the kernel and userland is properly separated from the boot code, and the MBR and UEFI code doesn't interfere with one another one could complete the boot system either before the install is finished (as what I understand you are suggesting there), or in post-install by booting on a platform compatible with with boot system you configured first. I suggested the latter partly based on how I understood the sysinst system to work. It seemed to be the route of least resistance.

Quote:
On OpenBSD, the amd64 install script will provision a zeroed drive with GPT partitioning if an EFI frame buffer efifb(4) is discovered
This part somewhat confused me. What does the frame buffer have to do with boot systems? Unless the presence of a frame buffer passed from UEFI is used to indicate the presence of UEFI capable systems. But this seems to be a rather roundabout method of doing this. What am I missing?
Reply With Quote
Old 13th April 2018
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

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
Reply With Quote
Old 13th April 2018
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

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
Reply With Quote
Old 13th April 2018
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

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.
Reply With Quote
Old 13th April 2018
shep shep is offline
Real Name: Scott
Arp Constable
 
Join Date: May 2008
Location: Dry and Dusty
Posts: 1,503
Default

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/grub2
2) EFI amd64
3) BIOS i386
4) Partion for development data to be mounted by the booted OS
It 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.
Reply With Quote
Old 14th April 2018
egency egency is offline
New User
 
Join Date: Apr 2018
Posts: 8
Default

Quote:
The MBR/EFI combination is normally intended for broadly bootable installation media. You are taking advantage of this flexibility for this custom installation.
Okay, that helps fit the various pieces together.

Quote:
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.
That is far easier than I would have expected! More broadly this entire endeavour is turning out far easier than I expected, things aren't this easy on Linux...

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.
Reply With Quote
Old 16th April 2018
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Quote:
Originally Posted by egency View Post
That is far easier than I would have expected!
All of that assumes that the Step 1 test actually works. Otherwise, there's not much point in continuing to Step 2.
Reply With Quote
Old 18th April 2018
egency egency is offline
New User
 
Join Date: Apr 2018
Posts: 8
Default

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.
Reply With Quote
Old 18th April 2018
jggimi's Avatar
jggimi jggimi is offline
More noise than signal
 
Join Date: May 2008
Location: USA
Posts: 7,977
Default

Quote:
Originally Posted by egency View Post
... for some reason it was incredibly slow...
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:
...There was a boot message about firmware...
Loadable firmware with licenses that prohibit packaging with the OS must be installed separately, similar to third party packages. The fw_update(1) utility is used to manage this, and is run for you at first boot. By default, fw_update() will download and install any needed and missing firmware, assuming that there is a working network connection. If a network connection is not yet possible due to missing firmware for a NIC, you must obtain the firmware package manually, mount it locally and point fw_update() at the package file.
Reply With Quote
Old 19th April 2018
egency egency is offline
New User
 
Join Date: Apr 2018
Posts: 8
Default

Quote:
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.
So I tried that, it speeds up significantly but it's still unusably slow... Rather disappointing actually, I was quite looking forward to this.

On the upside the boot system works.

Meh this rather sucks.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

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


All times are GMT. The time now is 10:01 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick