OSDev.org

It would be useful to be able to manipulate ext* disk images purely from userspace, like mtools allows you to do for FAT*. Are there any such tools?

What form of manipulation do you mean? The tools for partitioning disks and creating extx filesystems are userspace programs. (Of course you need the appropriate privileges to manipulate any filesystem.)

Well, I want to be able to build my OS without root permissions, including generating the VM disk image. This is perfectly reasonable; all the inputs and outputs are owned & readable/writeable by me. However, reading & writing to a disk image typically requires mounting the image, which requires root. That can be got around via a suitable /etc/fstab entry marked as user mountable.

Unfortunately, that still doesn't allow you to write to inode 5 (bootloader inode, not actually used by any current OS AFAIK, but it seems a good convention to me, and I intend to use it in my OS), as under Linux you can only write to inode 5 of a mounted filesystem as root.

You can use dd to write to any block of a block device without mounting it.

I'm not sure if building a whole image with it is advisable or at least easily possible, but debugfs can work on an ext2 filesystem image with user permissions.

iansjack wrote:You can use dd to write to any block of a block device without mounting it.

Sure - I have considered having a pre-built crafted image which the file is at a known position and written to with dd. That's not very flexible though, as it basically requires a fixed length file.

Kevin wrote:I'm not sure if building a whole image with it is advisable or at least easily possible, but debugfs can work on an ext2 filesystem image with user permissions.

Yes, looks like debugfs could be used. I had looked into it before, but struggled to work out how to use it to write to inode 5. I don't think you can directly write file contents to an inode number, but you can:

• Use debugfs to link inode 5 to a file in the directory structure
• Mount the fs, write to that file, and unmount
• Use debugfs to unlink inode 5 from the directory structure

I think this is an acceptable solution for now.

Interestingly, e2fsprogs (the project that contains debugfs) also contains a tool called ext2ed, which looked like it had the potential to be what I wanted. Unfortunately, it was originally a university project in 2001 and has barely been maintained since, so I think debugfs is the better option.

I use a tool called genext2fs to build ext2 partitions from source directories. That might fit your use case.

I have developed a tool for exactly what you're asking because I too wanted to write to inode 5. I'm currently writing my VFS layer in Linux (I.e. my VFS layer can be run as a user space Linux program) and I have full write/read/add directories for ext2 etc and it works.

It's not on my GitHub yet, but if you PM I'll send later (not at home now)

I have an old version of the tool up on GitHub here: https://github.com/lazear/ext2util/tree ... 00edb40aa7

I make no promises that any newer commit than that will work, but it should at least enable you to write to inode 5. I started trying to develop my VFS layer after writing the ext2 direct block driver...Not a good idea. Ended up doing it in the proper order.

If there is wide spread interest in this tool, I wouldn't be opposed to going back and fixing it.

madanra wrote:...but you can:

• Use debugfs to link inode 5 to a file in the directory structure
• Mount the fs, write to that file, and unmount
• Use debugfs to unlink inode 5 from the directory structure

I think this is an acceptable solution for now.

Unfortunately I've not been able to get this to work. Linux isn't keen on the resulting filesystem after step 1, any command I try gives an error like "cannot access 'mnt/boot_temp': Structure needs cleaning".

klange wrote:I use a tool called genext2fs to build ext2 partitions from source directories. That might fit your use case.

Thanks, that looks really useful! Solves everything apart from writing to inode 5, and is in Debian/Ubuntu repositories, which is a bonus. It doesn't look to have been worked on since 2007, but if it works...

crunch wrote:I have developed a tool for exactly what you're asking because I too wanted to write to inode 5. I'm currently writing my VFS layer in Linux (I.e. my VFS layer can be run as a user space Linux program) and I have full write/read/add directories for ext2 etc and it works.

It's not on my GitHub yet, but if you PM I'll send later (not at home now)

I have an old version of the tool up on GitHub here: https://github.com/lazear/ext2util/tree ... 00edb40aa7

I make no promises that any newer commit than that will work, but it should at least enable you to write to inode 5. I started trying to develop my VFS layer after writing the ext2 direct block driver...Not a good idea. Ended up doing it in the proper order.

If there is wide spread interest in this tool, I wouldn't be opposed to going back and fixing it.

Thanks, that's working for me!

Also - having your FS drivers able to run from userspace in Linux sounds an excellent idea, I may well copy that

This is exactly what I hate in *nix File system directory tree : it is unique per machine , you need to be root ( or setuid) to alter what a shell sees. Or use a vfs which makes you bound to gnome / KDE or some heavy machinery

madanra wrote:It would be useful to be able to manipulate ext* disk images purely from userspace, like mtools allows you to do for FAT*. Are there any such tools?

You could use a fuse filesystem adapter....

https://github.com/alperakcan/fuse-ext2