I checked and could not find this mentioed previously in the bug system. I checked under combinations of 2005.1,init,link,stage1. I recently did a stage1 install on an Intel STL2 system with dual Intel Intel P3 Coppermine CPUs. I was checking some things on the hard drive when I did an 'ls -l' on /etc/runlevels/default and noticed some ad symlinks on local and netmount. I checked /etc/runlevels/boot and found the same problem -- everything linked back to 'tmp/stage1root//etc/init.d/' instead of '/etc/init.d' I ran through 'rc-update del [script name] [boot|default|local]' followed by an 'rc-update add [script name] [boot|default|local]' to fix the symlinks. The symlinks did not effect a successful reboot of the machine. I was doing the install remotely so I was not able to see console output but it *seemed* to reboot faster after I fixed the above. I re-emerged base-layout but it did not help. I started to search where the problem may have come from and found it in the stage1 tarball. I *think* I downloaded it from ibiblio IIRC. I double checked the stage1 tar file and here is the output: [snip] drwxr-xr-x root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/ lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/bootmisc -> /tmp/stage1root//etc/init.d/bootmisc lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/checkroot -> /tmp/stage1root//etc/init.d/checkroot lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/consolefont -> /tmp/stage1root//etc/init.d/consolefont lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/keymaps -> /tmp/stage1root//etc/init.d/keymaps lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/modules -> /tmp/stage1root//etc/init.d/modules lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/rmnologin -> /tmp/stage1root//etc/init.d/rmnologin lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/urandom -> /tmp/stage1root//etc/init.d/urandom lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/checkfs -> /tmp/stage1root//etc/init.d/checkfs lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/clock -> /tmp/stage1root//etc/init.d/clock lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/domainname -> /tmp/stage1root//etc/init.d/domainname lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/hostname -> /tmp/stage1root//etc/init.d/hostname lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/localmount -> /tmp/stage1root//etc/init.d/localmount lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/net.lo -> /tmp/stage1root//etc/init.d/net.lo drwxr-xr-x root/root 0 2005-07-26 13:12:38 ./etc/runlevels/default/ lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/default/local -> /tmp/stage1root//etc/init.d/local lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/default/netmount -> /tmp/stage1root//etc/init.d/netmount drwxr-xr-x root/root 0 2005-07-26 13:12:38 ./etc/runlevels/nonetwork/ lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/nonetwork/local -> /tmp/stage1root//etc/init.d/local drwxr-xr-x root/root 0 2005-07-26 13:12:38 ./etc/runlevels/single/ [snip] Reproducible: Always Steps to Reproduce: 1. download stage1-x86-2005.1.tar.bz2 [ I just rechecked using ibiblio ] 2. run 'tar -tvjf stage1-x86-2005.1.tar.bz2 | grep runlevels' 3. notice target of symlink Actual Results: drwxr-xr-x root/root 0 2005-07-26 13:12:38 ./etc/runlevels/ drwxr-xr-x root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/ lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/bootmisc -> /tmp/stage1root//etc/init.d/bootmisc lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/checkroot -> /tmp/stage1root//etc/init.d/checkroot lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/consolefont -> /tmp/stage1root//etc/init.d/consolefont lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/keymaps -> /tmp/stage1root//etc/init.d/keymaps lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/modules -> /tmp/stage1root//etc/init.d/modules lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/rmnologin -> /tmp/stage1root//etc/init.d/rmnologin lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/urandom -> /tmp/stage1root//etc/init.d/urandom lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/checkfs -> /tmp/stage1root//etc/init.d/checkfs lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/clock -> /tmp/stage1root//etc/init.d/clock lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/domainname -> /tmp/stage1root//etc/init.d/domainname lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/hostname -> /tmp/stage1root//etc/init.d/hostname lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/localmount -> /tmp/stage1root//etc/init.d/localmount lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/boot/net.lo -> /tmp/stage1root//etc/init.d/net.lo drwxr-xr-x root/root 0 2005-07-26 13:12:38 ./etc/runlevels/default/ lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/default/local -> /tmp/stage1root//etc/init.d/local lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/default/netmount -> /tmp/stage1root//etc/init.d/netmount drwxr-xr-x root/root 0 2005-07-26 13:12:38 ./etc/runlevels/nonetwork/ lrwxrwxrwx root/root 0 2005-07-26 13:12:38 ./etc/runlevels/nonetwork/local -> /tmp/stage1root//etc/init.d/local drwxr-xr-x root/root 0 2005-07-26 13:12:38 ./etc/runlevels/single/ Expected Results: /etc/runlevel/ scripts should point to the local /etc/init.d/ directory
After seeing this bug, I asked people in #gentoo with a fresh install of 2005.1. Looks like this affects stage3 as well. Only people with upgraded baselayouts (to ~arch versions?) don't have it. Roger
So we're thinking this is a baselayout bug, then? If it is something we can fix easily, then a rev-bump of stable baselayout should fix it.
yeah, bug in baselayout pkg_postinst
revbumped stable/unstable to fix this
forgot to close
*** Bug 106128 has been marked as a duplicate of this bug. ***
*** Bug 106656 has been marked as a duplicate of this bug. ***
OK... it looks like emerging the new baselayout versions does not fix this bug... Anyway, I'm going to reopen this and reassign it until we get media out with fixed stages.
<note_to_self>carpaski mentions that bug 103275 still affects users as baselayout doesn't fix the stage tarballs. This leaves the symlinks invalid after remerging baselayout</note_to_self>
*** Bug 108006 has been marked as a duplicate of this bug. ***
This is fixed with the 2005.1-r1 release media.
*** Bug 129730 has been marked as a duplicate of this bug. ***
*** Bug 133607 has been marked as a duplicate of this bug. ***
Well, how do I fix this once it has already happened? It's almost a year since I installed my Gentoo system, and reinstall is not an option.
Assume I remove all faulty symlinks, and recreate them pointing to the right script in /etc/init.d If this will have any funny side effects, please tell quickly.
That's exactly what you need to do.
*** Bug 136033 has been marked as a duplicate of this bug. ***
Today I discoverd this at all of my machines so I did this quick hack: ,--<./repairRC>-- | #!/bin/sh | | LINK=$1 | FILE=/etc/init.d/$(basename $1) | DIR=$(dirname $1) | | echo $LINK => FILE | | if [ -f $FILE ]; then | rm $LINK && ln -s $FILE $DIR | fi `-- # find /etc/runlevels/ -type l -lname "/tmp/*" -exec repairRC {} \;
I think this bug has to be reopened: I got the same problem on 3 of 6 of our machines, except these were running fine before. Now they won't boot because most of the enties in /etc/runlevels/boot point to enties in /tmp/stage1root/... The machines hasn't been restarted for about 3 months, so I can't say what package broke them. I checked the emerge.log's, and about 300 packages has been upgraded since the last restart. After re-creating the symlinks, all machines started again.
No. That has nothing to do with the stages. Though something *else* might have given the same results, it is *not* the same bug. Unless you just installed using 2006.0 stages and got the *exact* same results, it is a different bug and needs to be treated as such. Thanks...
Has the cause of the broken stage-file been discovered? I still think this is the same bug. The same bug that caused the 2005.1 stage-file to be broken. And unless we find out what caused the stage-file and my systems, to break, it will likely happen again... From what I can see in the comments to this bug, we only know what to do when it happens, and that it happened when building stage1-x86-2005.1.tar.bz2.
The original bug was likely caused by catalyst. Once the stage is built and tar'd up, catalyst is out of the picture. If it occurs again, it is *not* the same bug.
OK, I'll create a new bug for this.
Are you sure that when it broke the 2nd time, they were pointing to /tmp/stage1root/some/path?
Yes, I'm absolutely sure of that. That's why I found this bug, I searched for stage1 and runlevels.
*** Bug 144969 has been marked as a duplicate of this bug. ***