Bug 144969 – System upgrade caused broke /etc/runlevels symlinks

• Product: Gentoo Linux
• Status: RESOLVED DUPLICATE

[Description Johan Ymerson 2006-08-24 06:21:49 UTC]

I just upgraded all packages on 6 of our machines (emerge --update --deep --newuse world). Last time I did that was in june.
After the upgrade 3 machines didn't start. After some investigation I found out that most of the symlinks under /etc/runlevels had been replaced by broken ones, like:
./etc/runlevels/boot/modules -> /tmp/stage1root//etc/init.d/modules

After replacing these broken symlinks, the machines started again.

emerge --info from one of the affected machines:
Portage 2.1-r2 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.17-gent
oo-r4 i686)
=================================================================
System uname: 2.6.17-gentoo-r4 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz
Gentoo Base System version 1.12.4
app-admin/eselect-compiler: [Not Present]
dev-lang/python:     2.3.5-r2, 2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r3
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=i686"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-O2 -march=i686"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://devsrv.transmode.se/portage/distfiles http://gentoo.osuos
l.org/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress 
--force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/d
istfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://devsrv.transmode.se/gentoo-portage"
USE="x86 alsa apache2 apm avi berkdb bitmap-fonts cli crypt cups dlloader dri ed
s emacs emboss encode foomaticdb fortran gdbm gif gpm gtk2 imlib ipv6 isdnlog jp
eg libg++ libwww mikmod motif mp3 ncurses nls nptl opengl oss pam pcre pdflib pe
rl png pppd python qt3 qt4 quicktime readline reflection session spell spl ssl t
cpd truetype truetype-fonts type1-fonts udev unicode usb xml xmms xorg xv zlib e
libc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev kernel
_linux userland_GNU video_cards_apm video_cards_ark video_cards_ati video_cards_
chips video_cards_cirrus video_cards_cyrix video_cards_dummy video_cards_fbdev v
ideo_cards_glint video_cards_i128 video_cards_i740 video_cards_i810 video_cards_
imstt video_cards_mga video_cards_neomagic video_cards_nsc video_cards_nv video_
cards_rendition video_cards_s3 video_cards_s3virge video_cards_savage video_card
s_siliconmotion video_cards_sis video_cards_sisusb video_cards_tdfx video_cards_
tga video_cards_trident video_cards_tseng video_cards_v4l video_cards_vesa video
_cards_vga video_cards_via video_cards_vmware video_cards_voodoo"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGU
AS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

[Comment 1 SpanKY 2006-08-24 20:18:32 UTC]

*** This bug has been marked as a duplicate of 103275 ***

[Comment 2 Johan Ymerson 2006-08-24 21:51:59 UTC]

According to bug #144969, this is not the same bug. I tried to report this under bug #144969 first, but they told me this is different bug.

[Comment 3 Chris Gianelloni (RETIRED) 2006-08-25 11:59:55 UTC]

I had this guy file a new bug because he claims that it happened during a world update.  However, seeing that it was pointing to the /tmp/stage1root directory, I don't see how this could be possible, so it's defintiely a DUPE.  After all, there is no /tmp/stage1root on a normal system, nor would any packages like baselayout even *try* to use such a directory, since it is a catalyst-only thing.

[Comment 4 SpanKY 2006-08-25 22:19:06 UTC]

older baselayouts would have ignored the actual symlink which is why it would have taken so long to notice

[Comment 5 Johan Ymerson 2006-08-26 01:34:40 UTC]

OK, that makes sense, but the systems was unbootable since most of the boot runlevel scripts didn't execute. I think I would have noticed that before...

I do not even have catalyst installed. I have checked the stage-file I used when I installed these machines, and all symlinks are OK on them (two was installed with stage3-i686-2005.0, the last one was installed with stage3-i686-2006.0).