 Welcome to the OpenBSD installer talk. So question up front, who has done an OpenBSD installation? All right, almost everyone. Anyone familiar with this question and answering this question with a yes? Raise your hand. Yes. They're probably familiar with the reinforcement that says, I really want the logger name, not the yes and no that you used to. That's an important point about the muscle memory. I'll come back later to this. First of all, a little introduction. This is me. I'm Clemens. I have been hacking on and playing around with OpenBC for a few years since I was in uni and most of the stuff I do for fun. And well, if I can, I don't like leaving bugs behind. So I try to fix them or at least contribute some quality of life improvements for the project. That's what I do. That's also mostly what I brought me to this talk or to the efforts that led up to this. Over you in the beginning of the talk, what you guys will be hearing from me. It's going to be a talk mixture of a recap for me, what I did, what I learned about the mistakes I made and the things I learned that you don't get from the manual pages because it's too well hidden or there is no manual page for it. And I'll explain the high-level bits of the installer, how it works, what you can do with it, what you can't do with it, why it's hopefully known as one of the nicer things of the OpenBC project. And I'll go into detail of how you can get your feed wet and start hacking or maybe fix this bug or this not perfect default you've been seeing so far. And yes, I'll show you how it's done, what it takes for the OpenBeast installer to work the way it does, and a few important change or interesting changes, stuff I did and with that the lessons I learned. And hopefully so that you don't make the same mistakes again. The design goals of the OpenBeast installer is pretty easy. We should come up with a very good first impression because it's the very first thing you as a new user get to know of the OpenBeast. So if that breaks, you're very unlikely to install the system and go ahead, but if it shines and if it just works and that's the goal really, then you're more likely to stick to it and it should always be very easy. It shouldn't matter whether you do a network install, a disk install, whether it's on Splunk64 or your AMD64 laptop, it should always work the same and it should be minimal effort for you to do the second installation, whether it's an automated in one or a new one. So in a nutshell, it should be as simple as possible and that's exactly where the problem lies. It's quite hard to do that sometimes. So when I talk about the installer, I often mean different things or more of a group of different components. So what the installer does, first of all, installs, but it can also upgrade. So if you have a running OpenBeast installation, you want to get the new version. The code that does the upgrade is the exact same code that does the installation for you. So when I say install, it really is a word for all of this, for all the different modes. And hopefully, most of the time, you just hit enter, enter, enter. It's a bit of a boring process, but it should be as boring as possible. So you don't have to think, you don't have to choose between options that are not really options and it should just pick the same defaults for you and then work in all the cases. Most of the time, you can also say, if you check back and you reconsider, I think, I don't want to configure this disk or I have to go back. Most of the time, you can also say, abort or done and go back, but it's not always the case. And how it works is all, but the different ways of installing is you can do a network installation where you start with a minimal boot environment, say from CD or a USB flash disk, or you can boot straight disk less over the usual PXE means from a purely network environment and that's how an installation works. These are all interactive ones. That's the one where you would type through and then watch the screen, but out of this, you can also do in an unintended way. Yes, so all the questions you're asking, you're being asked and you answer, you can answer up front those into a configuration file. I'll do my best to not repeat the information you can already find in the manual pages. So whenever you see the dash, for example here, auto install section eight, I'll briefly refer you to this instead of repeating all the information, but just as all the questions you have, you can just write them up front into a plain text file, answer them, and then they will be picked up by the installer and that's it. You can also, if you think there's something else missing in the installer or you need some custom changes, be it configuration files or additional sets, complete list of programs, whatever, additional files, you can also provide an additional set and custom shell scripting and there the endless possibility starts. You can do that if you look at install site, it's a relatively new manual page that explains how to do that. And if you want to upgrade, you can also do the unintended. In fact, this is what most of you, if you run OpenBC, already have been using, probably without knowing, and because the interesting call, the cool tool here is sys-upgrade. What sys-upgrade really is, to put it simply, it's a wrap around the existing installer and all it really does is it pre-faches the sets, so you have them on disk and then it creates a small file called auto-upgrade and that will be up on reboot, it will be picked up by the installer and all the magic isn't really in sys-upgrade. All the magic is already there, have been there for years in the installer, in the upgrade logic. So anyway, I wanted to highlight that sys-upgrade is a quite nice way of reusing the existing code instead of duplicating all that logic in the user space. Of course, there's much more, it also handles firmware upgrades in a very delicate way, but as we hopefully learn in doing that talk, most of these processes and mechanisms are very tightly integrated. So when I say install, it's really not just the script that they're running at the hardware, it begins at logic and tweaks in bootloader and with sys-upgrade, it can start in the previous boot and during during multi-user. So it's a very delicate process with many components working quite well together. But of course, you can also have or you can use this environment you have in the installer just as a rescue shell if you mess up your system or in the unlikely case that an upgrade went wrong, you can take the very same boot media or RAM disk kernel, you can boot that and drop into a shell and then you have the most essential tools at your hand and can hopefully fix everything. So far, it's been, I can't recall a case where I had to pull in anything from an existing installation. Usually I had everything I needed, an editor and the disk repasta, all of this is in the RAM disk and the rescue shell environment available. I'll go a bit, I'll just pick one example which is not covered by the manual pages. But again, if you look at these, what was it? If you look at install site and then auto install, there you can find existing examples for common use cases. One I have at the moment, for example, on my notebook is a file called upgrade site, you'll find this in the manual. It's a script that will be called at the end of the installation or respectively at the upgrade procedure. And it's a script, shell script really, just that runs in the change-rooted environment of the new installation. So for example, if you need to fix up something right after the installer basically finished, or the upgrade basically finished, what I do here is I'm making a backup copy of the EFI bootloader, because on this machine, I have another operating system installed. And whenever this operating system does an upgrade, I don't want it to wipe out my default bootloader. And even if it does that, I always have a backup copy so in the firmware menu of the notebook, I can just select the entry or get the last result in the EFI shell. I can always boot into my manually copied over bootloader and then have OpenBeasty at my disposal. It's a bit of a hack, of course. Not many people are happy with seeing OpenBeasty installed besides some other thing on the notebook, but that's the world we live in. And to get started about the details, the actual inner workings of the installer, I thought of starting with the less obvious components that are flexible, that are not the same on every architecture or on every installation medium. And previously explained when I say installer, this is really the combination of what starts with the bootstrap. So the very first code that runs on your machine, that's highly machine dependent. That's the boot blocks and then the bootloader. These you'll find if you wanna look at the code, you can find that in the SysArt sub-directories. These already have a bunch of variations. Some of them are size constraints, some of them are just inherently architectural specific. Not all of them have the same features, the same abilities or just the same hardware, really. So, and then, of course, depending on whether depending on whether you boot from a Floppy disk or CD ISO or the Mineroot image, which can flash on an arbitrary disk or whether you boot over network with a PXE install. All of this is built together with different components. And then you have principle architecture independent features, kernel features, really, that then again are only installed and enabled, sorry, enabled on the platforms that really support them all the way through. For example, Softrate, if you wanna have CryptoDisk or if you wanna have Softrate5, whatever, then, you can do that on all of the architectures we support, but not all of them support booting of the Softrate disks, right? Or not all of them have support for seeing those disks as early as the boot loader. So that's another aspect. If, for example, you have an encrypted installation on your notebook, that works because you have an AVD machine, but it would not work if you have, say, ARM on V7 machine. So that's a part that's there on every system. And then, after the bootstrap, the second part is the RAM disk kernel. Again, you have different kernel configurations for the different architectures and you have different network drivers, just mostly, these are mostly depending on the needs of the developers. So, say, on an ARM V7, not much work is happening compared to AMD64, Spark64. So if you need some fancy network driver for some network cards or pseudo network drivers like Trunk, you'll find these on the bigger architectures, but probably not, maybe not on the smaller ones, just because no one added them, or because you have size constraints that would not allow you, or not very easily, at least, to add new kernel code. And NFS, just another thing that's the variable. Last but not least, this is the thing you actually, the thing you see as a user is the user space. And it's really, it's the same code, it's the same set of programs you have in regular OpenVC installation, except it's a minimal subset and it is even compiled with a smaller subset of features. So, for example, if you look at the corn shell, you have all the fancy features in the corn shell, but if you have, but the build for the corn shell in the installer, for example, has no internal features to handle your inbox file. You just don't need that in the installer. It's bloat, it's ripped out, and it keeps the process smaller and simpler, but it can also be hard at some times, because if you look at the code and you see all these if depths with a small kernel, it becomes a bit of a mess, and it's probably something we could improve upon. And I suppose at least you have just some programs you don't have in every installation media, for example, not all of them have network, not all of them have an FTP or FTP command that has CLS support, so not all of them will allow you to use HTTPS. These are just a few of the knobs that are variable that it's not as obvious as a manual patch, right? You just see it while we're reinstalling, and then you wonder why HTTPS is not available. To come over to the way it actually works, it's not really a special process. You can really think of the installer as a very minimal, very stripped-down, regular installation. You have a bootloader, you have a kernel, and then you have a classic approach of an inner process, and then it would fork over the RC script, and then it would drop into a shell in multi-user with X11 or whatever. There's lots of stuff happening, but in the installer, it's quite simple. This RC, it's just an empty shell script. I think that's just a single double-colon inside, so that I think the inner process actually forks it off, but then it's an empty shell script. It just acts as immediately. That's how it works on the technical side, but it's probably not as interesting for you as the main user, but knowing this, you hopefully have a better time understanding how the actual stuff of the installer works. It works the stuff you see. For example, in the beginning of the talk, we had this prompt saying, welcome to the B-Steak on Euro 2023 program. This was a bit of a joke on the first prompt you see on the installer. This text prompt, and then how this actually works, is just in huge double quotes, just a shell script, and the mechanisms to start all this and to have the decision logic is the same as you would start any tactical shell on your notebook. It's already within the current shell. It loads a profile file, and in there you have just a little bit of glue code and it will handle the prompt for the question for you whether you want to install, upgrade, and it will do a bit of setup in the back. It will make sure that if you do an unattended installation, you can always opt out and, as a last resort, go to an interactive shell prompt. That's where the timeout is there, and then afterwards it really executes to the installation script proper, and this is where the logic lies. It's just short of 4,000 lines of code. That's including the commons and empty lines. If you open this up for the first time, it can be a bit daunting, this huge of a shell script, but it's surprisingly well structured. It's surprisingly well organized. The style is mostly completely identical. Here and there are a little bit of variations just because of evolution over time and then a new feature was added or a new style was embraced, but another piece was forgotten. Usually, once you come over this initial shock of seeing a 4,000 line in shell script, you can get going quite well, I dare say, and this is where all the logic happens. This is where the questions are composed. This is where the helper functions have, so you don't have to do all this questioning and sorting, whatever we need inside. None of this is duplicated, and come back to sysupgrade. This is also where you have features like if you do unattain an installation with sysupgrade, and for some reason, most of the time, it fills up disk, something goes wrong in the installer, and it doesn't read its finished point where it says welcome, congrats, you did an upgrade and now we reboot. So in case you never make it there, that's so-called watchdog, and that resets itself on every new, for example, set installation. So every time it goes back into the loop and says I'm gonna install the new set, it will reset the timer and then countdown for like 30 minutes and if nothing happened, or if the timer isn't reset in some of these 30 seconds, it will automatically reboot the machine. It's not always the best approach, but it's still far better for you to eventually drop back at a bootloader or a bioscreen, a bootloader, prompt, or whatever instead of being stuck somewhere inside this maze of the cell script. So that's what the sysupgrade watchdog also lies. And then all of this logic is so, try to briefly explain the main source of all of this is machine independent code, right? So this is the common code that is working across all the architectures we support. AMD64, A3, A6, and R&B7, R&B64, SparkCy, there's a huge list of architectures and all this code you see there is executed by all of them. So none of this is duplicated. This also means that there's a huge work or huge amount of work gone into the split of generic code and then the machine dependent code and all the logic in there to cleanly separate it and make the questions that are common to all of them actually common and then make them reusable. So in the end, we have an installer that really mostly works the same on all the architectures and all the boot environments we have without really duplicating the work. I think it's easy to underestimate the effort that went into this. And it's all AMD, that would be a file where you don't have machine specific code, for example, the disk setup. Not every machine has an MBR, not every machine has GPT support. Some machines like Spark64 use neither of them, they just have plain disk labels on the disk, so that's where this stuff would go. If anything is unclear in the process, I'm doing a talk like this for the first time. If anything is unclear, please raise your hand and I don't want to lose you in the meantime. But if you have just a general question, I would defer those to the end. So please don't make me lose you. Next step, I want to highlight the build process. Yes. Yes. I'm too stupid to navigate my own slides, sorry. All right, these. You mean inside the source directory? Yeah, sorry, you would find this on the user source disk trip short forward distribution. This is where these shell scripts are. I think I mentioned them on one of the later slides. But yes, usually if you want anything related to the installer, you go to the disk trip sub directory and then now you will see lots of build scripts and architectural specific sub directories. And this one you would find in the mini route sub directory of this. This is where these actual files are. The way I denote them here, I should have explained this, thank you, is the file layout on the actual booting, on the system you're booting. So if you drop into the shell and you would do an LS, then you would see an install sub script in the root directory of this, of this RAM disk. And then the dot profile, like it would live in your home directory in the dot profile or the slash root directory. So how it works is, or how the overall build process at the example of AMD64 is when you go into user disk trip, I'll be user disk trip arch AMD64 and then you have a RAM disk underscore CD sub directory. The first thing you need to do is, you need the bootstrap file. You can build this yourself. This is part of the release process or there's a copy shipped with every installation under user AMDAC. That's the first thing that's gonna be built in. Again, I'm trying not to repeat what's in the manual so I try to reference the existing manual pages that will explain in detail how these things are put together. But if you wanna look at the actual code, you will look at the make files on the user source disk trip and you'd see the different targets using actually make fast and RD set root. The gist is you need to combine these components. First component's being the bootstrap. The second component that's what people how people often refer to this is the RAM disk and the RAM disk is just a combination of the actual kernel. That's the stripped down RAM disk configuration of the kernel itself, just the kernel and there's a disk image. So that's a path file system with all those programs and they're glued together with make a person RD set root in the end so they have a single file. That would be the file called bsd.rd, you have on your regular installation. That would be the RAM disk, right, composed of the kernel and the disk image and inside of that you have all these user space programs I mentioned before. They live in user district special and they themselves are built into a single binary into a single program. It's similar to what you know as a buzzy box on the Linux so instead of having all this files, you crunch them together with crunch gen and next after that you have the installer code. That's what that was, the install sub and then the profile and install MD, these are the actual shell codes. They themselves are processed as well so it's a bit of a space saving effort so that they run through a small script which strips commons and then unneeded lines inside the script so it's not that much. It will be safe but it'll be worth on some of the architectures. We'll hopefully know about this afterwards in the latest light and we also need on many platforms is firmware. Not all of the firmware we can redistribute freely inside of OpenBC. Some of them we have older freely available Wi-Fi chip firmware that already lives inside the source tree. Whatever we have in there, it gets put onto the installation media but for example also U-boot files for the ARM boards of countless firmware and then the sets. I think I made a slight mistake because the sets are not really contained inside of the, well yeah, they are contained inside the disk image of the RAM disk but if you think BSD.rd of course doesn't contain the sets itself. They'll only hold true for the whole 300, whatever megabytes install 73, so the 73 image you would download but that's contained in there as well and then you have lots of static data like a massive dot pass WD file. These files also live under user distrub and they're copied over but also more importantly you have time zone data so you can actually select during the installation where you live or what time you should be seeing and then you have TLS certificates that configure as well so you can fetch over certificates and then, sorry, fetch over XGPS and then if actually you want to build this you know the first recommendation I should do is just release. This is the whole proper release process if you want to build everything over BSD that will take care of everything and that's the most simple one but this is the slowest one of course. So if you only want to build the boot media so you wouldn't want to build the whole set of clang and all these sets, you can do that if you follow these instructions and this is where we're getting into the territory of things that not really well covered at the moment in existing manual pages. Some of this you just figure it out when you read the make files or when you ask someone and they patiently reply and explain the process so if you just want to build or tinker around with the boot media and then the installer wouldn't test the change you would follow these instructions, make ops you always have to do that and then this is where everything goes and then special, this is the sub directory where all the user space programs are built you have to build these upfront and then you go into your machine specific directory in this case AMD64 and I want to build the RAM disk CD that would in the end give me the CD73.iso that's just a small iso without the sets and the minirude file system and the BST RAM disk kernel you build this and then afterwards in the OBJ directory you have all those files copied them yeah if you want to test them you can do that now with VM control with VMM on AMD64 it's very handy that's how I most of the time prototype quick changes I just fire up the kernel itself you see there's nothing but the kernel sorry nothing but the RAM disk so if I boot this up I land in the installer but then I couldn't perform a full installation there will be no disk, no interfaces but this is enough for me to enough most of the time to test certain changes to just have a live look inside the system that I just built and see who made any mistakes there are and this is where it gets quite technical because it's not really the best system with regards to introspection like this has no detrails obviously but with shell scripts you know how this works but if you want to even look inside it's a little bit you can do hopefully a small trick here and there with corn shell itself which should help you regardless of the set where you're working what I did is you can source the entire subdirect the entire installation script by sourcing that will mean you just basically load all the definitions the function definitions without executing any other code and then afterwards you can say with typeset and that's a generic control function you can just inspect the function definitions and that often helps me to find out before dropping into the actual installer find out what the actual function does or just run them on the spot if that would work but it's not really it's a very limited environment like none of these functions were ever designed to be executed on the spot but instead whenever you reach them inside the logic but nonetheless it's an effective way if you want to see what's going on or if you want to make changes you have an ED editor that's all you need you can life hack the installation script you can just edit it and then add your new function fix your bug tweak the bug you just introduced and then drop back out of the interactive shell you would lend back at the install upgrade or auto install prompt with the now edited install script and then you could test this it's not the proper way to hack at this but it's way faster than building the installation image seeing that you make a typo mistake in the shell script drop back out build everything again boot it again so this is for prototyping but of course you should always test the proper installation so fire up a proper VM or even better yet use real hardware not just a VM because that doesn't cover all the use cases by far not so if you actually want to hack on this please use real hardware and then replicate the real scenarios because it's a very very delicate system and I've done this many times myself I thought my change was great I tested it I worked for my use case and now you might even have committed it and then only to find out a day later that someone else found a flaw in another very very trivial installation use I just didn't in a very very trivial installation use because I just didn't cover myself so please testing is a very important point to highlight a few recent changes in the install and it's a bit hard to say recent because I think the first one I mentioned here is already a year ago happens quite fast we release twice a year but nonetheless it's interesting to highlight what changed sometimes it's the small stuff I'm installing inside of VM without networking that's the full installation image attached I have all the sets it's a purely offline installation but it would still ask me to configure networking the installer itself would see there are no interfaces but it would still ask me what interface do you want to configure do you want to configure VLAN zero and that would be no physical interface that's stupid right but at some point I think steward handles and what was that removed this VLAN check and then afterwards we just dropped the interface configuration altogether when there were no interfaces it's an obvious change but it's the combination of all those trivially changes that hopefully make the open B-Steak install experience the experience you know today right so these changes often seem small but that quite an important change the time and then a recent change by Andrew was the ability to configure your interfaces not only by an interface name but by the hopefully unique MAC address so that as well is documented in the hostname.if file and it's really the same mechanism as you have in user space so if you've already done interface configuration by MAC address it's just the same so now instead of at the prompt where you ask which interface to configure instead of answering EM zero you can just give it the MAC address and go that go that way and then there was a better better sense media default yeah that was the question for the disk that would contain your installation set right you would first select your root disk and say it's ST0 that's the only disk I have that's the one I'm going to install to so obviously there's nothing on it because I'm going to format it and fill this disk with a new installation and then the new question would and then the next question would ask you so where are the sets? is it on the same root disk? obviously it's not on the same root disk these are little disks that we can sometimes make a small tweak but it will have a good chain a good outcome like instead of having to enter an explicit disk name you could just type yet another enter with the same default and same for A people got lazy I didn't want to type autocon for the interface of the IP configuration so now I can just type A and another and that's a change list of changes that we've been working on for the last few years by now it's a bit of an extreme example but it's a very good example to illustrate the intricate details and pitfalls in the installer so I've added this new question to allow you to encrypt the root disk before this you would follow the FAQ and you had to drop into the shell and do all these steps by hand and hopefully make no mistake nowadays we have a proper question for this so you can just say yes and no and then possibly be prompted for a passphrase and then you will do all of this but what might seem like a a single line of addition to the installer that now defaults to no is really the result of a huge list of changes that came into the tree over the years ago right so we've been supporting or officially supporting encrypted disk installations on AMD64 and other platforms for years but if you go to the install and add the new question and then you want to have support on not just AMD64 you start to realize that there are many many corner cases no one ever ran into or no one thought about and what it means to add a new question is not just to have support for a single architecture for a single use case but really to make sure that this is covered in the same expectation of you know it just works on all the different scenarios so that was just a good example and it's also a good example of how the install is not just the self script I explained earlier but it's really the combination of tools that start as early on as the boot loader and the boot plus the very first code that runs before the kernel and then auxiliary programs like install boot which take the existing bootstraps off a disk and install it into the into the first few megabytes of the disk and take all the take care of all these little machine specific details and they're hidden away behind a single command right so commands that used to work just fine on on your favorite notebook that but that would just crash or do slightly different things on another machine just because no one thought about cases like the disk encryption on another case so that's a good example that when I say install it's there's way more to it than that meets the eye and I've learned that myself quite a few times by breaking the install and having to back it out or adding another fix on top of it and it's a long process it's a very fine process very interesting and entertaining process but lessons learned I think I've dabbled into the lessons learned already it's more complicated than it looks but nonetheless it I hope that it doesn't discourage you from from looking at the code or maybe making your favorite change or buck fix to it or just learning about the project and learning how it works and being curious thank you and it's more than it seems right so all of this most of this fits onto a small I-386 floppy disk it's a few megabytes and presents you with an installation set of that will do an installation do an upgrade do an unintended do an interactive upgrade over network all of this works quite well and sometimes surprising all you manage to do with that with that little space speaking of the floppy every now and then the kernel code grows or anything grows really and then these very very size constraints set up start to break and you can argue that no one really cares about I-386 floppies these days anymore but it's a really good measurement for you to keep noticing where the code grows right if you just hack on a 64 and you do hack away and you're not having size constraints but then someone yells at you because the the bill broke on on I-386 you start to realize something something has been creeping into the kernel over the development cycle this year and time to start for spring cleaning again and then you realize oh maybe this 20-year-old driver for hardware that no one no one really has anymore maybe it's time to clean this and bring this brings bring this around the corner so even though they're not really that relevant anymore they're still a good measure and very very useful to the project it's thing I had to learn over the years it did was absolutely not obvious yes and the new question I added also told me that good phrasing is really hard so if you want to ask a question there are so many ways to ask that question and think that you are they asked it in the right way but the first the first version I added that word it was you know it was at the wrong place in the insola it was it had the wrong wording I thought the I thought users would understand the technical wording but it was just too complicated and just need feedback and iteration and it also showed me that if you mess with the people's muscle memory it's it will be noticed right so even if you used over the years to just hit enter enter enter sd0 enter enter enter to to have a default installation and then some young fella comes around and adds a new question that will make you enter enter sd0 and suddenly and the wrong question with sd0 this will go this will not go unnoticed and it but it goes to show how how used people are to this interface and how important this is and if you mess with it you can enter problems but it's easy to work on it's it's it's just normal part of improvement and then development so yeah mentioning this did the defaults hopefully quite great already but then have a perfect and asked with the initial question where I asked you whether you miss answered that the set of user question maybe someday we can we can fix that so you will always hit the right answer but also some of the questions you can back out of some of them if you enter once into this not logical branch you have no other way but control C and then or exit the installation and you restarted it's not that much of a problem because most most of the questions are being remembered and you can just hit enter instead of refilling the same information but but still it's a so it's an interesting aspect I would like to to follow over the to follow up on and make this even more resilient and make it as boring as possible but boring turned out to be really hard and if you're into encrypt encrypted key disk sorry encrypted installations at the moment we only support pass phrases but there's also a way to do this with key disks if if you want this feature or if you think is interesting that's a different tech already that should be maybe hopefully good to go and then that's very hard way done and sort of a future plan or interests I have is you know a bit of more multi-boot awareness because if you these days you end up with multiple OSes on on your machine and open beast he still has the expectation that if you installed it on the machine it really owns the machine and it it's true but only up to a point and at some point you have to with this operate site example I provided you sometimes have to work around or do you make this work better together Linux has as more of these when it's bits and I think open beast he is at the point where it should catch up with this well that's that's all I have so far I'm I hope you could follow me color could follow me up to the end if you have any questions this is the time if not you welcome to shoot me a question via email in the first light I'm happy to help people get started on this code because I know it's not always that easy but I would welcome people being interested in actually hacking on this so that's it thank you very much yeah sure how difficult it would be to mm-hmm no and the answers no you never get the same installation and it's very unlikely that we that you will get same installation from the same installation media because there are processes in the ins or procedures in the installer such as a re-linked kernel so whenever you install an open-base system what it does as a security measure is it takes a corner actually relinks it so with every installation you have it OpenSD you get to have a unique kernel which is a feature but it's in direct contrast to what you want reproducible installation so sorry for that I don't think this is on the roadmap yes to mention that in even in the five system itself you have a random bits left and right so it's it's not the direction that the project is heading reproducibility at least not in this step thank you anything else not that's it