Bear with me, I know this isn't going to sound like a real bug at first glance. On a brand new installation, with NO existing .config to import, if a user goes to customize his kernel in make menuconfig, and removes DRM_I915 support, it goes ahead and disables CONFIG_TMPFS also. This is getting some users in trouble, since tmpfs is pretty important for gentoo systems these days. Steps to reproduce issue: 1. Follow the installation handbook right up until it's time to "make menuconfig" for the first time. 2. Enter "make menuconfig" 3. Search for CONFIG_TMPFS, notice it's enabled, think to yourself "oh good" 4. Go about your business enabling all your proper drivers, and disabling DRM_I915 because you (hypothetically) don't have Intel video 5. (typically omitted step) Search for CONFIG_TMPFS again, notice it's DISABLED, think "hmm that could be bad" 6. Save/exit, build/install/boot this new kernel as part of the rest of your gentoo install 7. Watch a flurry of "mount: wrong fs type, bad option, bad superblock.." messages during your first boot, since the kernel has no tmpfs support In my opinion, this is an upstream bug, and TMPFS should be enabled in defconfig. It's just by lucky chance that DRM_I915 is enabled in defconfig, and it happens to require TMPFS. I don't know the kconfig dep logic really well, but apparently removing DRM_I915 is enough that menuconfig thinks it should disable TMPFS as well. If it's not an upstream bug, then I do believe this should be mentioned in our handbook, so that users make sure they have this option. And BTW I find it a bit scary that this option IS set initially, then gets UNSET by removing an unrelated driver that happens to depend on it. I'm not crazy, this is a real issue, right?
BTW, I don't know how far this issue goes back, but it is happening in 3.6.5 also.
I might be crazy too, but here's my take on it... --- --- --- --- --- Let's see what /TMPFS has to say: Symbol: TMPFS [=y] Type : boolean Prompt: Tmpfs virtual memory file system support (former shm fs) Defined at fs/Kconfig:115 Depends on: SHMEM [=y] Location: -> File systems -> Pseudo filesystems Selected by: DRM_I915 [=y] && HAS_IOMEM [=y] && DRM [=y] && AGP [=y] && AGP_INTEL [=y] Notice the selected by fields, this means that if you select all of these then TMPFS will automatically be selected, because when you select these you will need TMPFS. This was introduced with http://article.gmane.org/gmane.linux.kernel/1100797/match=drm_i915+tmpfs Now the opposite is not necessarily true, if you deselect any of these then TMPFS will only deselect if your current config (and thus the default config) does not contain TMPFS. This is simple to test, you can do `make config` and atttempt to hold ENTER until you come to DRM_I915, then hit n for that entry, then continue to hold enter. grep TMPFS .config # CONFIG_DEVTMPFS is not set # CONFIG_TMPFS is not set Or if we just read the output which tells us where the default config is, we can do something simpler instead: grep TMPFS arch/x86/configs/x86_64_defconfig CONFIG_TMPFS_POSIX_ACL=y Why is this so? The goal of the default config is to provide the minimum necessary to be able to _boot_ for a large enough user base. Does the majority need TMPFS to boot? No, that's why it's not part of the default config. It assumes for the rest that you will configure the kernel as you have chosen for the defaults. Now, what would be the case if TMPFS were enabled? You can try this: 1. Disable DRM_I915. 2. Enable TMPFS. 3. Save, exit and open menuconfig again. 4. Notice that TMPFS is still enabled. 5. Enable DRM_I915. 6. Optional: Save, exit and open menuconfig again. 7. Disable DRM_I915. 8. Notice that TMPFS is still enabled. If TMPFS is enabled by default or by you, DRM_I915 will not toggle it; DRM_I915 will only be toggled to disabled if it's not loaded in as enabled through any form of config file. > Bear with me, I know this isn't going to sound like a real bug at first glance. Something as famous as TMPFS not being a default being a bug wouldn't go under the radar for over a year, you could start a discussion on it upstream but as evidenced it's not part of the default config as it remains a feature and not something explicitly necessary to boot and run base software. > This is getting some users in trouble, since tmpfs is pretty important for gentoo systems these days. This would have raised some awareness if it were the case. Is it really trouble? What particular problem did you experience by having this disabled? Don't Gentoo guides point out TMPFS needs to be enabled to accomplish certain tasks? > In my opinion, this is an upstream bug, and TMPFS should be enabled in defconfig. Does this opinion benefit the majority? I can't find a direct discussion on it, but I would think there's no direct need for it in general. And enabling it if it got disabled would follow as a logical consequence of some warning / error output in a log, or following some guide. > I don't know the kconfig dep logic really well, but apparently removing DRM_I915 is enough that menuconfig thinks it should disable TMPFS as well. The fun thing here is that if you don't remove it on your first menuconfig run it will get written as enaled to your .config such that next time you start menuconfig it will remain enabled. This might have an effect on minimizing the amount of people experiencing this problem, because most people first attempt to continue their long (or quick) install instead of trimming down the kernel. > If it's not an upstream bug, then I do believe this should be mentioned in our handbook, so that users make sure they have this option. But is this a necessary option to have? If you need all the possible features you might need soon, going for the default config of genkernel might be a better idea. > And BTW I find it a bit scary that this option IS set initially It doesn't get set initially, but is shown as enabled as a consequence. > then gets UNSET by removing an unrelated driver that happens to depend on it. The driver depends on it in a hard way, it can't hide or sneak the fact it's using tmpfs, can it? --- --- --- --- --- Don't get me wrong, this is my reasoning as to why it might be like it currently is and I don't want to defend either side. I hope I might have clarified something. I haven't seen an upstream standpoint about this, which is why I'd suggest you that if you really care about this you might want to take this upstream to see what their response is. Please leave an URL of the upstream bug and/or discussion here for reference, thank you...
Wow, what a reply! Most of this is not news to me, but it did help clarify the bit about TMPFS being disabled because the currently loaded .config did NOT contain it, so the DRM_I915 option was the only thing keeping it held in the "on" position. I know that it only happens in this very specific situation, where no .config was loaded, and the user disables I915 before his first save. That is why I spelled out the steps to reproduce so specifically. This is effecting gentoo installs in a real way, not just some feature that some users may user later. tmpfs is required to mount /run, cgroups, and /dev/shm on boot. Thus missing tmpfs support causes sysfs to fail, then udev to fail (actually, not even attempt to start). In fact, this missing TMPFS makes udev fail on stable udev, where the DEVTMPFS option missing is only an issue for unstable (for now). And we do put that in the handbook. So, that's why I think it's an issue that gentoo needs to address, regardless of what upstream thinks. Now, what makes me think it's an unintended upstream bug, is that CONFIG_TMPFS_POSIX_ACL is enabled in defconfig, but CONFIG_TMPFS is not. I don't see any other filesystems where they enable ACL w/o the FS itself. BTW-- upstream defconfig = minimum required for the majority to boot? HAH!
Sorry for any incorrect information there, I'm fairly new. Confirmed, disabling TMPFS allows me to boot into a TTY but disallows OpenRC from doing its work properly, which means that it's not necessary to init into a TTY. Haven't tried with systemd. Yeah, it's not exactly a majority then. Or perhaps it is still intended to be that way, which is why I believe you... :) I'd wonder if there were even reasons to _not_ have TMPFS as a default option, which may be much more interesting to reason about than the reasons to have it as a default option (which are obvious now that you listed them). Would be nice if it were fixed upstream for everyone, else I'd hope our maintainers to consider fixing it.
Will fix this downstream with next kernel release 3.10.7 which we will stabilize; as for upstream, feel free to file it there if you want to.
