Category Archives: Uncategorized

รู้จัก Boot ของ Windows 7

bootrec คือ โปรแกรม Boot Recovery เป็นโปรแกรมที่มีไว้ซ่อม boot loader ของ
Win7 (xp คือ fdisk)

bcdedit เป็น editor สำหรับแก้ Boot Configuration Data เป็น text file ที่เก็บรายละเอียดการ boot ไว้ (xp คือ boot.ini)

Bootrec.exe options

The Bootrec.exe tool supports the following options. Use the option that is appropriate for your situation. (This works on all versions of Vista and Windows 7 Only)

You can Try the following combination:
Bootrec.exe /FixMbr

The /FixMbr option writes a Windows 7 or Windows Vista-compatible MBR to the system partition. This option does not overwrite the existing partition table. Use this option when you must resolve MBR corruption issues, or when you have to remove non-standard code from the MBR.
Bootrec.exe /FixBoot

The /FixBoot option writes a new boot sector to the system partition by using a boot sector that is compatible with Windows Vista or Windows 7. Use this option if one of the following conditions is true:

* The boot sector has been replaced with a non-standard Windows Vista or Windows 7 boot sector.
* The boot sector is damaged.
* An earlier Windows operating system has been installed after Windows Vista or Windows 7 was installed. In this scenario, the computer starts by using Windows NT Loader (NTLDR) instead of Windows Boot Manager (Bootmgr.exe).

Bootrec.exe /ScanOs

The /ScanOs option scans all disks for installations that are compatible with Windows Vista or Windows 7. Additionally, this option displays the entries that are currently not in the BCD store. Use this option when there are Windows Vista or Windows 7 installations that the Boot Manager menu does not list.
Bootrec.exe /RebuildBcd

The /RebuildBcd option scans all disks for installations that are compatible with Windows Vista or Windows 7. Additionally, this option lets you select the installations that you want to add to the BCD store. Use this option when you must completely rebuild the BCD.


Get to know Windows Vista’s new boot loader architecture

Takeaway: Greg Shultz introduces you to Windows Vista’s new boot loader architecture and the Boot Configuration Data (BCD) system and explains how it works in a dual-boot configuration.

This article is available as a TechRepublic download.

Are you planning to use Windows Vista in a dual–boot configuration on your Windows XP system? If so, you may have read my article “How do I… Install Windows Vista in a dual-boot configuration along with Windows XP?”. While I explained the process of setting up a dual-boot configuration in detail in that article, there are a lot of things that go on behind the scenes that I didn’t touch on. Of course, you really don’t need to know about all that to set up and use Windows Vista in a dual–boot configuration. However, if you plan to modify the boot procedure like you may have done when dual-booting with Windows XP and previous Windows operating systems, you’ll need a deeper understanding of how Windows Vista boots.

If you set up dual-boot configurations with Windows XP and previous Windows operating systems, chances are that you became very familiar with the way Windows XP boots up, as well as how to configure the boot procedure via the Boot.ini file and the Bootcfg.exe utility.

Well, if you’re planning to set up a dual-boot configuration with Windows Vista and Windows XP and really want to get a handle on how it works, you’re going to have to forget all about Boot.ini and the Bootcfg.exe utility and learn about Windows Vista’s new boot loader architecture, which includes the Windows Boot Manager, the Boot Configuration Data (BCD) system, and the Boot Configuration Data Store Editor, BCDEdit.exe.

First, I’ll introduce you to Windows Vista’s new boot loader architecture and the BCD system and explain how it works in a dual-boot configuration. In a future article, I’ll show you how to use the new BCDEdit.exe utility to edit the BCD system and configure the Windows Boot Manager.
Taking a look back at NT Loader

Windows Vista’s predecessors (Windows NT, Windows 2000, and Windows XP) used a system based on the Windows NT boot loader, NTLDR, to boot up the system. To gain a better appreciation of Windows Vista’s new boot loader architecture, let’s begin with a quick look at how NT Loader worked.

NTLDR, which is short for NT Loader, is a special program that was first developed for Windows NT back in early 1990s. With this in mind, you can appreciate that NT Loader was definitely an outdated technology.

Essentially, as the computer boots up, the NTLDR file, containing the main boot loader, loads from the hard drive’s boot sector. Once NTLDR starts, it looks for hiberfil.sys and an active hibernation image. If NTLDR finds both the file and image, the operating system resumes from a hibernation state.

If an active hibernation image is not found, NTLDR reads the Boot.ini file, which contains special configuration options for booting the operating system as well as instructions for displaying the boot menu. Next, NTLDR launches, which, as is name implies, is responsible for detecting the basic hardware that is necessary to start the operating system. Finally, NTLDR launches Ntoskrnl.exe, which is the kernel image for an NT-based operating system, such as Windows XP.
Windows Vista’s new boot loader architecture

When Microsoft was developing Windows Vista, it decided to start from scratch and build the new operating system from the ground up. The new boot loader architecture is an excellent example of this methodology because it presents an entirely new way of booting up the Windows operating system that is both quicker and more secure.

To improve boot time and increase security, Microsoft’s Windows Vista developers decided to do away with NTLDR and replace it with an entirely new system built around three main components: the new boot loader architecture, a new boot option storage system called Boot Configuration Data (BCD), and a new boot option editing tool called BCDEdit.exe.

Now, the new boot loader architecture can itself be broken down into three main components: The Windows Boot Manager (Bootmgr.exe), the Windows operating system loader (Winload.exe), and the Windows resume loader (Winresume.exe).

In this new system, as the computer boots up, the Windows Boot Manager loads first and reads the Boot Configuration Data, which is essentially a database of boot–time configuration information stored on the hard disk in a format similar to the registry. The Boot Configuration Data database can include information about a current hibernation image, special configuration options for booting the Windows Vista operating system, and special configuration options for booting an alternate operating system. In addition to this type of information, the Boot Configuration Data database can provide instructions for launching diagnostic or recovery tools that actually run independent of the operating system.

