Slashdot Mirror
New LILO Breaks 1024-Cyl Limit
slambo writes: "Everyone's favorite bootloader, LILO has been updated to remove the 1024-cylinder limit. LILO now supports disks up to 2Tb. "
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
I friend of mine once did 5 Debian installs back-to-back.
He's ok now, except any time someone says "dselect", he starts screaming and sobbing uncontrollably.
This is great news! No more separate /boot partitions, etc..
I've had to explain the 1024 cylinder limitation to numerous newbies before, and it does nothing but puzzle them. Once distributions get the new LILO, that's a thing of the past. Maybe it's not too late for Debian to fold this into potato. Fingers crossed...
Here's a question for boot loader gurus: Do GRUB and other boot loaders have the 1024 cylinder limit problem as well?
Slashdot's first reaction to VMware
It's interesting that they claim an NT boot partition can be 7.8GB. I've never achieved more than 4GB - the setup program crapped out for anymore. On my 13GB drive I had to delete all my other partitions otherwise the NT setup program crapped out with a strange error number - I re-created the partitions afterwards without any data loss (obviously I didn't do any partitioning in the NT setup prog). For my work I need four versions of Windows installed... and I currently only have two drives. This new LILO will allow me to have 4 4GB partitions for each of the windows installations (I don't let them put NTLDR etc on other installation's partitions), and still have Linux without the small boot partition I currently have, which of course uses up one of my four primary partition entries.
It's a combination of the two. To put it simply, the loader needs to be able to find the OS, and the OS needs to find itself. The way LILO loads Linux is different from the way it loads other operating systems, so the precise limitations aren't identical.
That said, you'll probably run into problems installing NT on such a large drive if it's IDE, but there are workarounds. See: Q197667 - Installing Windows NT on a Large IDE Hard Disk. Two things to note:
SP4 fixes his problem, but of course you can't install SP's until after you install NT. The Installation will fail, so normally you'd be screwed. MS has worked out a hack (in the linked article) that works around this problem by installing SP4's updated Atapi.sys. Also note:
Why do I know this crap? I was installing NT4 on my Dad's new 20GB HD a few months ago. It took me three days to figure out why neither NT 4.0 or Windows 95 would install. I actually thought the HD was damaged at first, but Linux (Mandrake 6.0) installed with no problems. (He uses AutoCAD all day, so he wanted NT...)
"The 1024-cylinder limit has been removed by a patch that uses the EDD bios extensions and supports up to 2 TB disks."
so it's just a matter of supporting a BIOS extension to read >1024 cyl with real-mode bios calls.
--
Hi people. This is a joke, a parody of Microsoft's Linux Myths page. I know how tax deductions work, but thanks anyhow.
-JD, certified geek
Now that you have brought it to our attention, we realize the enormity of our gaffe.
Please accept our bowing and scraping as we endevor to correct our appaling mistake. In future we will post no stories without consulting you for approval.
No, that's not enough. We will give you all creative control of slashdot since we are clearly incapable of the intelect needed to properly run this, or any other, site.
Moderators, please moderate this post down as it is unworthy of being seen.
We now go to disembowel ourselves in shame.
With Abject Regret,
The Management.
Your wallet stays open. Our source remains closed. We are MSFT
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).