I'd appreciate VERY much if that folder and subfolder were writeable.
So I could add a module and load it with modprobe.
For example, 2007.0 doesn't have the atl1.ko (ethernet driver), so now to make it work I:
emerge a kernel (same version of the livecd and same arch), compile (or cross-compile in my case), copy the module in a usb stick subfolder, mount that subfolder under /lib/modules so that modprobe works.
So you can't tell me it's a matter of security because it's a matter of usability.
I'm here if you need more information.
It already should be writeable. If it's not, that's a function of the kernel's implementation of ramfs/rootfs, and there's likely not anything we can do about it.
It's not ramfs, indeed.
Because /lib32 and /lib64 are symlinks to /mnt/livecd/lib32-64
So it's normal that I can't write in the CD media.
What I personally think is that /lib should be copied into ramfs
Okay, you said ramfs. What you meant was tmpfs. That's something completely different.
Exactly, tmpfs: sorry, I was confused.
tmpfs like it is /lib/firmware : at least, it should be /lib/modules :)
I think I'm gonna WONTFIX this one for now. You can always copy the module to /tmp and use insmod to load it from there.
It's not done for a very simple reason, RAM usage. The more things we put into some kind of RAM-based file-system, the more memory we eat up and the more we increase the RAM requirements to even boot the CD. We're already at >256MB for the LiveCD, which isn't much by modern standards, but the LiveCD is usable on machines as old as Pentium Pro... ;]
Putting the modules into RAM would occupy an additional 25MB of RAM (using the 2008.0 in-progress builds as my data set) for just the tmpfs data.
The problem is that insmod isn't as advanced as modprobe and it can't ignore version flags.
About the ram: couldn't that be done only with "docache" or some other option?
Or can you think of another way?
Mine has a disvantage: /lib/modules is overwritten with my module, and is not very sane to mount something in a non-empty folder...
I had forgotten: I can't actually compile that module in 2.6.19 because it wasn't in the kernel tree at the time.
So, I *need* to ignore the module build-in kernel version.
Just wait, because... well... there's nothing going to happen before 2008.0 is released, anyway... so there's no point in continuing this discussion here... we've marked it WONTFIX and that's not going to change... Sorry...