[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


> in my initrd's to boot off of all
> kinds of goodies on a make shift nas to make userland a happy world

> 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: