· I got an error message about 'e2fsck' at the shell prompt. What do I do to fix it? (Entry last updated on January 4th, 2010)There are a few common errors you might see at the Linux shell prompt, usually when you are in the process of mounting the drives read-write to mess around with the files:
"EXT2-fs warning: maximal mount count reached, running e2fsck is recommended"
This means that on the next synch, your player will need to do its long "checking disk integrity" thing. It's nothing to worry about and you can safely ignore it. It will go away after the next synch.
"EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended"
This means that at some point in the past, you neglected to re-mount your drives as read-only before rebooting the player. Bad hacker, go to your room.
To prevent this error in the future, always remember to do ro and rom after doing rw and rwm. More details here.
This error can also be caused by rebooting the player during the middle of a synch operation, either on purpose or accidentally because of a crashed synch. The drives are mounted read-write during certain phases of the synch operation, and this error will happen if the player is rebooted during that time.
Another thing which might cause this error is trying to mount/unmount a partition, or perform an Emplode syncronization, while a third-party program is running off of that partition. When a program is active, the partition it's running from is locked and can't be unmounted. For example, if you use the Hijack @EXEC command to launch a program that's been copied to somewhere on the /drive0 partition (which is the same partition that contains the music), then you will be unable to perform a synch and will likely induce this problem. To work around this, use the @DC modifier so that you only run your programs when the player is in the car dock. Click here for more information about hijack commands.
To correct this error, make sure you're using the developer firmware on the player, use hyperterminal to get to a shell prompt with either a Q or a Ctrl-C command, then enter the following at the shell prompt:
ro
umount /dev/hda4 (Please note! The command is umount, not unmount.)
umount /dev/hdc4 (If you have only one hard disk, you may omit the lines that include /dev/hdc4.)
swapon /swapfile
fsck -fay /
fsck -fay /dev/hda4
fsck -fay /dev/hdc4
swapoff /swapfile
sync
(and then reboot the player by pulling its power cord)
Answer yes to any questions it gives you. Please note that some of the commands above will be followed by a mind-bogglingly long pause as it scans the disk. The larger your disk drives, the longer the pause. Do not panic, it's not frozen, just wait it out.
Important: After performing the above procedure, make sure to fully reboot the player by pulling the power plug and re-inserting it. If you don't, data loss may occur if you do another "rw".
If you get any one or more of the following errors:
"EXT2-fs: ide0(3,4): couldn't mount because of unsupported optional features."
"fsck.ext2: Bad magic number in super-block while trying to open /dev/hda4"
"fsck.ext2: Filesystem revision too high while trying to open /dev/hda4"
"The filesystem revision is apparently too high for this version of e2fsck."
This is probably music partition corruption. It is can sometimes be caused by the player, Emplode, or Windows crashing during a synch operation. If the player's power was cycled before the player had a chance to mount its drives read-only again (perhaps an unavoidable situation depending on the circumstances), the music partition might have become corrupted.
Permanent partition corruption is very rare in this situation, as there are fail-safes built into the player software to prevent it. For instance, if Windows crashes during a synch, you should let the player just sit there for a couple minutes until the "Synchronising" message disappears from the screen, so that you know it's set the drives back to read-only, before pulling the power.
The player also contains backup partition tables that can be restored if this sort of thing happens. You can restore one of these backup partition tables with the following steps at the shell:
ro
rom
fdisk -l /dev/hda
swapon /swapfile
fsck.ext2 -fay -b 32768 /dev/hda4
At this point it will either give you the "Bad Magic Number" error again, or it will give you a lot of output indicating it's trying to fix the partitions. If it's successfully working on fixing the partitions, you'll see output like this:
Pass 1: Checking inodes, blocks, and sizes (there may be a very very long pause here.)
Pass 2: Checking directory structure
Entry '16450' in /fids (129) has deleted/unused inode 13507. Clear? yes
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: (Lots of numbers may appear here.)
Free blocks count wrong for group #0 (277, counted=1).
Fix? yes
Free blocks count wrong for group #1 (5057, counted=0).
Fix? yes
Free blocks count wrong for group #3802 (698, counted=0).
Fix? yes
(etc...)
/dev/hda4: ***** FILE SYSTEM WAS MODIFIED *****
/dev/hda4: 17028/304448 files (14.4% non-contiguous), 35220991/38965657 blocks
If you get that ouput, great, then wait for it to finish the job so that it drops back to the shell prompt (it may take a very long time). Then skip the rest of the partition recovery commands listed below.
If you get another one of the "Bad magic number in super-block" errors instead, then try the next possible partition recovery command from the list below:
fsck -fay -b 24576 /dev/hda4
fsck -fay -b 24577 /dev/hda4
fsck -fay -b 98304 /dev/hda4
fsck -fay -b 98305 /dev/hda4
Try each one of those commands once until you get results. At any point that one of those commands succeeds instead of giving you a "Bad magic number in super-block" error, wait until the repair is complete and then do the following:
swapoff /swapfile
sync
Then reboot the player by pulling its power cord.
Important: After performing the above procedure, make sure to fully reboot the player by pulling the power plug and re-inserting it. If you don't, data loss may occur if you do another "rw".
If this procedure is complete and successful, after the player reboots, it might pause for a long time on "Building Music Databases". If that happens, you may have to rebuild the music databases by hand as described here. You may also need to redo the steps outlined in the first part of this section, under the heading "EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended", above.
|