e2fsck?

When I mounted my HD on my empeg a few mins ago I got:

empeg:/empeg/bin# rw
EXT2-fs warning: maximal mount count reached, running e2fsck is recommended

I looked around for e2fsck but didn't find it. How can I run this?

-Greg

This error message means that you did not remember to read-only mount (ro, rom) the player after you messed around on the hard disk. Don't forget to do this!

From an old thread where Brian Mihulka was answering the same question when I did the same thing, the solution is to do:

fsck.ext2 /dev/hda5

I would like to put this in the FAQ. For those who know: Is this still the correct thing to do?

Thanks, the only time i didn't set back to ro was when the player froze 2 days ago with hijack v117. Since then it never said anything uptill i just reuploaded the finaly index.html to my root.

-Greg

the only time i didn't set back to ro was when the player froze 2 days ago with hijack v117

Right, and the error message has been waiting to pounce on you ever since.

Can anyone confirm whether what I put in the other message is still the correct fix or not?

Actually, that warning just means the filesystem reached a certain mount count, and thinks it needs a routine check. Emplode would have probably done a check on the next sync, if it wasn't disabled in hijack.

EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended

Thats the error message when a filesystem wasn't unmounted cleanly (ro'ed in the case of the empeg)

Oh, so I was getting my e2fsck errors mixed up?

Okay, if that SECOND error appears, then is the fix line I posted still the correct fix?

The fix will work in both cases...As long as the partiton is mounted RO.

First, they're mount errors. Second, they're not errors, they're warnings. Neither one means that there is an error. Third, the one initially complained about is a very mild warning. Basically, the filesystem keeps track of how many times it's been mounted. Once it reaches a certain number of mounts, the mount utility suggests fscking it, just to be on the safe side. If this happens on boot, most Linux systems will automatically fsck it for you. The other warning means that there's a reasonable possibility of there being filesystem problems, as it wasn't unmounted, so there could be inconsistencies in the filesystem. But there might not be any errors, too. Just like powering off Windows without shutting down. Sorry for the partial repetition. Just trying to be clear.

This error message means that you did not remember to read-only mount (ro, rom) the player after you messed around on the hard disk.
ok so say if you DO forget to do this, I presume on the next power cycle, or boot. The player mounts the drive as ro?
or not?

cheers,
Jaidev

You really ought to unmount the partition first.

Now I'm even more confused.

I just want to write a FAQ entry that simply says:

"Q: I got an E2FSCK error message at the Bash prompt. What do I do to fix it?

A: Type the following:

xxxxxxxxxxxxxx
xxxxxxxxxxxxxx
xxxxxxxxxxxxxx

The error should go away."

What do I put in the xxxxxxxxxxxx section?

umount /dev/hda4
umount /dev/hdc4
fsck -f /dev/hda4
fsck -f /dev/hdc4
mount -n -o ro /dev/hda4 /drive0
mount -n -o ro /dev/hdc4 /drive1

Unmount both music partitions, run fsck on them. By default fsck only checks the disk if it's marked dirty, or the mount count is reached, so -f forces a check.

You then answer yes to the questions it gives you.

Then you remount the disks readonly.

...and omit all the lines mentioning /dev/hdc4 if you only have one drive.

You then answer yes to the questions it gives you.

In that case you could just give the -y option and go have a coffee instead
Or does the fsck on the empeg not support that flag?

One downside though, is that you don't get to see all things that might be wrong,
so it might be hard to tell exactly how fscked the disk is...

/Michael

Greetings!

I thought the -y would still print the errors. What I do is turn on the capture on the terminal session before walking away. If I am feeling lazy, I do a script, turn on capture, run the script and get coffee. The terminal usually has enough screen / buffer to see what is happening, unless there were lots of errors. Then I go back to the capture file.

This works on both a Mk1 and a Mk2?

