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.