after making a partition bigger can't boot anymore

hi

I made my windows partition smaller and made my home partition bigger with gparted, but now the Laptop doesn’t find any operating systems anymore.

I have XP and openSUSE 11.1 KDE 4.2.

I tried repairing the system with the opensuse DVD, but it didn’t work.

while reparing it said, the bootloader has a damage, I repaired and anything also was ok.

The laptop is an EEE PC H1000.

I don’t know how to help you, but maybe the Paragon partition manager is a better choice for you in this matter?

Have you ever tried it?

ok, but it is not for free (except 30 days trail) and now I think it can’t help anymore.

Boot the DVD into Rescue System, login as root, and do (that’s an “l” as in “list”, not the numeral 1):

fdisk -lu

Post back the output here. (This would be easier to do with a LiveCD - assuming it connects to the internet - in a terminal as root, if you have one.)


Disk /dev/sda: 160GB, 160041885696 bytes
255 heads, 63 sektors/track, 19457 cylinders, total 312581808 sectors
units = sectors of 1 * 512 = 512 bytes
Disk identifier: 0xd300da08

Device Boot    Boot    Start     End         Blocks    id  System
/dev/sda1              63        122881184   61440561   7  HPFS/NTFS
/dev/sda2       *      122881185 312576704   94847760   f  W95 Ext'd (LBA)
/dev/sda5              122881248 127090214   2104483+  82  Linux swap/Solaris
/dev/sda6              127090278 169035929   20972826  83  Linux
/dev/sda7              169035993 312576704   71770356  83  Linux

edit: thank you for your help, but I need the laptop tomorrow working and I am installing openSUSE new (good: he found the home, swap and the windows partition) and hopefully it would work again.

Anyone who knows how that problem appears, because on the laptop of a friend the same progress worked without any problems.

I hope no-one minds if I hijack in to this thread…:).
I had this problem: System load and SWAP - openSUSE Forums So I extended my linux partition, by shrinking “HOME” and growing SDA6, USING PARAGON. Now I get a boot fail, and boot instead into some special mode, with instructions on the lines of:
"root fs is read only, remount to RW by: mount -n -o remount, / (something like that, I am back in windies now…>:( ) followed by the instruction: “You can only shutdown%reboot using ctrl-D”. This is in a SU prompt. I tried following the instructions and then startx, which booted me to a KDE SU desktop. A reboot then put me back where I was. A repair, booting from the install DVD finds errors and demands that I run fsck manually. I try this a couple of times, answering “Y” to any questions, but this goes on for ever, even poking a cocktail stick into the KB to hold down the “Y” key (!!!) A little research brings me the -y option, [answer yes to all], and I run… and run and run and run. Overnight; 12 hrs, still running, and seems to be in some kind of loop. Can’t remember exactly what is flashing by but i-nodes seem to be the problem. Is there any hope or Am I doomed to lose all my carefully set-up Email, internet, wireless, forum, video drivers etc?
I realise that merrily re-sizing partitions like this might be considered a bit cavalier, but I have used Paragon before and it worked extremely well, in fact I used it to shrink my Windows partition to make room for openSuse from within Windows. I thought that re-sizing inactive/unmounted partitons from within Windows would be relatively trivial. Paragon btw does “know about” Linux ext2 ext3 reiserFS etc.

@wakou -

It sounds like the file system on the root partition was either marked dirty or there was some damage to the inode table - in either case, the solution is to run e2fsck. If the partition if very large, especially already populated with a lot of files, it can take a while. But I wouldn’t think overnight.

Try this:

mke2fs -n /dev/<partition>

That will read the superblock and may reveal a problem. It will also report the location of the backup superblocks. If you used a block size other than 4096 (IIRC in SuSE this is the default), you need to specify that with the -b argument. Then you can use e2fsck to recover the file system using the backup superblock. For example:

e2fsck -b 32768 -f /dev/<partition>

Also check and fix bad blocks with:

e2fsck -c /dev/<partition>

I trust you have a backup.

