Gee, SILO has been able to boot past 1024 cylinders for ages now. It also doesn't have to be run on new kernel images, understands ext2 and iso9660 filesystems, and even has some simple functionaly like the ability to ls some directory to see what you want to boot. In addition to Linux it can also boot SunOS and Solaris, and has been ported to PowerPC for use on Apple's Open Firmware systems. Very nice. Of course, the catch is that you'll need a system with enough intelligence in its firmware to know what it is. The peecee BIOS is too braindead for something nice like this. Though the possibility might exist of writing a bootloader for peecees that included an OF emulator. But then, why bother; writing real-mode 16-bit x86 code isn't my idea of fun, and I doubt it's yours either.
LILO has all sorts of bizare restrictions on it. But instead of moaning about the ones yet to be crushed underfoot, it's better to praise those scaled and defeated.
(On the other hand, I still think Shoestring was better.:)
For those wanting alternative loaders, take a look at these, to see if they'll do what you want. (I can't remember the URLs, but they should all be on Freshmeat.)
GAG
GRUB (Gnu or L4)
Shoestring (for that Olde Worlde look)
Barboot
Smart BootManager
-- It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Re:great but LILO still needs...an enema
by
logicTrAp
·
· Score: 4
LILO sucks, try GRUB. GRUB lets you boot from arbitrary kernel images, has a nice menu and doesn't need to be rerun after every kernel install. It works with *BSD, HURD, and maybe other OSes as well.
NetBSD already has this support for quite a while
by
gd
·
· Score: 4
This is Stuff That Matters. Some new version of an ICQ client is not slashworthy. But LILO boots most linux computers every day. It has also been the cause of more newbies giving up than probably any other problem. "Why do I have to have/boot?" "what's this 1024 cylinder thing?" "I can't make a new partition under 1024, that's where windows is!" Etc...
Fixing this problem _is_ big news, as far as I'm concerned, and I would have missed it on Freshmeat.
---
Re:great but LILO still needs...an enema
by
decaym
·
· Score: 5
Hey, it could be worse! You know you've been around Linux for too long when you can remember having to boot off floppy disks because there was no hard disk boot loader available.
One thing to remember about boot loaders is that their only purpose is to help the disk boot. You don't want a large application sitting here or you slow your system boot time down even more. I could be wrong here, but I believe that LILO has to fit completely in the MBR. This severly constrains how much can be put into it.
If something more is really needed, you would have to have a first stage loader like LILO boot a 2nd stage loader with all the bells and whistles. The problem this is that you have to get the 2nd stage loader out of the way for the kernel to come into memory.
Ask yourself the question, is this really necessary? Machine boots, I'm happy. Put your time in configuration tools to help with setting up LILO in the first place
Myth: Linux supports the use of larger-sized hard disks that are required for large scale enterprise server use.
Fact: Linux makes no sense as a server. Whereas NT supports up to 480 gazillion petabytes of disk storage, the largest disks Linux supports are only 27 terabytes. This limitation is especially frustrating for e-commerce companies and multimedia developers, for whom large amounts of hard drive are a requirement.
Myth: Linux has a lower TCO
Fact: If you consider that buying NT licenses for business use is tax-deductible, as are all those tech support calls, NT actually has a lower TCO than Linux! How are you going to expense software that doesn't cost anything? Eh?!?
great but LILO still needs...an enema
by
toh
·
· Score: 5
Actually, I hate LILO. I'm (genuinely) curious what the people posting in its favour like about it - it seems to me that it's not so much the favourite as it is the sole viable option, currently. In particular, have they used other schemes, like FreeBSD 3-4's multi-stage bootloader? A real CLI that can actually do stuff like read a filesystem, name a kernel by sight, and dynamically switch devices even from the first-stage loader in the boot block (not to mention from either a serial line or a console, automatically probed for or manually switchable at boot time). The next stage loader after that can dynamically preload modules, among a host of other useful features. And I don't have to update the MBR on the raw disk (!) every damn time I rebuild a kernel.
LILO has been due for replacement for a looong time, and it should probably take the current reliance on the awful MS-DOS fdisk style partitioning scheme with it (for a slice scheme like the BSD and many others use, or better still a completely flexible named-partition design like the (gasp) Mac has had for years). Really, these are areas that have been addressed by other Unices for years, including the free ones.
-- --
Life is short. Forgive quickly. Kiss slowly.
~ Robert Doisneau
Booker said...But LILO boots most linux computers every day.
Like hell. Every day!? Lessee, the last time I saw a LILO prompt was oh what the heck, 8 months ago? I had to bring the system down because of a hurricane.
Now if LILO loaded NT, well then everyone would see it just about every day... {cackle}
--
I am quite civilized, and I should be
brought a beer immediately. -- Bruce Sterling
Well, if you have a big disk, and want to boot a partition beyond 1024 cylinders, the old LILO couldn't handle this. An example is you have a 13 GB disk, with Windows installed. You decide to try linux, so you squash the windows partition to 8GB, and add a linux partition or two (including swap) at the end. If the beginning of your linux partitions is beyond 1024 cyliners (easy to happen for the larger drives), then LILO, or LInux LOader, which is supposed to bootstrap (ie, load) the kernel, chokes. Until now that is.
Older methods to get around this problem was to put a boot partition with the kernel image on a separate partition (earlier) on the disk to satisfy LILO. But now that shouldn't be necessary (unless you've got 27+ TB disks!)
--
make world, not war
Re:this fixes LILO, what about the 32GB limit?
by
randombit
·
· Score: 5
So the problem with LILO was that the root partition you wanted to boot to had to be all under the 1024 cyl limit?
To be totally exact, the kernel and related boot file had to be under the 1024th cyl. However, it's usually a good idea to make sure the whole partition is under the limit, as otherwise the OS might allocate the blocks for your next kernel upgrade right at the end of the partition, in which case you're fscked.
Is there a different problem with drives over 32Gig?
This sounds like a pure kernel problem. The problem with LILO is brain-dead BIOSes (well it's not totally their fault, the original BIOS interface assumed that things never got very big, like over ~800 Meg). It would be very interesting if some MB OEM created a new BIOS interface that can handle reasonably sized disks (say using an unsigned 64 bit int for handling addresses, with addressing single bytes thats 16777216 terabytes).
You don't need separate/boot partitions, just use the same one for all of the distros that you install. I had a 10GB disk with RedHat installed on it (with/boot accessible in the first 1024 sectors), and when I installed Debian on a 20GB disk (outside of the 1024-sector boundary), I booted it out of my RedHat's/boot with a different image and symlinked Debian's/boot to RedHat's/boot. It seemed to work ok. It only took about 3 installs of Debian (which was rather painful) to come up with this 'strategy'.:)
Gee, SILO has been able to boot past 1024 cylinders for ages now. It also doesn't have to be run on new kernel images, understands ext2 and iso9660 filesystems, and even has some simple functionaly like the ability to ls some directory to see what you want to boot. In addition to Linux it can also boot SunOS and Solaris, and has been ported to PowerPC for use on Apple's Open Firmware systems. Very nice. Of course, the catch is that you'll need a system with enough intelligence in its firmware to know what it is. The peecee BIOS is too braindead for something nice like this. Though the possibility might exist of writing a bootloader for peecees that included an OF emulator. But then, why bother; writing real-mode 16-bit x86 code isn't my idea of fun, and I doubt it's yours either.
(On the other hand, I still think Shoestring was better. :)
For those wanting alternative loaders, take a look at these, to see if they'll do what you want. (I can't remember the URLs, but they should all be on Freshmeat.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
LILO sucks, try GRUB. GRUB lets you boot from arbitrary kernel images, has a nice menu and doesn't need to be rerun after every kernel install. It works with *BSD, HURD, and maybe other OSes as well.
http://www.netbsd.org/Misc/feature s.html#large-ide
gd
This is Stuff That Matters. Some new version of an ICQ client is not slashworthy. But LILO boots most linux computers every day. It has also been the cause of more newbies giving up than probably any other problem. "Why do I have to have /boot?" "what's this 1024 cylinder thing?" "I can't make a new partition under 1024, that's where windows is!" Etc...
Fixing this problem _is_ big news, as far as I'm concerned, and I would have missed it on Freshmeat.
---
Hey, it could be worse! You know you've been around Linux for too long when you can remember having to boot off floppy disks because there was no hard disk boot loader available.
One thing to remember about boot loaders is that their only purpose is to help the disk boot. You don't want a large application sitting here or you slow your system boot time down even more. I could be wrong here, but I believe that LILO has to fit completely in the MBR. This severly constrains how much can be put into it.
If something more is really needed, you would have to have a first stage loader like LILO boot a 2nd stage loader with all the bells and whistles. The problem this is that you have to get the 2nd stage loader out of the way for the kernel to come into memory.
Ask yourself the question, is this really necessary? Machine boots, I'm happy. Put your time in configuration tools to help with setting up LILO in the first place
World Beach List, my latest project.
It probably boots more systems on this planet than the old DOS MBR did though its useful lifetime, and it sure seems stable enough. . .
-Omar
Myth: Linux supports the use of larger-sized hard disks that are required for large scale enterprise server use.
Fact: Linux makes no sense as a server. Whereas NT supports up to 480 gazillion petabytes of disk storage, the largest disks Linux supports are only 27 terabytes. This limitation is especially frustrating for e-commerce companies and multimedia developers, for whom large amounts of hard drive are a requirement.
Myth: Linux has a lower TCO
Fact: If you consider that buying NT licenses for business use is tax-deductible, as are all those tech support calls, NT actually has a lower TCO than Linux! How are you going to expense software that doesn't cost anything? Eh?!?
Actually, I hate LILO. I'm (genuinely) curious what the people posting in its favour like about it - it seems to me that it's not so much the favourite as it is the sole viable option, currently. In particular, have they used other schemes, like FreeBSD 3-4's multi-stage bootloader? A real CLI that can actually do stuff like read a filesystem, name a kernel by sight, and dynamically switch devices even from the first-stage loader in the boot block (not to mention from either a serial line or a console, automatically probed for or manually switchable at boot time). The next stage loader after that can dynamically preload modules, among a host of other useful features. And I don't have to update the MBR on the raw disk (!) every damn time I rebuild a kernel.
LILO has been due for replacement for a looong time, and it should probably take the current reliance on the awful MS-DOS fdisk style partitioning scheme with it (for a slice scheme like the BSD and many others use, or better still a completely flexible named-partition design like the (gasp) Mac has had for years). Really, these are areas that have been addressed by other Unices for years, including the free ones.
-- Life is short. Forgive quickly. Kiss slowly. ~ Robert Doisneau
Like hell. Every day!? Lessee, the last time I saw a LILO prompt was oh what the heck, 8 months ago? I had to bring the system down because of a hurricane.
Now if LILO loaded NT, well then everyone would see it just about every day... {cackle}
I am quite civilized, and I should be brought a beer immediately. -- Bruce Sterling
Older methods to get around this problem was to put a boot partition with the kernel image on a separate partition (earlier) on the disk to satisfy LILO. But now that shouldn't be necessary (unless you've got 27+ TB disks!)
make world, not war
So the problem with LILO was that the root partition you wanted to boot to had to be all under the 1024 cyl limit?
To be totally exact, the kernel and related boot file had to be under the 1024th cyl. However, it's usually a good idea to make sure the whole partition is under the limit, as otherwise the OS might allocate the blocks for your next kernel upgrade right at the end of the partition, in which case you're fscked.
Is there a different problem with drives over 32Gig?
This sounds like a pure kernel problem. The problem with LILO is brain-dead BIOSes (well it's not totally their fault, the original BIOS interface assumed that things never got very big, like over ~800 Meg). It would be very interesting if some MB OEM created a new BIOS interface that can handle reasonably sized disks (say using an unsigned 64 bit int for handling addresses, with addressing single bytes thats 16777216 terabytes).
You don't need separate /boot partitions, just use the same one for all of the distros that you install. I had a 10GB disk with RedHat installed on it (with /boot accessible in the first 1024 sectors), and when I installed Debian on a 20GB disk (outside of the 1024-sector boundary), I booted it out of my RedHat's /boot with a different image and symlinked Debian's /boot to RedHat's /boot. It seemed to work ok. It only took about 3 installs of Debian (which was rather painful) to come up with this 'strategy'. :)