In the overall boot process scheme, the Windows Boot Manager is a completely separate entity and is totally unaware of any operating system boot loader operations. This isolation adds a level of security between the actual booting of the computer and booting of the operating system.
How does it work?

When Windows Boot Manager reads the Boot Configuration Data, it uses the information it finds in the database to determine if it needs to display its menu. If a menu is not necessary, Windows Boot Manager does one of two things, depending on the information it finds in the Boot Configuration Data database: It either passes control over to the Windows resume loader or to the Windows operating system loader.
Windows resume loader

If the Boot Configuration Data database contains information about a current hibernation image, the Windows Boot Manager passes that information over to the Windows resume loader. Once that handover occurs, the Windows Boot Manager exits and the Windows resume loader takes over. At this stage, the Windows resume loader reads the hibernation image file and uses it return the operating system to the running state it was in when hibernation was invoked.
Windows operating system loader

If the Boot Configuration Data database doesn’t contain information about a current hibernation image, the Windows Boot Manager retrieves boot configuration information and then passes that information over to the Windows operating system loader. Once that handover occurs, the Windows Boot Manager exits and the Windows operating system loader takes over. At this stage, Windows operating system loader loads the kernel, Ntoskrnl.exe, and any basic hardware drivers. As it does so, the Windows Vista operating system boots up.
Booting an alternate operating system

Now, if the Windows Boot Manager finds information in the Boot Configuration Data database about another operating system, the Windows Boot Manager will build and display a menu that lists Windows Vista and the other operating system as choices. If the other operating system is selected, the Windows Boot Manager retrieves information about how to boot that operating system and then passes the information over to the appropriate operating system loader. As in the previous examples, the Windows Boot Manager then exits and the other operating system’s boot loader takes over.
Moving forward

As I mentioned at the beginning, the main reason for gaining a better understanding of Windows Vista’s new boot loader architecture is to help you to work with Windows Vista in a dual-boot configuration. With this information under your belt, we’ll delve into the Boot Configuration Data database and the Boot Configuration Data Store Editor, BCDEdit.exe, in the next article.


Introduction to Linux boot loaders

Takeaway: See how the Linux boot loaders LILO and GRUB work, and how to configure and manage them.

One of the remaining mysteries of Linux for many people is how to change the system startup. Sure, you’ve completed the installation, but now you want to tweak it a little bit. Perhaps you’ve upgraded your kernel and can’t figure out how to make the system boot it instead of your old kernel. Perhaps you want to password-protect the booting of your Linux workstation. These are all great goals, but how do you accomplish them?

In this Daily Drill Down, we will take a look at Linux boot loaders. A boot loader is the program that sits in your computer’s Master Boot Record, or MBR, or at the beginning of your bootable partition. Every operating system uses a boot loader of some sort; without it, the computer would not be able to boot into your operating system. Windows comes with its own boot loader that is transparent to the end user, the same as in DOS. It will simply boot Windows or DOS, whichever OS you have installed. You can purchase third-party boot loaders for Windows, which allow you to dual-boot between different operating systems on your computer. One example is PowerQuest’s BootMagic, which is also used by default for the OS/2 operating system.

With Linux, you can also use BootMagic if you feel like paying for a boot loader. BootMagic comes with PartitionMagic and you may have the need for an on-the-fly partitioning utility. However, if you do not need this, Linux comes with two excellent boot loaders: LILO and GRUB.

Introduction to LILO and GRUB
LILO (current version is 21.7.5) was the first Linux boot loader, and its name simply stands for “LInux LOader.” You will never need to download it because all Linux distributions come with it.

GRUB is a newer boot loader that at one point was a little more advanced than LILO. Its name stands for GRand Unified Bootloader. I find GRUB a little more difficult to use than LILO, and it is no longer any more advanced than LILO is. It offered a graphical boot menu before LILO did, and it was a text ANSI-based menu at that. Now, LILO offers a true graphical boot menu and is just as powerful, if not more so, than GRUB.

Using LILO
We will first take a look at LILO. The LILO configuration file is typically /etc/lilo.conf, and it contains information on the possible kernels, boot images, and defaults for LILO. Because LILO can dual-boot between Linux and Windows, as well as many other operating systems, your LILO configuration file can become quite confusing. On one system, I have LILO configured to boot between eight versions of Linux-Mandrake, Debian, and SuSE. So, as you can see, there are no real limits to what you can accomplish with LILO.

Let’s take a look at an example lilo.conf file:
append=” hdb=ide-scsi”
append=” hdb=ide-scsi failsafe”
append=” hdb=ide-scsi”

This is the configuration file I use on a Linux-Mandrake 8.0 system. It’s very straightforward and easy to follow.

The boot keyword tells LILO which hard drive contains the boot sector that is read. This should be the first hard drive in your system. We see that /dev/hde is the value here, which specifies the first ATA100 drive in the system. If you have ATA33 or ATA66 drives, this will likely be /dev/hda instead.

The map keyword specifies the location of the map file. This is typically /boot/map. If you do a directory listing in your /boot directory, you should see the map file there.

The install keyword contains the name of the file to be used as the new boot loader. With versions of LILO 21.5 and higher, this can be either boot-text.b or boot-menu.b. In our case, we use /boot/boot.b, which is actually a symbolic link to boot-menu.b. You will typically want to use boot-menu.b, as that provides you the graphical menu you see when you start your computer, while boot-text.b only exists for those who prefer a simple LILO prompt instead of the menu.

