Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
For example, if use grub to boot system, there may be lines such as
root (hd0,6)
kernel /boot/vmlinuz-2.6.11-1.1369_FC4 ro root=LABEL=/
initrd /boot/initrd-2.6.11-1.1369_FC4.img
in menu.lst.
My question is:
before the kernel image is loaded into memory, I think no file system info(such as file system type, super block) which can be used to locate the kernel image in the disk exist.
So how does bootloader know the CHS of the image in the disk?
I guess that bootloader could find the super block according to "root (hd0,6)"; if so, it must blindly detect all the possible file systems and find a matching one. Is it too complicated?
I am gonna give you an answer using Lilo like example:
The reason that you have to run /sbin/lilo after installing a new
kernel is that the LILO bootloader doesn't understand file systems it
only knows about the lower level block structure of the disk. The
/sbin/lilo program does understand file systems, and translates the
kernel's path (i.e "/boot/vmlinuz-2.6.3") into a logical block address
ie 3-4-123) so that the LILO bootloader can find the kernel image to
load. Effectively, this is a big hack.
Source:
http://courses.cs.washington.edu/courses/cse451/02wi/section/bootloaders.txt
The setup process for GRUB includes generation of
full list of physical addresses of stage 2 file
encoded drive number (as used with BIOS calls)
encoded partition number (these two forms value represented as (hd0,6) from your example)
Stage 1 and bootstrapper of stage 2 can together use this to load full stage 2 into memory. Since that moment, stage 2 can detect FS type, activate respective read-only FS driver, read runtime config (grub.cfg or menu.lst) and proceed with following reading of kernel, initrd, etc. using FS driver.
NB this principally differs from LILO that the latter hardcodes kernel and initrd sector lists during loader installing; when booted, loader knows only sector lists but not FS structure.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I've seen that df -H --total gives me the total space available but only of mounted devices, and lsblk gives me the sizes of all storage devices, yet not how much space is available within them.
Is there a way I could see the sum total, available storage space of all devices, e.g. hard disks, thumb drives, etc., in one number?
The operation of mounting a medium makes the operating system analyze the file system.
Before a medium is mounted, it exists as a block device and the only fact the OS might know about it might be the capacity.
Other than that, it is just a stream of bytes not interpreted in any way. That "stream of bytes" very probably contains the information of used and unused blocks. But, dependent on file system types, in very different places and can thus not be known by the OS (other than mounting and analyzing it)
You could write a specific application that would extract that information, but I would consider that temporarily mounting the file system. Standard Unix/Linux doesn't come with such an application.
From the df man page, I'd say "No", but the wording indicates that it may be possible on some sytems/distributions with some version(s) of df.
The other problem is how things can be accessed. For example, the system I'm using right now shows 3 160gb disks in it... but df will show one of them at / and the other 2 as a software based RAID-1 setup on /home.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I have run bitbake core-image-minimal-dev properly configured for a genericx86 machine. BitBake generates a bootia32.efi, a bzImage--<stuff>.bin, an .hddimg, an .iso, a .rootfs.ext3, a .rootfs.ext4, a .rootfs.tar.bz2, and a core-image-initramfs-<stuff>.rootfs.cpio.gz. I'm interested in a method of how to dd one or more of these onto the hard disk of my target machine and boot from that hard disk.
dd if=path/to/imagefile/imagename.hddimg of=/dev/usbdevicename
You'll find the correct usb device name e.g. by plugging in the usb disk and looking at dmesg|tail output -- do not guess as mistakes will be fatal to your hard disk. A practical example from my build machine:
sudo dd if=tmp/deploy/images/intel-corei7-64/core-image-sato-intel-corei7-64.hddimg \
of=/dev/sdb \
bs=4096
Note that you probably want to use intel-corei7-64 as the machine unless you know that genericx86 is correct for your hardware: despite the name former is the common Intel BSP for anything that's not ancient (that includes big Cores, Xeons, Atoms ...).
How to boot the image depends on your target device: you may need to go to BIOS settings to select "boot from USB".
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I have an ISO image (stock Ubuntu 13.10 DVD ISO image) loaded into memory pre-OS and I'm trying to start the Linux installation process from this image. GRUB can recognize the image as a cd and I can start the installation (I'm experimenting with an UEFI platform, and using an UEFI version of GRUB so it can recognize the image as a valid block device with a supported file system).
My problem is the kernel cannot find the install media (which is expected) so it panics early on. I realize I can write a simple block device driver so the kernel can find the image but for the sake of portability, is there a way to mount tmpfs/ramfs at a specific start address? Or is there a way to tell the kernel that there is a file system at a specific address?
Thanks
Compile your kernel with the ISO filesystem as a built-in. Specify the ISO image as the initrd image. The contents of the ISO will probably need modified to understand this new way of booting as, unlike a normal initrd image, you will not want to be unmounting it to mount the real root filesystem.
Note that the preferred way would probably be to write a kernel module that recognizes and mounts the ISO and put it in a smaller initramfs image instead. The above is just an idea about how you might accomplish it without writing a module.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
What would happen if the Linux kernel deleted itself? Will there be a moment when it could no longer delete files because rm or the program used for deletion has been deleted too?
Regards.
The question is (apart from being off-topic) somewhat wrong in itself, as rm is not part of the kernel, but either a shell built-in or a separate user-level program. Admittedly, rm uses a syscall provided by the kernel, but that is irrelevant.
The kernel itself is loaded from a compressed image and locked in RAM. It does not matter whether you delete the compressed image until you reboot (which will fail with the boot loader giving you a message like "vmlinuz not found"). You have no way of removing the kernel from RAM (well, other than rebooting...).
Also, for the most part, it does not even matter whether you delete a file, including a running program's executable anyway (if we may be so daunting as to call the kernel a "program" for a moment) under Linux, because deleting a file merely removes the link, not the file. It is a Windows-typical assumption that deleting a file does evil, destructive things.
Under Unix-like systems, it is perfectly possible to delete (or replace) a program while it is running, and it will not cause any problems at all. You will remove the name in the filesystem, that's all. Any open descriptors will remain valid until the last one is closed, the original file will stay intact as-is for any observer who obtained a handle earlier, and it will be "gone" for everyone trying to get at it later.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 9 years ago.
Improve this question
I have googled this question over the internet but couldn't find anything useful related to this question that "why compressed kernel image like bzImage or vmlinuz is used as initial kernel image",
Possible solutions which i could think of are:
Due to memory constraint?
But initially compressed kernel image is located at hard disk or some other storage media and during boot up time after second stage bootloader, kernel is first decompressed in main memory and then it is executed.
So, when at later stage kernel is to be decompressed in main memory then what is the need to compress it first. I mean if main memory could hold decompressed kernel image then what is the need for kernel compression?
Generally the processor can decompress faster than the I/O system can read. By having less for the I/O system to read, you reduce the time needed for boot.
This assumption doesn't hold for all hardware combinations, of course. But it frequently does.
An additional benefit for embedded systems is that the kernel image takes up less space on the non-volatile storage, which may allow using a smaller (and cheaper) flash chip. Many of these systems have ~ 32MB of system RAM and only ~ 4MB of flash.