Summary: | stage1-x86-2005.1.tar.bz2 - bad symlinks under /etc/runlevels/* | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | catfish <catfish> |
Component: | [OLD] baselayout | Assignee: | Gentoo Release Team <releng> |
Status: | VERIFIED FIXED | ||
Severity: | normal | CC: | alron, jean.regisser, johan, paapaa125, rabbe, rumen, stephane.gautier |
Priority: | High | ||
Version: | 2005.1 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
catfish
2005-08-21 13:07:51 UTC
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. *** |