Created attachment 354088 [details] Screenshot The attached screenshot shows what I see. I tried to oldconfig from 3.8.13 and a new config, both give the same result. Portage 2.1.12.13 (default/linux/amd64/13.0, gcc-4.6.3, glibc-2.15-r3, 3.8.13-gentoo x86_64) ================================================================= System uname: Linux-3.8.13-gentoo-x86_64-Intel-R-_Core-TM-_i7-2600K_CPU_@_3.40GHz-with-gentoo-2.2 KiB Mem: 2055892 total, 1630624 free KiB Swap: 2263820 total, 2263820 free Timestamp of tree: Wed, 24 Jul 2013 12:00:01 +0000 ld GNU ld (GNU Binutils) 2.23.1 app-shells/bash: 4.2_p45 dev-lang/python: 2.7.5, 3.2.5-r1 dev-util/cmake: 2.8.10.2-r2 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.6 sys-devel/binutils: 2.23.1 sys-devel/gcc: 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.7 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -g0 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.3/ext-active/ /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--with-bdeps y --keep-going y -1" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch preserve-libs protect-owned sandbox sfperms sign split-log strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://192.168.1.10/ http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl alsa amd64 berkdb bzip2 cli consolekit cracklib crypt cxx dbus dri fortran gdbm gpm iconv kde minizip mmx modules mp3 mudflap multilib ncurses nls nptl opengl openmp pam pcre policykit qt3support qt4 readline semantic-desktop session sse sse2 ssl symlink tcpd unicode zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="am fil zh af ca cs da de el es et gl hu nb nl pl pt ro ru sk sl sv uk bg cy en eo fo ga he id ku lt lv mk ms nn sw tn zu ja zh_TW en_GB pt_BR ko zh_CN ar en_CA fi kk oc sr tr fa wa nds as be bn bn_BD bn_IN en_US es_AR es_CL es_ES es_MX eu fy fy_NL ga_IE gu gu_IN hi hi_IN is ka kn ml mr nn_NO or pa pa_IN pt_PT rm si sq sv_SE ta ta_LK te th vi ast dz km my om sh ug uz ca@valencia sr@ijekavian sr@ijekavianlatin sr@latin csb hne mai se es_LA fr_CA zh_HK br la no es_CR et_EE sr_CS bo hsb hy mn sr@Latn lb ne bs tg uz@cyrillic xh be_BY brx ca_XV dgo en_ZA gd kok ks ky lo mni nr ns pap ps rw sa_IN sat sd ss st sw_TZ ti ts ve mt ia az me tl ak hy_AM lg nso son ur_PK it fr nb nb_NO hr nan ur tk cs_CZ da_DK de_1901 de_CH en_AU lt_LT pl_PL sa sk_SK th_TH ta_IN tt sco ha mi ven ar_SY el_GR ro_RO ru_RU sl_SI uk_UA vi_VN ar_SY te_IN de_DE es_VE fa_IR fr_FR hu_HU id_ID it_IT ja_JP ka_GE nl_NL sr_BA sr_RS ca_ES fi_FI he_IL jv ru_gold yi eu_ES chr jp bg_BG ko_KR" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-3 php5-4" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" QEMU_SOFTMMU_TARGETS="x86_64" QEMU_USER_TARGETS="x86_64" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" USE_PYTHON="2.7 3.2"
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.
ago... http://www.phoronix.com/scan.php?page=news_item&px=OTk5Mw :)
(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.
