Slashdot Mirror

← Back to Stories (view on slashdot.org)

Getting Grubby & Demystifying Linux Booting

Posted by CmdrTaco on from the you-like-to-look-at-newbies dept.

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."

15 of 105 comments (clear)

  1. Redhat specific by Janosh · · Score: 3, Informative

    The aritcle is wery redhat specific.

    --
    When i Moderate something -1 Flamebait, why do i not get another modpoint?
    5--1 = 6
    1. Re:Redhat specific by freeweed · · Score: 3, Informative

      Yeah. chkconfig, eh. :)

      It's also rather light on content. 3 pages to say "yeah, this runs, and a bunch of other stuff that I won't talk about happens".

      This might have been useful in 1999.

      --
      Endless arguments over trivial contradictions in books written by ignorant savages to explain thunder in the dark.
    2. Re:Redhat specific by Procasinator · · Score: 5, Funny

      Be wery, wery quiet.... I'm hunting grubby webhats!

  2. Bad article by vidarlo · · Score: 4, Informative

    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
    1. Re:Bad article by weeboo0104 · · Score: 3, Informative

      I'm not sure I agree about this being a bad article. Sure the things the author goes into are things that are second nature for experienced linux users, but people who have only been exposed to Red Hat or Fedora might not be familiar with all of the logs that are collected in /var/log and might not really know just how useful grep and dmesg can be. It might not warrant it's own webpage, but I hope the author considers posting it as a sticky to Linuxquestions.net

      --
      It is easier to build strong children than to repair broken men. -Frederick Douglass
    2. Re:Bad article by KillerBob · · Score: 4, Informative

      Yeah, but that's very *very* distro-specific.

      Slackware-based distros, for example, use runlevel 4 for X instead of RL 5. They also have *all* init scripts in /etc/rc.d, and the scripts are started on basis of whether they're executable. Anything runlevel-specific, like login managers and X servers are then loaded from /etc/rc.d/rcX.S where X is the runlevel.

      that's to say nothing of distros that aren't even using SysV init, like the current version of Ubuntu and anything BSD-based.

      It was pretty obvious that the author hasn't done his research, and that it's a pretty poor attempt at explaining stuff. I was rather hoping for an article where the author would actually parse the output of dmesg and explain, line for line, what everything meant. That would actually be informative. Instead, he gave information that was specific to RedHat Linux, a lot of which doesn't apply to other distros. I wouldn't even be complaining so much, except that he didn't even bother to write it specific to the most popular Linux distro. RedHat was the most popular when I started with Linux, over a decade ago. These days, that crown belongs to Ubuntu. If you're going to write something distro-specific, at least write it for the most popular one.

      Obligatory disclaimer: The last version of RedHat that I used was RedHat 6.0. When 7.0 came out, I switched to Slackware. I now use Zenwalk (slack-based, formerly MiniSlack, http://www.zenwalk.org/), having switched at Zenwalk 2.4. I have tried other distros, including Ubuntu, and still prefer Slackware-based distributions, and I find that the Zenwalk community and package management tools are the best of that breed.

      --
      If you believe everything you read, you'd better not read. - Japanese proverb
  3. No Upstart? by dzelenka · · Score: 3, Informative

    How can you have an article about init without even mentioning upstart? Ubuntu has been using it since 6.10.

    --
    Bah!
    1. Re:No Upstart? by Simon+(S2) · · Score: 3, Informative

      Because nobody can find any documentation on upstart?

      I think you didn't do your homework.
      --
      I just don't trust anything that bleeds for five days and doesn't die.
  4. Pathetic by Anrego · · Score: 4, Informative

    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..

  5. Windows refugees by Harmonious+Botch · · Score: 4, Interesting

    The article won't help, however... It is not nearly detailed enough for learning anything. For the recent immigrants from Windows, it is a great roadmap.
    1. Re:Windows refugees by NeverVotedBush · · Score: 4, Insightful

      And there are apparently quite a few Windows immigrants. More how-to and helping them get their Linux-legs is a good thing. And they will need all levels of articles too.

    2. Re:Windows refugees by Cprossu · · Score: 3, Informative

      As someone who currently has a 55 day uptime on his main XP box, I shall add a few others to the list

      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 .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)

      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.

  6. It's Web 2.0 by SignupRequired · · Score: 5, Insightful

    Ever since somebody decided "Web 2.0" existed, there's been a big slew of these awful new "IT stuff" sites that look like they've been designed using a checklist of Web 2.0 mainstays and buzzwords. User ratings? Check. Submit news? Check. Blogs? Check. Annoying multipage articles? Check. Attention whoring abuse of social bookmarking sites at the end of every article? Check. More banner ads than content on any given page? Check. User comments? Check. Half of it is actually a decade old and was pioneered by Slashdot, but thanks to the magic of buzzwords, everything old is new.

    And with all of this stuff in place, they invariably fail to even attempt the final hurdle: creating decent content. Instead of picking one of the two available routes (create good content vs Slashdot-style aggregation), they seem to like to go halfway, with awkward "stories" like this half-boiled Red Hat GRUB HOWTO masquerading as "Breaking News".

    Sure, maybe these are probably all honest people trying to kick-start their journalism careers. But if so, what the hell are they doing throwing this crap around? Even Katz was more interesting than this trash.

  7. Ubuntu's fast resume patch for grub by schwaang · · Score: 3, Interesting
    By way of making lemonade, here's a post by an Intel engineer to ubuntu-kernel-devel about a proposed grub patch that would make resuming from hibernation much faster:

    Below is the work theory of our "grub fast resume" patch
    The normal swsusp2 resume process is:
    "grub" -> "kernel" -> "initrd" -> "resume from the hibernate"
    Our "grub fast resume patch" can work as below:
    "grub" -> "resume from hibernate"

    Our "grub fast resume" patch can resume the saved hibernation image from
    grub directly that will save much time to load and run kernel and
    initrd. The patch does not change any kernel code.


    [I use hibernate on Fedora all the time, so I'd love to see a patch like this go in to Fedora's grub. Thing is, the patch is apparently based on swsusp2, and I'm not sure Fedora's kernel uses the swsusp2 version of hibernation.]

    In a reply to the post, a debian guy points out that grub is legacy at this point, and that they are looking to move to grub2.
  8. Re:What does Grub Offer that Lilo Doesn't by DaleGlass · · Score: 3, Informative

    LILO copies a kernel image to its boot area. It doesn't matter if you change the kernel on the hard drive, because LILO's installed image won't change until you invoke the "lilo" command. 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.


    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 recovery console is useful, but as I'm often tinkering with things, I prefer to have a bootloader that's static, and won't change until I explicitly tell it to. There's also the "lilo -v -t" command to test when I make a change to /etc/lilo.conf.


    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.