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.
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:
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.
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?
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 “ext2file 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.
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!