Slashdot Mirror
Getting Grubby & Demystifying Linux Booting
davidmwilliams writes "Linux users can boast long times between reboots, but even so, the startup screens will grace your display at some time. Here's just what your computer is doing during this process, what the messages mean, and how you can take control."
The aritcle is wery redhat specific.
When i Moderate something -1 Flamebait, why do i not get another modpoint?
5--1 = 6
Nothing new, and the author has apparently not used any other distros than the Redhat based ones. Nor has he heard about lilo or syslinux. First page of article looks like the man page of grub, listing the format for the menu.lst file of grub. Since it mentions selinux and redhat, I bet most of that page is copied more or less in verbatim from Redhat's manual. And since such a short article is split over 3 pages, and last page is laden with icons for digg, slashdot etc. I believe this is just an attempt to get some readers... Just don't bother to RTFA!
Assembling etherkillers for fun an profit
How can you have an article about init without even mentioning upstart? Ubuntu has been using it since 6.10.
Bah!
That article was just pathetic.
The concept to write an article about the boot process actually sounds cool, seeing as how there is quite a bit text that whips by on start up which many (even long time) Linux users don`t understand.
This article however, was a really lame attempt to do so. It was very general, without even so much as a sample of text from dmesg. And what was there was very distro-specific. It just provided a quick over view of the major parts of the boot process, and didn`t even do that very well.
Anyway, as someone said before, don`t even bother reading TFA..
As sad in previous posts this Article is about init, which is about to be obsoleted by upstart (at least in ubuntu and debian, but i think others will follow). Upstart can work as a drop-in replacement for init, and has done so in Ubuntu 6.10. Here is an old but nice Article about Linux Booting, that includes init and upstart.
I just don't trust anything that bleeds for five days and doesn't die.
No, it doesn't. You can read the LILO technical documentation if you don't believe me.
The fundamental thing about LILO is that unlike Grub, it's incapable of actually reading the filesystem the kernel is on. The way it works is that the boot sector contains the location of the map file, and the map file contains the list of sectors that make the kernel. There's no "boot area" as such. It's trivial to verify that the map file isn't the kernel, as it's tiny (78KB on one of my boxes)
The reason LILO booted for you is simply because a format didn't overwrite the data areas of the disk. Since LILO doesn't read the FS itself, it doesn't matter to it that all the metadata is gone. So long the boot sector is there, the map's data is there (even without metadata indicating the filename, etc), and the kernel's data is there, it'll boot.
LILO however will completely mess up if you are unlucky. Overwriting the kernel without calling "lilo" afterwards might work if it just happens to write over the same sectors and uses the same number of them. Or maybe the new kernel is written somewhere else entirely, in which case you'll boot the old kernel and it'll break later when something reuses the space taken by the old version.
The problem with LILO is that you can screw it up without touching LILO itself. For example, delete the active kernel. It'll probably work anyway, right until something reuses the space previously taken by the kernel. Then boom, doesn't work anymore. With grub it doesn't matter if you make a bad config file, or delete a needed kernel. So long there's a kernel on disk, grub can boot it.
GRUB, unlike LILO, is able to read filesystems and recognize kernel images too
Lilo probably overcame this a while ago but there is also problem reading beyond 1024 cylinders
A good way to know about the boot process is to install Linux From Scratch.
I always got annoyed about things that run on my computer that I don't know what it is, and if removing it would break anything. LFS clarified for me many dark-spots about the boot process. I even ran the installed system for almost a year, but it got harder to keep up-to-date with package versions, and I came back to using a normal distro.
factor 966971: 966971
No, it doesn't. When you run lilo to install a kernel, it finds out which set of physical disk blocks contain the kernel image and stores the address of those blocks in the boot area. At boot time, it loads from that address. Note that if your file system were in the habit of moving files around, it might break LILO.
I've actually seen LILO successfully boot a kernel and initrd (which panicked) after I had formatted a drive and removed all of the partitions, because I hadn't bothered to wipe the MBR.It didn't matter that the partitions were removed because LILO doesn't know or care about partitions. It was able to load the kernel because the disk blocks containing the kernel hadn't been overwritten.
I don't use GRUB, I don't think there's actually a test utility that will tell you whether your menu.lst is properly configured without rebooting.No, I don't think there is, but that's because it's not really necessary.
GRUB lets you edit the configuration from the bootloader, so if you happen to have messed up your menu.lst, it's no problem. Try to boot, see that it can't load the kernel, pop back to GRUB, look at the configuration you're trying to boot, tweak the config, try to boot that. Repeat until the system boots. In a worst-case scenario, you can even use the GRUB command line to explore the system, find a bootable kernel and boot it even with *no* menu.lst. This is better than LILO, because it even accommodates situations where the system may have changed. Being able to test your LILO config does no good if the config has been invalidated because disks have been swapped around, or if you forgot to update LILO after installing a kernel and removing the old one.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
As someone who currently has a 55 day uptime on his main XP box, I shall add a few others to the list
.net framework or vb based programs thieving memory and not returning it). (yay for firefox actually giving up the gobs of ram it takes once you close it after a week)
3. If explorer.exe doesn't crash and not unallocate it's memory (which I suppose could be taken care of by a third party shell, but most of them will end up pulling explorer up for something anyway , and a decent amount of them are unstable when run for a very long time, a way around most explorer crashes has been for me to check the little known box that will load another explorer process for every window that is needed so that when one crashes it 'possibly' won't take the rest of them out)
4. If general memory leaks don't take a substantial amount of your physical ram. (All I can say is I've personally had the most trouble with
5. If you don't pick up any viruses on the way (and your virus protection 1. requires no reboots during updates and 2. is programmed decently well)
although a few things will plague any OS's stability,
for an example,
If your UPS/battery doesn't run out of juice during a given outage. (however I suppose you could circumvent this with proper usb drivers and hibernation, but there could be a technicality as then it might not count as continuous uptime)
or
If a piece of critical hardware fails
Any OS can be stable (well, I take that back, except ME) just as long as you monitor it like crazy and keep everything up..
Although I will admit that I am spoiled by my smoothwall and it's 280 something day uptime (the silly UPS's battery died less than a year ago leaving it unpowered in an outage), although even that's nothing compared to the old fridge VAX we had at the place I worked, which had a non-rebooting uptime of 5 1/2 years, good old VMS.
Sure it mentions a few examples that are picked from RHEL but most of the stuff is very general. Never used RHEL and had no problems perfectly understanding the article.