Re: The sad demise of an etch.
On Mon, Oct 23, 2006 at 08:46:52PM -0700, Andrew Sackville-West wrote:
> hendrik@topoi.pooq.com wrote:
> > I run a dual-boot Debian system -- one partition is sarge; the other is
> > etch. The idea was that users would have a stable platform available if
> > they wished, for mission-critical work, but have access to (relatively)
> > recent software for the proce of a reboot.
> >
> > This etch had been ailing for quite a long while now. The xfree ->
> > xorg upgrade went flawlessly, but a few weeks after that, after a
> > routine general upgrade (which upgraded xorg) X ceased to function
> > properly. It would crash when switching virtual consoles,
> > unpredictably. Everything fine as long as no one switched virtual
> > consoles, of course. Switching to a text console would work (before the
> > crash) but switching between X consoles or from text to an X console was
> > fraught with peril. There was a suspicion that the problem was set
> > up by logging out from X and switching to another console before the
> > original one had manages to present a new login screen -- then switching
> > back to the original X later would present you with a dead machine.
> > This suspicion, however, was nevre tested consistently.
and it's too late now.
> >
> > The system was still somewhat usable. I occasionally upgraded it in
> > case this was a bug that would be fixed. IN any case, we still had
> > sarge as a fall-back in case of real trouble.
> >
> > sometime later, etch could no longer start X successfully -- it ould
> > fail, unable to access the AGP device. The X log made it look as if
> > it was the actual AGP interface on the motherboard that was
> > inaccessible, not the ATI card I had plugged into it.
> >
> > Upgradein udev seemed to cure this problem, but now X would
> > crash during startup.
> >
> > Last Friday I performed another upgrade. Now etch won't boot at
> > all:
> >
> > 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)
>
> what is your boot manager?
lilo
> did its configuration get corrupted?
Not as far as I know. But I'll try rerunning lilo from the sarge
system. Both etch and sarge have compatible lilo.conf files.
> or maybe
> you've got a bad block?
Hope not. If so I'll have do discard the hard disk *fast*.
> I've seen this before on my system and can't
> remember what it was.
>
> does it hang there or drop you to busybox?
It hangs, unresponsive. What's busybox?
>
> >
> >
> > I am tempted to pronounce this etch installation dead and reinstall from
> > scratch. 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)
> >
> > Or should I do something radical to get current software, such as
> > installing gentoo on the former etch partition?
>
> ack! bite your tongue! ;-0
No... that hurts.
The argument for having gentoo is that it really comes close to
the *latest* software, and is seems to be free of the version skews
imposed by package construction using different versions of, say, the C
and C++ run-times. On the other hand, installation and upgrading take
inordinately long, and I will no longer have the graceful handover from
testing to stable, after which the partition containing the former
stable system is upgraded to new testing.
Oh yes, gentoo is reported to have some stability problems, which is
unlikely to be worse than what's happening to me with etch now.
-- hendrik
Reply to: