gparted: now initramfs unpack failed
John Stumbles
did with gparted run from a knoppix boot disk. There was quite a bit of
juggling around to do since there were other partitions that had to be
resized to make room and on one try gparted reported an error but didn't
say what(!) and froze, and I had to reboot to run it again.
On trying to reboot off the hdd I found the bios had forgotten what I'd
told it about which devices to boot from (which is a bit worrying in
itself) and when I did get it to boot from the hdd with the os on I got
the grub menu but when I selected the instalaltion to boot I got:
Loading Linux 2.6.32-5-amd64 ...
Loading initial ramdisk ...
[ ......] Initramfs unpacking failed: no cpio magic
[ ......] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Booting back off the knoppix disk I can see my system partition and the
others I had to move and resize.
fsck.ext3 says they're all clean, and I can mount them.
sda6, which is normally mounted as /, has a boot/ directory with
System.map-2.6.32-5-amd64,
config-<ditto>,
initrd.img-... and
vmlinuz-...,
and a grub/ dir with lots of files in it, including a grub.cfg.
grub.cfg has an entry for the installation I wish to boot, like (this is
copied by hand so I'm not including all of it)
menuentry 'Debian GNU/Linux.....' --class debian --class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(hd0,msdos6)'
search --no-floppy --fs-uuid --set 4ecd06a3-17...(etc hex stuff)...
echo 'Loading Linux...'
linux /boot/vmlinuz-2.6.... root=UUID=4ecd06..(etc hex as above)... ro quiet
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img-2.6....
}
I can see where my "Loading Linux 2.6.32-5-amd64 ..." and
"Loading initial ramdisk ... messages come from.
I'm wondering if the UUID of the partition changed when gparted resized it and,
if so,
(a) how do I find what it is now (if the system were running I'd look
in /dev/disk/by-uuid but are the UUIDs reported by knoppix the same as I'd
get from my Debian system?), and
(b) can I just edit my grub.cfg and change to the new value? (I could try
anyway but it would be nice to know if I'm on the right track or if I'd
just be paddling myself further up the you-know-what creek :-))
--
John Stumbles
I'd rather have a full bottle in front of me
Than a full-frontal lobotomy
Richard Kettlewell
> On trying to reboot off the hdd I found the bios had forgotten what I'd
> told it about which devices to boot from (which is a bit worrying in
> itself) and when I did get it to boot from the hdd with the os on I got
> the grub menu but when I selected the instalaltion to boot I got:
>
> Loading Linux 2.6.32-5-amd64 ...
> Loading initial ramdisk ...
> [ ......] Initramfs unpacking failed: no cpio magic
> [ ......] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
It's the initramfs that is broken - not your /. You probably need to
get into the system somehow and use update-initramfs -u to regenerate
it.
As to how to get into an unbootable system: I personally use an Ubuntu
live CD and chroot into the installed system. I don't know if that's
practical from Knoppix, if it is then obviously use that.
[...]
> I can see where my "Loading Linux 2.6.32-5-amd64 ..." and
> "Loading initial ramdisk ... messages come from.
> I'm wondering if the UUID of the partition changed when gparted resized it and,
> if so,
That seems rather unlikely to me.
John Stumbles
> It's the initramfs that is broken - not your /. You probably need to
> get into the system somehow and use update-initramfs -u to regenerate
> it.
So how would initramfs get broken by the partition being resized? (I did
a bit of STFW but couldn't get an understanding of it.)
A Debian6 32-bit installation on another partition - sda7, which was
moved but not resized by gparted - works OK.
> As to how to get into an unbootable system: I personally use an Ubuntu
> live CD and chroot into the installed system. I don't know if that's
> practical from Knoppix, if it is then obviously use that.
I guess I could do it from this 32-bit installation I'm in now. What do I
do, just
root# chroot /mnt/sda6
and then
chroot# update-initramfs -u
?
--
John Stumbles
Richard Kettlewell
> Richard Kettlewell wrote:
>> It's the initramfs that is broken - not your /. You probably need to
>> get into the system somehow and use update-initramfs -u to regenerate
>> it.
>
> So how would initramfs get broken by the partition being resized? (I did
> a bit of STFW but couldn't get an understanding of it.)
Nothing springs to mind, unless the freeze you mentioned was on the
affected partition.
> A Debian6 32-bit installation on another partition - sda7, which was
> moved but not resized by gparted - works OK.
>
>> As to how to get into an unbootable system: I personally use an Ubuntu
>> live CD and chroot into the installed system. I don't know if that's
>> practical from Knoppix, if it is then obviously use that.
>
> I guess I could do it from this 32-bit installation I'm in now. What do I
> do, just
>
> root# chroot /mnt/sda6
> and then
> chroot# update-initramfs -u
> ?
Yes, the basic idea is to mount the target's filesystem(s) and then
'chroot <mount point>'.
There is a wrinkle however: if the sda6 install is 64-bit then the
32-bit install's kernel won't be able to run its executables.
In squeeze you can install a 64-bit kernel even in the 32-bit
distribution, though, so this needn't be too hard to work around.
(Be careful about running a 32-bit install on a 64-bit kernel in the
long term though - anything which draws inferences about the platform
from the kernel architecture will get confused.)
John Stumbles
> John Stumbles <john.s...@ntlworld.com> writes:
>> So how would initramfs get broken by the partition being resized? (I
>> did a bit of STFW but couldn't get an understanding of it.)
>
> Nothing springs to mind, unless the freeze you mentioned was on the
> affected partition.
If it corrupted something on the partition (although fsck.ext3 says it's
clean) I guess other files could be corrupted too.
> There is a wrinkle however: if the sda6 install is 64-bit then the
> 32-bit install's kernel won't be able to run its executables.
Ah, yes, just discovered that
> In squeeze you can install a 64-bit kernel even in the 32-bit
> distribution, though, so this needn't be too hard to work around.
If it is file corruption I do have a snapshot of the partition I took
just before trying to resize it. I guess I could just rsync that back...
or rsync --dry-run to see what's changed ...
--
John Stumbles
Richard Kettlewell
> If it is file corruption I do have a snapshot of the partition I took
> just before trying to resize it. I guess I could just rsync that back...
> or rsync --dry-run to see what's changed ...
That sounds like a worthwhile experiment, yes.
John Stumbles
> If it is file corruption I do have a snapshot of the partition I took
> just before trying to resize it. I guess I could just rsync that back...
> or rsync --dry-run to see what's changed ...
OK, I just noticed, my sda6 partition has a *lot* of files in lost+found,
all called #nnnnn (5 digits). I guess that's corruption.
I also found that I don't have a snapshot from *immediately* before the
resize :-(
(Though the latest I do have is probably close enough to go with.)
--
John Stumbles
John Stumbles
> I also found that I don't have a snapshot from *immediately* before the
> resize :-(
rsync-ed back the latest snapshot and it still does Initramfs unpacking
failed: no cpio magic / Kernel panic - not syncing: VFS: Unable to mount
root fs on unknown-block(0,0)
Though I no longer have stuff in lost+found.
--
John Stumbles
Richard Kettlewell
> John Stumbles wrote:
>> I also found that I don't have a snapshot from *immediately* before the
>> resize :-(
>
> rsync-ed back the latest snapshot and it still does Initramfs unpacking
> failed: no cpio magic / Kernel panic - not syncing: VFS: Unable to mount
> root fs on unknown-block(0,0)
What does cpio itself make of it? You'd want a command something like:
gzip -cd /boot/initrd.img-2.6.32-5-amd64 | cpio -t
T i m
<john.s...@ntlworld.com> wrote:
>rsync-ed back the latest snapshot and it still does Initramfs unpacking
>failed:
Probably nothing (and possibly as much for me as you and not wanting
to hijack the thread etc) but I saw something about 'unpacking
failed' yesterday when I went back to a PC I'd been working on and I
wasn't sure where the message had come from?
Story: I had been given a Sempron 3100+ box by a mate (was his
daughters but she's now got a laptop) and I was tidying it up for the
old lady who lives opposite to replace the aging 98 box I gave her
years ago (and she still uses pretty well daily).
I had re-installed XP on this new-to-me box and installed Mint 10,
dual boot leaving Mint the primary OS from GRUB.
I had just previously (30 mins) found and fitted a second 512M DIMM
(that another mate had given me) and had left the machine running.
When I went to it it had crashed and I could read half a message on
the TV / Monitor but CBA to reset the screen to see what the rest of
the message said.
I hit reset but it came back with some real issues so backtracked on
the RAM and it was fine straight away and for a day since in both XP
and Mint.
So, it looks like the bad RAM had crashed Windows but when it rebooted
it tried to start Mint but then gave the 'unpacking' error message
(I'd never seen that one in Windows before so wasn't sure if it was a
BIOS message (I'd just re-flashed that as well)).
So, in the vague chance it might be of use and if someone could kindly
tell me what the 'unpacking' bit is talking about please?
Cheers, T i m
Richard Kettlewell
John Stumbles
> What does cpio itself make of it? You'd want a command something like:
>
> gzip -cd /boot/initrd.img-2.6.32-5-amd64 | cpio -t
Looked borked :-/
gzip: 20110323-2320_post_resize_not_working/boot/initrd.img-2.6.32-5-
amd64: invalid compressed data--crc error
gzip: 20110323-2320_post_resize_not_working/boot/initrd.img-2.6.32-5-
amd64: invalid compressed data--length error
cpio: premature end of file
.
sbin
sbin/modprobe
sbin/blkid
sbin/udevd
sbin/dmsetup
sbin/udevadm
**********************
That was a saved copy. I reinstalled debian overnight. I'm using netinst
so it takes ages; and then it bloody stalled at the point where it should
have installed grub! I *think* that may have been because my router had
chosen that moment to go tits-up (which it does from time to time) and
maybe the installer was trying to download the grub installer from the
interwebs.
So then I did a very minimal install which got me back to a bootable
system, give or take gdm or gnome being broken (something about sanity
check but I didn't write it down). Tried rsync-ing over from snapshots
I'd taken of the system at various stages in its configuration from
before the point it broke (to save having to reinstall and reconfigure
everything yet again) but I get to a system where kdm offers a login box
but after logging in, just when you think it's going to do something, it
drops back to the login box again. I don't think it's a problem with my
~/.kde or ~/.kderc being screwed up because it happens for another user
too. Only sign of an error message is /var/log/daemon.log says:
'kdm_greet[2891]: Cannot load /usr/share/kde4/apps/kdm/
faces/.default.face: No such file or directory (though there isn't a
faces directory on my other, working, debian6/kdm machine).
So I'm back to another configure-from-basics marathon :-(
--
John Stumbles
T i m
<r...@greenend.org.uk> wrote:
>> So, it looks like the bad RAM had crashed Windows but when it rebooted
>> it tried to start Mint but then gave the 'unpacking' error message
>> (I'd never seen that one in Windows before so wasn't sure if it was a
>> BIOS message (I'd just re-flashed that as well)).
>>
>> So, in the vague chance it might be of use and if someone could kindly
>> tell me what the 'unpacking' bit is talking about please?
>
>Perhaps, if you can produce the full message.
Unless it was captured in some sort of log file or if I re-fit the
suspect RAM in the PC (that's now installed across the road) I don't
think I'd be able to sorry.
I was hoping that such a message, pretty well instantly after starting
boot of Mint from the GRUB menu may have been something 'known' etc.
Like 'Missing operating system' when you leave a non bootable floppy
in the drive?
If I see it anywhere again (and can easily see the whole message) I'll
note it down.
Cheers, T i m