Errr NO!
it was a relatively new install. I am very new to Linux and would not know how to back-up, still learning.
My symptoms are exactly as described here,
EXT3-fs: corrupt root inode after resize - Linux Forums
no solution was forthcoming and I can tell the poster was much more expert than me, and ran fsck for 10 days!

A broken inode table in ext3 is essentially the same as a broken MFT in NTFS. Fortunately, the superblock that holds it is copied (NTFS also does this with its MFT), so it’s possible that recovering from the backup superblock (see above) may work (note that ext3 keeps more than one backup superblock). While I haven’t seen the looping behavior in e2fsck, I have seen it in chkdisk with NTFS, and it was because the MFT was corrupted.

Something else you can try is the “testdisk” program, it is excellent. It is on the Parted Magic and System Rescue LiveCD’s, I’m sure others, too.

For what it’s worth, I’ve used PartitionMagic for years, and as good as it is, I have seen it corrupt file systems. Bottom line, if the data on a partition is important one should always have a backup before making any physical changes to it. It’s very rare to have this problem, but of course Murphey’s Law says it will happen when you least want or expect it to.

Good luck.

Thankyou Mingus…

@wakou -

It sounds like the file system on the root partition was either marked dirty or there was some damage to the inode table - in either case, the solution is to run e2fsck. If the partition if very large, especially already populated with a lot of files, it can take a while. But I wouldn’t think overnight.

Try this:

Code:

mke2fs -n /dev/<partition>

That will read the superblock and may reveal a problem. It will also report the location of the backup superblocks. If you used a block size other than 4096 (IIRC in SuSE this is the default), you need to specify that with the -b argument. Then you can use e2fsck to recover the file system using the backup superblock. For example:

Code:

e2fsck -b 32768 -f /dev/<partition>

Also check and fix bad blocks with:

Code:

e2fsck -c /dev/<partition>

Thank-you for you advice, I got hold of Parted Magic, and it is indeed a fine piece of work. I think I might be over my head in trying to reconstruct from here, although as a puzzle or exercise, I suppose it has some value. I am, as I say 90% Linux noob so a lot of this is Greek to me…

For instance when you suggest:

mke2fs -n /dev/<partition>

or similar do I have to mount the partition first? Or can I issue this sort of command having booted from a live CD?

Having run testdisk advanced on both sda6 and sda7 the list of superblocks seems to be the same for both; is this right?
Which should I use? Any of them?
The block size seems to be correct at 4096…

I am also confused at the differences between

mke2fs
e2fsck
fsck.ext3

Are they interchangeable? or all part of the same package?

Where do they “live”?

To answer your questions . . .

Definitely do NOT mount the partition when doing work on the file system. e2fsck will warn you if you try doing so on a mounted partition; do not ignore that warning! This is a main reason why a good LiveCD is important; it boots into RAM and your disk partitions do not need to be mounted.

The superblocks will be placed at the same location on a partition based upon the block size. So any partition blocked at 4096 will have its first superblock at 32768. There will be additional backup superblocks depending on the size of the file system. The e2fsck man page explains this.

mke2fs is “make ext2 file system”. This program creates an ext2/3 file system, that is, it “formats” the partition.

e2fsck is “ext2 file system check”. This program checks and repairs an ext2/3 file system (the equivalent of chkdisk in Windows).

Both must be run as root, and should be in the root path so it is not necessary to know where it “lives” in the file system. But anyway, they are under /sbin.

You can learn more about their operation with:


man mke2fs
man e2fsck

fsck is just a generic front-end that calls the actual file system repair program depending on what type it determines is on the partition. So running fsck will call e2fsck if the partition is ext2/3. Running fsck.ext3 simply executes e2fsck directly.

Good luck.

Thanks Mingus, I have learnt a lot from your replies and I am sure the new insights will come in handy later (I hope not tho!). I have tried to rescue using your suggestions but e2fsk went in to a loop again, even with back up SuperBlocks. Somewhere along the line I had also corrupted GRUB and have replaced the MBR, so that my Windows install could boot. Luckily my openSuse install was brand new and no important user data was with it, only install tweaks. I think it is time for the big hammer of a fresh re-partition/reinstall. Please look for my new thread(s) your input will be welcome!