The Syslinux Project
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Anvin, Peter H.
This talk will discuss the x86 boot process, how to make it work in a dynamic system, and the tradeoffs between versatility and reliability. It will also discuss the Syslinux modular interface and how to use it to quickly add new features with a minimum of coding. Originally written during an all-night hacking session in 1994 with the intent to better support the then-ubiquitous install boot floppies, Syslinux has evolved over the years into a widely used boot loader suite with an advanced modular interface, with emphasis on ease of use and reliability. It is now the most commonly used x86 bootloader for removable media, and is increasingly used for conventional hard disk booting as well. FOSDEM (Free and Open Source Development European Meeting) is a European event centered around Free and Open Source software development. It is aimed at developers and all interested in the Free and Open Source news in the world. Its goals are to enable developers to meet and to promote the awareness and use of free and open source software.
 This part of the kernel track, but I'm actually, it's actually a bit of a lie. I'm not going to talk about the kernel at all. The kernel is what comes afterwards. So I work for the Intel open source technology center, but this is not an Intel project. So don't blame them for that. They also like me to put this up. Cyslinux, as of right now, is a suite of bootloaders. It currently consists of four, what I call, derivatives. This is a bit of a legacy term from when the differences between them was much bigger in terms of code. It really comes down to different file system support. The original Cyslinux, in all caps, just to be extra confusing, is for FAT file systems, MS-DOS file systems. This was originally done for boot floppies. Followed that came network booting in PXC Linux. This is named after the PXC standard, which is the standard for network booting on X86. Followed that was ISO Linux, boots from CD-ROMs. This is, of course, from the ISO9660 file system. And most recently, EXT Linux, as a general-purpose bootloader, loads from Linux, EXT2, EXT3 file systems. And I promised Ted that I'm going to get EXT4 in there really soon now. Right now, this only supports the X86 BIOS platform. And this dates back from when this was designed for boot floppies. Cys mattered tremendously. Floppies aren't very big, so any overhead not being left for the kernel was a major problem. So the solution was to make it as small as possible, and that meant assembly language. This has since become a liability in terms of support and maintainability. So I am very much trying to get as much code out of the assembly as possible. We have several sophisticated menu systems, some on Mardin Rithimimie. And perhaps most important, this is, Cyslinix has been designed with a mod, it's extensible via a module API. It also contains a couple of additional pieces, which are useful for some people. Memdisk is a disk emulator. It loads a chunk of memory as the minicarnal, and then allows the booting of any operating system that still uses the BIOS. Or for that matter, another boot, it can even be used to load another bootloader. It's frequently used for diagnostics. It contains Gpixelinix, which is a collaboration with the Etherboot project, whose flagship product is Gpixel. This is, as you may be able to tell from the name, an open source PXE stack with enhanced capabilities. This lets us use a bunch of additional net ring protocol in addition to the legacy TFTP. Finally, and this is a relatively new feature, it contains a small tool called isohybrid. It post processes an ISO image. It only supports ISO images that uses isolinix. It makes them bootable from what BIOS thinks is a hard drive, which includes USB sticks. Now, a lot of the odd things about this ultimately comes down to the fact that the X86 PC by now is an ancient platform. I calculated out that the PC has existed for 45% of the entire existence of electronic computers, so almost half. The original IBM 5150 came out in 1981, and a lot of the BIOS definition dates back all the way to that one. There were a few more things added in the IBM AT and the PS2 that are still considered standard. This pretty much dates back from when IBM had firm leadership in the area. Then after that, we only had floppy and hard disk booting standard. Anything else required a custom ROM for everything. This kind of led to a bit of an untenable situation where it seemed like no one could advance the platform. After a few kind of missteps, there started to be industry consensus standards. One of the first ones of those was the CD-ROM booting standard called El Torrito, supposedly named after the restaurant where the people who came up with the standard had dinner. It came out in 1993. El Torrito contains two modes. One is you have a disk image on the CD, and it just boots as if it had been a disk. The other one is so-called native mode where you can actually access the entire CD. Unfortunately, the native mode didn't work very well in many BIOSes until the late 90s. Similarly, we had a network booting standard originally developed by Intel. It came out in 1997 and revised in 1999. Some of the early code were really, really problematic there. Even today, we are seeing a fair number of bugs. At the very least, this brought standards-based network booting to the X86 platform. USB drives is the most recent collection to the PC bootable zoo. They just appear as conventional disk drives, at least when there aren't bugs. Unfortunately, there are still bugs in a lot of BIOSes. There is, however, tricks that can help the SysLinux Wiki and the SysLinux mailing list have collected a fair number of tricks that seems to work for a lot of people. It's a good place to get some more information on that. The SysLinux project itself came out of an overnight hacking binge that I had in 1994. I had just had a miserable experience reinstalling the machine with Linux, where I found out that I needed a special kernel for the driver that I had. This was before modules were widely used in the Linux world. I had to boot from this floppy, which was a completely opaque object. I didn't have another Linux machine handy. Basically, I had to give up until I could go somewhere else where there was another Linux machine. I thought, this really sucks. This is just wrong. I decided to go out and write a bootloader that would actually boot from a floppy that another operating system would recognize, so that you could take your legacy operating system that was dosed primarily back then and actually make your Linux boot floppy, even if you have to do custom stuff. It should look like a dOS floppy. A dOS should be able to read. A dOS should be able to write it. And hence, I needed to understand the file system that it was underneath. This was in contrast to Lilo, which was the dominant Linux bootloader at the time, which only did raw blocks. It didn't actually look at file systems at all. So it was kind of okay. A lot of distributions adopted this for their boot floppies. Boot floppies were pretty ubiquitous back then. Out of some features that some people like, to help the distros primarily, added online help support in the bootloader. This is kind of a revolutionary idea at the time. So kind of move on. Pixie comes along. And okay, we should be able to boot Linux off of Pixie. This network booting thing is good. Well, so I look at the Pixie spec. And the spec says that the network boot program, which is the first stage bootloader in the Pixie scheme of things, should only be 32 kilobytes long. Like, wow, that's pretty restrictive. I'm going to need a pretty small bootloader. Wait, I already have a pretty small bootloader. So rather than starting over from scratch, let's take this thing that I already have and beat on it until it does roughly what I need. So this worked, eventually. And users liked it because, you know, by this time, Cislunix had kind of matured enough that it got most of the features that people really depended upon in it already. And it's like, suddenly, you have another medium, you can use all the same features. It's good. So kind of on that general note, I'm like, OK, this is kind of cool. Let's, you know, so decided to next tackle CD-ROMs and actually be able to boot CD-ROMs in native mode. This was different from, you know, the disk image variety. And the motivator for it was that the disk images were getting too small, they were getting too cramped. People were already using Cislunix on the disk images, but so let's give them access to the whole disk. This became Isolinix. Few years later than that, you know, a little bit more maturing and so on. But, you know, I kind of gotten this whole thing about supporting multiple file systems down reasonably well. You know, I should actually be able to make this so that I can use it as a general purpose bootloader. And that was EXT-Linux. In 2004, I did, apparently, did quite a lot of work because that's also where the modular API and the menu system was first written. 2006, a lot of people like, yeah, I like this menu system, but it's not flashy enough. So eventually, like, fine, fine, fine, fancy graphics. We got it. And in 2008, Gpixelinux and Isolinix hybrid support, which is the USB key, the ISO image that also works in the USB key. So what's good about Cislunix? The number one thing that Cislunix does different than other bootloaders or most other bootloaders is that it was from the very beginning designed for dynamic systems. It was designed for floppies, after all. And on a floppy, you can't assume that you're going to boot on the same system that you originally created the floppy on. But I've tried to keep true to that principle and do system discovery at boot time. I try very, very hard to keep Cislunix such that you should be able to make almost any arbitrary reconfiguration of your system, you should be able to pull out half your hard drives, rearrange them, put them in another system, whatever. It should still work if at all possible. The other basic principle I've tried to keep true to is place nice with others. I try to stick very closely to the established principles for booting a PC, which is somewhat arcane. And there's somewhat restricting. But, for example, I don't support installing into the MBR, as some other bootloaders do, simply because it makes the job of dealing with other operating systems that do weird stuff harder. By now we have a pretty sophisticated user interface and we have, again, the module or API, which I'm going to talk more about later. What's this problem? Well, first of all, it has a large core of assembly code. This was useful for size, but it really has become a liability. Again, it's only a liability on the X-26 BIOS platform, and this is pretty much because of the large assembly core. Well, the whole thing about playing nice with others and doing dynamic discovery does come at a price. That is, in a lot of bootloaders you can do such things as the bootloaders install on one disk and it will read a kernel from a file system on a different disk. I don't support that, mostly because it's not very clear what that even means in a dynamic system. This drive may be drive 0 and that drive may be drive 2 today, but there is no guarantee that that's going to be the case when the system is actually booted. There are ways one can work around that, but I haven't really, I have found, in general, I've asked for people, well, I need this feature, and I generally want to ask them, well, why do you need it? Well, I'm doing this, and there's usually another, usually better way of doing what they're needed to do. Now I'm fully willing to be convinced that this is, I have too narrow of a view, but this has turned out to be the case so far. I want to talk a little bit about Gpixel Linux here because it's a little bit of a segue, but it's kind of a cool thing. So this, Gpixie comes from the Etherboot project. It is Gpixie, and we have then taken it and put it together with Pixie Linux into one image. Now Gpixie provides an extended Pixie interface which is specifically designed for Pixie Linux. So Pixie Linux has some special bits for Gpixie, and Gpixie has some special bits for Pixie Linux. You put these together, you can boot over a variety of network protocols. Currently, we're up to HTTP, FTP, NFS, ATA over Ethernet, iSCSI, FSP, and I think there are like two or three other protocols which are just too obscure for me to remember right now. The goal is for this is that you should be able to, the goal for this was that you should be able to swap in and out Pixie Linux in an existing configuration and have it just work. We are about 95% there. There is one semi obscure feature of Pixie Linux that is not supported in Gpixie Linux yet, but it works for the vast majority of users. This lets you do things like, well, I want to dynamically generate configuration files, well, I can just do it, I can just put it up on Apache and do a CGI script, I know how to do that. If you're doing it this way, you still need a TFTP server for the initial bootstrap. This is because the Pixie stack that came on your card only supports TFTP. Now if you are willing to reflash your NIC and put Gpixie on your NIC, then you don't even need that. So I wanted to show a little demo of this. And there's no safety net for this. I am going to boot a virtual machine over the internet from a server in California. And the only thing that is kind of local on this is this CD-ROM image that has Gpixie on it. The actual Gpixie image is about 64 kilobytes. If you put it in a ROM, it would be a lot smaller than this. So this is Gpixie. We'll start up, do a usual discovery. Well, I just downloaded Pixie Linux from California. It's hunting for a configuration file. This takes a little bit. So this is the Linux menu system. You can have submenus and graphical backgrounds and all that sort of stuff. In this case, let's try to boot Tom's Boot Disk. Again, this is over HTTP from a web server in California. I did this later. I'm going to... And there we are. Now... As I mentioned, SysLinux has this module API, which is designed to be very flexible. This is actually sort of... This is kind of a good example on how interesting things come from unexpected places. This is actually done because someone's... because a former colleague of mine said, can't you support booting DOS-style com images? And I'm like, well, they're really easy to support. I might as well. Why do you need it? Well, I have this network bootloader called Netboot, which was the predecessor of the Etherboot project that comes as a.com file. Okay, fine. This is kind of sitting in there for... This is sitting in SysLinux for quite a long time and not really being used. At some point, I said, well, you know, yeah, this is 16-bit com stuff, but we should really have something 32-bit in there as well. So it came up with com32. Eventually kind of said, well, let's make it easier to write one of these modules, and maybe someone will actually use it. So I had already written a small C library that was intended to be bundled with a Linux kernel called Klib-C. So I ported it to this other system call interface, com32. So what you end up with is that you have a programming environment which is basically standard C environment. Most of the stuff you expect the standard C environment to have is there. The biggest thing is that when you open a file, you can only do so read-only and you can only read it sequentially. There's no support for Cs. This turns out to be a pretty small problem. For most users, you can live with this. And the interesting part of it is that these modules don't even need to know whether or not they're booting from a CD, from a hard drive, or from a network connection from across the world. So the most common types of modules that people have written, and this is sort of a rough taxonomy and doesn't fit everything, but it's a good example of what people can and do do. First of all, you obviously have user interfaces. The menu system that you already saw is implemented entirely as a module. We have file format modules. This is ways to support loading new types of kernels of various sorts. Policy modules, which are, this is what I want to do in this situation so that the user doesn't have to do it for me. And diagnostic modules, hardware diagnostics mostly. User interfaces. Right now, there are, in bundle with the SysLinux distribution, there are two different menu systems. The very first one was the complex menu system, written by Morali Ganapati, while he was at the University of Chicago. This thing does everything. I have some screenshots on it on my website. It does things like you can have cascading submenus and dialogue boxes, where setting a dialogue box here changes the command line in a completely different menu, and you have a little status bar at the bottom of the screen showing you what you're currently doing. Trust me, like for a large site that just needs this enormous flexibility, as they apparently did at University of Chicago, it's absolutely unbeatable. The simple menu system came later. This was after people were saying, well, yeah, this menu system that you have is, it's really cool, but it's way too much work to configure. For most people, it really is. The simple menu system just takes a simple file or set of files, and pretty straightforward, just presents a menu without too much fanciness. There's a graphics library in here, which is designed to make the same code work for either a graphical console, a text console, or a serial console. The code in the menu system that you saw is the same for all three types of consoles. In fact, if that menu system had booted and found that we didn't have a graphics card that it could use, it would just have defaulted back to text mode. Similarly, if it had found that it had a serial console, it would just have used the serial console. In fact, the serial console works in parallel with the display console so that you can either be a human being touching the physical console, or you can be on a remote terminal server somewhere else. Obviously, if you're using graphics features, like you're using little icons, for example, and you're bypassing this console library, well, there's not much I can do about that. But this is, of course, allowed if you want it. File format modules are a way to, you know, it's a module that implements a new type of loadable object. Again, the goal has been to make this easy to write. So in order to do that, the module describes where in memory things should be going. You don't actually, as the module author, have to do the work of actually putting it into the proper place. You just have to tell the rest of the library where things should be going. And then there is this thing called the shuffle library. The shuffle library looks at where things are now, where things need to be, and what scrap memory it has to play with, and computes a set of move operations that will end up with everything in the right place at the end. An example on this is the Microsoft system deployment image format. I had never heard of this until someone asked me, hey, I want to boot WinPE with SysLinux. It's like, okay, I don't know the first thing about WinPE. It turns out that they have this thing called SDI, which is roughly the equivalent of having a Linux kernel and a RAM disk. It's kind of basically a Windows kernel and a RAM disk. Supporting this format took a module that was 199 lines of C code. 139 lines of those were lines that actually did something, including lines that have single curly braces on them. Most of that is taken up by error handling, meaning, you know, look at this header field. This is not the right type of header field. If this problem then error this, if that problem then error that, if this problem error that. That's actually, you know, the end, the resulting code is very small. Diagnostic modules are modules that tell you about your hardware. One of the first ones was PCI dump or Rhythm Barrier 1 here. Now, what we have done is we've taken a lot of that dumping, the actual code that gets the state out and moved it into the library so it's available to other modules. This both lets us build better diagnostic tools. In fact, some, I wish I could find it again because someone showed me this kind of hardware inventory thing that's actually been written on top of this Linux. Then I lost track of where I found it because I hadn't even, because I hadn't seen it before. It was kind of neat where you could actually get like cascading windows of describing what your hardware looked like at pre-boot. And finally we have policy modules where an example of policy is boot this kernel if I'm on a 64-bit machine, boot this other kernel if I'm on a 32-bit machine that has PAE, this presumably high mem kernel, and otherwise boot yet another kernel. There's an example of policy. You can tell the user to pick different menu items but why should you have to? This is stuff that can be done automatically. It should be doable. This should be done automatically. So a module to implement this particular policy was 129 lies wrong, 70 of which were something other than blank lines or comments. Most of that code was taken out by picking apart the command line and putting it back together again. And this is because if these things had been fixed, compile time constants, that wouldn't have been necessary, but this was meant to be a general purpose module. And sure, you can combine things into modules that do all kinds of strange things. We have code right now that can probe your PCI bus, map those devices to the corresponding modules in the Linux kernel, then build you an init ram fs with those modules and no other modules and do all of this at boot time for the system that you're booting on. This is already there, already working code. But, soon as you have that, you also discover that there's always going to be limitations. Right now, for example, you're starting to see a lot more devices on USB, even on Firewire and so on. And these sort of extended buses are harder to discover because you need a driver for the bus itself for the HPA of the bus in order to be able to further enumerate it. So, this technique has been less useful than I was hoping it was going to be. But it is there and maybe someone will figure out the right way to use it. So, what's happening right now, we're working on integrating a Lua interpreter. And the purpose of this is primarily to write policies. People really don't like having to compile a C module to do a new policy and that's very understandable. So, doing it as a Lua script seems like a much more useful thing. Why do we pick Lua? Well, it had a clean, relatively small, sort of isolated interpreter that was, and it's a clean, small language. Reader support. Right now, Cyslinix doesn't support actually examining directories. This is partly because over the network you can't do that. But on disk, it would be nice to do that. So, that's work underway. The really big one is to get rid of all this legacy assembly code. First of all, the first thing that needs to happen is that file system code just needs to move out of assembly. The implementing something like BTRFS in assembly would be just a nightmare. But even getting rid of the rest of the code from assembly is going to be important to make this ever port beyond the X86 BIOS platform. In particular, for EFI, X86 EFI, which is becoming a more important platform, this needs to happen. And at this point, some of the groundwork is happening, but the actual work is still upcoming. This is what the core looks like. This is the components of the core as of right now. The first stage loader, disk and network I.O. And the BIOS extender, which is what allows us to get into protected mode. And the shuffle system, that is the part that makes all the memory magically end up where it should be at the end. All of these are kind of core platform support things, and they will always need to be in assembly if nothing else for size. However, the rest, command line interface, config file parser, the kernel loader and parser, and most important of all, the file system drivers really have no business doing this, and it needs to be rewritten in C. This is about 80 to 85% of the size of the current core. So the part on the left that is always going to have to be assembly code is really a very small portion. So why hasn't a lot of this happened before? Well, it really kind of comes down to the fact that it is getting to be too large for it to be a one person side project, which it really was until a couple of years ago. Now, we really, over the last few years, I am absolutely delighted how many people have kind of come in, and we are starting to form a real development community, and we can always use more developers. And in addition to actually writing code, things like helping newbies, there are so many things that can be done in the booting space in so many ways. And honestly, I have to say if there is anything in Cislindex I am ashamed of, it is the documentation. The state of the documentation is just miserable. But again, doing the core rewrite, it is going to take a lot of work. And so it really, in addition to me, we need other people. Now, also, all of this really only makes sense if the users want it. We can build the coolest piece of technology in the world, and if no one uses it, it doesn't matter. So we need to make sure that we end up building something that people actually want to use, that makes sense for users, makes sense for administrators, makes sense for distros. So feedback is always welcome. And this is where you can find the more information as well as these slides. And at that, I wonder if we have any questions. Yes. I'm sorry? So the question was whether or not we can check a cryptographic hash of what we download off the Internet. Right now, there is support in G-Pixie for HTTPS. The problem is that at boot time you don't have any sort of random number generator available to you. This means that the security you get is pretty weak because most authentication schemes rely on having a random number generator available. Could we do something... You're specifically asked if we could check a hash of what is there. It's certainly something that we could do relatively easily, but you also have to ask the question then, where do you get the hash to compare it from to? There are a lot of issues when it comes to that in the booting space. People really want to make the boot more secure, but then you kind of have to ask the next question is, how do I know my security works? I think we may be able to make the HTTPS support better. It hasn't been a huge priority for the G-Pixie people at the moment, but we probably can make that better, if not perfect. Would you use the hardware TPM environment to assist them? Why don't we use the hardware TPM environment to do that? That's actually probably the answer. Right now, TPMs are... They're availability is somewhat spotty, but that is of course changing. The TPM, if we can find the TPM and straighten out the fact that there is at least four different hardware protocols involved, at least they should provide us with a reliable random number generator and possibly secure storage for things like keys and stuff like that. It's actually the right way to do that. The question I believe is, do we support IPv6? Is that what I heard? The question is, do we support IPv6 or only IPv4? Right now we only support IPv4. IPv6 is not supported by the Pixie standard. The G-Pixie people are working on it, but we end up with a funny notion of what does it mean for us to support IPv6, given the fact that the underlying protocols we use don't. For the parts of the Pixie spec that are on the local machine sort of protocols, we can deal with that, but it also includes some over-the-wire components. There is a Pixie spec for IPv6 under development. Unfortunately, Microsoft is heavily involved in it, and therefore I have not... They're basically keeping it away from the open source people, so I have no idea what it even is going to look like. To be honest with you, if it ends up looking as bad as the original Pixie spec, it's going to be another nightmare. Can you tell us more about a celebrated initial ram disk? The question was if I can talk more about building an initial ram disk. Why do you get modules? The question is why do you get modules? Are you allowed to use DCC? We don't have DCC ported to the CysLinux. I don't believe I'm familiar with it. The answer on the module front is that the normal thing is that the modules will actually be already compiled on disk. I'm sure that we probably actually could build an environment where you could compile a module on the fly. There's no technical reason why it's not possible. I think it's probably not the most effective way of doing that. We can take files and put them in the NIT ramFS. We can also generate file contents and put them in the NIT ramFS. All the pieces are there, certainly. The question is if there's support for boot ones. Right now it's only in EXT Linux, but that's a fixable problem. Any more questions? I think we're done.
 This part of the kernel track, but I'm actually, it's actually a bit of a lie.  I'm not going to talk about the kernel at all.  The kernel is what comes afterwards.  So I work for the Intel open source technology center, but this is not an Intel project.  So don't blame them for that.  They also like me to put this up.  Cyslinux, as of right now, is a suite of bootloaders.  It currently consists of four, what I call, derivatives.  This is a bit of a legacy term from when the differences between them was much bigger in  terms of code.  It really comes down to different file system support.  The original Cyslinux, in all caps, just to be extra confusing, is for FAT file systems,  MS-DOS file systems.  This was originally done for boot floppies.  Followed that came network booting in PXC Linux.  This is named after the PXC standard, which is the standard for network booting on X86.  Followed that was ISO Linux, boots from CD-ROMs.  This is, of course, from the ISO9660 file system.  And most recently, EXT Linux, as a general-purpose bootloader, loads from Linux, EXT2, EXT3  file systems.  And I promised Ted that I'm going to get EXT4 in there really soon now.  Right now, this only supports the X86 BIOS platform.  And this dates back from when this was designed for boot floppies.  Cys mattered tremendously.  Floppies aren't very big, so any overhead not being left for the kernel was a major  problem.  So the solution was to make it as small as possible, and that meant assembly language.  This has since become a liability in terms of support and maintainability.  So I am very much trying to get as much code out of the assembly as possible.  We have several sophisticated menu systems, some on Mardin Rithimimie.  And perhaps most important, this is, Cyslinix has been designed with a mod, it's extensible  via a module API.  It also contains a couple of additional pieces, which are useful for some people.  Memdisk is a disk emulator.  It loads a chunk of memory as the minicarnal, and then allows the booting of any operating  system that still uses the BIOS.  Or for that matter, another boot, it can even be used to load another bootloader.  It's frequently used for diagnostics.  It contains Gpixelinix, which is a collaboration with the Etherboot project, whose flagship  product is Gpixel.  This is, as you may be able to tell from the name, an open source PXE stack with enhanced  capabilities.  This lets us use a bunch of additional net ring protocol in addition to the legacy TFTP.  Finally, and this is a relatively new feature, it contains a small tool called isohybrid.  It post processes an ISO image.  It only supports ISO images that uses isolinix.  It makes them bootable from what BIOS thinks is a hard drive, which includes USB sticks.  Now, a lot of the odd things about this ultimately comes down to the fact that the X86 PC by  now is an ancient platform.  I calculated out that the PC has existed for 45% of the entire existence of electronic  computers, so almost half.  The original IBM 5150 came out in 1981, and a lot of the BIOS definition dates back all  the way to that one.  There were a few more things added in the IBM AT and the PS2 that are still considered  standard.  This pretty much dates back from when IBM had firm leadership in the area.  Then after that, we only had floppy and hard disk booting standard.  Anything else required a custom ROM for everything.  This kind of led to a bit of an untenable situation where it seemed like no one could  advance the platform.  After a few kind of missteps, there started to be industry consensus standards.  One of the first ones of those was the CD-ROM booting standard called El Torrito, supposedly  named after the restaurant where the people who came up with the standard had dinner.  It came out in 1993.  El Torrito contains two modes.  One is you have a disk image on the CD, and it just boots as if it had been a disk.  The other one is so-called native mode where you can actually access the entire CD.  Unfortunately, the native mode didn't work very well in many BIOSes until the late 90s.  Similarly, we had a network booting standard originally developed by Intel.  It came out in 1997 and revised in 1999.  Some of the early code were really, really problematic there.  Even today, we are seeing a fair number of bugs.  At the very least, this brought standards-based network booting to the X86 platform.  USB drives is the most recent collection to the PC bootable zoo.  They just appear as conventional disk drives, at least when there aren't bugs.  Unfortunately, there are still bugs in a lot of BIOSes.  There is, however, tricks that can help the SysLinux Wiki and the SysLinux mailing list  have collected a fair number of tricks that seems to work for a lot of people.  It's a good place to get some more information on that.  The SysLinux project itself came out of an overnight hacking binge that I had in 1994.  I had just had a miserable experience reinstalling the machine with Linux, where I found out  that I needed a special kernel for the driver that I had.  This was before modules were widely used in the Linux world.  I had to boot from this floppy, which was a completely opaque object.  I didn't have another Linux machine handy.  Basically, I had to give up until I could go somewhere else where there was another  Linux machine.  I thought, this really sucks.  This is just wrong.  I decided to go out and write a bootloader that would actually boot from a floppy that  another operating system would recognize, so that you could take your legacy operating  system that was dosed primarily back then and actually make your Linux boot floppy, even  if you have to do custom stuff.  It should look like a dOS floppy.  A dOS should be able to read.  A dOS should be able to write it.  And hence, I needed to understand the file system that it was underneath.  This was in contrast to Lilo, which was the dominant Linux bootloader at the time, which  only did raw blocks.  It didn't actually look at file systems at all.  So it was kind of okay.  A lot of distributions adopted this for their boot floppies.  Boot floppies were pretty ubiquitous back then.  Out of some features that some people like, to help the distros primarily, added online  help support in the bootloader.  This is kind of a revolutionary idea at the time.  So kind of move on.  Pixie comes along.  And okay, we should be able to boot Linux off of Pixie.  This network booting thing is good.  Well, so I look at the Pixie spec.  And the spec says that the network boot program, which is the first stage bootloader in the  Pixie scheme of things, should only be 32 kilobytes long.  Like, wow, that's pretty restrictive.  I'm going to need a pretty small bootloader.  Wait, I already have a pretty small bootloader.  So rather than starting over from scratch, let's take this thing that I already have  and beat on it until it does roughly what I need.  So this worked, eventually.  And users liked it because, you know, by this time, Cislunix had kind of matured enough  that it got most of the features that people really depended upon in it already.  And it's like, suddenly, you have another medium, you can use all the same features.  It's good.  So kind of on that general note, I'm like, OK, this is kind of cool.  Let's, you know, so decided to next tackle CD-ROMs and actually be able to boot CD-ROMs  in native mode.  This was different from, you know, the disk image variety.  And the motivator for it was that the disk images were getting too small, they were  getting too cramped.  People were already using Cislunix on the disk images, but so let's give them access  to the whole disk.  This became Isolinix.  Few years later than that, you know, a little bit more maturing and so on.  But, you know, I kind of gotten this whole thing about supporting multiple file systems  down reasonably well.  You know, I should actually be able to make this so that I can use it as a general purpose  bootloader.  And that was EXT-Linux.  In 2004, I did, apparently, did quite a lot of work because that's also where the modular  API and the menu system was first written.  2006, a lot of people like, yeah, I like this menu system, but it's not flashy enough.  So eventually, like, fine, fine, fine, fancy graphics.  We got it.  And in 2008, Gpixelinux and Isolinix hybrid support, which is the USB key, the ISO image  that also works in the USB key.  So what's good about Cislunix?  The number one thing that Cislunix does different than other bootloaders or most other bootloaders  is that it was from the very beginning designed for dynamic systems.  It was designed for floppies, after all.  And on a floppy, you can't assume that you're going to boot on the same system that you  originally created the floppy on.  But I've tried to keep true to that principle and do system discovery at boot time.  I try very, very hard to keep Cislunix such that you should be able to make almost any  arbitrary reconfiguration of your system, you should be able to pull out half your hard  drives, rearrange them, put them in another system, whatever.  It should still work if at all possible.  The other basic principle I've tried to keep true to is place nice with others.  I try to stick very closely to the established principles for booting a PC, which is somewhat  arcane.  And there's somewhat restricting.  But, for example, I don't support installing into the MBR, as some other bootloaders do,  simply because it makes the job of dealing with other operating systems that do weird  stuff harder.  By now we have a pretty sophisticated user interface and we have, again, the module or  API, which I'm going to talk more about later.  What's this problem?  Well, first of all, it has a large core of assembly code.  This was useful for size, but it really has become a liability.  Again, it's only a liability on the X-26 BIOS platform, and this is pretty much because  of the large assembly core.  Well, the whole thing about playing nice with others and doing dynamic discovery does come  at a price.  That is, in a lot of bootloaders you can do such things as the bootloaders install on  one disk and it will read a kernel from a file system on a different disk.  I don't support that, mostly because it's not very clear what that even means in a  dynamic system.  This drive may be drive 0 and that drive may be drive 2 today, but there is no guarantee  that that's going to be the case when the system is actually booted.  There are ways one can work around that, but I haven't really, I have found, in general,  I've asked for people, well, I need this feature, and I generally want to ask them,  well, why do you need it?  Well, I'm doing this, and there's usually another, usually better way of doing what  they're needed to do.  Now I'm fully willing to be convinced that this is, I have too narrow of a view, but  this has turned out to be the case so far.  I want to talk a little bit about Gpixel Linux here because it's a little bit of a segue,  but it's kind of a cool thing.  So this, Gpixie comes from the Etherboot project.  It is Gpixie, and we have then taken it and put it together with Pixie Linux into one  image.  Now Gpixie provides an extended Pixie interface which is specifically designed for Pixie Linux.  So Pixie Linux has some special bits for Gpixie, and Gpixie has some special bits for Pixie  Linux.  You put these together, you can boot over a variety of network protocols.  Currently, we're up to HTTP, FTP, NFS, ATA over Ethernet, iSCSI, FSP, and I think there  are like two or three other protocols which are just too obscure for me to remember right  now.  The goal is for this is that you should be able to, the goal for this was that you should  be able to swap in and out Pixie Linux in an existing configuration and have it just work.  We are about 95% there.  There is one semi obscure feature of Pixie Linux that is not supported in Gpixie Linux  yet, but it works for the vast majority of users.  This lets you do things like, well, I want to dynamically generate configuration files,  well, I can just do it, I can just put it up on Apache and do a CGI script, I know how  to do that.  If you're doing it this way, you still need a TFTP server for the initial bootstrap.  This is because the Pixie stack that came on your card only supports TFTP.  Now if you are willing to reflash your NIC and put Gpixie on your NIC, then you don't  even need that.  So I wanted to show a little demo of this.  And there's no safety net for this.  I am going to boot a virtual machine over the internet from a server in California.  And the only thing that is kind of local on this is this CD-ROM image that has Gpixie  on it.  The actual Gpixie image is about 64 kilobytes.  If you put it in a ROM, it would be a lot smaller than this.  So this is Gpixie.  We'll start up, do a usual discovery.  Well, I just downloaded Pixie Linux from California.  It's hunting for a configuration file.  This takes a little bit.  So this is the Linux menu system.  You can have submenus and graphical backgrounds and all that sort of stuff.  In this case, let's try to boot Tom's Boot Disk.  Again, this is over HTTP from a web server in California.  I did this later.  I'm going to...  And there we are.  Now...  As I mentioned, SysLinux has this module API,  which is designed to be very flexible.  This is actually sort of...  This is kind of a good example on how interesting things come from unexpected places.  This is actually done because someone's...  because a former colleague of mine said,  can't you support booting DOS-style com images?  And I'm like, well, they're really easy to support.  I might as well.  Why do you need it?  Well, I have this network bootloader called Netboot,  which was the predecessor of the Etherboot project  that comes as a.com file.  Okay, fine.  This is kind of sitting in there for...  This is sitting in SysLinux for quite a long time and not really being used.  At some point, I said, well, you know,  yeah, this is 16-bit com stuff,  but we should really have something 32-bit in there as well.  So it came up with com32.  Eventually kind of said, well, let's make it easier to write one of these modules,  and maybe someone will actually use it.  So I had already written a small C library that was intended to be bundled with a Linux kernel called Klib-C.  So I ported it to this other system call interface, com32.  So what you end up with is that you have a programming environment  which is basically standard C environment.  Most of the stuff you expect the standard C environment to have is there.  The biggest thing is that when you open a file,  you can only do so read-only and you can only read it sequentially.  There's no support for Cs.  This turns out to be a pretty small problem.  For most users, you can live with this.  And the interesting part of it is that these modules don't even need to know  whether or not they're booting from a CD, from a hard drive,  or from a network connection from across the world.  So the most common types of modules that people have written,  and this is sort of a rough taxonomy and doesn't fit everything,  but it's a good example of what people can and do do.  First of all, you obviously have user interfaces.  The menu system that you already saw is implemented entirely as a module.  We have file format modules. This is ways to support loading new types of kernels of various sorts.  Policy modules, which are, this is what I want to do in this situation  so that the user doesn't have to do it for me.  And diagnostic modules, hardware diagnostics mostly.  User interfaces.  Right now, there are, in bundle with the SysLinux distribution,  there are two different menu systems.  The very first one was the complex menu system, written by Morali Ganapati,  while he was at the University of Chicago.  This thing does everything.  I have some screenshots on it on my website.  It does things like you can have cascading submenus and dialogue boxes,  where setting a dialogue box here changes the command line in a completely different menu,  and you have a little status bar at the bottom of the screen  showing you what you're currently doing.  Trust me, like for a large site that just needs this enormous flexibility,  as they apparently did at University of Chicago, it's absolutely unbeatable.  The simple menu system came later.  This was after people were saying,  well, yeah, this menu system that you have is, it's really cool,  but it's way too much work to configure.  For most people, it really is.  The simple menu system just takes a simple file or set of files,  and pretty straightforward, just presents a menu without too much fanciness.  There's a graphics library in here,  which is designed to make the same code work for either a graphical console,  a text console, or a serial console.  The code in the menu system that you saw is the same for all three types of consoles.  In fact, if that menu system had booted and found that we didn't have a graphics card that it could use,  it would just have defaulted back to text mode.  Similarly, if it had found that it had a serial console, it would just have used the serial console.  In fact, the serial console works in parallel with the display console  so that you can either be a human being touching the physical console,  or you can be on a remote terminal server somewhere else.  Obviously, if you're using graphics features, like you're using little icons, for example,  and you're bypassing this console library, well, there's not much I can do about that.  But this is, of course, allowed if you want it.  File format modules are a way to, you know, it's a module that implements a new type of loadable object.  Again, the goal has been to make this easy to write.  So in order to do that, the module describes where in memory things should be going.  You don't actually, as the module author, have to do the work of actually putting it into the proper place.  You just have to tell the rest of the library where things should be going.  And then there is this thing called the shuffle library.  The shuffle library looks at where things are now, where things need to be,  and what scrap memory it has to play with, and computes a set of move operations  that will end up with everything in the right place at the end.  An example on this is the Microsoft system deployment image format.  I had never heard of this until someone asked me, hey, I want to boot WinPE with SysLinux.  It's like, okay, I don't know the first thing about WinPE.  It turns out that they have this thing called SDI, which is roughly the equivalent of having a Linux kernel and a RAM disk.  It's kind of basically a Windows kernel and a RAM disk.  Supporting this format took a module that was 199 lines of C code.  139 lines of those were lines that actually did something, including lines that have single curly braces on them.  Most of that is taken up by error handling, meaning, you know, look at this header field.  This is not the right type of header field.  If this problem then error this, if that problem then error that, if this problem error that.  That's actually, you know, the end, the resulting code is very small.  Diagnostic modules are modules that tell you about your hardware.  One of the first ones was PCI dump or Rhythm Barrier 1 here.  Now, what we have done is we've taken a lot of that dumping, the actual code that gets the state out and moved it into the library so it's available to other modules.  This both lets us build better diagnostic tools.  In fact, some, I wish I could find it again because someone showed me this kind of hardware inventory thing that's actually been written on top of this Linux.  Then I lost track of where I found it because I hadn't even, because I hadn't seen it before.  It was kind of neat where you could actually get like cascading windows of describing what your hardware looked like at pre-boot.  And finally we have policy modules where an example of policy is boot this kernel if I'm on a 64-bit machine,  boot this other kernel if I'm on a 32-bit machine that has PAE, this presumably high mem kernel, and otherwise boot yet another kernel.  There's an example of policy. You can tell the user to pick different menu items but why should you have to?  This is stuff that can be done automatically. It should be doable. This should be done automatically.  So a module to implement this particular policy was 129 lies wrong, 70 of which were something other than blank lines or comments.  Most of that code was taken out by picking apart the command line and putting it back together again.  And this is because if these things had been fixed, compile time constants, that wouldn't have been necessary,  but this was meant to be a general purpose module.  And sure, you can combine things into modules that do all kinds of strange things.  We have code right now that can probe your PCI bus, map those devices to the corresponding modules in the Linux kernel,  then build you an init ram fs with those modules and no other modules and do all of this at boot time for the system that you're booting on.  This is already there, already working code.  But, soon as you have that, you also discover that there's always going to be limitations.  Right now, for example, you're starting to see a lot more devices on USB, even on Firewire and so on.  And these sort of extended buses are harder to discover because you need a driver for the bus itself for the HPA of the bus in order to be able to further enumerate it.  So, this technique has been less useful than I was hoping it was going to be.  But it is there and maybe someone will figure out the right way to use it.  So, what's happening right now, we're working on integrating a Lua interpreter.  And the purpose of this is primarily to write policies.  People really don't like having to compile a C module to do a new policy and that's very understandable.  So, doing it as a Lua script seems like a much more useful thing.  Why do we pick Lua? Well, it had a clean, relatively small, sort of isolated interpreter that was, and it's a clean, small language.  Reader support. Right now, Cyslinix doesn't support actually examining directories.  This is partly because over the network you can't do that.  But on disk, it would be nice to do that. So, that's work underway.  The really big one is to get rid of all this legacy assembly code.  First of all, the first thing that needs to happen is that file system code just needs to move out of assembly.  The implementing something like BTRFS in assembly would be just a nightmare.  But even getting rid of the rest of the code from assembly is going to be important to make this ever port beyond the X86 BIOS platform.  In particular, for EFI, X86 EFI, which is becoming a more important platform, this needs to happen.  And at this point, some of the groundwork is happening, but the actual work is still upcoming.  This is what the core looks like. This is the components of the core as of right now.  The first stage loader, disk and network I.O.  And the BIOS extender, which is what allows us to get into protected mode.  And the shuffle system, that is the part that makes all the memory magically end up where it should be at the end.  All of these are kind of core platform support things, and they will always need to be in assembly if nothing else for size.  However, the rest, command line interface, config file parser, the kernel loader and parser,  and most important of all, the file system drivers really have no business doing this, and it needs to be rewritten in C.  This is about 80 to 85% of the size of the current core.  So the part on the left that is always going to have to be assembly code is really a very small portion.  So why hasn't a lot of this happened before?  Well, it really kind of comes down to the fact that it is getting to be too large for it to be a one person side project,  which it really was until a couple of years ago.  Now, we really, over the last few years, I am absolutely delighted how many people have kind of come in,  and we are starting to form a real development community, and we can always use more developers.  And in addition to actually writing code, things like helping newbies, there are so many things that can be done in the booting space in so many ways.  And honestly, I have to say if there is anything in Cislindex I am ashamed of, it is the documentation. The state of the documentation is just miserable.  But again, doing the core rewrite, it is going to take a lot of work.  And so it really, in addition to me, we need other people.  Now, also, all of this really only makes sense if the users want it.  We can build the coolest piece of technology in the world, and if no one uses it, it doesn't matter.  So we need to make sure that we end up building something that people actually want to use,  that makes sense for users, makes sense for administrators, makes sense for distros.  So feedback is always welcome.  And this is where you can find the more information as well as these slides.  And at that, I wonder if we have any questions.  Yes.  I'm sorry?  So the question was whether or not we can check a cryptographic hash of what we download off the Internet.  Right now, there is support in G-Pixie for HTTPS.  The problem is that at boot time you don't have any sort of random number generator available to you.  This means that the security you get is pretty weak because most authentication schemes rely on having a random number generator available.  Could we do something... You're specifically asked if we could check a hash of what is there.  It's certainly something that we could do relatively easily, but you also have to ask the question then,  where do you get the hash to compare it from to?  There are a lot of issues when it comes to that in the booting space.  People really want to make the boot more secure, but then you kind of have to ask the next question is,  how do I know my security works?  I think we may be able to make the HTTPS support better.  It hasn't been a huge priority for the G-Pixie people at the moment, but we probably can make that better, if not perfect.  Would you use the hardware TPM environment to assist them?  Why don't we use the hardware TPM environment to do that?  That's actually probably the answer.  Right now, TPMs are...  They're availability is somewhat spotty, but that is of course changing.  The TPM, if we can find the TPM and straighten out the fact that there is at least four different hardware protocols involved,  at least they should provide us with a reliable random number generator and possibly secure storage for things like keys and stuff like that.  It's actually the right way to do that.  The question I believe is, do we support IPv6?  Is that what I heard?  The question is, do we support IPv6 or only IPv4?  Right now we only support IPv4.  IPv6 is not supported by the Pixie standard.  The G-Pixie people are working on it, but we end up with a funny notion of what does it mean for us to support IPv6,  given the fact that the underlying protocols we use don't.  For the parts of the Pixie spec that are on the local machine sort of protocols, we can deal with that,  but it also includes some over-the-wire components.  There is a Pixie spec for IPv6 under development.  Unfortunately, Microsoft is heavily involved in it, and therefore I have not...  They're basically keeping it away from the open source people, so I have no idea what it even is going to look like.  To be honest with you, if it ends up looking as bad as the original Pixie spec, it's going to be another nightmare.  Can you tell us more about a celebrated initial ram disk?  The question was if I can talk more about building an initial ram disk.  Why do you get modules?  The question is why do you get modules? Are you allowed to use DCC?  We don't have DCC ported to the CysLinux.  I don't believe I'm familiar with it.  The answer on the module front is that the normal thing is that the modules will actually be already compiled on disk.  I'm sure that we probably actually could build an environment where you could compile a module on the fly.  There's no technical reason why it's not possible.  I think it's probably not the most effective way of doing that.  We can take files and put them in the NIT ramFS.  We can also generate file contents and put them in the NIT ramFS.  All the pieces are there, certainly.  The question is if there's support for boot ones.  Right now it's only in EXT Linux, but that's a fixable problem.  Any more questions?  I think we're done.
FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_0_131.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_132_179.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_180_287.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_288_395.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_396_443.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_444_491.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_492_539.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_540_599.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_600_911.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_912_4667.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_4668_5603.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_5604_10391.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_10392_10451.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_10452_10499.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_10500_10607.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_10608_10655.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_10656_11999.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_12000_20555.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_20556_20603.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_20604_20651.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_20652_23783.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_23784_23831.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_23832_25667.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_25668_29111.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_29112_29195.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_29196_29243.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_29244_30311.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_30312_31115.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_31116_31583.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_31584_31739.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_31740_32447.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_32448_32867.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_32868_33071.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_33072_33131.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_33132_33239.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_33240_33335.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_33336_33395.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_33396_33443.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_33444_41375.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_41376_41423.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_41424_41471.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_41472_49943.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_49944_49991.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_49992_50039.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_50040_56567.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_56568_60251.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_60252_60923.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_60924_61175.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_61176_61223.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_61224_61271.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_61272_61319.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_61320_65411.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_65412_65459.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_65460_65507.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_65508_70991.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_70992_71039.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_71040_71087.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_71088_71135.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_71136_71243.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_71244_71483.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_71484_71531.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_71532_71771.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_71772_71819.png FOSDEM_2009_Syslinux_and_the_dynamic_x86_boot_process_wZB8KxXdiKg_1_71820_71965.png