The vga keyword determines which VGA mode LILO will boot with. If you wish to boot into straight 80×25 mode, use the word “normal” here; if you wish to boot into 80×50 mode, use ext. If you want to know what VGA modes are available, use the word ask and LILO will present you with a list of VGA modes from which to choose.

The default keyword determines which image is the default to be loaded. In this case, we want the linux image to be loaded by default.

The lba32 keyword tells LILO to generate 32-bit logical block addresses instead of sector/head/cylinder addresses. This is recommended for all recent drives, as it allows LILO to boot from partitions beyond the 1024-cylinder barrier.

The prompt keyword tells LILO to issue the boot prompt and wait for user input before proceeding. The timeout keyword tells LILO how long to wait in tenths of a second. So the value of 50 in the timeout section tells LILO to wait 5 seconds.

The password keyword defines a password that must be used to boot the system. In this case, our password is secret. If you wish to have the system require the password to boot, remove the restricted keyword from the file. If you only want a password to be required if the user tries to append options to the kernel at the boot prompt, leave the restricted keyword where it is. The restricted keyword is generally used when you want the system to be able to boot without human intervention but want to prevent people from changing kernel options. These keywords can also be used in the image sections, so you can password-protect certain images completely, while using the restricted keyword with only some other images. If you wish to mix and match restricted and unrestricted images, define the password in the global section and use the restricted keyword in the images you wish to be able to boot without human intervention (usually the default image) and omit it from the other sections so that a password is required to boot them.

The message keyword tells LILO which file to use that contains the message to display before the boot prompt. For our graphical menu, we are using /boot/message-graphic, which contains the graphic for our graphical menu. If you were using the text loader, you could enter some text in the file to be displayed before the boot prompt. Whenever you change the message file, you will need to rerun LILO to rebuild the map file.

