The reverse of #68653. I don't believe I have the option of configuring ramfs out of my kernel. I CAN (and DO) configure tmpfs out of my kernel, because I don't need its additional functionality (such as extented attributes) and have swap disabled anyway. ramfs works just fine -- or did, anyway, until baselayout decided to hard-code tmpfs in /sbin/rc! With tmpfs configured out of the kernel, unfortunately, /proc/filesystems still lists it. Further, an attempt to mount -t tmpfs doesn't fail. It completes without error. However, attempts to access the mountdir after that result in not a directory errors. Suggestion: Handle /dev as $svcdir is already handled with $svcfstype. Put a new var in /etc/conf.d/rc called $devfstype (or $udevfstype), and default it to tmpfs, but allow ramfs as another option. Reproducible: Always Steps to Reproduce: Boot with /sbin/rc hard coded to mount /dev as tmpfs, with no tmpfs in the kernel. Actual Results: The mount "succeeds" with no error. However, attempts to access /dev after that fail with not-a-dir. Boot fails. Expected Results: /sbin/rc should look to /etc/conf.d/rc for a $udevfstype option, and honor it, just as it does for $svcdir. Alternatively, it should test the tmpfs mount and if attempts to access /dev result in not-a-dir errors, it should unmount it and fall back to ramfs. A successful boot should not depend on the kernel optional tmpfs. emerge info shouldn't be necessary. However, I'll attach it. I'm running kernel 2.6.10-rc1 from kernel.org. baselayout-1.11.4 Portage 2.0.51-r2 (default-linux/amd64/2004.3/lib64, gcc-3.4.2, glibc-2.3.4.20040808-r1, 2.6.10-rc1 x86_64) ================================================================= System uname: 2.6.10-rc1 x86_64 AMD Opteron(tm) Processor 242
Created attachment 42658 [details] emerge info output
This thread from the forums seems to be related: http://forums.gentoo.org/viewtopic.php?t=242001&highlight=ext3+fsck&sid=62950d8ce05f2be9eb061eea100895fa Bug 68795 also seems related, but different. It's devfs instead of udev selection related, while this is ramfs vs tmpfs. However, replacing /sbin/rc with an older one would work just as well as it did there, altho I fixed it here by booting my known working alternate root and eventually diffing /sbin/rc and finding it was ramfs vs tmpfs, then confirming it by doing the edit and rebooting to my regular root with the edited /sbin/rc.
the reason ramfs is a bad idea vs tmpfs is that it has no size limitations ... try this on your box (but make sure you dont have anything running you care about :P) dd if=/dev/zero of=/dev/blalhalhal then, when your box crashes when it's out of ram, you'll see why tmpfs is the saner default :) i'll add an option to allow users to choose, but the default will remain tmpfs
# UDEV OPTION: # FS type that should be used for /dev. Currently just tmpfs and # ramfs are supported. The downside of tmpfs is that you have to # enable support for it in the kernel. The downside of ramfs is # that it has no size restrictions. RC_DEVICE_FS="tmpfs" look for it in 1.11.5+
Thank you. Looks like a perfect solution to me, and the option description looks good too. I haven't checked stability status, but particularly if a ramfs default version remains latest stable, a postinst message indicating the change to tmpfs and where the config option is might be wise, and keep a few more folks from running into the sort of followon problems outlined in this family of bugs. Looking forward to the 1.11.5+!
