Re: The sad demise of an etch.
On Tue, Oct 24, 2006 at 12:46:36PM +0800, Tim Post wrote:
> On Mon, 2006-10-23 at 12:22 -0400, hendrik@topoi.pooq.com wrote:
>
> > RAMDISK: Conplressed image found at block 0
> > input: AT Translated Set 2 keyboard as /calss/input/input0
> > invalid argument format (err=1)
> > VFS: Cannot open root device "304" or unknown-block(3, 4)
> > Pleas append a correct "root=" boot option
> > Kernel panic - not syncing: VFS: Unable to mount root fs on
> > unknown-block(3, 4)
>
> did you do any debugging in linuxrc on your initrd (such as echoing the
> module name and value of $? as each was loaded, in particular anything
> needed to access disks?)
No, not as far as I know. Don't know how to do this, either.
>
> You mentioned a udev upgrade, but not much about the disks / chipset.
The disk is an old IDE drive, bought and installed back when 80G was
considered pretty big.
>
> > I am tempted to pronounce this etch installation dead and reinstall from
> > scratch.
>
> Understandable. You have to take the shortest route to making your phone
> stop ringing, but this would be a cool problem to pronounce fixed .. if
> you can give it just a bit more effort? I'll propose a quick fix to make
> the world happy below.
>
> > I'm also reluctant to do this, becase of Debian's reputation
> > as being the system that never needs to be reinstalled. Sarge, of
> > course, continues to soldier on without any problems at all (except for
> > application obsolescence -- but that's spec)
> >
>
> I think you ran into a bad case of Murphy's law. Can't speculate too
> much without playing with your system which isn't very possible :)
Probably several in a row. After I get it to boot, I'll still have to
worry about getting X back up. And then getting the ctl-alt-f* keys to
work reliably. My guess is that my system has suffered damage from
transitional bugs in the year-long process of upgrading etch -- bugs
which will probably not be present in a new install.
>
> > Or should I do something radical to get current software, such as
> > installing gentoo on the former etch partition?
>
> I've had really good luck using AoE
AoE?
> in my initrd's to boot off of all
> kinds of goodies on a make shift nas to make userland a happy world
nas?
> again, which may plug the crack in the dam for you while you figure this
> one out.
>
> My little nas has a few varaities of Debian, Ubuntu, Fedora as well as
> slack and other stuff. I pieced it together to make a more versatile
> lab.
>
> While this doesn't fix your etch problem, it fixes the problem of people
> being able to work.
They currently have sarge available. If I install an openoffice
from backports, they'll be happy for a while. In any case, their home
directories are on an NFS-mounted file system. Alice accesse hers from
my son's machine, which runs etch reliably. She thinks it's great to
be able to use the same home from different computers.
>
> here's a snip (from memory) from my linuxrc
>
> modprobe e1000
> i=0
> while [ "$?" = 0 ]; do
> ifconfig eth${i} up
> let "i += 1"
> done
>
> modprobe aoe
> echo 1 > /dev/etherd/discover
> sleep 5
>
> .... and later
>
> major=${root%.*}
> minor=${root#*.}
>
> aoeping -s 10 $major $minor
> case "$?" in
> 0)
> (code to continue boot and pivot_root)
> (this means /dev/etherd/ex.x (boot part) is there)
> (continue loading modules and go)
> ;;
> *)
> (endless loop that says AoE bombed)
> (or re-define $root to be the sarge partition)
> ;;
> esac
>
> You'll just need to copy some aoe-tools to the initrd, this assumes the
> AoE network containing the images can be found on eth0, but I brought
> all nics up for future convenience. I'm typing more from memory, if you
> want a copy of my linuxrc I'll send it along when I get back to the
> office this weekend coming.
This is a bit deeper than my current Linux knowledge. It looks like
something I should learn about, though.
>
> pass root=/dev/etherd/eX.Y (aoe major/minor) just as you'd specify
> root=/dev/sda1 (etc). take hd x, y out of grub for that instance.
I specified root=/dev/sda4 on the boot line yesterday. That didn't
work, gave me exactly the same problems. Is there any chance that
telling lilo to boot the etch partition (/dev/sda4) but overriding
root=/dev/sda3 (the sarge partition would work -- or at lest provide
some diagnostic information? (sarge here runs a 2.6.8-2-386 kernel)
> They can have whatever OS they want, you can keep plugging away at
> whatever you want .. everyone is happy :) Maybe you could find an old p4
> with a 40 gig drive to throw at it?
By the way there's no possibility that some of the new stuff in confused
by the primary boot partition /dev/hda4 being *after* the extended
partition /dev/hda2 is there? Windows gets confused easily, but I
wouldn't expect it of Linux.
>
> When you get etch re-stabilized they can come back to the local boot
> partitions. Hate to see you ditch Debian altogether, but understand your
> frustration.
The home-directory NFS server is currently runnin Ubuntu, because the
Debian etch on that machine (an AMD64 with nvidia on the motherboard)
currently crashes randomly while X is being used. Once a month or so I
reboot it to etch, do a reoutine upgrade, and find the crashes are still
present, though they have become less frequent. I've reported that
bug to the bug-tracking system. It took a lot of my time when I should
perhaps have been worrying about the ailing etch on the client machine.
It's entirely possible that a bad shutdown has made things go from bad
to worse.
-- hendrik
>
> HTH,
> Tim
>
> >
> > -- hendrik
> >
> >
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: