Fedora 11 Acer Aspire 1 boot problem
in [UK Linux]
|
Prev: Blocking iPlayer
Next: Linux for the elderly?
From: Ivor Jones on 10 Nov 2009 19:29 Hi All I have an Acer Aspire 1 netbook running Fedora 11, all has been fine until tonight when it wanted to do a software update, something which has gone without problems before now. This time however the update completed with the message that one dependency (don't remember what) couldn't be found, but it's done that before without issue also. Anyway it completed and said it wanted to reboot, however once past the (brief) option to enter the grub menu, the bootup halts and I'm left sitting at a blank screen. I retried the process but editing out the 'rhgb quiet' portion from the 'grub append' line and get the following: JBD: no valid journal superblock found EXT3-fs: error loading journal Anyone got any ideas before I do a complete reinstall..? I'd rather not do this if at all possible, not that there's a lot of data on the drive but it takes ages to configure things the way I like it. As you can probably tell I'm a bit of a Linux newbie so any assistance gratefully received. Cheers Ivor
From: Nix on 12 Nov 2009 08:36 On 11 Nov 2009, Ivor Jones uttered the following: > Anyway it completed and said it wanted to reboot, however once past > the (brief) option to enter the grub menu, the bootup halts and I'm > left sitting at a blank screen. > > I retried the process but editing out the 'rhgb quiet' portion from > the 'grub append' line and get the following: > > JBD: no valid journal superblock found > EXT3-fs: error loading journal Yay filesystem damage! It looks like the filesystem is there, but the journal (that records writes in progress but not yet committed) has vanished out from under it (how? Strange.) > Anyone got any ideas before I do a complete reinstall..? I'd rather > not do this if at all possible, not that there's a lot of data on the > drive but it takes ages to configure things the way I like it. If you can boot from the install media, it almost always gives you an option to get a shell. Once you've got that, getting to the block device is somewhat more amusing, but this sequence might do it (some of the commands might give errors if they're not even there): mdadm --assemble --scan --auto=md lvm vgscan --ignorelockingfailure --mknodes && lvm vgchange -ay --ignorelockingfailure mdadm --assemble --scan --auto=md You should now have a root filesystem in a block device somewhere. The problem is finding it. First, let's give the LVM volumes a good checking: for name in /dev/mapper/*; do [[ "$name" = "/dev/mapper/control" ]] || e2fsck -fy $name; done ('f' means 'check no matter whether we've checked it recently'; 'y' means 'answer yes to all questions about disk modification', and it's in there only because you're contemplating a reinstall anyway and because most of the questions it asks are greek to non-fs hackers. Feel free to drop the 'y' or replace if with a 'n' if you only want to see if there is damage, and not fix it at this stage.) But the root filesystem may well not be on LVM. sfdisk -l /dev/hd[a-z] /dev/sd[a-z] will give you a listing of all your partitions, so you can pick out the ones that claims to be 'Linux' and e2fsck them as well, something like e2fsck -fy /dev/sda1 if sda1 was one that claimed to be of type 'Linux'. (The filesystem type ID in the partition table is an almost totally useless historical artifact, and is never used by Linux at all. It pretty much exists entirely for emergency situations like this, so you can pluck your partitions out of a mass of others and not end up accidentally fscking your windows installation or swap device.) You should then have a filesystem back. e2fsck is pretty good so unless the damage was really bad most of the data will probably be OK. But this is definitely 'touch wood' territory now, as with any filesystem recovery on any OS. > As you can probably tell I'm a bit of a Linux newbie so any assistance > gratefully received. Bad luck getting fs corruption so soon then :( I think I've seen three serious cases in twelve years, discounting those that were down to bugs I'd just introduced: all were due to hardware failure (mostly the disk not bothering to seek when asked but claiming it had seeked, so it then proceeded to write data in the wrong place, generally all over critical filesystem structures. Damn buggy drive firmware.)
From: Ivor Jones on 18 Nov 2009 16:33 On 12/11/09 13:36, Nix wrote: > On 11 Nov 2009, Ivor Jones uttered the following: >> Anyway it completed and said it wanted to reboot, however once past >> the (brief) option to enter the grub menu, the bootup halts and I'm >> left sitting at a blank screen. >> >> I retried the process but editing out the 'rhgb quiet' portion from >> the 'grub append' line and get the following: >> >> JBD: no valid journal superblock found >> EXT3-fs: error loading journal > > Yay filesystem damage! It looks like the filesystem is there, but the > journal (that records writes in progress but not yet committed) has > vanished out from under it (how? Strange.) [snip] Thanks a lot for the detailed information, but it's a bit beyond me..! Anyway as there wasn't a great deal of locally stored information (the machine is mainly used for internet broswing/email etc. when away from home) I decided on the re-install route and as Fedora 12 came out yesterday I went for that, which has installed a treat, now all I have to do is configure everything..! Note to self - backup config files at the very least..! Cheers Ivor
From: Martin Gregorie on 18 Nov 2009 18:39 On Wed, 18 Nov 2009 21:33:25 +0000, Ivor Jones wrote: > On 12/11/09 13:36, Nix wrote: >> On 11 Nov 2009, Ivor Jones uttered the following: >>> Anyway it completed and said it wanted to reboot, however once past >>> the (brief) option to enter the grub menu, the bootup halts and I'm >>> left sitting at a blank screen. >>> >>> I retried the process but editing out the 'rhgb quiet' portion from >>> the 'grub append' line and get the following: >>> >>> JBD: no valid journal superblock found EXT3-fs: error loading journal >> >> Yay filesystem damage! It looks like the filesystem is there, but the >> journal (that records writes in progress but not yet committed) has >> vanished out from under it (how? Strange.) > > [snip] > > Thanks a lot for the detailed information, but it's a bit beyond me..! > Anyway as there wasn't a great deal of locally stored information (the > machine is mainly used for internet broswing/email etc. when away from > home) I decided on the re-install route and as Fedora 12 came out > yesterday I went for that, which has installed a treat, now all I have > to do is configure everything..! > > Note to self - backup config files at the very least..! > Look into using: - CVS to keep versions of config files as you change them (set up a CVS user as the place for it to put its repository and don't use that login for anything else - Use a USB portable drive for backups and do the job with rsync. That gives the fastest backup you're likely to find. This combo means you really only have to back up /home if you're happy to reinstall any programs, etc. that aren't part of the distro. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Nix on 19 Nov 2009 18:20
On 18 Nov 2009, Martin Gregorie spake thusly: > Look into using: > > - CVS to keep versions of config files as you change them (set up a > CVS user as the place for it to put its repository and don't use > that login for anything else I'd recommend using something not obsolete that doesn't destroy permissions and ownership, which are often critical with config files. Personally I like etckeeper. (Or just keep backups.) > - Use a USB portable drive for backups and do the job with rsync. > That gives the fastest backup you're likely to find. Do the job with rdiff-backup, and you get the speed of rsync, optional remote backups, and efficient storage of backups gone by as well. (I back up every night, and at the rate I use space on my 1Tb USB drive, I'll have to start discarding old backups in about ten years, by which point I expect the drive to have packed it in!) |