Bad Geometry on Boot

bsilvereagle · 2011-08-10 21:13:08

I recently backed up my Arch partitions using fsarchiver: https://bbs.archlinux.org/viewtopic.php?id=124176. I then restored windows which wiped and formatted the whole disk. I recreated (similar) partitions using an openSuse LiveCD. Using the LiveCD I restored with fsarchiver.
I use the Windows bootloader, so after I restored the partitions I dd'd the first 512 bytes to a file on the Windows partition and set up the Bootloader.
I can boot into the Arch GRUB fine, and selected my entry. The boot process goes fine (the graphics resolution even changes) then it tries to mount /dev/sda7 to /new_root. It fails with "Bad Geometry, disk exceeds size"
Googling tells me my Hard Drive is shot, but that is not the case at all. Could the initrd think it needs to be on a different cylinder head then it should be? The partitions are in a different order and slightly larger than they used to be. However, /dev/sda7 is the correct root partition, I made sure it stayed the same

alphaniner · 2011-08-10 21:24:34

I wouldn't know where to start without your menu.lst, fstab, and the output of fdisk -l.

bsilvereagle · 2011-08-11 01:45:58

just "fdisk -l" won't do you very much good

isk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xb5598132

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         912     7321600   27  Unknown
Partition 1 does not end on cylinder boundary.
/dev/sda2   *         912         925      102400    7  HPFS/NTFS
Partition 2 does not end on cylinder boundary.
/dev/sda3             925       57615   455360512    7  HPFS/NTFS
/dev/sda4           57615       60802    25601024    f  W95 Ext'd (LBA)
/dev/sda5           57615       58137     4198400   82  Linux swap / Solaris
/dev/sda6           58138       59182     8385536    c  W95 FAT32 (LBA)
/dev/sda7           59182       60801    13003776   83  Linux

menu.lst
Well. Straight mounting from the LiveCD is failing.

linux:/home/linux # mount /dev/sda7 /mnt/linux
mount: wrong fs type, bad option, bad superblock on /dev/sda7,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

So does this mean fsarchiver botched up and I have a massive amount of redownloading to do?
I find that error odd since I copied the first 512 bytes out just fine.

Output of dmesg | tail:

[ 1493.617969] EXT4-fs (sda7): bad geometry: block count 4196352 exceeds size of device (3250944 blocks)
[ 1508.634600] EXT4-fs (sda7): bad geometry: block count 4196352 exceeds size of device (3250944 blocks)

I guess you won't be getting a menu.lst or fstab.

alphaniner · 2011-08-11 02:32:41

FWIW, I highly doubt fsarchiver messed up, at least without informing you. You did read the final 'report' after backup and restore, right? I have only ever had one issue with fsa in the 2-3 years I've been using it, and it was NTFS metadata related.

Moving on, it seems 'bad geometry' is a file system error rather than a partition table error like I assumed (and is why I asked for fdisk -l). If I understand, the filesystem expects to span 4196352 blocks, but the partition is only 3250944 blocks in size.

This and some googling leads me to believe the problem is a partition/filesystem misalignment. Did you modify the MBR (first 512b of HDD) or otherwise modify the partition table after restoring the fsarchiver image? Because that could certainly explain things.

You could try mount with the -v flag and fsck with the -V flag to get verbose output, maybe that would shed some more light on the situation.

The only other thing that springs to mind is the type of extended partition you are using, 'W95 Ext'd (LBA),' ID f. The standard type of extended partition used by Linux is 'Extended', ID 5. This may be perfectly all right. I only mention it because I had an issue a long time ago with Windows and extended/logical partitions, and since then I've always created them with fstab and only used them for Linux.

bsilvereagle · 2011-08-11 02:44:01

Yes, there was an opensuse partition earlier than the Arch partition in the extended partition that is not there now.

I've used the W95 Ext'd (LBA), partition for years, it's what the openSuse installer uses by default.

The MBR got wiped by Windows in the reset. I was using the Windows BootLoader to chain Grub, still am, probably always will.

linux:/home/linux # mount -v /dev/sda7 /mnt/linux
mount: you didn't specify a filesystem type for /dev/sda7
       I will try type ext4
mount: wrong fs type, bad option, bad superblock on /dev/sda7,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

The partition is ext4, fdisk seems to recognize it.

fsck

linux:/home/linux # fsck -V /dev/sda
fsck from util-linux-ng 2.17.2
[/sbin/fsck.ext2 (1) -- /dev/sda] fsck.ext2 /dev/sda 
e2fsck 1.41.11 (14-Mar-2010)
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sda

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

run e2fsck?

[EDIT]
I also made an image with dd and just threw it on the partition. Exact same errors.

Last edited by bsilvereagle (2011-08-11 02:58:43)

alphaniner · 2011-08-11 03:17:16

Just to confirm, whatever method you used to restore (dd image, fsarchiver image) was done after making any changes to the partition table? If so then your images are probably borked.

