 Hi I'm Leonard buttering and today I'm coming for your bootloader Yeah, this is not as new as the stuff force that I talked about yesterday, but I still think it's kind of interesting But of course I would say that but anyway, this is I'm gonna talk about two closely related, but distinct topics like one is the bootloader spec and One is SD boot as the boot some of you might already know, but my hope is to make it more Well known among those who don't know it yet So, yeah, I'm talking about bootloaders So let's jump like right in. What is the bootloader specification? What's the first topic? I want to talk about the bootloader specification is a Specification which you find under this URL it defines Well, let's then ask the next question. What is actually as the boot? What's the other topic? that is a bootloader that is documented there and It used to be called gummy boot and it implements the bootloader specification So let's have a closer look what bootloader specific specification actually is It's a generic specification on any platform any firmware that Allows you to define boot entries, which are simple drop-in files These drop-in files are supposed to be placed below a location called dollar boot Like that's just a wild card name because there might be various different ways to reference it So it's not really in anything called dollar boot. That's just like in the variable where one option is that dollar boot is a partition of type EA hex on MBR partition tables or on a partition of this UUID type on GPT like we just picked that up because it was Not used yet option B is that dollar boot actually equals the EFI system partition for those who don't know EFI's that well I mean all your laptops all your current laptop is least probably boot with EFI these days and The way How linux gets ultimately started is that the firmware the EFI firmware finds a special petition which is the ESP on your hard disk and once and find it Yeah, basically starts some binary in that thing that is traditionally grub But I kind of want to advertise it to you to make this SD boot instead And that then eventually invokes the linux kernel and then from then on you get in order to then system decent control but Yeah, if my system petition is something you have on all your computers regardless if you run windows or linux Even macOS they all have one ESP that contains like the stuff that the firmware supposed to Load the specification that I'm talking about Can use the ESP to find these snippets that I'm talking about The file system for dollar boot is supposed to be VFAT like Microsoft file system The ESP kind of suggests that anyway if it's used like that, but even if you're not using the ESP for this purpose Use VFAT anyway, but this is not actually enforced to require anything like this is just a suggestion So these snippets each define a boot menu item, right? Like, you know grub when it shows you like this menu that you select what you actually want to boot each of these snippets actually defines one of those Yeah, just as a side note by the way if You actually use The GPT petition was that you your ID value or was that MBR? Marker then system. He actually mounts this automatically at slash boot Which is something really really nice because it makes things very robust and you don't have to have at CFS tab around right like any Petition that is marked that way that is on the same hard disk as the root petition of your operating system will be Entirely automatically always be mounted to slash boot Unless you actually have a manual entry in which case that takes precedence and similar if you use option B Um Yeah, the ESP gets mounted to slash EFI nowadays Unless you have a manual entry for it again So this is actually little known and unfortunately most of the distributions that actually make use of this They really really should because it allows you to like basically boot up the system without any entry in FS tab But anyway, this is kind of a side show here actually it just is supposed to show you that if you stick to The locations for the bootloader spec that I just suggested then you have this wonderful benefit that After boot everything is automatically discovered for you as well So let's have a closer look on these drop-ins that I mentioned each drop in as mentioned defines one entry in the bootloader menu Two types of these there's type number one, which is like a config file These config files just define a kernel just boot and in a dot-e boot a title for that a version for that and then a Entry in the boot menu is created through that Yeah, simple text files describing kernel entity name and other metadata and there's type two. It's in a slightly different Directory and these are EFI binaries for those who don't know ESP that well is P EFI that well EFI is actually a little bit like this firmware Interfaces a little bit of an operating system of its own that inherits lots of semantics from DOS, but also from Windows not so many from Unix, but It knows a concept of EFI binaries which are just executables as you might know them now in the second in type 2 mode the the entries are just one EFI binary for each menu entry, right so and no further data just that Let's have a closer look at type 1 generic This is like type 1 entries are generic and very flexible because you can create them with your text editor And then you can just add to that whatever you want to add you can generate them with a script It's completely up to you and very very simple type 2 on the other hand are Simple in a different way because basically you just have for each boot menu entry that you have you have altogether only one file because Yeah, the EFI file encapsulates all the other bits in one, right? So because it's one file that incorporates the EFI binary for the operating system like the Linux kernel Also incorporates the unit already Corporate some metadata and things like that. You can sign them as one that is awesome for Shakya boot stuff Of course this concept is specific to you if I While the boot loader spec is supposed to be generic and useful outside of the EFI spec If you use these kinds of binaries, of course You are strictly within you if I simply because the concept of EFI executables does not exist Anywhere else by the way if any of you have any questions I know that there's a lot of very low-level technical stuff by all means do interrupt me right away in case I can clarify something What's also awesome about type 2 stuff is because it's a single file we can do single file updates This is really nice for something as fragile as a bootloader because it basically means that Dropping in a new entry into the boot menu means dropping in one file Removing one means removing one file Renaming something means renaming one file So you never have this risk that you update do you drop something in there and you drop something in there And you drop something at the third place and then you have to pull it all together by adding this Force file and then if something aborts in the middle you get a like half installed kernel and the Internet is missing and stuff Like that all of that doesn't exist because it's just one file Both of these types are equally supported by the bootloader specification Both of the types has their use cases for many use case type 2 is nicer for other use cases type 1 is nicer To be more specific how this can look like this for example is the bootloader Specification snippet type 1 for Fedora 30. I hope you can actually read that even in the back rows there It's a very very simple Configuration file it's purposefully simple So that even people who hack on bootloaders can easily write a parser for this right? So there's no Jason no fancy stuff There's no continuation in lines or anything like that. It's just one word followed by some value I think most of this should be pretty self-explanatory. There's a field title. That's the name for the bootloader menu item There's the version which is the it's a version for that the idea Why these entries have versions is so that the bootloader menu can automatically sort each entry and automatically put the newest entry first Their machine ID is useful like the machine ID is actually the Same machine ID that you see an Etsy machine ID after you booted up the system The idea is basically that if you have multiple operating system multiple Linux is installed on the same system That you can see which options which many like kernels actually belong together Simply because they will all carry the same machine ID There is options. That's really just a kernel command line string. There is Linux This line actually specifies a kernel binary to execute and there's an ID which you guess it Specifies the inner ID. I know this is again very technical and maybe some of you don't know what an inner ID is An inner ID is basically the first thing that if the Linux kernel initialized after the kernel itself initialized it starts the first user space program and On most generic Linux distributions this first program sits in a little bit something like a tar ball But it's actually not a tar ball that Is loaded into memory by the bootloader already and that thing is then responsible for finding the rest of the operating system So usually when you boot a Linux system you combine both you take This is the kernel and this is the first program you're supposed to start. So that's what it's about. So this is yeah For anyone who ever dealt with bootloaders, this should be very very self-explanatory As mentioned both types are supposed to be like complimentary you can use them together if you want So you can have some operating systems on your like if you can install multiple operating systems on your on your Hard disk and they all will all share the same ESP or the same Yeah, dollar boot location all these operating systems can drop in their own boot menu items simply by dropping in one or More files in case of type one or type two But each one of them because they can drop in their own files They will not step over the files of the others which is systematically different from how things used to be with grub and all these bootloaders because Grub can only be owned by one operating system at the time and when you install multiple Linux operating systems on the same system they tend to end up fighting for the Who owns actually the bootloader and how the other ones get to register themselves? Anyway, thief in the bootloader spec all items describes themselves and Can be combined freely Yeah, this is what I just said bootloader and drop-in directories are shared between the Oasis That's kind of the key here, right? It is not our like I mean there is this if you ever install multiple operating systems or just multiple versions of the same operating system like Fedora 30 and Fedora 31 you always have this problem that they Fight for who owns the bootloader and who gets to write to grab CFG or whatever. It's called This is supposed to fix this right like simply by taking a lesson from how we do drop-in directories from RPMs Right, you nowadays know that that for example install a GNOME program via an RPM on your system What actually happens to make it show up in the menu of GNOME shell? For example is they drop in a dot desktop file into some directory where GNOME shell ends up looking we just say And this model is used all across Linux nowadays like for example if you have an RPM then contains a system You service what does it do? It drops in one dot service file into a directory in Etsy and that's how system he learns about it and so we this is how we do these things in Linux and the bootloader spec is ultimately just taking that inspiration and Saying drop-in directories are awesome for jointly managed, but independent loose coupling components To register something with something else. So let's just do do that for the bootloader as well so bootloader and drop-in directories are shared between OS's in a safe way without these Multiple operating systems to ever step on each other's toes Because they will never own the same files together They will only Yeah, it drops stuff into common directories together Yeah, of course the bootloader that actually boots all these operating systems that needs to be installed once But the idea is really you have one bootloader and many co-operating players multiple versions of the same operating system Or multiple operating systems all together The bootloader specification like this was very quick Overview what it does if you want to read the full thing go to the website. It tells you all the further details about this The takeaway is the bootloader specification is supposed to be very generic way how operating systems can described how they want to be Started it's implementable by any bootloader, right like in fact, I Couple of years ago wrote a module for grub that just implemented that the big difference being Yeah, in that case you wouldn't have to constantly rewrite grub CFG when you add a new your kernel But it would just yeah find automatically what it what these bootloader specifications snippets actually defined One specific implementation is the second part of the talks that I'm gonna want to talk about This is SD boot is the EFI bootloader shipped along with system you can use it independently too, but it helps us Maintaining that together with system D because it basically allows us to do adds a couple of integration points between system D On the host and the bootloader before it System D also makes use of the bootloader specification at a different place specifically in system D's k-exec reboot mode, right like you know that if you reboot a System D system you do that with system control reboot, but there's also system D system control k-exec if you do that then We won't return to the bootloader and the bootloader will start the new operating system to start on them after the reboot, but instead it's The old Linux that finds the new Linux kernel to start and then uses the kernels k-exec mechanism To start that it's the k-exec is something that the kernel supports where you basically can replace the current kernel with another kernel So if you say system control k-exec we somehow need to figure out which kernels to actually start So we use the bootloader specification with that so that basically allows you to actually even use system D itself as a bootloader for another operating system that is registered that way so Yeah So far about the bootloader specification if anyone has any questions about this so far would be the perfect time to ask a question now That's one What about the support for other operating systems, I mean in the past you hard-coded Linux But what about free BSD or even in a good future Microsoft Windows? So very good point Here you see like the fifth line that says linux, right? This is how you specify linux carl actually This is just an example that couple of more stands has defined There's one more for example. It's called EFI then you can specify an EFI binary and Windows and Mac OS They get started as EFI binary. That's how we can hook those up There also people have said send us patch and we merged it for multi-boot specification, which is how you can start free BSD in these kind of things Yeah, so The bootloader that we implemented ourselves like SD boot Does not implement the multi-boot specification for the simple reason it's too dumb But the bootloader specification is really supposed to be something that everybody can implement right bootloaders for mbr Bootloaders for whatever year else you want And not even just that actually Ideally we want that the bootloader specification is actually something that just the firmwares implement directly because there's no reason to Plug a bootloader between if it doesn't do much more than just show a show a boot menu. Oh with Multiple operating systems operating cooperatively to add entries. How is the default entry determined? So that's a very good question, but let me quickly finish that but now I forgot your what you Well the tape I says Linux it doesn't do that type 1 says nothing Linux specific. It's type 2 that says this Yeah, it has lungs in it, but It it doesn't matter really what you have there you can put anything in there So, I mean we put it the Linux in there because these are EFI binaries where we request that you add a special metadata Object into the binary so that we can extract from the binary the information like what's the name for the menu entry? What's the version for this so that we can have that information, right and that is Linox specific but also Linux specific people could also do that with honest binaries ignore the Linux thing. Anyway, your question again was about what was it again default entry. Oh the default boot entry so SD boot right like I mean this is of course the precise algorithm implemented for this is up to the bootloader that wants to do this SD boot has a logic it orders By the menu entry name alphabetically and then individually for each of these it orders by version putting the newest version first So if you only have one operating system installed It's always going to be the newest one of that and if you have multiple and it's beneficial if you if your operating system starts with an A Yeah, that's that's why we did that of course So what about integration with different architectures like IRM and so So the specification is explicitly supposed to be entirely generic Regarding which cut kind of firmware you have and what kind of bullet I have and also what kind of architecture you have Our implementation only works for EFI people have are running it on arm and on x8632 and on AMD64 and I think even some people did it for on AI 64. I'm not sure why they care about that stuff, but I Mean the specification is so generic right, but there's nothing specific in there. There's actually one key But I don't have that here, but there's actually one key defined that says architecture even for the snippets Because sometimes it might be interesting That you might want control that you can define a 32 bit kernel that you want to show on 64 bit EFI because that's actually compatible some way or sometimes you don't want that So we added this key specifically so that you can make filtering land and decide things like this, but yeah summary is The specification supports it your bootloader, hopefully too Anyway, then let's switch to the To sd boot so sd boot I always claim as a boot loader, but it's actually not It's really just a boot manual like a boot loader is something that takes some operating system image loads Into memory and then jumps into it sd boot doesn't do that sd boot is a efi binary and it shows you if nice Rent as a nice menu on screen. You can use keyboard and stuff like that And what does it do when you select one it just invokes whatever you selected as an efi binary again So it's the bios the firmware that's actually doing the boot loading It's not sd boot. Of course this distinction who's actually loading stuff into memory and stuff like that is irrelevant for most people That's why we just sloppily call it a bootloader even if it's really just a dumb dumb menu Sd boot is a efi only It makes the world so much easier because we have file system access we can do all kinds of very simple stuff And yeah sd boot as mentioned is shipped with system D For reasons that we can like we can pass lots of little bits and information between system D To the boot loader and from the boot loader to system D like starts with performance data But it's also like that system D can tell sd boot for the next reboot What it shall be shall be booting into which is pretty cool actually because you can you can then say from for example Gdm you can click on something booted to windows and then you can tell then you can reboot and Automatically boot the windows because sd boot will then know It implements of course a boot loader spec With limits it only supports invoking efi binaries nothing else I mean, that's totally okay by the way if people do this right like they always like our primary interest with the boot loader Speckers that we get people to Accept that as what to unify on and then of course we're completely aware that on different architectures different firmwares There are different sets of execution environments you want to support fine Do it and ignore all the other boot entries. We ignore basically all boot entries that do not much match our expectations about efi What sd boot also has this nifty feature is that it actually automatically discovers windows and macOS installations on the same hard disk Which is super awesome, right? It does that at boot, right? It's very different from how distributions did this was grub right like where you have this humongous horrible script That collects all kind of data from your operating system to generate the linux entries and then goes on and tries to probe all system petitions for Windows or macOS and then generates some magic weird programming Script out of this that is then processed again with m4 or something like that and then you get any output This is so much easier because this thing actually while because if I is so much easier to to work with during boot It just looks like is there also windows installed. Is there also macOS installed? Oh, let's add a new menu entry for this requires zero configuration. It's just if it's there it shows up Has a couple of other things as well like for example if you have the efi shell Which is like the DOS prompt, but just for you if I installed will automatically find that to add that to the boot menu It also has if the firmware supports it and all modern firmwares do It gets a boot into firmware menu item where like we nowadays live in the world where booting can be very very quick so most of the firmware manufacturers did this by not necessarily initializing all the Keyboards any more in particularly if you have us be once that makes it difficult to enter the firmware menu this way so it's very very useful if at least the Bootloader menu the one that we implement gives you the ability to return to the Far more menu. So you basically yeah, if you manage to get into sd boot into the boot menu There's an item you click on it. Bam. You're in the firmware setup As I mentioned already it doesn't do anything else been running if I Um variables, um, it's one if I binary you just drop that into your ESP and Our next boot will automatically find these drop-ins will automatically find Windows and Mac OS blah blah blah blah I showed in a menu you pick something it boots it up. There's a tool called boot control install Which does that for you, right? It's super duper stupid. It just takes this If I binary like the compiled version of sd boot Takes it from some directory and use a lip where it was shipped in the rpm And then does a simple CP basically and puts it into the ESP and that's I mean It does slightly bit more like it creates the drop-in files for directories for you But mostly to make it beautiful not because that was necessary. It's totally sufficient of the first one creating the boot entries actually does that but yeah If you want to update the thing there's boot control update updating is what you would do if You installed a new version of sd boot that has some newer features and yeah, it's a little bit smart Like it checks it looks at the if I binary Reads the version out of it like when it was compiled what system the version it was Compiled from and only if that's if it has a newer version will update this It's the idea basically of this is that the rpms of Sd boot that are shipped with the various distributions like for Doros or whatever if they should all adopt this which of course they should that they can all just call boot control update from the rpm scriptlets and Yeah, the newest version of the of sd boot will always win and be automatically updated to make this fighting around the bootloader main binary unnecessary It has a boot control status that tells you if it's installed or not and it can also tell you which Which boot menu entries are actually existing right now So that you can know while you boot it into Linux Which are the boot menu entries that will show up if you would reboot right now and would see the boot menu Yeah, they're pretty trivial commands Just to master mention that they have a couple of other nice features like for example the command line editor Grub has that too nothing too fancy If I has this nice concept called if I variables which are away how the bootloader can communicate with the way In both directions we define a couple of those for example to select the next entry to boot into I already mentioned that this is useful for implementing boot into Windows from Linux, right? You click on GNOME the button somewhere boot into Windows and just just that It has this in two ways just for the next boot or for all future boots. I Yeah, you can also Is an if I variable to select the boot timeout, which is just how long the menu is going to be shown before the default menu item is Selected This can be used in various ways like for example You could also add a menu to go like a menu item to GNOME that says Boot into boot menu and all it does it changes the timeout from 0 to 15 or something to make sure that the menu is actually invisible to the user Already mentioned that briefly there are also if I variables for performance data Specifically if you want to know how quick your system boots up You want to know how much time was spent in the bootloader and you also want to know how much time The bootloader spent waiting for user input Before the user pressed enter because that data is usually not that interesting to you Right like because it just means like how quick was the user to react So we pass all the time in data along and actually system de-analyze if you have applied with this actually reads that data And automatically makes use of this very useful information What's also very interesting is it sets an EFI variable referencing the used ESP Right, which is something that is weirdly missing in the if I specification that the operating system Otherwise has no way to figure out which is actually the ESP that was used for booting because there can be multiple options for that Let's say you have the hardest whereas an ESP, but you also plucked an USB stick that also contains the ESP because it's the windows Live media or something that's not always clear. Which one is the one that's used We send if I ever tells us that it's actually what we used to that mount slash EFI as I mentioned earlier There's also an EFI variable that enumerates discovered entries Just that tells you yeah, what was actually there on the previous boot That it found and usually tells you also if there's a windows or macOS installed parallel it's kind of similar to the boot control status output that I Mentioned earlier the only difference is this shows what was actually there when the boot loader was last running While boot control status is tells you what it's right now there There's also an EFI variable that Declare the feature set of the boot loader like which of these options actually supports This is really nice so that GNOME can show the menu items when that I mentioned when they are available But can suppress them when they're not Actually most of the stuff that's on this Slide is not specific to SD boot. We kept this entirely generic so that any other bootloaders can implement that too So far we're not aware that any of those do right like if bootloaders implement this they get this wonderful benefit that Systemally at various places actually will start making uses of the information like for example system to analyze Will show you this among the normal performance data that it shows and system control reboot has this option reboot into Boot menu item that will then suddenly work But yeah, there's a little bit of a like the grub people they're not interested in this kind of whereas integration So yeah, we did our side of making this Open but so far there wasn't any interest from the other side So far about the basic feature sets, I hope you've got the basic idea what we're doing here right like I would like to clean up how we do bootloading on Linux a bit and dumb it down substantially and Diminish the risk how the various players in this field fight around common resources, right? And I hope you also get the idea that the specification that that we did is really supposed to be something that is Systemally makes use of heavily and that we really would like if Distributions would adopt across the board and that while we implement them and as the boot They're actually not as the boot specific and any bootloader can implement them even without ever mentioning system D By the way, but yeah, there are questions now is would be a perfect time to ask questions Do you have any plans to implement? verification of Like a secure boot or encryption encrypted boot partitions that kind of stuff that is a very good question I think this kind of a verification like second boot is very very important how we should build our operating systems It is the reason why this type 2 Bootloader entries exist right the unified ones where you take a kernel you conquer that in an ID to it You can add a boot splash actually to it You can add a lot some little metadata that is gripe the things and you can add a kernel command line string to it If you that's all combined into one EFI file one PE if I file that you can run And then the good thing is if we do it this way then you can take this whole file and sign it with PE sign for second boot, right? So that basically means that During if you want a fully secure boot path All you have to do is you sign sdboot itself You generate these unified binaries you sign those and then the inner D that's inside of that needs to verify the The root file system, but then that's already all you need for for having a secure chain So it makes this so much simpler because there's no not not that many components that have to verify each other It's just that yeah firmware verifies sdboot sdboot very it doesn't even verify anything It just asks the firmware to verify the unified carlamage and then the carlamage is just the root file system And there you go, so I think it's very important But our approach to this is we don't do anything we just make sure it's in a very friendly way So that the firmware can do this for us for free so Sorry, my question is rather about I guess it's an asshole question because it's about the chances of adoption In the sense of I mean, it's it's not a bad idea. Obviously You need to get us into grub realistically, right? Well, I mean so Yeah, grub. I think grub is a problem not a solution. I don't know, but file system drivers and user space Yeah, what was them? You only do with if I write Well, the boot loader specifications completely generic, right? but I mean my point being for sdboot to be Used instead of grub must probably do something similar, right? No No So the key really is that we agree on this dollar boot petition and that everybody puts the stuff there and Ideally on EFI that can just be the ESP, but if that's not possible you have a separate petition But inside of that you have VFAT VFAT is something that EFI reads anyway Linux reads anyway Grubb reads anyway everybody that's kind of the lowest common denominator that everybody can agree on that is already Built into hardware that even the the the freaking raspberry pi weird firmware actually supports some form of Fat so the idea really is just use that and you have to have that anyway on EFI machines, right? Like you cannot boot EFI without an ESP around right so the idea is that yeah We just define one way how to define that stuff and one directory where you put that stuff. That's it Make sense But yeah, I mean your earlier question regarding grubb is I wrote that patch as mentioned that added bootloader specs support to grub but That was four years ago or something like this and didn't go in and I didn't even want to fight that stuff I think yeah, I would really like if distributions would adopt that I we'd never talked about this public so much It's like only a second talk that I'm doing about this so it's definitely my intention to push this harder and Yeah, I know that this is this is like said lots of people who have lots of time and love invested into grub I think the approach of grubb is just too complex and too fragile because it it's in like at least the way We have implemented this on Fedora and well, it's like a programming language that generates a script that Then generates a script that Jen ultimately generates a script that the bootloader in Executes as a as a touring complete language and just like Jesus Christ. That's so wrong in every way So this is supposed to be the complete anti-thesis to any of this right like because there is no there's no programming language in this There's no no no shell scripting in this. There's nothing. It's just let's just agree on one petition One directory and everybody just puts some stupid files in there the way how RPM and TPKG figured it out like 25 years ago or something If I wanted to modify or pass the kernel command line Parameters and I'm happened to use either type one, but more interestingly type two binary and Can I do that? And is it like an EFI app? Slash arcs or what what is it? So it's a very good question So for type two, right the ones that potentially assigned yeah We probably shouldn't even allow that at all right like if you turn on second measure them into TPM Sure, but I mean then then then you can as well sign them right like that's no different right There is big difference between signed and measured sure anyway, but The model that I would assume there is that if you turn second boot off You don't want the user to make changes to this right? I know you want to so you want to turn on secure boot and allow some changes and make policies based on measure of whether what was But my assumption is generally that that if you lock everything down then Locking down the kernel command line is one of those things that said there's also type one stuff And I know that people also want to be able to use type two without this stuff, right? If so they first of all have of course the option to make the changes interactively right at boot There that's an SD boot implementation feature to change the command line Sure, but every bootloader does that like Grapp allows you the same thing, right? Okay. Yeah. Yeah the other thing is like we have been talking about adding a At least to SD boot now if I variable that is just read during boot Append it to the existing stuff, right so that you can override the defaults if you want And then we would probably add a logic that by default on secure boot We don't do this but on other cases we do what I yeah But then you basically what could do something like for example that when you shut down you add to this if if I variable that Like the at force FS check mode or something then you reboot once and we can do it like this That we have one variable that gets removed on the next boot so that it only applies once and one variable That applies forever so we can very nicely do the same way you've just set the force of s check for the next boot And then not for the subsequent ones without that's something actually nobody could do before right like if you if you want I said FS check for the next boot once and crap. That's messy, right? So, yeah So do you have a Specification support of boot counter and rollback situation This is actually I mean if I had twice the amount of time. This is what it's about. Yes Sdboot support said there's another specification that is very closely related to the bootloader spec that adds all that Where you basically can specify boot this automatically five times give up if that happens then go to the next one my recommendation is read this Documentation it's it's a very simple mechanism. The count is implemented in the file name for us. The reason is For this is because we hope we hope that given the shitty defect drivers in the firmware as we were looking for a simple Way to change the file system that has the least chance to crop the file system if the file system driver is bad And the good thing is that if you rename a file on fat There's at least a very good chance that this can be done was a single block, right? Which we think Yeah, it's the biggest chance, but of course it's a bet but yeah anyway if you want to know a bit more about this read the map page Hey, so two questions one is VFAT is not a requirement for BLS, but for Sdboot VFAT is a requirement, right? Not really, you know on Mac OS like on on Mac machines They actually implement like what's the Mac OS file system HFS plus driver in the firmware But there are gonna be file system requirements depending on for us, okay? It's more even more complicated like this than this So I had this long discussion inside of a red hat in particular where people said oh VFAT is so evil You shouldn't use VFAT. That's not safe. We need to use a proper file system to this I'm not sure how much I agree to that idea, but regardless The firmware will generally only start VFAT. That's fine as I Mentioned there's dollar boot and can either be ESP or can be this other petition if you load a user space File system driver for any other file system of your choice From the ESP before or buy Sdboot Then this allows Sdboot to look into the other petition of that type and looks at stuff there But Sdboot's never gonna maintain an XT2 driver or whatever people want there What we probably will add is is some kind of drop-in director We can add file system drives as much as you like then you maintain the folders system drivers We don't have to give a fuck, but I will look on those petitions. Anyway, I think my time is very much over Thank you very much if you have further questions, you know where to find me