Talk:Linux startup process
|This is the talk page for discussing improvements to the Linux startup process article.|
|WikiProject Linux||(Rated C-class, High-importance)|
- 1 First sentence
- 2 Early user space
- 3 Klibc
- 4 Embedded Linux Startup
- 5 Is LILO able or not? Contradiction?
- 6 Data vs. Program
- 7 LILO is difficult to describe as a bootloader
- 8 Shouldn't syslinux get a bigger piece of the Bootloader pie?
- 9 kthreadd ?
- 10 Confusing sentence about partition boot sector
- 11 still massive non-explaining
- 12 UEFI- and GPT-specific information needed in Boot loader phase section
The Linux startup process is the process of Linux-operating system initialize.
Is that a sentence? Shouldn't it be initialization instead of initialize.
- 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)
- 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)
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. 22.214.171.124 19:02 24 March 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)
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 126.96.36.199 (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?
- Under LILO, this is done via the map installer[clarification needed] which reads the configuration file
/etc/lilo.confto identify the available systems.
- LILO does not understand file systems, so it uses raw disk offsets and the BIOS for data load.
- 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."
- A fair point; in actuality, the kernel executes
/linuxrcwithin 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.
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)
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, that 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 maintaining things orderly and not escaping. On a side note, something tells me this article S.U.C.K.S. It resembles Frankenstein. 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 booted from it, such as BIOS routines, init systems, kernel boot needs serious deduplication. 188.8.131.52 (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? 184.108.40.206 (talk) 19:23, 20 May 2014 (UTC)
- Hello there! Good point, went ahead and Dsimic (talk | contribs) 08:04, 24 May 2014 (UTC) , please check it out. —
still massive non-explaining
- Good point! Went ahead and Dsimic (talk | contribs) 16:03, 25 May 2014 (UTC) that part as well, please check it out. —
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. 220.127.116.11 (talk) 17:14, 8 July 2014 (UTC)