How did Linux/xBSD boot before GRUB?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












23















According to Wikipedia, GRUB was released in 1995. By that point Linux and xBSD existed for several years. I know early Unix versions were tied to hardware in the 70s and 80s, but Linux and xBSD were free to distribute and install. Which begs the question how would you boot Linux back then? Were distributions shipping with their own implementations of bootloaders?










share|improve this question



















  • 32





    Umm... You weren't around when LILO was the only Linux bootloader? And I've never used LILO nor Grub on my BSD systems. Which one are you interested in? See e.g. biosboot(8).

    – Kusalananda
    Jan 7 at 10:45






  • 8





    @Kusalananda Unfortunately, I cared more about toys and drawing Ninja Turtles than pipes,execs, and shells back then :) I'm interested in general history, not specific bootloader. From the page you've linked I see OpenBSD has biosboot for two architectures, i386 and amd64. Does that mean OpenBSD specifically had to target the architectures instead of having one, unifying tool ?

    – Sergiy Kolodyazhnyy
    Jan 7 at 10:50






  • 1





    The first-stage bootloader would be different for each architecture (only i386 and amd64 has a "bios" BIOS anyway). Have a look at NetBSD if you're interested in more exotic architectures than the bog standard PC.

    – Kusalananda
    Jan 7 at 10:58







  • 3





    @Kusalananda I don't think LILO ever was the only Linux bootloader. As far as I know the loader built into kernel images predates LILO, and by the time support for the built in loader was discontinued there were at least a handful of other bootloaders around.

    – kasperd
    Jan 7 at 18:12






  • 2





    LILO was the default bootloader for a lot of distros up until the beginning of 2000s

    – phuclv
    Jan 8 at 2:39















23















According to Wikipedia, GRUB was released in 1995. By that point Linux and xBSD existed for several years. I know early Unix versions were tied to hardware in the 70s and 80s, but Linux and xBSD were free to distribute and install. Which begs the question how would you boot Linux back then? Were distributions shipping with their own implementations of bootloaders?










share|improve this question



















  • 32





    Umm... You weren't around when LILO was the only Linux bootloader? And I've never used LILO nor Grub on my BSD systems. Which one are you interested in? See e.g. biosboot(8).

    – Kusalananda
    Jan 7 at 10:45






  • 8





    @Kusalananda Unfortunately, I cared more about toys and drawing Ninja Turtles than pipes,execs, and shells back then :) I'm interested in general history, not specific bootloader. From the page you've linked I see OpenBSD has biosboot for two architectures, i386 and amd64. Does that mean OpenBSD specifically had to target the architectures instead of having one, unifying tool ?

    – Sergiy Kolodyazhnyy
    Jan 7 at 10:50






  • 1





    The first-stage bootloader would be different for each architecture (only i386 and amd64 has a "bios" BIOS anyway). Have a look at NetBSD if you're interested in more exotic architectures than the bog standard PC.

    – Kusalananda
    Jan 7 at 10:58







  • 3





    @Kusalananda I don't think LILO ever was the only Linux bootloader. As far as I know the loader built into kernel images predates LILO, and by the time support for the built in loader was discontinued there were at least a handful of other bootloaders around.

    – kasperd
    Jan 7 at 18:12






  • 2





    LILO was the default bootloader for a lot of distros up until the beginning of 2000s

    – phuclv
    Jan 8 at 2:39













23












23








23


6






According to Wikipedia, GRUB was released in 1995. By that point Linux and xBSD existed for several years. I know early Unix versions were tied to hardware in the 70s and 80s, but Linux and xBSD were free to distribute and install. Which begs the question how would you boot Linux back then? Were distributions shipping with their own implementations of bootloaders?










share|improve this question
















According to Wikipedia, GRUB was released in 1995. By that point Linux and xBSD existed for several years. I know early Unix versions were tied to hardware in the 70s and 80s, but Linux and xBSD were free to distribute and install. Which begs the question how would you boot Linux back then? Were distributions shipping with their own implementations of bootloaders?







boot-loader history






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Jan 8 at 3:55









Boann

1657




1657










asked Jan 7 at 10:41









Sergiy KolodyazhnyySergiy Kolodyazhnyy

8,67912355




8,67912355







  • 32





    Umm... You weren't around when LILO was the only Linux bootloader? And I've never used LILO nor Grub on my BSD systems. Which one are you interested in? See e.g. biosboot(8).

    – Kusalananda
    Jan 7 at 10:45






  • 8





    @Kusalananda Unfortunately, I cared more about toys and drawing Ninja Turtles than pipes,execs, and shells back then :) I'm interested in general history, not specific bootloader. From the page you've linked I see OpenBSD has biosboot for two architectures, i386 and amd64. Does that mean OpenBSD specifically had to target the architectures instead of having one, unifying tool ?

    – Sergiy Kolodyazhnyy
    Jan 7 at 10:50






  • 1





    The first-stage bootloader would be different for each architecture (only i386 and amd64 has a "bios" BIOS anyway). Have a look at NetBSD if you're interested in more exotic architectures than the bog standard PC.

    – Kusalananda
    Jan 7 at 10:58







  • 3





    @Kusalananda I don't think LILO ever was the only Linux bootloader. As far as I know the loader built into kernel images predates LILO, and by the time support for the built in loader was discontinued there were at least a handful of other bootloaders around.

    – kasperd
    Jan 7 at 18:12






  • 2





    LILO was the default bootloader for a lot of distros up until the beginning of 2000s

    – phuclv
    Jan 8 at 2:39












  • 32





    Umm... You weren't around when LILO was the only Linux bootloader? And I've never used LILO nor Grub on my BSD systems. Which one are you interested in? See e.g. biosboot(8).

    – Kusalananda
    Jan 7 at 10:45






  • 8





    @Kusalananda Unfortunately, I cared more about toys and drawing Ninja Turtles than pipes,execs, and shells back then :) I'm interested in general history, not specific bootloader. From the page you've linked I see OpenBSD has biosboot for two architectures, i386 and amd64. Does that mean OpenBSD specifically had to target the architectures instead of having one, unifying tool ?

    – Sergiy Kolodyazhnyy
    Jan 7 at 10:50






  • 1





    The first-stage bootloader would be different for each architecture (only i386 and amd64 has a "bios" BIOS anyway). Have a look at NetBSD if you're interested in more exotic architectures than the bog standard PC.

    – Kusalananda
    Jan 7 at 10:58







  • 3





    @Kusalananda I don't think LILO ever was the only Linux bootloader. As far as I know the loader built into kernel images predates LILO, and by the time support for the built in loader was discontinued there were at least a handful of other bootloaders around.

    – kasperd
    Jan 7 at 18:12






  • 2





    LILO was the default bootloader for a lot of distros up until the beginning of 2000s

    – phuclv
    Jan 8 at 2:39







32




32





Umm... You weren't around when LILO was the only Linux bootloader? And I've never used LILO nor Grub on my BSD systems. Which one are you interested in? See e.g. biosboot(8).

– Kusalananda
Jan 7 at 10:45





Umm... You weren't around when LILO was the only Linux bootloader? And I've never used LILO nor Grub on my BSD systems. Which one are you interested in? See e.g. biosboot(8).

– Kusalananda
Jan 7 at 10:45




8




8





@Kusalananda Unfortunately, I cared more about toys and drawing Ninja Turtles than pipes,execs, and shells back then :) I'm interested in general history, not specific bootloader. From the page you've linked I see OpenBSD has biosboot for two architectures, i386 and amd64. Does that mean OpenBSD specifically had to target the architectures instead of having one, unifying tool ?

– Sergiy Kolodyazhnyy
Jan 7 at 10:50





@Kusalananda Unfortunately, I cared more about toys and drawing Ninja Turtles than pipes,execs, and shells back then :) I'm interested in general history, not specific bootloader. From the page you've linked I see OpenBSD has biosboot for two architectures, i386 and amd64. Does that mean OpenBSD specifically had to target the architectures instead of having one, unifying tool ?

– Sergiy Kolodyazhnyy
Jan 7 at 10:50




1




1





The first-stage bootloader would be different for each architecture (only i386 and amd64 has a "bios" BIOS anyway). Have a look at NetBSD if you're interested in more exotic architectures than the bog standard PC.

– Kusalananda
Jan 7 at 10:58






The first-stage bootloader would be different for each architecture (only i386 and amd64 has a "bios" BIOS anyway). Have a look at NetBSD if you're interested in more exotic architectures than the bog standard PC.

– Kusalananda
Jan 7 at 10:58





3




3





@Kusalananda I don't think LILO ever was the only Linux bootloader. As far as I know the loader built into kernel images predates LILO, and by the time support for the built in loader was discontinued there were at least a handful of other bootloaders around.

