Fast booting Linux image that boots from any x86 PC

[Goi]

Hi,

I've been trying to create a very small, fast and compact Linux image that I can copy to an SSD, that allows me to boot into a Linux shell across all kinds of laptops and desktops. My approach has been to download a Linux kernel, manually build all possible drivers I can think of into the kernel (no modules) for performance reasons, disable everything I think I don't need, and then use LILO/GRUB to select this kernel during bootup. I also don't have an init for performance reasons.

This works for many, but not all the PCs I've tried. I'll often get a kernel panic, probably due to the boot loader being hard coded to /dev/sda, and sometimes this not being the case as different SATA controllers assign device names differently depending on BIOS boot order, SATA slot the drive is inserted into, etc.

Is it possible to create a Linux image that boots from any x86 desktop, laptop regardless of hardware configuration? Something like a Linux LiveCD, but much faster(boots to shell in <10s) and without all the fluff.

Thanks!

 

[ninaholic37]

What was the size of your Linux images and their boot time, just out of curiosity?

 

[Goi]

My kernel is just a few MB large, and the entire image was 64MB, though it could've easily fit into something much smaller. It booted in less than 5s.

 

[Elixer]

Is it possible to create a Linux image that boots from any x86 desktop, laptop regardless of hardware configuration? Something like a Linux LiveCD, but much faster(boots to shell in <10s) and without all the fluff.

Thanks!

Problem is, you need drivers for all the hardware configurations, and if that isn't known, then you are stuck with packaging a large amount of drivers.

While you could get a basic shell that fast, it would be pretty useless for the most part, unless all you are doing is using ssh or telnet or something.

 

[Goi]

Problem is, you need drivers for all the hardware configurations, and if that isn't known, then you are stuck with packaging a large amount of drivers.

While you could get a basic shell that fast, it would be pretty useless for the most part, unless all you are doing is using ssh or telnet or something.

I understand that. I mostly just need the following drivers:
SATA, so the SSD actually works
USB, because I'll be accessing USB devices

Other than that, I don't really need that many other drivers.

One of my biggest problems, I think, is what I described earlier. I'm hard coding my boot loader to load my kernel from /dev/sda1, and this doesn't always happen, depending on the BIOS SATA mode, BIOS boot order, or even which SATA port the drive is connected to.

When it doesn't find the kernel in /dev/sda1, I get a kernel panic.

So is there a way for the boot loader to inherently know where to load the kernel from based on some other identifier?

 

[Essence_of_War]

I know GRUB, for example, uses UUIDs to prevent confusion from the possibility of SATA ports being initialized in different orders. Could that help? Instead of hardcoding a /dev/, instead hardcode the UUID?

 

[ninaholic37]

My kernel is just a few MB large, and the entire image was 64MB, though it could've easily fit into something much smaller. It booted in less than 5s.

Sounds interesting. I've never tried making an image of just the Linux CLI. I do use FreeDos which takes up only 110K for the two required files (+5K if you want XMS, +5K if you want the mouse, +5K to control the CPU frequency, etc.) and boots up instantly (less than 1 second?). Of course, having extra programs makes it more fun, but you can just load them up later and still have instant boot times. I've never had a machine that couldn't boot into it or Linux on a Flash Stick (using UNetbootin) or Hard Drive (using Grub4dos) yet, though I guess that's because I either didn't need extra drivers or they were already included.

 

[Elixer]

I understand that. I mostly just need the following drivers:
SATA, so the SSD actually works
USB, because I'll be accessing USB devices

That is still lots of drivers, there are tons of different chipsets around, and how do you deal with ARM vs x86 vs X64 and so on.
Then for USB, you got a crap load of devices that can be used, so, you need drivers for lots of device types. (Keyboard, mouse, and so on)

Other than that, I don't really need that many other drivers.

No video out?

One of my biggest problems, I think, is what I described earlier. I'm hard coding my boot loader to load my kernel from /dev/sda1, and this doesn't always happen, depending on the BIOS SATA mode, BIOS boot order, or even which SATA port the drive is connected to.

When it doesn't find the kernel in /dev/sda1, I get a kernel panic.

So is there a way for the boot loader to inherently know where to load the kernel from based on some other identifier?

It all depends on how you are getting the info, and at what stage you are in.
If you turn off the splash screen on a distro, (say ubuntu) and turn on verbose output, that is a good place to figure out, step by step on how you should handle things.
Usually, nothing should be hard coded, since there are too many variables involved, so, usually they use virtual devices (and use a RAM drive for quick inits) until the kernel loads up the drivers for everything it needs. Polling some devices takes forever.
So, to get to your goal of booting off of ANY device things get much more complicated quickly.
What exactly is the end goal here?
Do you just want to have a shell up ASAP that does what?

 

[dave_the_nerd]

Meh, I'd just use an Ubuntu Server liveUSB stick. But I'm lazy and charge by the hour, so...

If you're just attaching your own USB drive to the computers, you could use the partition UUID. Otherwise you'd have to grab UUID and/or /dev/partition path when you install the bootloader/kernel on the client system.

 

[Fallen Kell]

You should look at Damn Small Linux.

 

[jhu]

Why not just boot from USB? Seems like it would be a lot less hassle. With your current approach, how do you deal with EFI?

 

[replica9000]

I would also vote USB over an SSD. If this setup is for a variety of machines, what if you come across one that does not have a sata port? Even if it does, why open the machine, find an extra cable, and hope there's an available and easy to get to power connector.

There's also some pretty fast USB sticks these days. Using filesystems such as btrfs or zfs with compression could reduce the boot time from a USB stick.

 

[Goi]

That is still lots of drivers, there are tons of different chipsets around, and how do you deal with ARM vs x86 vs X64 and so on.
Then for USB, you got a crap load of devices that can be used, so, you need drivers for lots of device types. (Keyboard, mouse, and so on)

No video out?

It all depends on how you are getting the info, and at what stage you are in.
If you turn off the splash screen on a distro, (say ubuntu) and turn on verbose output, that is a good place to figure out, step by step on how you should handle things.
Usually, nothing should be hard coded, since there are too many variables involved, so, usually they use virtual devices (and use a RAM drive for quick inits) until the kernel loads up the drivers for everything it needs. Polling some devices takes forever.
So, to get to your goal of booting off of ANY device things get much more complicated quickly.
What exactly is the end goal here?
Do you just want to have a shell up ASAP that does what?

The end goal is to have a SATA drive boot up quickly and run a Linux application that I've developed in non-graphical mode. Hence, the Linux portion is simply to support my application, which accesses certain hardware such as the SATA drive, keyboard (USB or PS2) as well as a USB smart card reader device. This drive has to ideally support all PCs and desktops.