Talk:Booting process of Linux

First sentence

The Linux startup process is the process of Linux-operating system initialize.

Is that a sentence? Shouldn't it be initialization instead of initialize.

—Preceding unsigned comment added by 88.68.65.225 (talk • contribs) 06:11, 24 June 2009

This was fallout from some edits by someone whose first language obviously isn't English. Chris Cunningham (not at work) - talk 10:39, 24 June 2009 (UTC)

Early user space

I think that stub should be merged here unless the terminology is used outside Linux, which doesn't seem to be the case. Pcap ping 02:12, 27 December 2009 (UTC)

Agree, that’s definitively Linux specific. Some other OSes may have similar technologies, but neither is it used as widespread as with the Linux kernel, nor do they use this terminology. mirabilos (talk) 13:56, 11 August 2010 (UTC)

Klibc

The klibc library doesn't seem to have much in the way of uses outside the scope of this article (the license seems to be the culprit). Proposing we merge that here. Pcap ping 22:22, 28 December 2009 (UTC)

I would agree that it could be merged with a redirect. Bpringlemeir (talk) 22:38, 29 December 2009 (UTC)

I disagree on merge: klibc is known to compile Debian Installer boot floppies, dash, mksh, udev, module-init-tools and other projects. So it is not only boot related. It is a libc and should stay on its own. 138.234.212.84 19:02 24 March 2010 (UTC)

I disagree on merge. klibc seems to be an entity on its own, thus meriting a separate article, even if it plays a major role in the Linux startup process. Intersofia (talk) 09:45, 12 April 2010 (UTC)

I disagree on merge, for the reasons above. It is a standalone C library that can be used to link programs--not just boot programs. LtDonny (talk) 09:30, 7 June 2010 (UTC)

For what it’s worth, I’m hoping to / working on linking mksh-static (in Debian) against klibc instead of dietlibc on as many architectures as possible. I indeed see it as a stand-alone, limited C library for random userspace programmes, just like Bionic is, just not a choice for most of them, or a popular one. mirabilos (talk) 13:53, 11 August 2010 (UTC)

Disagree on merge. klibc is a standard library, just like every other minimal C standard library (uClibc, newlib and others) and they would be just as suitable for inclusion in early user space, so if klibc got a mention on this page, maybe so would these other C standard libraries? カラム 11:52, 30 November 2010 (UTC)

Disagree. It's misleading to cover klibc in the boot article. It isn't boot specific, even if booting is one of its major "customers", there are plenty of others as other editors have illustrated. -- Jon Dowland (talk) 16:23, 6 December 2010 (UTC)

I've just noticed that someone went ahead and merged. I don't see consensus here. What's going on? -- Jon Dowland (talk) 16:30, 6 December 2010 (UTC)

Embedded Linux Startup

While the heading of this page implies a general Linux startup it is highly PC specific and does not decribe the process for the devices starting with embedded Linux, say on ARM using other boot loaders. Either it should be brodened to include other cases or calrification added as to the above point. —Preceding unsigned comment added by 76.218.105.120 (talk) 11:07, 4 January 2010 (UTC)

I agree that the article currently is too specific to one platform, yet is written as if the mentioned startup process applies for all kinds of computers. For example: "In Linux, the flow of control during a boot is from BIOS, to boot loader, to kernel.[...]"

The "BIOS" exists only with IBM PC compatible computers, yet there are many other non-IBM PC compatible computers which can start up Linux in their own way. --Abdull (talk) 14:02, 7 March 2010 (UTC)

Is LILO able or not? Contradiction?

1. Under LILO, this is done via the map installer which reads the configuration file /etc/lilo.conf to identify the available systems.
2. LILO does not understand file systems, so it uses raw disk offsets and the BIOS for data load.

How can LILO read a file system file, if LILO does not understand file systems? --Abdull (talk) 14:39, 7 March 2010 (UTC)

The map installer (used to be /sbin/lilo back when I used GNU/Linux) is a regular GNU/Linux userspace programme. It scans for available systems, writes the mapfile containing “pointers” to them to disc, and then embeds the location of the mapfile into the LILO bootblocks which, indeed, cannot parse any filesystems. HTH, HAND. mirabilos (talk) 13:55, 11 August 2010 (UTC)

Data vs. Program

"It may also optionally run Initrd to allow setup and device related matters (RAM disk or similar) to be handled before the root file system is mounted."

How can you run a file system? --Abdull (talk) 17:54, 7 March 2010 (UTC)

A fair point; in actuality, the kernel executes /linuxrc within the initrd. The usual loader rules apply, so the kernel interprets that file's magic number. If for example the file begins "#!", it loads the interpreter named on that line as the actual executable. It is very typical for that to be #!/bin/sash, BusyBox, or some other stripped down, statically linked, standalone, Bourne-based shell. I say "stripped down" because usually it is desired to have the initrd to be as small as practical to reduce RAM requirements, initrd disk space, and therefore initrd loading time (think "floppy, CD, or DVD"). But the system admin can make that anything s/he wishes, such as /bin/bash (provided all its dependencies, such as libc, are also in the initrd). -- Joe (talk) 23:18, 17 August 2011 (UTC)

LILO is difficult to describe as a bootloader

I tried to clear up some of the inaccuracies about the bootloaders, particularly those surrounding the MBR. While often it is in the MBR, it doesn't have to be; it can just as easily be the partition/volume boot record. Therefore references are instead "boot sector."

The biggest difficulty in describing the process is it's sort of catch-22. It's difficult to understand the mechanics of how LILO loads in pieces of itself and the kernel/initrd/bootsectors of other OSes without also describing the map and bootloader installer, lilo. Obviously, it can't "find itself" without these predetermined data being put there in the first place by lilo itself, as the platform only allows for 512 bytes of code, or less if it's in the MBR. But of course those offsets (e.g. disk addresses) only get put onto the boot medi(um|a) by a previous run of the system (and lilo). (Actually, that's one of the more annoying aspects of modern GRUB, that Linux must be running first, contrasted with GRUB Legacy having facilities to patch in these sector IDs with e.g. setup (hd0,2).)

-- Joe (talk) 23:04, 17 August 2011 (UTC)