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)

Shouldn't it read "The Linux startup process is the process of Linux-operating systems initialization." ? — Preceding unsigned comment added by 213.248.109.131 (talk) 12:09, 12 April 2012 (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)

Initramfs has responsibility immediately before starting init (in fact, providing the filesystem where init resides is its primary responsibility). I've moved this section to more accurately reflect this timing. (Certainly it comes after the bootloader, which had been the section immediately following.) David Hand (talk) 18:31, 7 March 2015 (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)

The boot process begins with a strip of mylar tape run through a paper-tape reader that preloads the computers dynamic (RAM) memory with instructions to initialize the reading of a 9-track tape or other device. That device then transfers instructions needed to initialize the other hardware and load the operating system. BIOS was a proprietary IBM product designed to eliminate the need for a paper-tape reader by storing this information in ROM. The BIOS coincidently made available a number of low level hardware controls (hooks) that could be used by software developers. Graphics devices normally went directly to the hardware, bypassing the BIOS codes to improve system speed and thus BIOS became synonymous with the paper-tape bootstrap in the minds of many programmers. BIOS sounds better than the more correct, "Initiate hardware interface," and the acronym for "Basic Input/Output System" has become a part of everyday speech. Pendare (talk) 12:00, 10 January 2012 (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)

Shouldn't syslinux get a bigger piece of the Bootloader pie?

Shouldn't syslinux get a bigger piece of the Bootloader pie as opposed to just being a link down the bottom of the page (in other words the boot-loader section focuses on GRUB etc too much imo). -- Afree10 (talk) 06:38, 2 October 2013 (UTC)

kthreadd ?

It is said that Init is the mother of all processes - but there is a kthreadd process that spawns threads in user space and does not descend from init, which should be further analyzed (where, why etc) — Preceding unsigned comment added by The Ubik (talk • contribs) 18:26, 15 December 2013 (UTC)

Kthreadd is *kernel* worker thread daemon. Every time a thread is needed to be created in *kernel* space, kthreadd is invoked. It has no relation to init (0) thread, which runs in *user* space and orchestrates either initramfs tasks, or is used by init system to fork and kill processes (applications, daemons etc) as needed. Because one can't simply create kernel thread from userspace call, kthreadd is used. It also helps to maintain things orderly and not escaping. After spending a day on Linux boot analysis, I was able to "surgically thread" the content down to 1/3 of the article. A lot of stuff needs to boot from it, such as BIOS routines, init systems, kernel boot needs serious deduplication. 77.180.173.46 (talk) 04:25, 27 January 2014 (UTC)

Hello there! Why should BIOS-related stuff (or init systems) be removed from the article? Having that actually provides a much broader overview and a bigger picture. Also, it's about the "Linux startup process", not "Linux kernel startup process". — Dsimic (talk | contribs) 04:30, 27 January 2014 (UTC)

Confusing sentence about partition boot sector

"when the partition boot sector code is executed in real mode and loads the first-stage boot loader"

Does this make sense? I thought the master boot record (MBR) contains the first code that is loaded and invoked right from the BIOS code (which is mapped into the main memory). Shouldn't any partition or volume specific boot records come after that i.e. be loaded and invoked by the code in the master boot record? 37.24.145.57 (talk) 19:23, 20 May 2014 (UTC)

Hello there! Good point, went ahead and improved the article, please check it out. — Dsimic (talk | contribs) 08:04, 24 May 2014 (UTC)

still massive non-explaining

E.g. "After an operating system is chosen, it is loaded and executed." --Itu (talk) 06:12, 25 May 2014 (UTC)

Good point! Went ahead and corrected/clarified that part as well, please check it out. — Dsimic (talk | contribs) 16:03, 25 May 2014 (UTC)

UEFI- and GPT-specific information needed in Boot loader phase section

Modern PCs have largely switched from BIOS to UEFI, and drives have likewise switched from using MBR to GPT. This section currently contains only information about the old methods of booting from BIOS on MBR disks. I think this article would be served by including relevant information on how the boot loader phase operates on systems with UEFI and GPT disks. 69.2.120.11 (talk) 17:14, 8 July 2014 (UTC)

You're totally right, and I've already thougt about doing that. Will be added to my to-do list. :) — Dsimic (talk | contribs) 20:37, 12 July 2014 (UTC)

Soviet state collapsed, because everyone worked with their todo-list and not actual work... 93.129.214.220 (talk) 18:50, 9 September 2015 (UTC)

open-rc

Is anyone againt on changing upstart references to open-rc, the sentence say "modern alternatives" but upstart has been deprecated and the only modern alternatives are systemd and open-rc, since those two are the most used and know it make sence keep the "modern alternatives" with the ones in development. 190.96.79.218 (talk) 06:12, 14 March 2017 (UTC)