Summary: | =sys-kernel/gentoo-sources-3.9.11-r1 - init-early.sh used greatest stack depth | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | bkohler, bobbykent32 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 477220, 477976 | ||
Attachments: |
Screenshot
Working 3.9.11-r1 kernel config for vbox 4.2.14 amd64 VM config |
Description
Agostino Sarubbo
![]() CONFIG_TMPFS=Y, CONFIG_DEVTMPFS=Y or CONFIG_DEVTMPFS_MOUNT=Y missing? Considering nobody else filed this yet, I guess it'll be that problem. If you still experience this, please post your config so mpagano or someone else can look further into this; but after all, I'm guessing it is a consequence of one of the above config variables missing because the CONFIG_DEVTMPFS_MOUNT suggestion has been in the #gentoo topic for quite some time. Report of this fix: https://forums.gentoo.org/viewtopic-t-879347-start-0.html If that fixed it, please mark the bug invalid and unblock stabilization; thanks. Created attachment 354246 [details]
Working 3.9.11-r1 kernel config for vbox 4.2.14 amd64 VM
Tested 3.9.11-r1 in a 64-bit VBox VM to see whether the issue was reproducible on my system. The config (attached) started as a working 3.7.10 config, that I ran make menuconfig against and saved without any further changes. No issues on booting to the resulting kernel via kexec or grub.
Note that CONFIG_DEVTMPFS_MOUNT is only a workaround for the real problem of missing /dev/{console,null} on rootfs. A properly installed gentoo will have these device nodes existing on rootfs before init & udev start, so there is no requirement for CONFIG_DEVTMPFS_MOUNT. Created attachment 354248 [details] config (In reply to Tom Wijsman (TomWij) from comment #1) > CONFIG_TMPFS=Y, CONFIG_DEVTMPFS=Y or CONFIG_DEVTMPFS_MOUNT=Y missing? vbp linux # grep TMPFS .config CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_TMPFS_XATTR=y The problem happen for me only on the vbox vm. (In reply to Mike Pagano from comment #5) > ago... > > http://www.phoronix.com/scan.php?page=news_item&px=OTk5Mw > > :) ok but this is a regression :) (In reply to Mike Pagano from comment #5) > ago... > > http://www.phoronix.com/scan.php?page=news_item&px=OTk5Mw > > :) It's a bit of a shame that known the email leading to this article is so widely known, yet the outcome of the thread is not: http://www.gossamer-threads.com/lists/linux/kernel/1439152?do=post_view_threaded vboxdrv is not now, nor appears to have ever been, marked as TAINT_CRAP by upstream. It's unlikely that vboxdrv would be the cause of ago's issue as it does not run in a guest vm. Modified the working config attached earlier to include .config: # echo "#.config" ; zgrep -i tmpfs /proc/config.gz ; \ mkdir /tmp/root ; mount --bind / /tmp/root ; echo ; \ echo "#/dev" ; ls -l /tmp/root/dev/{console,null,zero} ; echo ; \ echo "#uname" ; uname -rsm #.config CONFIG_DEVTMPFS=y # CONFIG_DEVTMPFS_MOUNT is not set CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_TMPFS_XATTR=y mkdir: cannot create directory '/tmp/root': File exists #/dev crw------- 1 root root 5, 1 Jul 29 12:43 /tmp/root/dev/console crw-rw-rw- 1 root root 1, 3 Jan 23 2013 /tmp/root/dev/null crw-rw-rw- 1 root root 1, 5 Jan 23 2013 /tmp/root/dev/zero #uname Linux 3.9.11-gentoo-r1 x86_64 ago, could it be that your vm was created with a "bad" Stage 3? http://forums.gentoo.org/viewtopic-t-880149.html (In reply to Agostino Sarubbo from comment #4) > Created attachment 354248 [details] > config > > (In reply to Tom Wijsman (TomWij) from comment #1) > > CONFIG_TMPFS=Y, CONFIG_DEVTMPFS=Y or CONFIG_DEVTMPFS_MOUNT=Y missing? > > vbp linux # grep TMPFS .config > CONFIG_DEVTMPFS=y > CONFIG_DEVTMPFS_MOUNT=y > CONFIG_TMPFS=y > CONFIG_TMPFS_POSIX_ACL=y > CONFIG_TMPFS_XATTR=y > > The problem happen for me only on the vbox vm. CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y These are a problem. I've done some more testing with this. I still cannot reproduce with a normal stock install-- virtualbox-4.2.16 host install-amd64-minimal-20130613 stage3-amd64-20130724 gentoo-sources-3.9.11-r1 "make menuconfig" to add CONFIG_DEVTMPFS, nothing more build, install, boot via grub:0 I still believe there is a problem with the reporter's on-disk /dev. I've done a few tests making sure I set DEVTMPFS_MOUNT=n (so that the system boot depends on actual on-disk /dev contents), I notice: --My setup no longer depends on /dev/{console,null,zero}. I can remove these from the on-disk /dev, and while I get a few warnings from early openrc services, it boots fine --My setup DOES seem to depend on at least some of /dev/tty*. If I remove just tty0, openrc seems to fail but it drops me to a root login shell w/ read-only rootfs. If I delete all of /dev/tty*, I get a result identical to Agostino's attached screenshot. 3.10.3 is fine here Can you boot your working kernel, and bindmount rootfs somewhere like "mount -o bind / /mnt/bindroot" then attach the output of "ls -l /mnt/bindroot/dev"? Ping, ago, can you check for 1) a bad stage3 as per Comment 7. 2) how the SYSFS config variables are set as per Comment 8. 3) the troubleshooting steps as per Comment 11. If you consider this a show stopper (I haven't seen other reports so far) we can opt to stabilize one of the next 3.10 releases instead; since that is going to be a long term branch [1] we can ride along it for some time (eg. stabilize 3.10.6, 3.10.12, ...) ensuring some stability and compatibility. Doing a bisect is still an option, but I'm not sure whether it really is worth going through; if the long term branches work, and this is only present in 3.9 or so, we don't really gain anything by trying to fix this I think. Another option which we can do is to scan the commit log for relevant fixes, but a better idea of the actual cause would first be needed for that; unless the author of the commit was kind enough to include the greatest stack depth error. Thank you Ben and Bob for helping on this bug. [1]: http://www.kroah.com/log/blog/2013/08/04/longterm-kernel-3-dot-10/ We plan to drop this kernel as soon as a newer kernel is stabilized on HPPA. |