The menu-scheme keyword determines the color scheme to use with graphical booting. It follows the syntax: :::, which in our case is wb:bw:wb:bw. This means we will have white on blue for the text and border, with blue on white for the highlight and title. The letters you can use are kbgcrmyw, which stand for blacK, Blue, Green, Cyan, Red, Magenta, Yellow, and White, respectively. Use uppercase letters if you want the color to be intense.</p> <p>Finally, we come to the section defining our images to boot from. Each image section has the same structure, which consists of a starting image keyword that determines the Linux image to boot; this will usually be /boot/vmlinuz-[kernel_version]. In most cases, /boot/vmlinuz will be a symlink to a real image file, like /boot/vmlinuz-2.4.3-20mdk.</p> <p>Next, you define the name of the image with the label keyword. The first one we define is linux, which is our default image. Further on, we define labels like linux-nonfb for a nonframebuffer kernel and linux2.2 for a 2.2 kernel.</p> <p>You also need to define the root directory for this Linux installation with the root keyword. Here, we define /dev/hde1, which we mount as / (root).</p> <p>If you have a SCSI adapter or if you use the ReiserFS filesystem, you will probably need an initrd image. This image is the initial ramdisk to be loaded for the specified kernel. This is particularly needed in systems where you boot off a SCSI drive or you have your root partition formatted to ReiserFS. The initrd image will contain the modules for those devices; without the modules available, you will not be able to boot off of your SCSI devices or mount your root partition.</p> <p>The append keyword tells LILO what options to pass to the kernel when booting. In this case, we pass “hdb=ide-scsi” to the kernel, which tells the kernel that the device /dev/hdb, our IDE CD writer, is to be used with the ide-scsi module. This allows us to use tools like cdrecord to write to our IDE CD-RW with the SCSI emulation for IDE devices driver.</p> <p>The read-only keyword tells LILO to mount the root partition as read-only. Don’t worry, because later the startup procedures will remount the root filesystem as read-write, after performing a check on it. This is just a safety precaution.</p> <p>You can have as many image definitions as you want. As stated earlier, I have a system that boots between 10 different Linux distributions, so my lilo.conf file is full of image directives. You can also see here that you can tell LILO to boot from other devices, like the floppy disk. This can be beneficial because it will allow you to prevent people from putting their own floppy boot disk into the system to boot off of by telling the BIOS to boot from the hard drive only. By password-protecting LILO and your BIOS, you can ensure that only authorized people will be able to boot from a floppy.</p> <p>To save your changes and regenerate the boot image, you will need to run the lilo command. I suggest using:<br /> /sbin/lilo -v</p> <p>This will tell LILO to be verbose and tell you what it is doing as it does it. This way, if you do have any errors in your file, you can determine quickly what the error is.</p> <p>Using GRUB<br /> GRUB works in a very different way. It comes with an interactive script called grub-install, which is how you should initially configure it, unless you really know what you’re doing. You will need to have GRUB installed first; most distributions also come with GRUB, but if not, you can download it from the site.</p> <p>To begin the configuration, issue the following as root:<br /> grub-install /dev/hde</p> <p>where /dev/hde is the primary drive to boot from. Again, /dev/hde is the primary ATA100 drive, but if you use ATA33 or ATA66 drives, be sure to use /dev/hda.</p> <p>Once grub-install runs for the first time, it will create a file called /boot/grub/ and will print the contents of that file to the screen. This will list all of the drive devices on your system, including your floppy drive. After running grub-install here, my /boot/grub/ file looked like Table A.</p> <p>Table A (fd0) /dev/fd0<br /> (hd0) /dev/hde<br /> (hd1) /dev/hdf<br /> (hd2) /dev/hdg<br /> The file</p> <p>If this looks correct, you will then need to create the GRUB configuration file: /boot/grub/menu.lst. Let’s look at an example configuration file.</p> <p>Keywords<br /> The default keyword tells GRUB to boot the first definition by default; in this case, it will be the one titled Linux.</p> <p>The timeout keyword tells GRUB to wait 5 seconds before booting automatically. Unlike LILO, GRUB uses seconds, not tenths of a second.</p> <p>The i18n keyword tells GRUB which file to use for its message file, which will be shown prior to the grub> prompt. This tells GRUB to use the file /boot/grub/messages, located on the first partition on the first hard drive (hd0,0).</p> <p>The password keyword defines the password required to start any interactive operations, such as editing menu entries and entering the command-line interface. In this fashion, you can prevent GRUB from doing anything other than starting the default operating system without the password, but you will need to use the lock keyword as we see in the second image (in the above configuration example). The lock keyword tells GRUB to only boot that image if a valid password is entered.</p> <p>The title keyword starts an image definition. The first image we define, which we also have set to our default, is Linux.</p> <p>The kernel keyword defines the kernel image to load and all other kernel options. Where LILO uses a number of entries to specify all of this information, GRUB uses a single line. The first part determines the location of the boot image. In this case, we are using /boot/vmlinuz, which is located on the first partition of the first hard drive. If boot is located on a different partition, say /dev/hde5, you would use (hd0,4) to tell GRUB to use the fifth partition of the first hard drive. Finally, you tell it the root directory to use, /dev/hde1, the initrd.img file to use, /boot/initrd.img, and the appended options, which in this case is hdb=ide-scsi, to load the ide-scsi module for our CD-RW. In the above example, the lines have wrapped; they are in fact all on the same line.</p> <p>There are a few more options you can set to fine-tune GRUB, and browsing the info pages will give you that information. Type info grub to obtain detailed information about GRUB. But this should be enough to get you started.</p> <p>Writing changes<br /> Finally, to write your changes to the MBR, simply run<br /> grub</p> <p>as root. You will then be given a grub> prompt. Now you need to enter a few commands to install GRUB into your MBR.<br /> grub> root (hd0,0)</p> <p>This tells GRUB where the root device is located. In our case, /dev/hde1 is where our /boot partition is located, and thus our GRUB stage1 file, so we use (hd0,0). Next, you need to actually install GRUB into the MBR by using<br /> grub> setup (hd0)</p> <p>After this command is completed, GRUB will tell you if it was successful or not. You can now reboot and GRUB will be your default boot loader.</p> <p>Conclusion<br /> Of the two boot loaders, LILO is my preferred program. It handles my dual-booting perfectly, has a nice graphical interface at boot, and is much easier to configure. While GRUB is powerful, I find the configuration to be much more confusing than LILO. It also isn’t as standard as LILO, nor has it been used quite as long. While GRUB works well, I find LILO works better.</p> <p>At this point, you should be able to modify your system to your heart’s content. While there are more advanced options you can use with both boot loaders, the info and man pages will provide you with the help you need if what has been illustrated here is not sufficient.</p> <p>One final word of caution: Remember to have a working floppy boot disk before you start fiddling with LILO or GRUB. If you configure them incorrectly, you may be unable to start your system without having a valid and working boot disk first. You should have generated a boot floppy when you first installed Linux. Before changing configuration files for LILO and GRUB, boot off of your floppy disk to ensure it works.</p> <p>Ref: <a href="" rel="nofollow"></a></p> </div> <div class="entry-meta"> <span class="author vcard">โดย <a class="url fn n" href="" title="ดูเรื่องทั้งหมดโดย ipowerthailand">ipowerthailand</a></span> <span class="meta-sep">|</span> <span class="comments-link"><a href="">Comments (63)</a></span> </div> </div><!-- .post --> <div id="post-26" class="hentry p4 post publish author-ipowerthailand category-uncategorized untagged y2010 m06 d12 h01 alt"> <h3 class="entry-title"><a href="" rel="bookmark">Linux startup process</a></h3> <div class="entry-date"><a href="" class="published" title="2010-06-11T18:41:09+0000">มิถุนายน 11, 2010 – 6:41 pm</a></div> <div class="entry-content"> <p>Overview of typical process</p> <p>In Linux, the flow of control during a boot is from BIOS,[clarification needed] to boot loader, to kernel. The kernel then starts the scheduler (to allow multi-tasking) and runs the first userland (i.e. outside kernel space) program Init (which sets up the user environment[clarification needed] and allows user interaction and login), at which point the kernel goes idle unless called externally.</p> <p>In detail:</p> <p> 1. The BIOS performs hardware-platform specific startup tasks<br /> 2. Once the hardware is recognized and started correctly, the BIOS loads and executes the partition boot code from the designated boot device, which contains phase 1 of a Linux boot loader. Phase 1 loads phase 2 (the bulk of the boot loader code). Some loaders may use an intermediate phase (known as phase 1.5) to achieve this since modern large disks may not be fully readable without further code.<br /> 3. The boot loader often presents the user with a menu of possible boot options. It then loads the operating system, which decompresses into memory, and sets up system functions such as essential hardware and memory paging, before calling start_kernel().<br /> 4. start_kernel() then performs the majority of system setup (interrupts, the rest of memory management, device initialization, drivers, etc) before spawning separately, the idle process and scheduler, and the Init process (which is executed in user space).<br /> 5. The scheduler effectively takes control of the system management, as the kernel goes dormant (idle).<br /> 6. The Init process executes scripts as needed that set up all non-operating system services and structures in order to allow a user environment to be created, and then presents the user with a login screen.</p> <p>On shutdown, Init is called to close down all user space functionality in a controlled manner, again via scripted directions, following which Init terminates and the Kernel executes its own shutdown.<br /> [edit] Boot loader phase</p> <p>The boot loader phase varies by platform. Since the earlier phases are not specific to the OS, the boot process is considered to start:</p> <p> * For x86 or x86-64: when the partition boot sector code is executed in real mode and loads the first stage boot loader (typically a part of LILO or GRUB).</p> <p>From that point, the boot process continues as follows:</p> <p>The first stage BOOT Loader loads the remainder of the boot loader, which typically gives a prompt asking which operating system (or type of session) the user wishes to initialize. Under LILO, this is done via the map installer[clarification needed] which reads the configuration file /etc/lilo.conf to identify the available systems. It includes data such as boot partition and kernel location for each, as well as customized options if any. The selected operating system is loaded into RAM memory, a minimal initial file system is set up in RAM from an image file (“initrd”), and along with the appropriate parameters, control is passed to the newly activated operating system.</p> <p>LILO and GRUB differ in some ways:[1]</p> <p> * LILO does not understand file systems, so it uses raw disk offsets and the BIOS for data load. It loads the menu code, and then depending on the response loads either the 512 byte disk sectors for an MBR system[clarification needed] such as Microsoft Windows, or the kernel image for Linux.[1]<br /> * GRUB by contrast does have understanding of the common ext2 and ext3 file systems.[2] Because GRUB stores its data in a configuration file rather than the MBR and contains a command-line interface, it is often easier to rectify or modify GRUB if misconfigured or corrupt.[3]</p> <p>[edit] GRUB</p> <p> Source: Red Hat GRUB description.</p> <p> 1. The first stage loader is read by the BIOS from the MBR (master boot record).<br /> 2. The first stage loads the rest of the boot loader (second stage). If the second stage is on a large drive, sometimes an intermediate 1.5 stage is loaded, which contains extra code to allow cylinders above 1024, or LBA type drives, to be read. The 1.5 boot loader is stored (if needed) in the MBR or the boot partition.<br /> 3. The second stage boot loader executes, and displays the GRUB startup menu. It also allows choice of operating environment[clarification needed], and examination of system parameters.<br /> 4. When an operating system is chosen, it is loaded and control is passed.</p> <p>GRUB supports both direct and chain-loading boot methods, LBA, ext2, and “a true command-based, pre-OS environment on x86 machines”. It contains three interfaces: a selection menu, a configuration editor, and a command line console. The new Grub version 2 has support for ext4 file system.[4]<br /> [edit] LILO</p> <p>LILO, the older of the two boot loaders, is almost identical to GRUB in process, except that it does not contain a command line interface. Thus all changes must be made to its configuration and written to the MBR, and then the system restarted. An error in configuration can therefore leave a disk unable to be booted without use of a separate boot device (floppy disk etc) containing a program capable of fixing this.[3] Additionally, it does not understand file systems. Instead, locations of image files are stored within the MBR directly[3] and the BIOS is used to access them directly.<br /> [edit] Loadlin<br /> Main article: Loadlin</p> <p>Yet another way to boot Linux is from DOS or Windows 9x, where the Linux kernel completely replaces the running copy of this operating system. This can be useful in the case of hardware which needs to be switched on via software and for which such configuration programs are only available for DOS, whereas not for Linux, those being proprietary to the manufacturer and kept an industry secret. This tedious booting method is less necessary nowadays, as Linux has drivers for a multitude of hardware devices, but it used to be helpful in the past.<br /> Another case is when the Linux is located on a storage device which is not available to the BIOS for booting: DOS or Windows can load the appropriate drivers to make up for the BIOS limitation, and boot Linux from there.<br /> [edit] Kernel phase</p> <p>The kernel in Linux handles all operating system processes, such as memory management, task scheduling, I/O, interprocess communication, and overall system control. This is loaded in two stages – in the first stage the kernel (as a compressed image file) is loaded into memory and decompressed, and a few fundamental functions such as basic memory management are set up. Control is then switched one final time to the main kernel start process. Once the kernel is fully operational – and as part of its startup, upon being loaded and executing – the kernel looks for an init process to run, which (separately) sets up a user space and the processes needed for a user environment and ultimate login. The kernel itself is then allowed to go idle, subject to calls from other processes.<br /> [edit] Kernel loading stage</p> <p>The kernel as loaded is typically an image file, compressed into either zImage or bzImage formats with zlib. It contains a header program[clarification needed] which does a minimal amount of hardware setup, decompresses the image fully into high memory, taking note of any RAM disk if configured.[5] It then executes kernel startup via ./arch/i386/boot/head and the startup_32 () (for x86 based processors) process.<br /> [edit] Kernel startup stage</p> <p> Source: IBM description of Linux boot process</p> <p>The startup function for the kernel (also called the swapper or process 0) establishes memory management (paging tables and memory paging), detects the type of CPU and any additional functionality such as floating point capabilities, and then switches to non-architecture specific Linux kernel functionality via a call to start_kernel ().</p> <p>start_kernel executes a wide range of initialization functions. It sets up interrupt handling (IRQs), further configures memory, starts the Init process (the first user-space process), and then starts the idle task via cpu_idle (). Notably, the kernel startup process also mounts the initial RAM disk (“initrd”) that was loaded previously as the temporary root filing system during the boot phase. This allows driver modules to be loaded without reliance upon other physical devices and drivers,[clarification needed] and keeps the kernel smaller. The root file system is later switched via a call to pivot_root () which unmounts the temporary root file system and replaces it with the use of the real one, once the latter is accessible. The memory used by the temporary root file system is then reclaimed.</p> <p>Thus, the kernel initializes devices, mounts the root filesystem specified by the boot loader as read only, and runs Init (/sbin/init) which is designated as the first process run by the system (PID = 1).[1] A message is printed by the kernel upon mounting the file system, and by Init upon starting the Init process. It may also optionally run Initrd[clarification needed] to allow setup and device related matters (RAM disk or similar) to be handled before the root file system is mounted.[1]</p> <p>According to Red Hat, the detailed kernel process at this stage is therefore summarized as follows:[2]</p> <p> “When the kernel is loaded, it immediately initializes and configures the computer’s memory and configures the various hardware attached to the system, including all processors, I/O subsystems, and storage devices. It then looks for the compressed initrd image in a predetermined location in memory, decompresses it, mounts it, and loads all necessary drivers. Next, it initializes virtual devices related to the file system, such as LVM or software RAID before unmounting the initrd disk image and freeing up all the memory the disk image once occupied. The kernel then creates a root device,[clarification needed] mounts the root partition read-only, and frees any unused memory. At this point, the kernel is loaded into memory and operational. However, since there are no user applications that allow meaningful input to the system, not much can be done with it.”</p> <p>At this point, with interrupts enabled, the scheduler can take control of the overall management of the system, to provide pre-emptive multi-tasking, and the init process is left to continue booting the user environment in user space.<br /> [edit] Init process (SysV init style only)</p> <p> “Init is the father of all processes. Its primary role is to create processes from a script stored in the file /etc/inittab. This file usually has entries which cause init to spawn gettys on each line that users can log in. It also controls autonomous processes[clarification needed] required by any particular system. A run level is a software configuration of the system which allows only a selected group of processes to exist. The processes spawned by init for each of these run levels are defined in the /etc/inittab file.<br /> – manual page for Init[6]</p> <p>Init’s job is “to get everything running the way it should be” [7] once the kernel is fully running. Essentially it establishes and operates the entire user space. This includes checking and mounting file systems, starting up necessary user services, and ultimately switching to a user-environment when system startup is completed. It is similar to the Unix and BSD init processes, from which it derived, but in some cases has diverged or became customized. In a standard Linux system, Init is executed with a parameter, known as a runlevel, that takes a value from 1 to 6, and that determines which subsystems are to be made operational. Each runlevel has its own scripts which codify the various processes involved in setting up or leaving the given runlevel, and it is these scripts which are referenced as necessary in the boot process. Init scripts are typically held in directories with names such as “/etc/rc…”. The top level configuration file for init is at /etc/inittab.[7]</p> <p>During system boot, it checks whether a default runlevel is specified in /etc/inittab, and requests the runlevel to enter via the system console if not. It then proceeds to run all the relevant boot scripts for the given runlevel, including loading modules, checking the integrity of the root file system (which was mounted read-only) and then remounting it for full read-write access, and sets up the network.[1]</p> <p>In detail, according to Red Hat, the init process follows the following steps:[2]</p> <p> 1. It looks at the sysinit script, which “sets the environment path[clarification needed], starts swap, checks the file systems, and takes care of everything the system needs to have done at system initialization.” This includes the system and hardware clock, special serial port processes, and the like.<br /> 2. Init then looks at the specific runlevel, as specified in that runlevels configuration.<br /> 3. Init then sets the source function library[clarification needed] for the system. This spells out how to start or kill a program and how to determine the PID of a program.<br /> 4. It then searches and starts each applicable process, and it creates a login session for the user.</p> <p>After it has spawned all of the processes specified, init goes dormant, and waits for one of three events to happen:- processes it started to end or die, a power failure signal[clarification needed], or a request via /sbin/telinit to further change the runlevel.[6]</p> <p>This applies to SysV-style init binaries. Other init binaries may behave differently.</p> <p>Ref: Wiki</p> </div> <div class="entry-meta"> <span class="author vcard">โดย <a class="url fn n" href="" title="ดูเรื่องทั้งหมดโดย ipowerthailand">ipowerthailand</a></span> <span class="meta-sep">|</span> <span class="comments-link"><a href="">Comments (0)</a></span> </div> </div><!-- .post --> <div id="post-24" class="hentry p5 post publish author-ipowerthailand category-uncategorized untagged y2010 m06 d12 h01"> <h3 class="entry-title"><a href="" rel="bookmark">Windows Vista startup process</a></h3> <div class="entry-date"><a href="" class="published" title="2010-06-11T18:40:08+0000">มิถุนายน 11, 2010 – 6:40 pm</a></div> <div class="entry-content"> <p>The startup process of Microsoft’s Windows Vista, Windows Server 2008 and Windows 7 operating systems is slightly different from previous versions.</p> <p>The sequence of booting Windows Vista is slightly different from any previous version of Windows that uses the NT kernel. First, when the computer is switched on, either the BIOS or the EFI is loaded. In the case of a BIOS system, the MBR of the boot disk, which can be a hard drive or external media, is accessed, followed by the boot sector of the drive or of the relevant hard disk partition. This boot sector then loads the rest of the boot blocks. For Windows Vista, the boot sector loads the Windows Boot Manager (with filename BOOTMGR), which accesses the Boot Configuration Data store and uses the information to load the final stage, the operating system.</p> <p>Windows Boot Manager</p> <p>The Windows Boot Manager (BOOTMGR) reads the boot configuration data and displays an operating system selection menu,[1] and is thus, in some respects, equivalent to the boot selection menu functionality of NTLDR in prior versions of Windows NT. A notable change is that the Windows Boot Manager is invoked by pressing the space bar instead of the F8 function key. [2] The F8 key still remains assigned for advanced boot options once the Windows Boot Manager menu appears.</p> <p>To maintain a consistent boot experience on Extensible Firmware Interface systems that also have a boot manager of their own, the Windows Boot Manager, and hence all of the installed Windows operating systems that can be booted using it, appear as a single entry on the EFI boot manager menu. (On EFI systems, the Windows Boot Manager is an EFI application stored on the EFI System Partition). Microsoft only adds multiple entries to the Windows Boot Manager (BCD) menu itself, and sets the timeout of the EFI boot manager to two seconds.<br /> [edit] Boot Configuration Data</p> <p>Boot Configuration Data (BCD) is a firmware-independent database for boot-time configuration data. It replaces the boot.ini that was used by NTLDR, and is used by Microsoft’s new Windows Boot Manager.[3]</p> <p>Boot Configuration Data is stored in a data file (formatted in the same way as a Windows registry hive) that is located either on the EFI System Partition (on machines that use Extensible Firmware Interface firmware) or in \Boot\Bcd on the system volume (on machines that use IBM PC compatible firmware).</p> <p>Boot Configuration Data may be altered using a command-line tool (bcdedit.exe), by using Windows Management Instrumentation, or with 3rd party tools like EasyBCD that allow more advanced configuration and support for non-Windows operating systems.</p> <p>Boot Configuration Data contain the menu entries that are presented by the Windows Boot Manager, just as boot.ini contained the menu entries that were presented by NTLDR. These menu entries can include:</p> <p> * Options to boot Windows Vista by invoking winload.exe.<br /> * Options to resume Windows Vista from hibernation by invoking winresume.exe.<br /> * Options to boot a prior version of the Windows NT family by invoking its NTLDR.<br /> * Options to load and to execute a Volume Boot Record.</p> <p>Boot Configuration Data allows for third party integration so anyone can implement tools like diagnostics or recovery options.<br /> [edit] winload.exe</p> <p>The Windows Boot Manager invokes winload.exe—the operating system boot loader—to load the operating system kernel (ntoskrnl.exe) and (boot-class) device drivers.[1] In that respect, winload.exe is functionally equivalent to the operating system loader function of NTLDR in prior versions of Windows NT.</p> <p>Ref: Wiki</p> </div> <div class="entry-meta"> <span class="author vcard">โดย <a class="url fn n" href="" title="ดูเรื่องทั้งหมดโดย ipowerthailand">ipowerthailand</a></span> <span class="meta-sep">|</span> <span class="comments-link"><a href="">Comments (0)</a></span> </div> </div><!-- .post --> <div id="nav-below" class="navigation"> <div class="nav-previous"></div> <div class="nav-next"></div> </div> </div><!-- #content --> <div id="primary" class="sidebar"> <ul class="xoxo"> <li id="pages"> <h3>หน้า</h3> <ul> <li class="page_item page-item-2"><a href="">เกี่ยวกับเรา</a></li> <li class="page_item page-item-93"><a href="">ขาย คอนโด JWPlace – ซ.รัชดา32 ใกล้กรมส่งเสริมการส่งออก, รถไฟใต้ดิน</a></li> </ul> </li> <li id="categories"> <h3>หมวดหมู่</h3> <ul> <li class="cat-item cat-item-37964100"><a href="" >ประกาศ ขายบ้าน</a> </li> <li class="cat-item cat-item-3385"><a href="" title="เกี่ยวกับระบบเน็ตเวิคค์">Network</a> </li> <li class="cat-item cat-item-3383"><a href="" >OS</a> </li> <li class="cat-item cat-item-1 current-cat"><a href="" >Uncategorized</a> </li> </ul> </li> <li id="archives"> <h3>คลังเก็บ</h3> <ul> <li><a href=''>สิงหาคม 2010</a></li> <li><a href=''>มิถุนายน 2010</a></li> <li><a href=''>พฤษภาคม 2010</a></li> </ul> </li> <li id="search"> <h3><label for="s">ค้นหา</label></h3> <form id="searchform" class="blog-search" method="get" action=""> <div> <input id="s" name="s" type="text" class="text" value="" size="10" tabindex="1" /> <input type="submit" class="button" value="Find" tabindex="2" /> </div> </form> </li> <li id="linkcat-1356" class="linkcat"><h3>Blogroll</h3> <ul class='xoxo blogroll'> <li><a href="">Development Blog</a></li> <li><a href="">Documentation</a></li> <li><a href="">Plugins</a></li> <li><a href="">Suggest Ideas</a></li> <li><a href="">Support Forum</a></li> <li><a href="">Themes</a></li> <li><a href="">WordPress Planet</a></li> </ul> </li> <li id="rss-links"> <h3>RSS Feeds</h3> <ul> <li><a href="" title="iPower Thailand's Blog latest posts" rel="alternate" type="application/rss+xml">โพสต์ทั้งหมด</a></li> <li><a href="" title="iPower Thailand's Blog latest comments" rel="alternate" type="application/rss+xml">All comments</a></li> </ul> </li> <li id="meta"> <h3>Meta</h3> <ul> <li><a href="">ลงทะเบียน</a></li> <li><a href="">เข้าสู่ระบบ</a></li> </ul> </li> </ul> </div><!-- #primary .sidebar --> </div><!-- #container --> <div id="footer"> <span id="generator-link"><a href="">สร้างเว็บไซต์หรือบล็อกฟรีที่</a></span> <span class="meta-sep">|</span> .</span> </div><!-- #footer --> </div><!-- #wrapper .hfeed --> <!-- --> <script type='text/javascript' src='//'></script> <script type='text/javascript'> /* <![CDATA[ */ var WPGroHo = {"my_hash":""}; /* ]]> */ </script> <script type='text/javascript' src=''></script> <script> //initialize and attach hovercards to all gravatars jQuery( document ).ready( function( $ ) { if (typeof Gravatar === "undefined"){ return; } if ( typeof Gravatar.init !== "function" ) { return; } Gravatar.profile_cb = function( hash, id ) { WPGroHo.syncProfileData( hash, id ); }; Gravatar.my_hash = WPGroHo.my_hash; Gravatar.init( 'body', '#wp-admin-bar-my-account' ); }); </script> <div style="display:none"> </div> <div class="widget widget_eu_cookie_law_widget"><div class="hide-on-button ads-active" data-hide-timeout="30" data-consent-expiration="180" id="eu-cookie-law" > <form method="post"> <input type="submit" value="Close and accept" class="accept" /> Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use. <br /> To find out more, including how to control cookies, see here: <a href="" > Cookie Policy </a> </form> </div> </div><script type='text/javascript'> /* <![CDATA[ */ var actionbardata = {"siteID":"13776598","siteName":"iPower Thailand's Blog","siteURL":"http:\/\/","icon":"<img alt='' src='https:\/\/\/i\/logo\/wpcom-gray-white.png' class='avatar avatar-50' height='50' width='50' \/>","canManageOptions":"","canCustomizeSite":"","isFollowing":"","themeSlug":"pub\/notesil","signupURL":"https:\/\/\/start\/","loginURL":"https:\/\/\/wp-login.php?","themeURL":"","xhrURL":"https:\/\/\/wp-admin\/admin-ajax.php","nonce":"e2cc42352a","isSingular":"","isFolded":"","isLoggedIn":"","isMobile":"","subscribeNonce":"<input type=\"hidden\" id=\"_wpnonce\" name=\"_wpnonce\" value=\"8bc9386775\" \/>","referer":"https:\/\/\/category\/uncategorized\/","canFollow":"1","feedID":null,"statusMessage":"","customizeLink":"https:\/\/\/wp-admin\/customize.php?","i18n":{"view":"View site","follow":"\u0e15\u0e34\u0e14\u0e15\u0e32\u0e21","following":"Following","edit":"\u0e41\u0e01\u0e49\u0e44\u0e02","login":"\u0e40\u0e02\u0e49\u0e32\u0e2a\u0e39\u0e48\u0e23\u0e30\u0e1a\u0e1a","signup":"\u0e2a\u0e21\u0e31\u0e04\u0e23","customize":"\u0e1b\u0e23\u0e31\u0e1a\u0e41\u0e15\u0e48\u0e07","report":"Report this content","themeInfo":"Get theme: NotesIL","shortlink":"Copy shortlink","copied":"\u0e04\u0e31\u0e14\u0e25\u0e2d\u0e01\u0e41\u0e25\u0e49\u0e27","followedText":"New posts from this site will now appear in your <a href=\"https:\/\/\/\">Reader<\/a>","foldBar":"Collapse this bar","unfoldBar":"Expand this bar","editSubs":"Manage subscriptions","viewReader":"View site in Reader","viewReadPost":"View post in Reader","subscribe":"Sign me up","enterEmail":"\u0e43\u0e2a\u0e48\u0e2d\u0e35\u0e40\u0e21\u0e25\u0e25\u0e4c\u0e02\u0e2d\u0e07\u0e04\u0e38\u0e13\u0e17\u0e35\u0e48\u0e19\u0e35\u0e48","followers":"","alreadyUser":"Already have a account? <a href=\"https:\/\/\/wp-login.php?\">Log in now.<\/a>","stats":"\u0e2a\u0e16\u0e34\u0e15\u0e34"}}; /* ]]> */ </script> <script type='text/javascript' src=''></script> <script type="text/javascript"> // <![CDATA[ (function() { try{ if ( window.external &&'msIsSiteMode' in window.external) { if (window.external.msIsSiteMode()) { var jl = document.createElement('script'); jl.type='text/javascript'; jl.async=true; jl.src='/wp-content/plugins/ie-sitemode/custom-jumplist.php'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(jl, s); } } }catch(e){} })(); // ]]> </script> <script type="text/javascript"> var skimlinks_pub_id = "725X584219" var skimlinks_sitename = ""; </script> <script type="text/javascript" defer src=""></script><script src="//" type="text/javascript" async defer></script> <script type="text/javascript"> _tkq = window._tkq || []; _stq = window._stq || []; _tkq.push(['storeContext', {'blog_id':'13776598','blog_tz':'7','user_lang':'th','blog_lang':'th','user_id':'0'}]); _stq.push(['view', {'blog':'13776598','v':'wpcom','tz':'7','user_id':'0','subd':'ipowerthailand'}]); _stq.push(['extra', {'crypt':'UE5XaGUuOTlwaD85flAmcm1mcmZsaDhkV11YdWFnNncxc1tjZG9XVXhRREQ/V0xPZ1hKXy82Z2xTLWJPfjY9JnMmK1MmK2doUmszLkNncD1NeEhkbmhEcUFSajNHfng3XTNLJUVtLmVoc21CZmNUaTA2eVhkb1BZZXpUfGR6Nng9bHQsekpEYjVBSiU/d0xqX0tsTnE3bHpybGUwRmdGOGFWP0paTnhURzguPzBzbDZtajQ3fmNHeVhOc18xK0ZCMzhyNnZZL0RLJmRReXVZWltbOD0yXURpTV1VLDQ2RUJyUFVfaVFtNS44TEszejk5RFh+aGx3'}]); _stq.push([ 'clickTrackerInit', '13776598', '0' ]); </script> <noscript><img src="" style="height:0px;width:0px;overflow:hidden" alt="" /></noscript> <script> if ( 'object' === typeof wpcom_mobile_user_agent_info ) { wpcom_mobile_user_agent_info.init(); var mobileStatsQueryString = ""; if( false !== wpcom_mobile_user_agent_info.matchedPlatformName ) mobileStatsQueryString += "&x_" + 'mobile_platforms' + '=' + wpcom_mobile_user_agent_info.matchedPlatformName; if( false !== wpcom_mobile_user_agent_info.matchedUserAgentName ) mobileStatsQueryString += "&x_" + 'mobile_devices' + '=' + wpcom_mobile_user_agent_info.matchedUserAgentName; if( wpcom_mobile_user_agent_info.isIPad() ) mobileStatsQueryString += "&x_" + 'ipad_views' + '=' + 'views'; if( "" != mobileStatsQueryString ) { new Image().src = document.location.protocol + '//' + mobileStatsQueryString + '&baba=' + Math.random(); } } </script></body> </html>