I mounted the cramfs image in some directory.The files in that dir are showing the timestamp of 1970-01-01.I am having issues in compressing this file system because of old time stamp.So i want to change the time stamp using touch command but when i am always getting error Read only file system.
I have also tried remounting as read/write filesystem but even after that i am not able to change the permissions.
Could anyone guide me regarding this.
Thanks and Regards,
Mayank
cramfs is a read-only file system perfect for small-system boot ROMs
and other read-only programs and data.
~Hallinan, Christopher (2010-10-26). Embedded Linux Primer: A Practical Real-World Approach (2nd Edition) (Kindle Locations 4746-4747). Pearson Education (USA). Kindle Edition.
Related
Today I just realized in my Ubuntu Linux, I can mount and store files on my newly purchased hard drive as a raw device without a file system. (as long as I partitioned the disk correctly)
So, I am not sure if my below statement is correct, looking for expert to answer:
Looks like it's not required to create a file system on a disk in order to use it in Linux? Is it correct?
I have some very basic understanding of how a file system works. In Linux, is the concept of "inode" a file system feature or a Linux feature?
I understand that the "inode" file system works unlike NTFS or FAT32 that it tries to spread out the data across the disk so that Linux/Unix doesn't need as Windows like "defgramentation" program to keep data in consecutive chunks. My question is, if I am storing my data on a raw device without a file system, and if "inode" is a file system feature not a Linux feature, what will the actual data layout look like on the raw device then?
Thanks in advance
I am searching for a way to get all the metadata of the linux file system (ext2/3/4). The task is to find all the files (deleted/or not deleted) present on the linux partition. The metadata of the files should include creation time , modification time etc. (basically what you get from the command istat)
The problem i am facing is regarding the deleted files. I cannot find a way to get the inode of the deleted files currently present on the file system. Kindly suggest a way to solve this issue for the above mentioned file systems.
Thanks in advance.
You may find The Coroner's Toolkit to be quite useful. It includes tools to allow you to view any element of the metadata, directly view inodes, dump out all of the disk sectors that an inode references, dump disk sectors directly, etc. Since you are working with the inodes and sectors directly, it does not matter if they are deleted or not, they are all accessible.
Does Linux need a writeable file system to function correctly? I'm just running a very simple init programme. Presently I'm not mounting any partitions. The Kernel has mounted the root partition as read-only. Is Linux designed to be able run with just a read-only file system as long as I stick to mallocs, readlines and text to standard out (puts), or does Linux require a writeable file system in-order even to perform standard text input and output?
I ask because I seem to be getting kernel panics and complaints about the stack. I'm not trying to run a useful system at the moment. I already have a useful system on another partition. I'm trying to keep it as simple as possible so as I can fully understand things before adding in an extra layer of complexity.
I'm running a fairly standard x86-64 desktop.
No, writable file system is not required. It is theoretically possible to run GNU/Linux with the only read-only file system.
In practice you probably want to mount /proc, /sys, /dev, possibly /dev/pts to everything work properly. Note that even some bash commands requires writable /tmp. Some other programs - writable /var.
You always can mount /tmp and /var as ramdisk.
Yes and No. No it doesn't need to be writeable if it did almost nothing useful.
Yes, you're running a desktop so it's needed to be writeable.
Many processes actually need a writeable filesystem as many system calls can create files. e.g. Unix Domain Sockets can create files.
Also many applications write into /var, and /tmp
The way to get around this is to mount the filesystem read/only and use a filesystem overlay to overlay an in memory filesystem. That way, the path will be writable but they go to ram and any changes are thrown away on reboot.
See: overlayroot
No it's not required. For example as most distributions have a live version of Linux for booting up for a cd or usb disk with actually using and back end hdd.
Also on normal installations, the root partitions are changed to read-only when there are corruptions on the disk. This way the system still comes up as read-only partition.
You need to capture the vmcore and the stack trace of the panic form the dmesg output to analyse further.
I am working on a project for set top boxes and I need to mount a HDD partition formatted with xtvfs filesystem.
I have only received the following information regarding xtvfs:
The partition formatted with xtvfs is basically a type 1 (FAT12) to be used with xtvfs
I searched the internet and found a program called Copy+ that can be used to copy xtvfs images form one HDD to another.
The set top I am working on uses linux and so I need to mount and read the partition on it.
I have the following question:
I did not find any xtvfs named filesystem supported in the kernel. Can I be able to mount it using vfat?
If not, then how do I get to work such a filesystem in Linux.
Information on XTVFS is hard to find and support is not widespread - http://wiki.ph-mb.com/wiki/XTVFS is probably the best page I found. I could not find a linux driver for it. XTVFS is based on FAT32 and mounting that on Linux will get you part of the way - basically for everything but the video files. The video files have a separate Video FAT and video data section. I wrote some code to read files from an XTVFS image and will share it once it is tidied.
In Linux, how to get/set the Security info of file in NTFS partition?
Your best bet here is looking at the source code of ntfsprogs, and particularly of the ntfsinfo utility, which seems to do what you want.
I'm just guessing but because the security system is so different between NT and Linux (and other Unixes) probably the best format you'll be able to get with full fidelity is the raw binary version of the security descriptor on a file. Anything else would be an inexact translation to POSIX ACLs or classic Unix security.
The format stored on disk will be a self-relative security descriptor (one binary blob), up to 64k. Note that NTFS keeps a single copy of each unique security descriptor in a special $SECURITY file in the root directory; files point back to the shared entry in there. This is done because most of the time all the files in a directory or a tree will all have identical SDs and it's a waste of space to store 5000 copies of the same data. The filesystem driver used to read/update NTFS security would need to take that into account.