I'd think so... All from memory, could be off: The empeg guys sort of mislabels the /dev/hdb into /dev/hdc on the MkIIs (normally hdb is slave on the first IDE channel and hdc is master on the second IDE channel) so that the MkI and MkIIs can do the same thing despite the secondary disk in the MkI being master on the second channel while it's slave on the first channel in the MkIIs. What physical device the /dev/whatever actually point to is decided by the major and minor device numbers, not the name.

/Michael

Okay, thanks everyone. FAQ entry put in place:

http://www.riocar.org/modules.php?op=modload&name=FAQ&file=index&myfaq=yes&id_cat=8&categories=Known+problems+and+troubleshooting+questions#162

If corrections are needed, please put them here in this thread.

The only thing I can think to add would be commands to check the root partition as well. To do this, run "ro" first, then "fsck -f /".

And don't remount the root directory read-write again, afterwards. Reboot.

I can't emphasis this enough. The problems with disk corruption that we experienced early in the 2.0 beta cycle (before anybody other than the alpha team got to see v2.0) were caused by a complicated chain of events involving a read-only, fsck, read-write cycle.

Thanks for the warning. I've done this a few times in the past, and haven't noticed a problem. But from now on, I'll avoid doing this.

It went like this:

1. Disks are mounted read-write.
2. We delete the /lost+found directory.
3. We mount the disk read-only.
4. We run fsck.
5. fsck recreates the /lost+found directory.
6. We mount read-write.
7. Disk corruption results.

The problem seems to be caused by the kernel not updating its directory cache for the root directory. When fsck recreates lost+found, the two get out of sync. Then you remount read-write, and the kernel modifies its cached copy, and then flushes it. Boom.

Now, this sequence of events is so rare as to be extremely unlikely to happen to anyone else, but I'd be aware of it anyway -- simply remounting the disks ro doesn't cause the kernel to flush its changes out, or to discard its cached copy.

This particular bug resulted in Steve Sanders losing all of his music -- the first lot of disk corruption caused _everything_ to be moved into lost+found, which we then emptied. Whoops.

If corrections are needed, please put them here in this thread.

The FAQ refers to commands RO, ROM, RW, RWM, but these commands are case-sensitive and lower case. Mind you, anyone clueful enough to have got their player in that state in the first place will probably know this.

And while we're on, what's with those out-of-control URLs that riocar.org invents for everything? Even if it needs that huge URL in Tony's post for internal purposes, can't the server rewrite it from a simpler user-visible URL -- something like http://www.riocar.org/faq/myfaq/8/ ? Tony's post makes this whole thread unviewable in narrow browser windows...

Peter

So what are you saying? Should I update the FAQ entry to say "Reboot the player (important!)" after the procedure?

I will fix the case on RO etc.

And sorry for the wide link. My fault for not encasing it in a URL= tag. Got lazy.

For any partition that you mounted read-only in order to run fsck, yes. This generally will only mean the root partition.

When a normal Linux box checks its root partition (which is mounted read-only) at bootup, and changes were made by fsck, it forces a reboot for just this reason.

Completely unmounting the music partitions before running fsck (as per my post, above) doesn't require a reboot afterwards.

And while we're on, what's with those out-of-control URLs that riocar.org invents for everything?

I don't know, ask the PHPNuke people...

I am looking at what to do with the site when I go in to upgrade the code. I'll probably start testing some thing here in the next few weeks. I don't like the code much ,as seen by the many lines of code I have added to "correct" some issues. Some of those involved database framework changes, thus making a normal upgrade even harder.

And for the future, FAQ links can strip out the &category portion, all that does is pass the title over to be displayed on the top of the page. Again, it's a stupid way of doing it when it has the database open already, but again, I didn't code it from scratch.

If no major improvements were made to the FAQ code in whatever I decide to move to, I will recode it, since 75% of the code in the FAQ file is mine anyhow.

I just read the FAQ entry, and have one comment: if you're going to reboot the player, there's no need to remount the disks...

If what I wrote doesn't HURT anything, I'll just leave it there to be redundant.