– kasperd
Jan 7 at 18:12





@Kusalananda I don't think LILO ever was the only Linux bootloader. As far as I know the loader built into kernel images predates LILO, and by the time support for the built in loader was discontinued there were at least a handful of other bootloaders around.

– kasperd
Jan 7 at 18:12




2




2





LILO was the default bootloader for a lot of distros up until the beginning of 2000s

– phuclv
Jan 8 at 2:39





LILO was the default bootloader for a lot of distros up until the beginning of 2000s

– phuclv
Jan 8 at 2:39










5 Answers
5






active

oldest

votes


















51














The first Linux distribution I used back in the 90s (Slackware 3.0 IIRC) used LILO as a bootloader. And many distros used LILO for years even when GRUB was becoming the "default" bootloader.



Moreover, in the early years of Linux it was common to boot Linux from another OS (i.e. DOS or Windows) instead of relying on a bootloader/dual booting. For example there was loadlin.



Don't forget Syslinux, which is a simpler boot loader often used for USB self-bootable installation/recovery distros. Or Isolinux (from the same project) used by many "Live" distros.



Keep in mind that today GRUB can be used to load many operating systems, while LILO was more limited, and specifically targeted at Linux (i.e. LInux LOader), with some support for dual booting to Windows.
GRUB is very useful for dual/multi booting because of its many configurable options, scripting capabilities, etc...

If you just want a single OS on your machine "any" (i.e. whichever bootloader is the default for your Linux/BSD distribution) should be enough.






share|improve this answer




















  • 5





    @MrShunz: there was no UEFI back then. Booting windows was just a matter of adding an entry of e.g. other=/dev/hda1 with table=/dev/hda to lilo.conf, and lilo would just transfer control to the boot sector at hda1, knowing the partition table would be at hda.

    – ninjalj
    Jan 7 at 12:10






  • 2





    You used to be able to get NTLDR to load LILO; see jaeger.morpheus.net/linux/ntldr.php; I discovered the same independently, back in the day.

    – Roger Lipscombe
    Jan 7 at 13:41






  • 2





    The downside of the LILO approach is it breaks if the location of disk of the files to load changes. In particular this means that LILO needed to be re-written to the boot location (either MBR or partition boot sector) after every kernel upgrade.

    – plugwash
    Jan 7 at 14:26






  • 1





    @plugwash: GRUB has the same issue with its second stage file. The difference here is that 1) the "second stage" of LILO was the kernel, so it was kernel updates, not LILO updates that broke things; and 2) GRUB updates include an automatic re-writing of the second stage location to the MBR (with the second stage then loading the Linux kernel, with full knowledge of the file system so kernel location does not matter). ;-)

    – DevSolar
    Jan 8 at 13:54







  • 1





    IIRC grub will if possible store a "stage 1.5" that understands the file system between the MBR and the first partition and will only resort to storing a reference to specific filesystem sectors if there is no room for stage 1.5 (or if it is installing to a partition boot sector rather than the MBR)

    – plugwash
    Jan 8 at 13:55



















28














LILO was the de-facto standard for booting Linux on PCs before Grub, from a very early stage (MCC, one of the first Linux distributions, used it). Various other bootloaders were used contemporaneously. Loadlin was quite common; it booted Linux from DOS, and was even used in some configurations with umsdos to host a Linux environment in a DOS file system... Another common configuration didn’t involve a bootloader at all: the kernel could boot itself from a floppy, and most Linux users kept a known-good pair of “boot and root” floppies, one containing the kernel, the other a basic root file system for rescue purposes.



There were a number of ways of using other operating systems’ bootloaders to boot Linux too; for example, OS/2’s boot manager, or Windows NT’s NTLDR.



Other systems had their own bootloaders:




  • SILO on SPARC (Sun workstations and others);


  • PALO on PA-RISC (HP workstations);

  • YaBoot and Quik on PowerPC;

  • aBoot and MILO on Alpha...

Even nowadays Grub isn’t the only bootloader you’ll see. While having the kernel boot directly from floppy is no longer very useful (I haven’t checked whether it’s still possible, assuming you can build a kernel small enough to fit on a floppy), it can boot directly from EFI (which is effectively its own small operating system designed to load other operating systems, as is Grub). On many smaller systems (embedded systems, single-board computers...) you’ll find U-Boot. (And there’s also an EFI layer for U-Boot.)






share|improve this answer

























  • The PowerPC architecture is also interesting because some motherboards had a Turing-complete BIOS - Openfirmware (basically the Forth programming language with some preinstalled functions). This allowed booting directly from BIOS without bootloader if you know how to configure your BIOS

    – slebetman
    Jan 8 at 1:21











  • Hey, just curious, NTLDR can load linux kernel directly? I heard that NTLDR can chainloader grub4dos and then load the linux kernel.

    – 炸鱼薯条德里克
    Jan 8 at 4:09











  • @slebetman: More precisely, OpenFirmware was developed by Sun for SPARC and then adopted by the PowerPC alliance (IBM, Apple, Motorola) for the PowerPC Reference Architecture, and specifically by Apple for PowerPC-based Macintoshs. One of the powerful aspects was that simple drivers could be stored inside ROM chips on the expansion cards, or in some designated boot area of a HDD, and since they were written in bytecode against a known specified ABI, they would work regardless of which CPU architecture and OS you were trying to boot.

    – Jörg W Mittag
    Jan 8 at 14:07











  • E.g. you could have RAID adapter which has its OpenFirmware driver inside a ROM chip, then the OpenFirmware environment could use that driver to access the RAID, inside the RAID, there could be another driver for the partition table format, which would allow the OFW environment to find the partitions, at the beginning of each partition would be an OFW driver for the filesystem, which would allow the OFW system to find the kernel, and the kernel would have a small bootloader written in OFW bytecode at the beginning.

    – Jörg W Mittag
    Jan 8 at 14:10











  • GRUB can operate in a similar way, but the difference is that all those drivers have to be written specifically for GRUB, whereas the beauty of OFW was that the device would bring its drivers with it, which means that even devices that didn't yet exist when the OFW environment was written would just "magically" work. UEFI can also operate in a similar way, but its "portable bytecode format" is essentially a subset of DOS, which is the main reason why Itaniums still need an x86 emulator.

    – Jörg W Mittag
    Jan 8 at 14:13



















12














Up through mid 2.6 kernels, the x86 kernel was directly bootable if copied onto a floppy disk (as though it were a disk image).



This was, in fact, the original way of booting Linux.



If you look at the header of an x86 kernel today you see an error message that says booting from floppies like that doesn't work anymore.






share|improve this answer


















  • 2





    On the other hand, the x86 kernel is now directly bootable if given to an UEFI firmware. So there's still a stub bootloader tacked in front of the kernel, just a different type...

    – grawity
    Jan 7 at 20:58











  • @grawity: Are you sure you don't mean x64?

    – Joshua
    Jan 7 at 20:59






  • 1





    @Joshua: I'm not sure what you mean by that. EFI doesn't actually execute this part as code.

    – grawity
    Jan 8 at 14:12






  • 2





    @Joshua what? It’s “DEC BP”, “POP DX” in 16-bit mode (EBP/EDX in 32-bit mode). But it shouldn’t be executed anyway; EFI binaries are PE files (which of course doesn’t matter if it’s written to a boot sector...).

    – Stephen Kitt
    Jan 8 at 14:14







  • 1





    @Joshua OK, but that’s not undefined x86 behaviour in my mind ;-). (I think of “undefined x86 behaviour” as opcodes whose behaviour isn’t defined, not undefined platform behaviour.)

    – Stephen Kitt
    Jan 8 at 14:26



















5














I started with Linux in the late 90s and as mentioned lilo was the default. If you wanted to dual boot with a DOS system, you could do a bare boot without loading stuff into HIMEM or loading CD drivers, etc. and use loadlin. For Win95 dual booting, you could make the drive bootable first with DOS, then install '95, and '95's boot loader would let you boot the DOS kernel still, and then you could use loadlin.



For dual booting with NT4, the trick was to write LILO to the / partition, then strip off the first 512 bytes using dd (dd if=/dev/sda2 of=/path/to/file bs=512 count=1) and put the resulting file where ntldr could see it and you could use it from WinNT's boot loader. The issue with doing that is when you upgraded your kernel you had to remember to repeat all the steps before rebooting, otherwise you'd have issues getting back into the Linux system. Same process worked with Win2k.



With LILO, any time the kernel was updated, you had to remember to update LILO.



With loadlin any time the kernel updated, you had to remember to copy the kernel out to the DOS partition.



