I had the idea of dynamically detecting the root files system type and mounting it, instead of forcing the user to compile his specific filesystem into the kernel. It goes on the lines of : * copy filesystem modules specified in MODULES_FS variable , to the initramfs. * REAL_ROOT_TYPE = `vol_id -t ${REAL_ROOT}` * mount -t ${REAL_ROOT_TYPE} ....... etc... As you can see it uses vol_id from udev and needs no extra deps, except the filesystem modules. I am actually using this right now and everything works fine.
Created attachment 76394 [details, diff] patch to allow root filesystem to be module Here is the patch to do what I described. I have added the filesystems I know can be used as root filesystems on x86 ( thus x86/modules_load ) .. dunno about the rest of the archs. Maybe you need to minimize the list of supported filesystems down to the number officially supported by gentoo-sources, although if the modules don't exist genkernel skips harmlessly.
Well, the problem with this is that all the modules in the config are added to the initramfs so IMO this really makes no difference either way: you might as well have those compiled straight into the kernel, you still end up using the same (double, really) space to store the code so I don't see the advantage here. I think I misread your email thinking the "vol_id" would be a udev-sided for fix the blkid things we have now with e2fsprogs :P
ok, I can modify this so that the genkernel user can specify what filesystem module gets copied to the initramfs.. Tell me what's wrong with the blkid thing I might be able to fix it. I know vol_id can read the volume labels.
I am also using a modular IDE kernel, and genkernel copies the modules to the initramfs.
I think what Tim was getting at is that by having them as a module, they exist twice, once in the initramfs and once on the actual filesystem. Having them in the kernel itself only requires half the space. This isn't so much of a big deal on an installed system, but on our release media, every little bit of space counts, especially on architectures like sparc. What quantifiable advantages are there in making the root filesystem a module?
The idea came when I started using one kernel with several installed systems. I wanted to try out different filesystems without recompiling the kernel. Having all in was making the kernel too big. I honestly don't know if a monolithic kernel is bad. Let's take the example that made me do this patch: *my kernel had ext2 only. *root filesystem is ext3. *initramfs generated using genkernel mounts root filesystem as ext2, remounting it as ext3 after the system starts doesn't work properly. If I turn on unsupported features in ext3 it won't mount as ext2 ( acl for example) *If I have all filesystems as modules and this patch, everything works without modification. The main application I thought for this was: *In the gentoo install guide, we could allow the user to have any root filesystem if he uses genkernel to generate his kernel/initramfs. *people installing from the livecd can use livecd's kernel directly with any root filesystem without the need for a kernel recompile. All these arguments may seem weak, but it all translates to more freedom and choice, without breakage. Besides as I said we can make it optional. The final verdict is yours. Whatever the decision I'd like you to point me in the right direction as I want to help.
plasmaroo: what do you think? I can see this being useful...
Ok, so this probably would be quite useful. I'm tagging it genkernel-4 so the feature doesn't get lost in the transition if we were to add it to gk-3.
I've added a modified version of this to CVS for genkernel 3.x and it'll show up in the next version. Tim, what would you like me to do with this bug once I release a working gk-3 with this?
(In reply to comment #9) > I've added a modified version of this to CVS for genkernel 3.x and it'll show > up in the next version. Eh, isn't the vol_id thing used in the patch something that is part of udev (which we've now scrapped) so it'll die horribly now? > Tim, what would you like me to do with this bug once I release a working gk-3 > with this? Keep it open I suppose; we need to implement it in gk4.
GRRR... you're right...
OK. I reverted the vol_id/mount, but left everything else alone. If anyone has a good way to check what type of filesystem root is, then we're set. This *may* work with just the modules in place, but I wouldn't *count* on it.
Hi all it's me again. It's good to see genkernel shaping up. I know I haven't been a good citizen, as I didn't share my modifications to get genkernel to work properly with unionfs. I released my livecd based on the modifications some time ago. I think removing udev from the initramfs is a good thing, but how are you going to create the /dev nodes when extra modules get loaded ? Anyway I have a suggestion for a vol_id replacement which is disktype. It supports way too many filesystems, and is in portage. The glibc compiled binary is 65Kb, not sure how big it would be if statically compiled, or it is compiled against klibc. The downside being we would have to write a small patch to get it to output in a usable format. Currently it does this : disktype /dev/hda1 --- /dev/hda1 Block device, size 101.9 MiB (106896384 bytes) Ext2 file system Volume name "BOOT" UUID 402FED36-BD54-488A-9FBC-C4DEFA7EAE0B (DCE, v4) Volume size 101.9 MiB (106893312 bytes, 104388 blocks of 1 KiB) Something useful would be : disktype -f /dev/hda1 FS=ext2 What do you think ?
(In reply to comment #13) > Anyway I have a suggestion for a vol_id replacement which is disktype. > It supports way too many filesystems, and is in portage. The glibc > compiled binary is 65Kb, not sure how big it would be if statically > compiled, or it is compiled against klibc. We've dumped klibc too. So it'll either have to be static and optional (read: something like a --disktype flag) or we need it to be teeny -- meaning, you could compile it into an applet into busybox. > The downside being we would have to write a small patch to get it to > output in a usable format. Well, getting it into busybox (speaking of which, does busybox already have functionality of some sort like this? If not I'm sure upstream will find it useful) will need some work so you might as well change the output while you're at it if you plan on doing that.
http://www.uclibc.org/lists/busybox/2005-July/014928.html Well reading around on the matter, I see it wasn't a big deal after all. The linuxrc script could try mounting the root filesystem with all available filesystems. for i in /lib/modules/`uname -r`/kernel/fs/*.ko ; do modprobe `basename $i .ko` ; mount -t `basename $i .ko` <rootdev> <mountpoint> ; done You get the idea. What do you think?
(In reply to comment #15) > You get the idea. What do you think? It'll work but this is exactly more or less what the kernel does anyway if the filesystems are compiled into the kernel. So I don't see any advantage gained by this method (in fact, it'll probably cause more problems).
You're right. But then again what I meant to say is we can do it in a script. This way we can for example prioritize ext3 over ext2. If ext3 module is not availale we can still mount it as ext2. Any fancy filesystems built as modules can be tried this way, while the if we leave it to the kernel, it won't try these filesystems ( since they are not built into the kernel).
(In reply to comment #17) > You're right. But then again what I meant to say is we can do it in a script. > This way we can for example prioritize ext3 over ext2. If ext3 module is not > availale we can still mount it as ext2. Any fancy filesystems built as modules > can be tried this way, while the if we leave it to the kernel, it won't try > these filesystems ( since they are not built into the kernel). Sure, but all our configs build the filesystems right into the kernel so that's a non-issue; neither is prioritization; if the kernel fails to mount something with one filesystem it'll try with another... Chris, do you see any point in this one?
I am tired right now after a long day's work. I seem to recall the kernel insisting on mounting my ext3 partition as ext2 even when ext3 is builtin the kernel. Maybe I am hallucinating. I will think of a useful use scenario for this when I wake up :)
(In reply to comment #19) > I am tired right now after a long day's work. > I seem to recall the kernel insisting on mounting my ext3 partition as ext2 > even when ext3 is builtin the kernel. Maybe I am hallucinating. That was an e2fsprogs bug, not the kernel. > I will think of a useful use scenario for this when I wake up :) I'm still confused on what would need to be done more than adding the FS stuff to genkernel to cause it to pull th emodules into the initrd. After that, the kernel should take care of it fine.
I am going to guess that this is FIXED since I haven't heard anything back in quite some time. If someone wants to test this and ensure that it works for your usage, feel free to reopen this bug, or file a new one, if this isn't truly fixed.