fscking any mounted filesystem, even if it's read-only, on any Unix that I'm aware of, can have such problems. The problem is that the OS expects that it's the only thing modifying the filesystem. When you run fsck on the device, it ends up modifying the filesystem. The OS has absolutely no way to know this. So it's easily possible for it to encounter inconsistencies and screw up in undefined ways.

Well, there's like a bizillion replys so far, mostly correct. Here is some more background info on the "problem":

"maximal mount count" refers to a counter on the disk, one per filesystem, that is normally incremented each time the filesystem is mounted "writable" (read-write). When this counter exceeds a programmed threshold, a lengthy time-consuming filesystem check is "forced" the next time that filesystem is mounted writable (usually by Emplode). Mostly this is a nuisance, a total waste of time..

The Hijack "disable periodic filesystem checks" simply prevents this counter from incrementing. There is a second, related test done on "writeable" mounts: a time/date comparism. If a programmed time "interval" has elapsed since the most recent filesystem check, then this too will force one. Ugh. Hijack also prevents that from happening.

Neither of the mountcount nor interval checks are necessary for a healthy system. On my Linux desktops, I routinely turn these features off using "tune2fs -c0" -i0", necessary once (ever) per filesystem.

The neat thing is that filesystem checks will still happen with those things turned off, but now they happen ONLY when necessary (improper shutdown while "writeable", or kernel bug, or..).

To check filesystems while logged into an Empeg running the developer image, use the following command sequence:

ro
fsck -fay /
fsck -fay /drive0
fsck -fay /drive1
sync
(and force a reboot by cycling the power or using Hijack's menu)


Cheers

the resident kernel dude.

So do you recommend that I change my FAQ entry to your lines instead of the ones that are there?

I don't understand any of this, I'm just parroting.

I still think it's safer to umount the filesystems you can (/drive0 and /drive1). Then there's not much need to sync or reboot. However, it makes a lot of sense to run sync before rebooting after fscking an un-umountable filesystem, like /.

Edit: After rereading your FAQ entry, you should make the following changes:

• add `a' and `y' flags to the fsck commands you have now so that it reads ``fsck -fay ...''.
  
• add info about how to fsck the root filesystem:
  
  

  ro
  
  fsck -fay /
  
  sync
  
  [reboot]

  
  
• the caveat about rebooting need only apply to the root fsck
  

It seems as though there are differing opinions of how to go about this.

You experts please hash it out here and come to a consensus amongst yourselves. When you're all done and all agree, I'll put the "consensus" version in the FAQ.

Okay. Anyone disagree with my previous statement? I'm fine with keeping in the unnecessary reboots. It's hardly an issue with the empeg, as it has no uptime requirements, nor does it take a long time to reboot, and there's no need to babysit it, anyway. Adding the root fs info would be a plus, though.

For simplicity, it is best to sync;reboot after any filesystem checks on the player. That is what the FAQ should recommend.

For those "in the know", if you run fsck on a "mounted read-only" filesystem, it is possible for fsck to "repair" something without that knowledge being passed on to the kernel filesystem code.. thus the kernel may have one view in memory, when in fact fsck has written a differing view to the disk.

This will confuse the player, and possibly result in filesystem corruption if the filesystem is later remounted rw (dubious, but perhaps possible). This is why the fsck program warns against running it on a mounted filesystem, even when the filesystem is "read-only".

So, again, the simplest rote sequence for everyone:

	ro

	fsck -fay /

	fsck -fay /drive0

	fsck -fay /drive1

	sync



	[reboot the player]

Strictly speaking, the "-fay" could be replaced with "-ay", to avoid having fsck run on filesystems it "knows" are okay. But this discussion was about forcing checks, so..

-ml

And that will definitely get rid of the error messages?

Empeg guys, is this good?

Yes, that will definitely get rid of the "maximal mount count" warnings.. but so too will setting the Hijack "Filesystem Check on Sync" setting to "Disabled".

cheers

Yes, I'm aware of that neat feature in Hijack.

But I'm not just concerned about the maximal mount count. I'm also concerned about the other similar error that happens when you reboot the file systems in RW mode. Will this also clear that error as well?

Yes, it clears all errors.

Is this something to worry about? I ran the fsck -fay / and fsck -fay /drive0 commands without error, but I get the following message when running fsck -far /drive1

empeg:/empeg/bin# fsck -fay /drive1

Parallelizing fsck version 1.19 (13-Jul-2000)

e2fsck 1.19, 13-Jul-2000 for EXT2 FS 0.5b, 95/08/09

ext2fs_check_if_mount: No such file or directory while determining whether /drive1 is mounted.

fsck.ext2: Is a directory while trying to open /drive1



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 



empeg:/empeg/bin# 

I can see and browse through /drive1 through http/ftp and command prompt. Is there a problem with the partition if the filesystem check is giving me this message?

I suspect that fsck is not looking in /proc/mounts to find the partition name of the disk -- either that or it's not actually mounted. The default /etc/fstab doesn't ship with /drive1 listed in it.

You need to change those commands so that /drive0 reads /dev/hda4 and that /drive1 reads /dev/hdc4

And would that work on a Mk1 as well?

Should do -- I don't have my mk1 handy to check this, unfortunately.

Yes, /drive1 is /dev/hdc4 on a MkI too. Actually it's on the MkI that this is "same as on an ordinary PC". You relabel the devices for the first IDE channels slave drive to /dev/hdcX on the MkII (where it would "normally" be called /dev/hdbX), I guess so that it can use the same code/same instructions as the MkI...

/Michael

So then, I should have the FAQ say:

ro
fsck -fay /
fsck -fay /dev/hda4
fsck -fay /dev/hdc4
sync

[reboot the player]


Will that work in all cases? Is there a consensus on this?

Should work in all cases. I think it's a little overkill, and very slightly undersafe, but there's not a lot of drawback to the overkill and the undersafe is kinda irrelevant considering the machine is in, basically, a single-user mode. Anyone who has a system where it won't work safely knows enough not to do it that way.

Greetings!

You might want to add a line about turning the swap on and off...

Oh yeah, good point.

Arg, okay, how do I add a line about turning the swap on and off?

Will somebody please give me an exact list of things to type that everyone agrees on?

The command to turn swap off is

swapoff -a

.

And this goes... where?

Except that you might want to turn swap on before starting the fsck -- it can use a lot of memory, and you wouldn't want it to run out half-way through.

I dunno, I rarely need to use swap space on my Empeg so I've never had to turn it on/off for fsck. I've never had it run out of memory as Roger suggests it might, but I think this is what we're getting at:

ro

swapon -a

fsck -fay / 

fsck -fay /dev/hda4 

fsck -fay /dev/hdc4 

sync 

swapoff -a



[reboot the player]

I guess the swapoff could be before the sync but I don't think that matters.

The whole swapon/swapoff bit assumes you've created swap space somewhere, and I don't know that the player, by default, has that. I know it has a partition designed for swap space (hda6) but I dunno if it's used in an "out of the box" configuration. In thatcase, the user would have had to execute a mkswap command to set up the swap space, like "mkswap /dev/hda6" or something.

Is this the longest discussion of a FAQ entry ever, or what!

The player's swap space is configured correctly. The player itself turns swap on when doing an fsck, which is why I suggested it. I'm still not convinced about leaving the music partitions mounted while running fsck, though, and in deference to the fact that the /etc/fstab file might not have everything in it, I'd go with this:

ro
umount /dev/hda4
umount /dev/hdc4
swapon /swapfile
fsck -fay /
fsck -fay /dev/hda4
fsck -fay /dev/hdc4
swapoff /swapfile
sync


and then reboot.

The swapon/off lines are actually what the player does. /swapfile is a symlink to /dev/hda6

Okay, so is this good with everyone?

Okay, so is this good with everyone?

Roger that!

(ducking to avoid tomatoes)

Okay. That's one vote. Mark?