One last suggestion though, you could try to mount the dd image. I've never done it, but it's a common and established practice. I believe the syntax would be:

mount -t ext4 <image> <mount-point> -o loop

bsilvereagle · 2011-08-11 13:03:55

1. Both dd'd and fsa'd.
2. Windows wiped the disk.
3. Shrank Windows partition in Windows
4. Used an openSuse LiveCD to create similar (larger) partitions to original disk.
5. fsa'd over - errors
6. dd'd over -errors

Trying to mount the .img

linux:/media/Backup 1/Vaio/C # mount -t ext4 arch.img /mnt/arch -o loop
mount: wrong fs type, bad option, bad superblock on /dev/loop1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

linux:/media/Backup 1/Vaio/C # dmesg | tail
[ 1249.754755] EXT4-fs error (device loop1): file system corruption: inode #8 logical block 1280 mapped to 1607682 (size 1)
[ 1249.754797] EXT4-fs error (device loop1): file system corruption: inode #8 logical block 1281 mapped to 1607683 (size 1)
[ 1249.754838] EXT4-fs error (device loop1): file system corruption: inode #8 logical block 1282 mapped to 1607684 (size 1)
[ 1249.754878] EXT4-fs error (device loop1): file system corruption: inode #8 logical block 1283 mapped to 1607685 (size 1)
[ 1249.754919] EXT4-fs error (device loop1): file system corruption: inode #8 logical block 1284 mapped to 1607686 (size 1)
[ 1249.754960] EXT4-fs error (device loop1): file system corruption: inode #8 logical block 1285 mapped to 1607687 (size 1)
[ 1249.755000] EXT4-fs error (device loop1): file system corruption: inode #8 logical block 1286 mapped to 1607688 (size 1)
[ 1249.755042] EXT4-fs error (device loop1): file system corruption: inode #8 logical block 1287 mapped to 1607689 (size 1)
[ 1249.996335] EXT4-fs (loop1): corrupt root inode, run e2fsck
[ 1249.996339] EXT4-fs (loop1): mount failed

Why would changing the table mess with anything? A bit for bit copy shouldn't care what partition it is on. I was under the impression you could fsa a partition and then copy it over to several computers, classroom style.

alphaniner · 2011-08-11 13:51:33

Changing the table would (could, depending on precisely what was done) mess things up if done after the restore. I thought it was clear that's what I was asking about, if not I apoligize.

In any case, if you can't mount the dd image, you're pretty much done. Maybe you could try to forcibly fsck it or the partition, but it seems unlikely to succeed.

I just don't get it though. A dd operation obviously has no idea of what it's copying, but fsarchiver would have told you if the filesystem was borked when you imaged it. Unless there were errors during the restore operation, I don't think I'd ever be able to figure out what happened.

Last edited by alphaniner (2011-08-11 14:07:37)

bsilvereagle · 2011-08-11 17:02:28

It's my fault too, neither of us have been differentiating between the fsa and windows restore.

I tried fsck'ing both which failed.

fsarchiver didn't hiccup at all on either operation.
I guess I'm just going to have to reinstall/download/configure again. I hate to lose my kernel configs and patches. I guess next time I'm backing those up independently instead of just grabbing the whole partition.

alphaniner · 2011-08-11 17:36:56

I still have trouble believing that fsarchiver restored successfully and the partition is bad. If you'd like to humour me, you could do another restore and &> the output so I could have a look at it.

If I were you, though, I'd try restoring to a primary partition on a spare HDD for the sake of simplicity. Failing that, I'd look into pulling individual files out of the fsa image. It is a file-level backup tool after all. Maybe ask over at the fsa forums.

bsilvereagle · 2011-08-11 17:40:25

Arch is installing as I type, so I won't reimage that partition.
I did not know that it was file level backup, I figured it was on the lines of dd. I will have to look into that, thanks.

I'd flash a spare HDD but I don't have a spare HDD, rather, I don't have a free SATA port, external HDD, or eSata cable.

Arch Linux

#1 2011-08-10 21:13:08

Bad Geometry on Boot

#2 2011-08-10 21:24:34

Re: Bad Geometry on Boot

#3 2011-08-11 01:45:58

Re: Bad Geometry on Boot

#4 2011-08-11 02:32:41

Re: Bad Geometry on Boot

#5 2011-08-11 02:44:01

Re: Bad Geometry on Boot

#6 2011-08-11 03:17:16

Re: Bad Geometry on Boot

#7 2011-08-11 13:03:55

Re: Bad Geometry on Boot

#8 2011-08-11 13:51:33

Re: Bad Geometry on Boot

#9 2011-08-11 17:02:28

Re: Bad Geometry on Boot

#10 2011-08-11 17:36:56

Re: Bad Geometry on Boot

#11 2011-08-11 17:40:25

Re: Bad Geometry on Boot

Board footer