One other option that is hinted at in other answers was to write the kernel directly to a floppy using dd if=/path/to/vmlinuz of=/dev/fd0 BUT the root device had to be set properly in the kernel, either at compile time or by using the rdev utility.



When GRUB came around, there was much rejoicing because you no longer had to remember to update LILO, or update LILO and re-strip off the boot info, etc. No more getting left out of your Linux system because you forgot to update the boot loader info...






share|improve this answer























  • Sounds like it was whole lot of work and high chance to be left with non-booting machine back then, but definitely an educational experience

    – Sergiy Kolodyazhnyy
    Jan 9 at 3:02











  • @SergiyKolodyazhnyy yeah, and there wasn't such a wealth of info on the internet, or the great search engines to find it if it was there. There were several single floppy disk rescue distros that had just enough Linux to boot and fix LILO, etc. We've come a long way!

    – ivanivan
    Jan 9 at 3:05











  • Running make install would run /sbin/lilo, so you didn't really have to update anything by hand (and that may still be the case, if you have lilo installed). That may be a matter of opinion, but I don't remember much rejoicing at grub, at the contrary. And lilo (at least its 1999 version) could dual boot windows just fine, no need of loadlin.

    – mosvy
    Jan 9 at 19:51



















0














And before LILO and GRUB, you had to launch it from the command line with some sort of custom bootloader utility.



As an example, the Amiga had Linux available. You had to use a command line utility called amiboot to load the kernel ELF into memory and jump to it.



Here is a video of someone using amiboot from the command line to launch linux on an Amiga 600. His StartInstall script is calling the amiboot executable. You can watch amiboot configure memory, figure out the desired load address, and pass parameters to the kernel at around 0:55.






