Ubuntu has an OEM installer that manufacturers use for installing the distro on devices they’re going to ship. It helps in their workflows for configuring the device for customers rather than having to work around the regular installer and setting up temporary usernames and passwords. Slimbook specifically has mentioned that it would be great for Fedora to have an OEM mode. I imagine Lenovo, Framework, and other potential vendors would like the same.
How can we make this happen? Assuming there was interest from the right people, what would be the next step toward developing an OEM mode? Is this something that would start with the Anaconda team?
I haven’t used Ubuntu’s, but it sounds similar to the BFO (boot.fedoraproject.org) service that Fedora used to run (and I did use for a while). It had a very small (a few megabytes) bfo.lkrn binary that you could put on your boot/ESP partition and point GRUB (or whatever bootloader you were using) at. It would then connect to that remote server and begin an installation if you selected that menu item.
I suspect Fedora discontinued it because it was not getting enough use to justify its upkeep. But if there would be more vendor interest now, maybe it would be worth reviving?
Since you bring up Workstation, it would be good if we had a solution that applied to all spins and not just Workstation. I’m thinking specifically of Fedora KDE, but other spins would be nice to have as an option if for some reason a vendor wanted to provide those out of the box.
Having this work for Fedora Atomic spins would also be nice. I don’t know if anything different is needed between the atomic spins vs the traditional spins. This would also be nice to have as we explore how to get the first computer to ship with Fedora Atomic.
I see that I completely misunderstood your original post/question. Sorry about that. I saw “OEM Installer” and the first screenshot in that link and somehow by brain jumped to “rescue-mode installer available from boot menu”.
Also, since I might be getting things confused, wouldn’t an OEM installer make it easier for companies to add whatever packages they needed to their installs (like the infamous NVIDIA drivers, for example)?
It would. As I understand it, that’s the main benefit of an OEM installer. It lets you install the distro, make a temporary user account to install any extra packages or drivers that are needed, and then you close out in such a way that on next boot it will prompt you to set up the computer like new. It’s a cleaner experience for the customer.
For example, Slimbook with their Fedora installs have to make a user account that is username ‘slimbook’, password ‘slimbook’ so that they can do testing on a device and install the Nvidia drivers on non-Fedora Slimbook devices. As a user you’re not getting the setup experience that you do when you initially install the distro. There may be other benefits too, but that’s the one that prompted the conversation.
I don’t know how PC production works, but I also can imagine that vendors would like a more efficient way of installing an OS onto a device. Maybe I’m wrong, but I don’t think the big manufacturers are literally installing Windows on one computer at a time after it’s been fully put together. If there’s a lack of efficiency there or the workflow doesn’t fit within the process they have for their core business, I can see how Fedora and other distros would be a non-starter for them.
Tagging @mpearson and @vaja-slimbook to see what insights or requests they bring to the table. If this is something we can do, we should aim for features they need rather than what we think they need.
I have thought of how this would work on linux, Windows ties Bitlocker keys to your user account, your Microsoft account and also your log in. There are known issues with how Windows handles that.
LUKS, needs a password to set up the container. Once that 1st key is set you have access to the Header File for the container. That’s a huge “No No”. OEM’s typically want convenience maybe looking at how technology was handled 25+ yrs ago, when the systems we built or purchased came with a CD Rom with a full version of the OS? In this case ship the .iso on a USB or have a link to an image/container of the Fedora Installer. Convenience over Security? Security over Convenience? It’s tough to make those decisions.
I reached out to Framework and got this feedback from their Linux Support Lead:
I really love this idea! On Ubuntu, the thing that we would want is the ability to select a specific kernel. They have OEM kernels and we bounce between them.
For Fedora, this is less of an issue as there is not really a need for the OEM kernel due to things getting addressed rather quickly, thus ensuring updates and related can just be sent out to updates as needed.
That said, it would be amazing to be able to graphically select one of the most recent kernels on the ISO image. Going even further, being able to do this on a Live boot (not installed) would be even better.
Giving users the ability to split test kernel scenarios with live media without touching an install is the holy grail of troubleshooting for us. But, if this is still valuable as an OEM install option, select one of the following most recent kernels, continue installation. This also has value.
Maybe a stupid question, but… why not just have an empty SSD and a ready and tested USB stick, set as the first uefi boot target? Power on, install, and afterwards install Fedora everywhere!
It’s more about the Full Disk Encryption, I believe having a USB drive you plug in when you buy the system ( Like the Olden Days. . . ) would be more than enough for you. You can customize the installer in such a way that user is clicking through install on a fresh machine. I would even advocate for a KeePassXC vault as part of the install so you can keep the Header file and Keys in the vaut.
Except presumably the whole “copy to the local disk” step would have already been done by the OEM. I sorta assumed this was the entire point of imagebuilder. The oem would customize an image with packages/themes/whatever, which would create a raw disk image they would use during system imaging at the factory.
Then when the user powers the machine on the first time it boots, and runs through the initial-setup logic, like the normal disk images, asking for username/pw/etc and finalizing the config.
Yes, post install disk encryption would still be a problem because all the obvious solutions end up sharing the underlying encryption key. Maybe not ideal, but the short term solution is maybe more OPAL complaint HW, where the disk/FW do the encryption and linux/etc is generally unaware of it.
PS: There is apparently a rencypt option in cryptsetup now, so maybe that could be used.
