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?