share|improve this answer






















    Your Answer








    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f492966%2fhow-did-linux-xbsd-boot-before-grub%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    5 Answers
    5






    active

    oldest

    votes








    5 Answers
    5






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    51














    The first Linux distribution I used back in the 90s (Slackware 3.0 IIRC) used LILO as a bootloader. And many distros used LILO for years even when GRUB was becoming the "default" bootloader.



    Moreover, in the early years of Linux it was common to boot Linux from another OS (i.e. DOS or Windows) instead of relying on a bootloader/dual booting. For example there was loadlin.



    Don't forget Syslinux, which is a simpler boot loader often used for USB self-bootable installation/recovery distros. Or Isolinux (from the same project) used by many "Live" distros.



    Keep in mind that today GRUB can be used to load many operating systems, while LILO was more limited, and specifically targeted at Linux (i.e. LInux LOader), with some support for dual booting to Windows.
    GRUB is very useful for dual/multi booting because of its many configurable options, scripting capabilities, etc...

    If you just want a single OS on your machine "any" (i.e. whichever bootloader is the default for your Linux/BSD distribution) should be enough.






    share|improve this answer




















    • 5





      @MrShunz: there was no UEFI back then. Booting windows was just a matter of adding an entry of e.g. other=/dev/hda1 with table=/dev/hda to lilo.conf, and lilo would just transfer control to the boot sector at hda1, knowing the partition table would be at hda.

      – ninjalj
      Jan 7 at 12:10






    • 2





      You used to be able to get NTLDR to load LILO; see jaeger.morpheus.net/linux/ntldr.php; I discovered the same independently, back in the day.

      – Roger Lipscombe
      Jan 7 at 13:41






    • 2





      The downside of the LILO approach is it breaks if the location of disk of the files to load changes. In particular this means that LILO needed to be re-written to the boot location (either MBR or partition boot sector) after every kernel upgrade.

      – plugwash
      Jan 7 at 14:26






    • 1





      @plugwash: GRUB has the same issue with its second stage file. The difference here is that 1) the "second stage" of LILO was the kernel, so it was kernel updates, not LILO updates that broke things; and 2) GRUB updates include an automatic re-writing of the second stage location to the MBR (with the second stage then loading the Linux kernel, with full knowledge of the file system so kernel location does not matter). ;-)

      – DevSolar
      Jan 8 at 13:54







    • 1





      IIRC grub will if possible store a "stage 1.5" that understands the file system between the MBR and the first partition and will only resort to storing a reference to specific filesystem sectors if there is no room for stage 1.5 (or if it is installing to a partition boot sector rather than the MBR)

      – plugwash
      Jan 8 at 13:55
















    51














    The first Linux distribution I used back in the 90s (Slackware 3.0 IIRC) used LILO as a bootloader. And many distros used LILO for years even when GRUB was becoming the "default" bootloader.



    Moreover, in the early years of Linux it was common to boot Linux from another OS (i.e. DOS or Windows) instead of relying on a bootloader/dual booting. For example there was loadlin.



    Don't forget Syslinux, which is a simpler boot loader often used for USB self-bootable installation/recovery distros. Or Isolinux (from the same project) used by many "Live" distros.



    Keep in mind that today GRUB can be used to load many operating systems, while LILO was more limited, and specifically targeted at Linux (i.e. LInux LOader), with some support for dual booting to Windows.
    GRUB is very useful for dual/multi booting because of its many configurable options, scripting capabilities, etc...

    If you just want a single OS on your machine "any" (i.e. whichever bootloader is the default for your Linux/BSD distribution) should be enough.






    share|improve this answer




















    • 5





      @MrShunz: there was no UEFI back then. Booting windows was just a matter of adding an entry of e.g. other=/dev/hda1 with table=/dev/hda to lilo.conf, and lilo would just transfer control to the boot sector at hda1, knowing the partition table would be at hda.

      – ninjalj
      Jan 7 at 12:10






    • 2





      You used to be able to get NTLDR to load LILO; see jaeger.morpheus.net/linux/ntldr.php; I discovered the same independently, back in the day.

      – Roger Lipscombe
      Jan 7 at 13:41






    • 2





      The downside of the LILO approach is it breaks if the location of disk of the files to load changes. In particular this means that LILO needed to be re-written to the boot location (either MBR or partition boot sector) after every kernel upgrade.

      – plugwash
      Jan 7 at 14:26






    • 1





      @plugwash: GRUB has the same issue with its second stage file. The difference here is that 1) the "second stage" of LILO was the kernel, so it was kernel updates, not LILO updates that broke things; and 2) GRUB updates include an automatic re-writing of the second stage location to the MBR (with the second stage then loading the Linux kernel, with full knowledge of the file system so kernel location does not matter). ;-)

      – DevSolar
      Jan 8 at 13:54







    • 1





      IIRC grub will if possible store a "stage 1.5" that understands the file system between the MBR and the first partition and will only resort to storing a reference to specific filesystem sectors if there is no room for stage 1.5 (or if it is installing to a partition boot sector rather than the MBR)

      – plugwash
      Jan 8 at 13:55














    51












    51








    51







    The first Linux distribution I used back in the 90s (Slackware 3.0 IIRC) used LILO as a bootloader. And many distros used LILO for years even when GRUB was becoming the "default" bootloader.



    Moreover, in the early years of Linux it was common to boot Linux from another OS (i.e. DOS or Windows) instead of relying on a bootloader/dual booting. For example there was loadlin.



    Don't forget Syslinux, which is a simpler boot loader often used for USB self-bootable installation/recovery distros. Or Isolinux (from the same project) used by many "Live" distros.



    Keep in mind that today GRUB can be used to load many operating systems, while LILO was more limited, and specifically targeted at Linux (i.e. LInux LOader), with some support for dual booting to Windows.
    GRUB is very useful for dual/multi booting because of its many configurable options, scripting capabilities, etc...

    If you just want a single OS on your machine "any" (i.e. whichever bootloader is the default for your Linux/BSD distribution) should be enough.






    share|improve this answer















    The first Linux distribution I used back in the 90s (Slackware 3.0 IIRC) used LILO as a bootloader. And many distros used LILO for years even when GRUB was becoming the "default" bootloader.



    Moreover, in the early years of Linux it was common to boot Linux from another OS (i.e. DOS or Windows) instead of relying on a bootloader/dual booting. For example there was loadlin.



    Don't forget Syslinux, which is a simpler boot loader often used for USB self-bootable installation/recovery distros. Or Isolinux (from the same project) used by many "Live" distros.



    Keep in mind that today GRUB can be used to load many operating systems, while LILO was more limited, and specifically targeted at Linux (i.e. LInux LOader), with some support for dual booting to Windows.
    GRUB is very useful for dual/multi booting because of its many configurable options, scripting capabilities, etc...

    If you just want a single OS on your machine "any" (i.e. whichever bootloader is the default for your Linux/BSD distribution) should be enough.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jan 7 at 12:04

























    answered Jan 7 at 10:48









    Mr ShunzMr Shunz

    3,44212027




    3,44212027







    • 5





      @MrShunz: there was no UEFI back then. Booting windows was just a matter of adding an entry of e.g. other=/dev/hda1 with table=/dev/hda to lilo.conf, and lilo would just transfer control to the boot sector at hda1, knowing the partition table would be at hda.

      – ninjalj
      Jan 7 at 12:10






    • 2





      You used to be able to get NTLDR to load LILO; see jaeger.morpheus.net/linux/ntldr.php; I discovered the same independently, back in the day.

      – Roger Lipscombe
      Jan 7 at 13:41






    • 2





      The downside of the LILO approach is it breaks if the location of disk of the files to load changes. In particular this means that LILO needed to be re-written to the boot location (either MBR or partition boot sector) after every kernel upgrade.

      – plugwash
      Jan 7 at 14:26






    • 1





      @plugwash: GRUB has the same issue with its second stage file. The difference here is that 1) the "second stage" of LILO was the kernel, so it was kernel updates, not LILO updates that broke things; and 2) GRUB updates include an automatic re-writing of the second stage location to the MBR (with the second stage then loading the Linux kernel, with full knowledge of the file system so kernel location does not matter). ;-)

      – DevSolar
      Jan 8 at 13:54







    • 1





      IIRC grub will if possible store a "stage 1.5" that understands the file system between the MBR and the first partition and will only resort to storing a reference to specific filesystem sectors if there is no room for stage 1.5 (or if it is installing to a partition boot sector rather than the MBR)

      – plugwash
      Jan 8 at 13:55













    • 5





      @MrShunz: there was no UEFI back then. Booting windows was just a matter of adding an entry of e.g. other=/dev/hda1 with table=/dev/hda to lilo.conf, and lilo would just transfer control to the boot sector at hda1, knowing the partition table would be at hda.

      – ninjalj
      Jan 7 at 12:10






    • 2





      You used to be able to get NTLDR to load LILO; see jaeger.morpheus.net/linux/ntldr.php; I discovered the same independently, back in the day.

      – Roger Lipscombe
      Jan 7 at 13:41






    • 2





      The downside of the LILO approach is it breaks if the location of disk of the files to load changes. In particular this means that LILO needed to be re-written to the boot location (either MBR or partition boot sector) after every kernel upgrade.

      – plugwash
      Jan 7 at 14:26






    • 1





      @plugwash: GRUB has the same issue with its second stage file. The difference here is that 1) the "second stage" of LILO was the kernel, so it was kernel updates, not LILO updates that broke things; and 2) GRUB updates include an automatic re-writing of the second stage location to the MBR (with the second stage then loading the Linux kernel, with full knowledge of the file system so kernel location does not matter). ;-)

      – DevSolar
      Jan 8 at 13:54







    • 1





      IIRC grub will if possible store a "stage 1.5" that understands the file system between the MBR and the first partition and will only resort to storing a reference to specific filesystem sectors if there is no room for stage 1.5 (or if it is installing to a partition boot sector rather than the MBR)

      – plugwash
      Jan 8 at 13:55








    5




    5





    @MrShunz: there was no UEFI back then. Booting windows was just a matter of adding an entry of e.g. other=/dev/hda1 with table=/dev/hda to lilo.conf, and lilo would just transfer control to the boot sector at hda1, knowing the partition table would be at hda.

    – ninjalj
    Jan 7 at 12:10





    @MrShunz: there was no UEFI back then. Booting windows was just a matter of adding an entry of e.g. other=/dev/hda1 with table=/dev/hda to lilo.conf, and lilo would just transfer control to the boot sector at hda1, knowing the partition table would be at hda.

    – ninjalj
    Jan 7 at 12:10




    2




    2





    You used to be able to get NTLDR to load LILO; see jaeger.morpheus.net/linux/ntldr.php; I discovered the same independently, back in the day.

    – Roger Lipscombe
    Jan 7 at 13:41





    You used to be able to get NTLDR to load LILO; see jaeger.morpheus.net/linux/ntldr.php; I discovered the same independently, back in the day.

    – Roger Lipscombe
    Jan 7 at 13:41




    2




    2





    The downside of the LILO approach is it breaks if the location of disk of the files to load changes. In particular this means that LILO needed to be re-written to the boot location (either MBR or partition boot sector) after every kernel upgrade.

    – plugwash
    Jan 7 at 14:26





    The downside of the LILO approach is it breaks if the location of disk of the files to load changes. In particular this means that LILO needed to be re-written to the boot location (either MBR or partition boot sector) after every kernel upgrade.

    – plugwash
    Jan 7 at 14:26




    1




    1





    @plugwash: GRUB has the same issue with its second stage file. The difference here is that 1) the "second stage" of LILO was the kernel, so it was kernel updates, not LILO updates that broke things; and 2) GRUB updates include an automatic re-writing of the second stage location to the MBR (with the second stage then loading the Linux kernel, with full knowledge of the file system so kernel location does not matter). ;-)

    – DevSolar
    Jan 8 at 13:54






    @plugwash: GRUB has the same issue with its second stage file. The difference here is that 1) the "second stage" of LILO was the kernel, so it was kernel updates, not LILO updates that broke things; and 2) GRUB updates include an automatic re-writing of the second stage location to the MBR (with the second stage then loading the Linux kernel, with full knowledge of the file system so kernel location does not matter). ;-)

    – DevSolar
    Jan 8 at 13:54





    1




    1





    IIRC grub will if possible store a "stage 1.5" that understands the file system between the MBR and the first partition and will only resort to storing a reference to specific filesystem sectors if there is no room for stage 1.5 (or if it is installing to a partition boot sector rather than the MBR)

    – plugwash
    Jan 8 at 13:55






    IIRC grub will if possible store a "stage 1.5" that understands the file system between the MBR and the first partition and will only resort to storing a reference to specific filesystem sectors if there is no room for stage 1.5 (or if it is installing to a partition boot sector rather than the MBR)

    – plugwash
    Jan 8 at 13:55














    28














    LILO was the de-facto standard for booting Linux on PCs before Grub, from a very early stage (MCC, one of the first Linux distributions, used it). Various other bootloaders were used contemporaneously. Loadlin was quite common; it booted Linux from DOS, and was even used in some configurations with umsdos to host a Linux environment in a DOS file system... Another common configuration didn’t involve a bootloader at all: the kernel could boot itself from a floppy, and most Linux users kept a known-good pair of “boot and root” floppies, one containing the kernel, the other a basic root file system for rescue purposes.



    There were a number of ways of using other operating systems’ bootloaders to boot Linux too; for example, OS/2’s boot manager, or Windows NT’s NTLDR.



    Other systems had their own bootloaders:




    • SILO on SPARC (Sun workstations and others);


    • PALO on PA-RISC (HP workstations);

    • YaBoot and Quik on PowerPC;

    • aBoot and MILO on Alpha...

    Even nowadays Grub isn’t the only bootloader you’ll see. While having the kernel boot directly from floppy is no longer very useful (I haven’t checked whether it’s still possible, assuming you can build a kernel small enough to fit on a floppy), it can boot directly from EFI (which is effectively its own small operating system designed to load other operating systems, as is Grub). On many smaller systems (embedded systems, single-board computers...) you’ll find U-Boot. (And there’s also an EFI layer for U-Boot.)






    share|improve this answer

























    • The PowerPC architecture is also interesting because some motherboards had a Turing-complete BIOS - Openfirmware (basically the Forth programming language with some preinstalled functions). This allowed booting directly from BIOS without bootloader if you know how to configure your BIOS

      – slebetman
      Jan 8 at 1:21











    • Hey, just curious, NTLDR can load linux kernel directly? I heard that NTLDR can chainloader grub4dos and then load the linux kernel.

      – 炸鱼薯条德里克
      Jan 8 at 4:09











    • @slebetman: More precisely, OpenFirmware was developed by Sun for SPARC and then adopted by the PowerPC alliance (IBM, Apple, Motorola) for the PowerPC Reference Architecture, and specifically by Apple for PowerPC-based Macintoshs. One of the powerful aspects was that simple drivers could be stored inside ROM chips on the expansion cards, or in some designated boot area of a HDD, and since they were written in bytecode against a known specified ABI, they would work regardless of which CPU architecture and OS you were trying to boot.

      – Jörg W Mittag
      Jan 8 at 14:07











    • E.g. you could have RAID adapter which has its OpenFirmware driver inside a ROM chip, then the OpenFirmware environment could use that driver to access the RAID, inside the RAID, there could be another driver for the partition table format, which would allow the OFW environment to find the partitions, at the beginning of each partition would be an OFW driver for the filesystem, which would allow the OFW system to find the kernel, and the kernel would have a small bootloader written in OFW bytecode at the beginning.

      – Jörg W Mittag
      Jan 8 at 14:10











    • GRUB can operate in a similar way, but the difference is that all those drivers have to be written specifically for GRUB, whereas the beauty of OFW was that the device would bring its drivers with it, which means that even devices that didn't yet exist when the OFW environment was written would just "magically" work. UEFI can also operate in a similar way, but its "portable bytecode format" is essentially a subset of DOS, which is the main reason why Itaniums still need an x86 emulator.

      – Jörg W Mittag
      Jan 8 at 14:13
















    28














    LILO was the de-facto standard for booting Linux on PCs before Grub, from a very early stage (MCC, one of the first Linux distributions, used it). Various other bootloaders were used contemporaneously. Loadlin was quite common; it booted Linux from DOS, and was even used in some configurations with umsdos to host a Linux environment in a DOS file system... Another common configuration didn’t involve a bootloader at all: the kernel could boot itself from a floppy, and most Linux users kept a known-good pair of “boot and root” floppies, one containing the kernel, the other a basic root file system for rescue purposes.



    There were a number of ways of using other operating systems’ bootloaders to boot Linux too; for example, OS/2’s boot manager, or Windows NT’s NTLDR.



    Other systems had their own bootloaders:




    • SILO on SPARC (Sun workstations and others);


    • PALO on PA-RISC (HP workstations);

    • YaBoot and Quik on PowerPC;

    • aBoot and MILO on Alpha...

    Even nowadays Grub isn’t the only bootloader you’ll see. While having the kernel boot directly from floppy is no longer very useful (I haven’t checked whether it’s still possible, assuming you can build a kernel small enough to fit on a floppy), it can boot directly from EFI (which is effectively its own small operating system designed to load other operating systems, as is Grub). On many smaller systems (embedded systems, single-board computers...) you’ll find U-Boot. (And there’s also an EFI layer for U-Boot.)






    share|improve this answer

























    • The PowerPC architecture is also interesting because some motherboards had a Turing-complete BIOS - Openfirmware (basically the Forth programming language with some preinstalled functions). This allowed booting directly from BIOS without bootloader if you know how to configure your BIOS

      – slebetman
      Jan 8 at 1:21











    • Hey, just curious, NTLDR can load linux kernel directly? I heard that NTLDR can chainloader grub4dos and then load the linux kernel.

      – 炸鱼薯条德里克
      Jan 8 at 4:09











    • @slebetman: More precisely, OpenFirmware was developed by Sun for SPARC and then adopted by the PowerPC alliance (IBM, Apple, Motorola) for the PowerPC Reference Architecture, and specifically by Apple for PowerPC-based Macintoshs. One of the powerful aspects was that simple drivers could be stored inside ROM chips on the expansion cards, or in some designated boot area of a HDD, and since they were written in bytecode against a known specified ABI, they would work regardless of which CPU architecture and OS you were trying to boot.

      – Jörg W Mittag
      Jan 8 at 14:07











    • E.g. you could have RAID adapter which has its OpenFirmware driver inside a ROM chip, then the OpenFirmware environment could use that driver to access the RAID, inside the RAID, there could be another driver for the partition table format, which would allow the OFW environment to find the partitions, at the beginning of each partition would be an OFW driver for the filesystem, which would allow the OFW system to find the kernel, and the kernel would have a small bootloader written in OFW bytecode at the beginning.

      – Jörg W Mittag
      Jan 8 at 14:10











    • GRUB can operate in a similar way, but the difference is that all those drivers have to be written specifically for GRUB, whereas the beauty of OFW was that the device would bring its drivers with it, which means that even devices that didn't yet exist when the OFW environment was written would just "magically" work. UEFI can also operate in a similar way, but its "portable bytecode format" is essentially a subset of DOS, which is the main reason why Itaniums still need an x86 emulator.

      – Jörg W Mittag
      Jan 8 at 14:13














    28












    28








    28







    LILO was the de-facto standard for booting Linux on PCs before Grub, from a very early stage (MCC, one of the first Linux distributions, used it). Various other bootloaders were used contemporaneously. Loadlin was quite common; it booted Linux from DOS, and was even used in some configurations with umsdos to host a Linux environment in a DOS file system... Another common configuration didn’t involve a bootloader at all: the kernel could boot itself from a floppy, and most Linux users kept a known-good pair of “boot and root” floppies, one containing the kernel, the other a basic root file system for rescue purposes.



    There were a number of ways of using other operating systems’ bootloaders to boot Linux too; for example, OS/2’s boot manager, or Windows NT’s NTLDR.



    Other systems had their own bootloaders:




    • SILO on SPARC (Sun workstations and others);


    • PALO on PA-RISC (HP workstations);

    • YaBoot and Quik on PowerPC;

    • aBoot and MILO on Alpha...

    Even nowadays Grub isn’t the only bootloader you’ll see. While having the kernel boot directly from floppy is no longer very useful (I haven’t checked whether it’s still possible, assuming you can build a kernel small enough to fit on a floppy), it can boot directly from EFI (which is effectively its own small operating system designed to load other operating systems, as is Grub). On many smaller systems (embedded systems, single-board computers...) you’ll find U-Boot. (And there’s also an EFI layer for U-Boot.)






    share|improve this answer















    LILO was the de-facto standard for booting Linux on PCs before Grub, from a very early stage (MCC, one of the first Linux distributions, used it). Various other bootloaders were used contemporaneously. Loadlin was quite common; it booted Linux from DOS, and was even used in some configurations with umsdos to host a Linux environment in a DOS file system... Another common configuration didn’t involve a bootloader at all: the kernel could boot itself from a floppy, and most Linux users kept a known-good pair of “boot and root” floppies, one containing the kernel, the other a basic root file system for rescue purposes.



    There were a number of ways of using other operating systems’ bootloaders to boot Linux too; for example, OS/2’s boot manager, or Windows NT’s NTLDR.



    Other systems had their own bootloaders:




    • SILO on SPARC (Sun workstations and others);


    • PALO on PA-RISC (HP workstations);

    • YaBoot and Quik on PowerPC;

    • aBoot and MILO on Alpha...

    Even nowadays Grub isn’t the only bootloader you’ll see. While having the kernel boot directly from floppy is no longer very useful (I haven’t checked whether it’s still possible, assuming you can build a kernel small enough to fit on a floppy), it can boot directly from EFI (which is effectively its own small operating system designed to load other operating systems, as is Grub). On many smaller systems (embedded systems, single-board computers...) you’ll find U-Boot. (And there’s also an EFI layer for U-Boot.)







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Jan 7 at 12:26

























    answered Jan 7 at 12:18









    Stephen KittStephen Kitt

    168k24378455




    168k24378455












    • The PowerPC architecture is also interesting because some motherboards had a Turing-complete BIOS - Openfirmware (basically the Forth programming language with some preinstalled functions). This allowed booting directly from BIOS without bootloader if you know how to configure your BIOS

      – slebetman
      Jan 8 at 1:21











    • Hey, just curious, NTLDR can load linux kernel directly? I heard that NTLDR can chainloader grub4dos and then load the linux kernel.

      – 炸鱼薯条德里克
      Jan 8 at 4:09











    • @slebetman: More precisely, OpenFirmware was developed by Sun for SPARC and then adopted by the PowerPC alliance (IBM, Apple, Motorola) for the PowerPC Reference Architecture, and specifically by Apple for PowerPC-based Macintoshs. One of the powerful aspects was that simple drivers could be stored inside ROM chips on the expansion cards, or in some designated boot area of a HDD, and since they were written in bytecode against a known specified ABI, they would work regardless of which CPU architecture and OS you were trying to boot.

      – Jörg W Mittag
      Jan 8 at 14:07











    • E.g. you could have RAID adapter which has its OpenFirmware driver inside a ROM chip, then the OpenFirmware environment could use that driver to access the RAID, inside the RAID, there could be another driver for the partition table format, which would allow the OFW environment to find the partitions, at the beginning of each partition would be an OFW driver for the filesystem, which would allow the OFW system to find the kernel, and the kernel would have a small bootloader written in OFW bytecode at the beginning.

      – Jörg W Mittag
      Jan 8 at 14:10











    • GRUB can operate in a similar way, but the difference is that all those drivers have to be written specifically for GRUB, whereas the beauty of OFW was that the device would bring its drivers with it, which means that even devices that didn't yet exist when the OFW environment was written would just "magically" work. UEFI can also operate in a similar way, but its "portable bytecode format" is essentially a subset of DOS, which is the main reason why Itaniums still need an x86 emulator.

      – Jörg W Mittag
      Jan 8 at 14:13


















    • The PowerPC architecture is also interesting because some motherboards had a Turing-complete BIOS - Openfirmware (basically the Forth programming language with some preinstalled functions). This allowed booting directly from BIOS without bootloader if you know how to configure your BIOS

      – slebetman
      Jan 8 at 1:21











    • Hey, just curious, NTLDR can load linux kernel directly? I heard that NTLDR can chainloader grub4dos and then load the linux kernel.

      – 炸鱼薯条德里克
      Jan 8 at 4:09











    • @slebetman: More precisely, OpenFirmware was developed by Sun for SPARC and then adopted by the PowerPC alliance (IBM, Apple, Motorola) for the PowerPC Reference Architecture, and specifically by Apple for PowerPC-based Macintoshs. One of the powerful aspects was that simple drivers could be stored inside ROM chips on the expansion cards, or in some designated boot area of a HDD, and since they were written in bytecode against a known specified ABI, they would work regardless of which CPU architecture and OS you were trying to boot.

      – Jörg W Mittag
      Jan 8 at 14:07











    • E.g. you could have RAID adapter which has its OpenFirmware driver inside a ROM chip, then the OpenFirmware environment could use that driver to access the RAID, inside the RAID, there could be another driver for the partition table format, which would allow the OFW environment to find the partitions, at the beginning of each partition would be an OFW driver for the filesystem, which would allow the OFW system to find the kernel, and the kernel would have a small bootloader written in OFW bytecode at the beginning.

      – Jörg W Mittag
      Jan 8 at 14:10











    • GRUB can operate in a similar way, but the difference is that all those drivers have to be written specifically for GRUB, whereas the beauty of OFW was that the device would bring its drivers with it, which means that even devices that didn't yet exist when the OFW environment was written would just "magically" work. UEFI can also operate in a similar way, but its "portable bytecode format" is essentially a subset of DOS, which is the main reason why Itaniums still need an x86 emulator.

      – Jörg W Mittag
      Jan 8 at 14:13

















    The PowerPC architecture is also interesting because some motherboards had a Turing-complete BIOS - Openfirmware (basically the Forth programming language with some preinstalled functions). This allowed booting directly from BIOS without bootloader if you know how to configure your BIOS

    – slebetman
    Jan 8 at 1:21





    The PowerPC architecture is also interesting because some motherboards had a Turing-complete BIOS - Openfirmware (basically the Forth programming language with some preinstalled functions). This allowed booting directly from BIOS without bootloader if you know how to configure your BIOS

    – slebetman
    Jan 8 at 1:21













    Hey, just curious, NTLDR can load linux kernel directly? I heard that NTLDR can chainloader grub4dos and then load the linux kernel.

    – 炸鱼薯条德里克
    Jan 8 at 4:09





    Hey, just curious, NTLDR can load linux kernel directly? I heard that NTLDR can chainloader grub4dos and then load the linux kernel.

    – 炸鱼薯条德里克
    Jan 8 at 4:09













    @slebetman: More precisely, OpenFirmware was developed by Sun for SPARC and then adopted by the PowerPC alliance (IBM, Apple, Motorola) for the PowerPC Reference Architecture, and specifically by Apple for PowerPC-based Macintoshs. One of the powerful aspects was that simple drivers could be stored inside ROM chips on the expansion cards, or in some designated boot area of a HDD, and since they were written in bytecode against a known specified ABI, they would work regardless of which CPU architecture and OS you were trying to boot.

    – Jörg W Mittag
    Jan 8 at 14:07





    @slebetman: More precisely, OpenFirmware was developed by Sun for SPARC and then adopted by the PowerPC alliance (IBM, Apple, Motorola) for the PowerPC Reference Architecture, and specifically by Apple for PowerPC-based Macintoshs. One of the powerful aspects was that simple drivers could be stored inside ROM chips on the expansion cards, or in some designated boot area of a HDD, and since they were written in bytecode against a known specified ABI, they would work regardless of which CPU architecture and OS you were trying to boot.

    – Jörg W Mittag
    Jan 8 at 14:07













    E.g. you could have RAID adapter which has its OpenFirmware driver inside a ROM chip, then the OpenFirmware environment could use that driver to access the RAID, inside the RAID, there could be another driver for the partition table format, which would allow the OFW environment to find the partitions, at the beginning of each partition would be an OFW driver for the filesystem, which would allow the OFW system to find the kernel, and the kernel would have a small bootloader written in OFW bytecode at the beginning.

    – Jörg W Mittag
    Jan 8 at 14:10





    E.g. you could have RAID adapter which has its OpenFirmware driver inside a ROM chip, then the OpenFirmware environment could use that driver to access the RAID, inside the RAID, there could be another driver for the partition table format, which would allow the OFW environment to find the partitions, at the beginning of each partition would be an OFW driver for the filesystem, which would allow the OFW system to find the kernel, and the kernel would have a small bootloader written in OFW bytecode at the beginning.

    – Jörg W Mittag
    Jan 8 at 14:10













    GRUB can operate in a similar way, but the difference is that all those drivers have to be written specifically for GRUB, whereas the beauty of OFW was that the device would bring its drivers with it, which means that even devices that didn't yet exist when the OFW environment was written would just "magically" work. UEFI can also operate in a similar way, but its "portable bytecode format" is essentially a subset of DOS, which is the main reason why Itaniums still need an x86 emulator.

    – Jörg W Mittag
    Jan 8 at 14:13






    GRUB can operate in a similar way, but the difference is that all those drivers have to be written specifically for GRUB, whereas the beauty of OFW was that the device would bring its drivers with it, which means that even devices that didn't yet exist when the OFW environment was written would just "magically" work. UEFI can also operate in a similar way, but its "portable bytecode format" is essentially a subset of DOS, which is the main reason why Itaniums still need an x86 emulator.

    – Jörg W Mittag
    Jan 8 at 14:13












    12














    Up through mid 2.6 kernels, the x86 kernel was directly bootable if copied onto a floppy disk (as though it were a disk image).



    This was, in fact, the original way of booting Linux.



    If you look at the header of an x86 kernel today you see an error message that says booting from floppies like that doesn't work anymore.






    share|improve this answer


















    • 2





      On the other hand, the x86 kernel is now directly bootable if given to an UEFI firmware. So there's still a stub bootloader tacked in front of the kernel, just a different type...

      – grawity
      Jan 7 at 20:58











    • @grawity: Are you sure you don't mean x64?

      – Joshua
      Jan 7 at 20:59






    • 1





      @Joshua: I'm not sure what you mean by that. EFI doesn't actually execute this part as code.

      – grawity
      Jan 8 at 14:12






    • 2





      @Joshua what? It’s “DEC BP”, “POP DX” in 16-bit mode (EBP/EDX in 32-bit mode). But it shouldn’t be executed anyway; EFI binaries are PE files (which of course doesn’t matter if it’s written to a boot sector...).

      – Stephen Kitt
      Jan 8 at 14:14







    • 1





      @Joshua OK, but that’s not undefined x86 behaviour in my mind ;-). (I think of “undefined x86 behaviour” as opcodes whose behaviour isn’t defined, not undefined platform behaviour.)

      – Stephen Kitt
      Jan 8 at 14:26
















    12














    Up through mid 2.6 kernels, the x86 kernel was directly bootable if copied onto a floppy disk (as though it were a disk image).



    This was, in fact, the original way of booting Linux.



    If you look at the header of an x86 kernel today you see an error message that says booting from floppies like that doesn't work anymore.






    share|improve this answer


















    • 2





      On the other hand, the x86 kernel is now directly bootable if given to an UEFI firmware. So there's still a stub bootloader tacked in front of the kernel, just a different type...

      – grawity
      Jan 7 at 20:58











    • @grawity: Are you sure you don't mean x64?

      – Joshua
      Jan 7 at 20:59






    • 1





      @Joshua: I'm not sure what you mean by that. EFI doesn't actually execute this part as code.

      – grawity
      Jan 8 at 14:12






    • 2





      @Joshua what? It’s “DEC BP”, “POP DX” in 16-bit mode (EBP/EDX in 32-bit mode). But it shouldn’t be executed anyway; EFI binaries are PE files (which of course doesn’t matter if it’s written to a boot sector...).

      – Stephen Kitt
      Jan 8 at 14:14







    • 1





      @Joshua OK, but that’s not undefined x86 behaviour in my mind ;-). (I think of “undefined x86 behaviour” as opcodes whose behaviour isn’t defined, not undefined platform behaviour.)

      – Stephen Kitt
      Jan 8 at 14:26














    12












    12








    12







    Up through mid 2.6 kernels, the x86 kernel was directly bootable if copied onto a floppy disk (as though it were a disk image).



    This was, in fact, the original way of booting Linux.



    If you look at the header of an x86 kernel today you see an error message that says booting from floppies like that doesn't work anymore.






    share|improve this answer













    Up through mid 2.6 kernels, the x86 kernel was directly bootable if copied onto a floppy disk (as though it were a disk image).



    This was, in fact, the original way of booting Linux.



    If you look at the header of an x86 kernel today you see an error message that says booting from floppies like that doesn't work anymore.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Jan 7 at 19:52









    JoshuaJoshua

    1,159713




    1,159713







    • 2





      On the other hand, the x86 kernel is now directly bootable if given to an UEFI firmware. So there's still a stub bootloader tacked in front of the kernel, just a different type...

      – grawity
      Jan 7 at 20:58











    • @grawity: Are you sure you don't mean x64?

      – Joshua
      Jan 7 at 20:59






    • 1





      @Joshua: I'm not sure what you mean by that. EFI doesn't actually execute this part as code.

      – grawity
      Jan 8 at 14:12






    • 2





      @Joshua what? It’s “DEC BP”, “POP DX” in 16-bit mode (EBP/EDX in 32-bit mode). But it shouldn’t be executed anyway; EFI binaries are PE files (which of course doesn’t matter if it’s written to a boot sector...).

      – Stephen Kitt
      Jan 8 at 14:14







    • 1





      @Joshua OK, but that’s not undefined x86 behaviour in my mind ;-). (I think of “undefined x86 behaviour” as opcodes whose behaviour isn’t defined, not undefined platform behaviour.)

      – Stephen Kitt
      Jan 8 at 14:26













    • 2





      On the other hand, the x86 kernel is now directly bootable if given to an UEFI firmware. So there's still a stub bootloader tacked in front of the kernel, just a different type...

      – grawity
      Jan 7 at 20:58











    • @grawity: Are you sure you don't mean x64?

      – Joshua
      Jan 7 at 20:59






    • 1





      @Joshua: I'm not sure what you mean by that. EFI doesn't actually execute this part as code.

      – grawity
      Jan 8 at 14:12






    • 2





      @Joshua what? It’s “DEC BP”, “POP DX” in 16-bit mode (EBP/EDX in 32-bit mode). But it shouldn’t be executed anyway; EFI binaries are PE files (which of course doesn’t matter if it’s written to a boot sector...).

      – Stephen Kitt
      Jan 8 at 14:14







    • 1





      @Joshua OK, but that’s not undefined x86 behaviour in my mind ;-). (I think of “undefined x86 behaviour” as opcodes whose behaviour isn’t defined, not undefined platform behaviour.)

      – Stephen Kitt
      Jan 8 at 14:26








    2




    2





    On the other hand, the x86 kernel is now directly bootable if given to an UEFI firmware. So there's still a stub bootloader tacked in front of the kernel, just a different type...

    – grawity
    Jan 7 at 20:58





    On the other hand, the x86 kernel is now directly bootable if given to an UEFI firmware. So there's still a stub bootloader tacked in front of the kernel, just a different type...

    – grawity
    Jan 7 at 20:58













    @grawity: Are you sure you don't mean x64?

    – Joshua
    Jan 7 at 20:59





    @grawity: Are you sure you don't mean x64?

    – Joshua
    Jan 7 at 20:59




    1




    1





    @Joshua: I'm not sure what you mean by that. EFI doesn't actually execute this part as code.

    – grawity
    Jan 8 at 14:12





    @Joshua: I'm not sure what you mean by that. EFI doesn't actually execute this part as code.

    – grawity
    Jan 8 at 14:12




    2




    2





    @Joshua what? It’s “DEC BP”, “POP DX” in 16-bit mode (EBP/EDX in 32-bit mode). But it shouldn’t be executed anyway; EFI binaries are PE files (which of course doesn’t matter if it’s written to a boot sector...).

    – Stephen Kitt
    Jan 8 at 14:14






    @Joshua what? It’s “DEC BP”, “POP DX” in 16-bit mode (EBP/EDX in 32-bit mode). But it shouldn’t be executed anyway; EFI binaries are PE files (which of course doesn’t matter if it’s written to a boot sector...).

    – Stephen Kitt
    Jan 8 at 14:14





    1




    1





    @Joshua OK, but that’s not undefined x86 behaviour in my mind ;-). (I think of “undefined x86 behaviour” as opcodes whose behaviour isn’t defined, not undefined platform behaviour.)

    – Stephen Kitt
    Jan 8 at 14:26






    @Joshua OK, but that’s not undefined x86 behaviour in my mind ;-). (I think of “undefined x86 behaviour” as opcodes whose behaviour isn’t defined, not undefined platform behaviour.)

    – Stephen Kitt
    Jan 8 at 14:26












    5














    I started with Linux in the late 90s and as mentioned lilo was the default. If you wanted to dual boot with a DOS system, you could do a bare boot without loading stuff into HIMEM or loading CD drivers, etc. and use loadlin. For Win95 dual booting, you could make the drive bootable first with DOS, then install '95, and '95's boot loader would let you boot the DOS kernel still, and then you could use loadlin.



    For dual booting with NT4, the trick was to write LILO to the / partition, then strip off the first 512 bytes using dd (dd if=/dev/sda2 of=/path/to/file bs=512 count=1) and put the resulting file where ntldr could see it and you could use it from WinNT's boot loader. The issue with doing that is when you upgraded your kernel you had to remember to repeat all the steps before rebooting, otherwise you'd have issues getting back into the Linux system. Same process worked with Win2k.



    With LILO, any time the kernel was updated, you had to remember to update LILO.



    With loadlin any time the kernel updated, you had to remember to copy the kernel out to the DOS partition.



    One other option that is hinted at in other answers was to write the kernel directly to a floppy using dd if=/path/to/vmlinuz of=/dev/fd0 BUT the root device had to be set properly in the kernel, either at compile time or by using the rdev utility.



    When GRUB came around, there was much rejoicing because you no longer had to remember to update LILO, or update LILO and re-strip off the boot info, etc. No more getting left out of your Linux system because you forgot to update the boot loader info...






    share|improve this answer























    • Sounds like it was whole lot of work and high chance to be left with non-booting machine back then, but definitely an educational experience

      – Sergiy Kolodyazhnyy
      Jan 9 at 3:02











    • @SergiyKolodyazhnyy yeah, and there wasn't such a wealth of info on the internet, or the great search engines to find it if it was there. There were several single floppy disk rescue distros that had just enough Linux to boot and fix LILO, etc. We've come a long way!

      – ivanivan
      Jan 9 at 3:05











    • Running make install would run /sbin/lilo, so you didn't really have to update anything by hand (and that may still be the case, if you have lilo installed). That may be a matter of opinion, but I don't remember much rejoicing at grub, at the contrary. And lilo (at least its 1999 version) could dual boot windows just fine, no need of loadlin.

      – mosvy
      Jan 9 at 19:51
















    5














    I started with Linux in the late 90s and as mentioned lilo was the default. If you wanted to dual boot with a DOS system, you could do a bare boot without loading stuff into HIMEM or loading CD drivers, etc. and use loadlin. For Win95 dual booting, you could make the drive bootable first with DOS, then install '95, and '95's boot loader would let you boot the DOS kernel still, and then you could use loadlin.



    For dual booting with NT4, the trick was to write LILO to the / partition, then strip off the first 512 bytes using dd (dd if=/dev/sda2 of=/path/to/file bs=512 count=1) and put the resulting file where ntldr could see it and you could use it from WinNT's boot loader. The issue with doing that is when you upgraded your kernel you had to remember to repeat all the steps before rebooting, otherwise you'd have issues getting back into the Linux system. Same process worked with Win2k.



    With LILO, any time the kernel was updated, you had to remember to update LILO.



    With loadlin any time the kernel updated, you had to remember to copy the kernel out to the DOS partition.



    One other option that is hinted at in other answers was to write the kernel directly to a floppy using dd if=/path/to/vmlinuz of=/dev/fd0 BUT the root device had to be set properly in the kernel, either at compile time or by using the rdev utility.



    When GRUB came around, there was much rejoicing because you no longer had to remember to update LILO, or update LILO and re-strip off the boot info, etc. No more getting left out of your Linux system because you forgot to update the boot loader info...






    share|improve this answer























    • Sounds like it was whole lot of work and high chance to be left with non-booting machine back then, but definitely an educational experience

      – Sergiy Kolodyazhnyy
      Jan 9 at 3:02











    • @SergiyKolodyazhnyy yeah, and there wasn't such a wealth of info on the internet, or the great search engines to find it if it was there. There were several single floppy disk rescue distros that had just enough Linux to boot and fix LILO, etc. We've come a long way!

      – ivanivan
      Jan 9 at 3:05











    • Running make install would run /sbin/lilo, so you didn't really have to update anything by hand (and that may still be the case, if you have lilo installed). That may be a matter of opinion, but I don't remember much rejoicing at grub, at the contrary. And lilo (at least its 1999 version) could dual boot windows just fine, no need of loadlin.

      – mosvy
      Jan 9 at 19:51














    5












    5








    5







    I started with Linux in the late 90s and as mentioned lilo was the default. If you wanted to dual boot with a DOS system, you could do a bare boot without loading stuff into HIMEM or loading CD drivers, etc. and use loadlin. For Win95 dual booting, you could make the drive bootable first with DOS, then install '95, and '95's boot loader would let you boot the DOS kernel still, and then you could use loadlin.



    For dual booting with NT4, the trick was to write LILO to the / partition, then strip off the first 512 bytes using dd (dd if=/dev/sda2 of=/path/to/file bs=512 count=1) and put the resulting file where ntldr could see it and you could use it from WinNT's boot loader. The issue with doing that is when you upgraded your kernel you had to remember to repeat all the steps before rebooting, otherwise you'd have issues getting back into the Linux system. Same process worked with Win2k.



    With LILO, any time the kernel was updated, you had to remember to update LILO.



    With loadlin any time the kernel updated, you had to remember to copy the kernel out to the DOS partition.



    One other option that is hinted at in other answers was to write the kernel directly to a floppy using dd if=/path/to/vmlinuz of=/dev/fd0 BUT the root device had to be set properly in the kernel, either at compile time or by using the rdev utility.



    When GRUB came around, there was much rejoicing because you no longer had to remember to update LILO, or update LILO and re-strip off the boot info, etc. No more getting left out of your Linux system because you forgot to update the boot loader info...






    share|improve this answer













    I started with Linux in the late 90s and as mentioned lilo was the default. If you wanted to dual boot with a DOS system, you could do a bare boot without loading stuff into HIMEM or loading CD drivers, etc. and use loadlin. For Win95 dual booting, you could make the drive bootable first with DOS, then install '95, and '95's boot loader would let you boot the DOS kernel still, and then you could use loadlin.



    For dual booting with NT4, the trick was to write LILO to the / partition, then strip off the first 512 bytes using dd (dd if=/dev/sda2 of=/path/to/file bs=512 count=1) and put the resulting file where ntldr could see it and you could use it from WinNT's boot loader. The issue with doing that is when you upgraded your kernel you had to remember to repeat all the steps before rebooting, otherwise you'd have issues getting back into the Linux system. Same process worked with Win2k.



    With LILO, any time the kernel was updated, you had to remember to update LILO.



    With loadlin any time the kernel updated, you had to remember to copy the kernel out to the DOS partition.



    One other option that is hinted at in other answers was to write the kernel directly to a floppy using dd if=/path/to/vmlinuz of=/dev/fd0 BUT the root device had to be set properly in the kernel, either at compile time or by using the rdev utility.



    When GRUB came around, there was much rejoicing because you no longer had to remember to update LILO, or update LILO and re-strip off the boot info, etc. No more getting left out of your Linux system because you forgot to update the boot loader info...







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Jan 9 at 2:57









    ivanivanivanivan

    3,6221414




    3,6221414












    • Sounds like it was whole lot of work and high chance to be left with non-booting machine back then, but definitely an educational experience

      – Sergiy Kolodyazhnyy
      Jan 9 at 3:02











    • @SergiyKolodyazhnyy yeah, and there wasn't such a wealth of info on the internet, or the great search engines to find it if it was there. There were several single floppy disk rescue distros that had just enough Linux to boot and fix LILO, etc. We've come a long way!

      – ivanivan
      Jan 9 at 3:05











    • Running make install would run /sbin/lilo, so you didn't really have to update anything by hand (and that may still be the case, if you have lilo installed). That may be a matter of opinion, but I don't remember much rejoicing at grub, at the contrary. And lilo (at least its 1999 version) could dual boot windows just fine, no need of loadlin.

      – mosvy
      Jan 9 at 19:51


















    • Sounds like it was whole lot of work and high chance to be left with non-booting machine back then, but definitely an educational experience

      – Sergiy Kolodyazhnyy
      Jan 9 at 3:02











    • @SergiyKolodyazhnyy yeah, and there wasn't such a wealth of info on the internet, or the great search engines to find it if it was there. There were several single floppy disk rescue distros that had just enough Linux to boot and fix LILO, etc. We've come a long way!

      – ivanivan
      Jan 9 at 3:05











    • Running make install would run /sbin/lilo, so you didn't really have to update anything by hand (and that may still be the case, if you have lilo installed). That may be a matter of opinion, but I don't remember much rejoicing at grub, at the contrary. And lilo (at least its 1999 version) could dual boot windows just fine, no need of loadlin.

      – mosvy
      Jan 9 at 19:51

















    Sounds like it was whole lot of work and high chance to be left with non-booting machine back then, but definitely an educational experience

    – Sergiy Kolodyazhnyy
    Jan 9 at 3:02





    Sounds like it was whole lot of work and high chance to be left with non-booting machine back then, but definitely an educational experience

    – Sergiy Kolodyazhnyy
    Jan 9 at 3:02













    @SergiyKolodyazhnyy yeah, and there wasn't such a wealth of info on the internet, or the great search engines to find it if it was there. There were several single floppy disk rescue distros that had just enough Linux to boot and fix LILO, etc. We've come a long way!

    – ivanivan
    Jan 9 at 3:05





    @SergiyKolodyazhnyy yeah, and there wasn't such a wealth of info on the internet, or the great search engines to find it if it was there. There were several single floppy disk rescue distros that had just enough Linux to boot and fix LILO, etc. We've come a long way!

    – ivanivan
    Jan 9 at 3:05













    Running make install would run /sbin/lilo, so you didn't really have to update anything by hand (and that may still be the case, if you have lilo installed). That may be a matter of opinion, but I don't remember much rejoicing at grub, at the contrary. And lilo (at least its 1999 version) could dual boot windows just fine, no need of loadlin.

    – mosvy
    Jan 9 at 19:51






    Running make install would run /sbin/lilo, so you didn't really have to update anything by hand (and that may still be the case, if you have lilo installed). That may be a matter of opinion, but I don't remember much rejoicing at grub, at the contrary. And lilo (at least its 1999 version) could dual boot windows just fine, no need of loadlin.

    – mosvy
    Jan 9 at 19:51












    0














    And before LILO and GRUB, you had to launch it from the command line with some sort of custom bootloader utility.



    As an example, the Amiga had Linux available. You had to use a command line utility called amiboot to load the kernel ELF into memory and jump to it.



    Here is a video of someone using amiboot from the command line to launch linux on an Amiga 600. His StartInstall script is calling the amiboot executable. You can watch amiboot configure memory, figure out the desired load address, and pass parameters to the kernel at around 0:55.






    share|improve this answer



























      0














      And before LILO and GRUB, you had to launch it from the command line with some sort of custom bootloader utility.



      As an example, the Amiga had Linux available. You had to use a command line utility called amiboot to load the kernel ELF into memory and jump to it.



      Here is a video of someone using amiboot from the command line to launch linux on an Amiga 600. His StartInstall script is calling the amiboot executable. You can watch amiboot configure memory, figure out the desired load address, and pass parameters to the kernel at around 0:55.






      share|improve this answer

























        0












        0








        0







        And before LILO and GRUB, you had to launch it from the command line with some sort of custom bootloader utility.



        As an example, the Amiga had Linux available. You had to use a command line utility called amiboot to load the kernel ELF into memory and jump to it.



        Here is a video of someone using amiboot from the command line to launch linux on an Amiga 600. His StartInstall script is calling the amiboot executable. You can watch amiboot configure memory, figure out the desired load address, and pass parameters to the kernel at around 0:55.






        share|improve this answer













        And before LILO and GRUB, you had to launch it from the command line with some sort of custom bootloader utility.



        As an example, the Amiga had Linux available. You had to use a command line utility called amiboot to load the kernel ELF into memory and jump to it.



        Here is a video of someone using amiboot from the command line to launch linux on an Amiga 600. His StartInstall script is calling the amiboot executable. You can watch amiboot configure memory, figure out the desired load address, and pass parameters to the kernel at around 0:55.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jan 8 at 22:41









        BoredBseeBoredBsee

        1111




        1111



























            draft saved

            draft discarded
















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f492966%2fhow-did-linux-xbsd-boot-before-grub%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown






            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?