I'm wondering if, in a embedded linux board after the initial booting phase, if I surfing the filesystem using the terminal, is there a place where I can read which dtb file is currently in use from my system? A log stored in filesystem or something similar?
Related
There is a program (program A), that uses some specific file in some folder. Normally that file is on the hard disk.
I need to write a program (program B) that can create such file, but this file should be physically in RAM, not on HDD. So if you unplug HDD, you could not find the file.
I also have no access to program A code. But I want A to interpreting that file as a normal file.
Is it possible in Windows to do something like that?
The only way to have a file that is only in memory is to use a RAM-drive. You can find free RAM-drives and probably some open source implementations but they do require a kernel driver. NTFS mount points will allow you to mount this drive as a subfolder on drive C: if that is a requirement.
From a programming point of view, the only thing program B would be able to do is to set the delete-on-close flag after program A has opened the file. Depending on how A uses the file, you might be able to just delete the file, and if not, B would have to call SetFileInformationByHandle(FileDispositionInfo, ...) on the file handle but this will only work if program A opens the file with the share flags set to allow delete. I have never tested this so I'm not 100% sure it would work if power was lost. NTFS does have journaling that makes sure the filesystem state is correct but I'm not sure if it applies to the delete flag.
I have a library that has a file based interface (it only accept file names/paths).
Since the operations are time critical i would like to load the file to memory.
Is there a way to create create in-memory files that have a file path that is resolvable with the normal file access routines?
For example many programs still work if they get some win32 device path or an UNC path instead of a 'classic' windows path.
or maybe if that is not the case maybe a softlink can be used to map it into 'normal' filesystem.
One obvious way would be to use some ramdisk software but this would require further manual steps and also requires to tell the program the ramdisks letter.
I am creating an operating system, and am able to create a simple multitasking kernel (though the code has been lost) and an IDE/ATA PIO driver without BIOS interrupts. I wish to create a boot loader that puts the system into Protected Mode, disables paging, creates a flat memory model, and then does a long jump to the 0x0 offset of a file named OS.SYS in the root directory of a FAT32 formatted hard drive. I know how do do everything except for one thing: change the boot sector of the disk. I know how to format a hard drive as FAT32 to get the correct BPB and such at the beginning of the file, but I do not know how to copy over the code so that the BPB is not corrupted. Even in Linux when DD was available, I was unable to overcome this hurdle - I always used a custom file system. I am now seeing the disadvantages to this, though, such as not being able to use simple tools like file managers to move files around for testing.
Basically, to sum it up, I'm asking how to change the boot sector code on an already working FAT32 file system without messing up the BPB.
Note: I am using Windows 10 and NASM, and intend to use virtual hard disks with QEMU or Virtualbox.
I am studying the boot process in Linux. I came across this sentence "RAM is several orders of magnitude faster than a floppy disk, so system operation is fast from a ramdisk"
The kernel will anyway load the root filesystem in RAM for executing it. So my question why do we need a ramdisk for loading the root filesystem, if the kernel loads the root file system into RAM ?
The documentation for SUSE Linux provides a good explanation of why Linux is booted with a RAMDisk:
As soon as the Linux kernel has been
booted and the root file system (/)
mounted, programs can be run and
further kernel modules can be
integrated to provide additional
functions. To mount the root file
system, certain conditions must be
met. The kernel needs the
corresponding drivers to access the
device on which the root file system
is located (especially SCSI
drivers). The kernel must also contain
the code needed to read the file
system (ext2, reiserfs, romfs, etc.).
It is also conceivable that the root
file system is already encrypted. In
this case, a password is needed to
mount the file system.
For the problem of SCSI drivers, a
number of different solutions are
possible. The kernel could contain all
imaginable drivers, but this might be
a problem because different drivers
could conflict with each other. Also,
the kernel would become very large
because of this. Another possibility
is to provide different kernels, each
one containing just one or a few SCSI
drivers. This method has the problem
that a large number of different
kernels are required, a problem then
increased by the differently optimized
kernels (Athlon optimization, SMP).
The idea of loading the SCSI driver as
a module leads to the general problem
resolved by the concept of an initial
ramdisk: running user space programs
even before the root file system is
mounted.
This prevents a potential chicken-or-egg situation where the root file system cannot be loaded until the device on which it is located can be accessed, but that device can't be accessed until the root file system has been loaded:
The initial ramdisk (also called initdisk or initrd) solves precisely the problems described above. The Linux kernel provides an option of having a small file system loaded to a RAM disk and running programs there before the actual root file system is mounted. The loading of initrd is handled by the boot loader (GRUB, LILO, etc.). Boot loaders only need BIOS routines to load data from the boot medium. If the boot loader is able to load the kernel, it can also load the initial ramdisk. Special drivers are not required.
Of course, a RAMDisk is not strictly necessary for the boot process to take place. For example, you could compile a kernel that contained all necessary hardware drivers and modules to be loaded at startup. But apparently this is too much work for most people, and the RAMDisk proved to be a simpler, more scalable solution.
The reason that most Linux distributions use a ramfs (initramfs) when booting, is because its contents can be included in the kernel file, or provided by the bootloader. They are therefore available immediately at boot, without the kernel having to load them from somewhere.
That allows the kernel to run userspace programs that e.g. configure devices, load modules, setup that nifty RAID array that contains all filesystems or even ask the user for the password to his encrypted root filesystem.
When this configuration is done, the first script that is called just exec()s /sbin/init from the (now configured and available) root filesystem.
I have seen quite a few systems where the drivers themselvess for the disk controllers and the rootfs are loaded via modules in an initramfs, rather than being included in the kernel image.
You do not strictly need an initramfs to boot - if your kernel image contains all drivers necessary to access the rootfs and you don't need any special configuration or user input (like RAID arrays or encrypted filesystems) to mount it, it is often possible to directly start /sbin/init from the rootfs.
See also:
http://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
http://www.kernel.org/doc/Documentation/initrd.txt
As a side note, some systems (rescue disks, embedded and such) may use a ramfs as the root filesystem when the actual root filesystem is in a medium that may be removed or is not writable (CD, Flash MTDs etc).
When I boot up Linux Mint from a Live CD, I am able to save files to the "File System". But where are these files being saved to? Can't be the disc, since it's a CDR. I don't think it's stored in the RAM, because it can only hold so much data and isn't really intended to be used as a "hard drive". The only other option is the hard drive... but it's certainly not saving to any partition on the hard drive I know about, since none of them are mounted. Then where are my files being saved to??
Believe it or not, it's a ramdisk :)
All live distros mount a temporary hard disk in RAM memory. The process is completely user-transparent and is all because of the magic of Linux kernel.
The OS, in fact, first allocates an area of your RAM memory into a virtual device, then mounts it as a regular hard drive in your file system.
Once you reboot, you lose all your data from that ramdrive.
Ramdrive is needed by almost all software running on Live CDs. In fact, almost all programs, in particular desktop managers, are designed in order to write files, even temporary, during their execution.
As an example, there are two ways to run KDE on a Live CD: either modify its code deeply in order to disallow you to change wallpaper etc. (the desktop settings are stored inside ~/.kde) or redeploy it onto a writable file system such as a ramdrive in order to avoid write fails on read-only file systems.
Obviously, you can mount your real HDD or any USB drive into your virtual file system and make all writes to them permanent, but by default no live distro mounts your drives into the root file system, instead they usually mount into specific subdirectories like /mnt, /media, /windows
Hope to have been of help.
It does indeed emulate a disk using RAM; from Wikipedia:
It is able to run without permanent
installation by placing the files that
typically would be stored on a hard
drive into RAM, typically in a RAM
disk, though this does cut down on the
RAM available to applications.
RAM. In Linux, and indeed most unix systems, any kind of device is seen as a file system.
For example, to get memory info on linux you use cat /proc/meminfo, where cat is used to read files. Then, there's all sorts of strange stuff like /dev/random (to read random crap) and /dev/null (to throw away crap). ;-)
To make it persistent - use a USB device - properly formatted and with a special name. See here:
https://help.ubuntu.com/community/LiveCD/Persistence