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

Re: (re-)boot woes



Martin Wheeler wrote:
> [please cc any reply as not always subscribed to list]
> 
> Problem:
> I just hosed a Toshiba Satellite 1110 laptop (multi-boot: XP and three 
> different kernels of Debian testing - 2.6.8, 2.4.27 & 2.4.26) by trying to 
> add SUSE Linux Enterprise Server 9, which barfed on the re-boot.
> [L 07 07 07 recurring]   My fault; this machine would never have re-booted 
> from an external USB device, anyway.
> 
> Now, any attempt to boot from rescue disk using <whatever>linu[z|x] 
> root=/dev/hda2 results in:
> 
>           unable to mount root fs on unknown-block(0,0)

This looks like an initrd problem.  As in that the kernel needs an
initrd (initial ram disk) with the module drivers to load the root
filesystem.  But these appear not to be getting loaded and so the root
filesystem cannot be mounted.  If using grub it should automatically
detect the initrd.  But if using lilo this needs to be added manually
to the lilo.conf file or be able to see the symlinked files.

> (And I've also got a partition that holds a lot of valuable data that's 
> now showing empty.  This is the real tragedy.  I don't mind blowing away 
> and re-formatting; as long as I can get that data back.  It's the only set 
> of photographs I have of a pilgrimage to Rome and back, being prepared 
> to be put on CD.)

I am sorry for your potential loss.

> Booting form non-invasive CD, I've been able to make bit-for-bit copies of 
> each partition, as well as the whole disk; and readable copies of 
> everything, *except* what used to be in the now-empty partition.

Making bit copies of everything is definitely a good idea.

> Any ideas?  I *really* need some help here.

Unfortunately I don't have the expertise to help other than to ask if
you know the type of filesystem that used to store the data?  There is
a big difference between the popular ext2, ext3, reiserfs and other
systems.  Knowing the type of filesystem may allow someone else to
suggest other ideas.

> Backtracking, I suspect that what happened was that /usr (in its own 
> partition) filled up to 100%; the SUSE install procedures detected this 
> and tried to 'repair' it; and thus scribbled over the first part of the 
> 'following' partition, where all my valuable data being prepared for 
> backup lives/lived.

I doubt that the installer would try to fix a full partition.  But I
don't doubt that it would try to repartition the drive so that
everything would fit.  Ouch.

Bob



Reply to: