The forums are filled with instructions to put the flash drive in a Windows computer and run chkdsk.  But then I saw this one:

  http://lime-technology.com/forum/index.php?topic=34266.msg318661#msg318661

that explains how to run dosfsck from within unRAID.  Which makes me wonder...

 

1. Can we add a "checkdisk" option to the boot menu that loads a minimal environment, runs dosfsck on the USB drive, and then reboots?

 

2. Or even better... when unRAID detects a problem with the USB drive during bootup, why not have it automatically unmount the drive, run dosfsck and then remount the drive (or reboot if needed)?

 

Would be nice if it were automatic before the filesystem were mounted.

Yes, I second this request!

Would be nice if it were automatic before the filesystem were mounted.

 

hmm,  not for those of us who run headless.  Prefer it to be a menu option.

Would be nice if it were automatic before the filesystem were mounted.

 

hmm,  not for those of us who run headless.  Prefer it to be a menu option.

 

My assumption is that it would be fully automated, with no need to "press Y to continue" or anything like that.  So running headless shouldn't be an issue?

 

I do think it needs to be run outside of the unRAID environment (either from a boot menu option or automated during bootup) to ensure the flash is ready to be mounted when unRAID boots.

 

It has been suggested in other threads that a plugin (powerdown) could be the reason so many people are having to run chkdsk these days, so I don't think it would help a whole lot to run it prior to shutdown.

 

Even once that particular plugin is fixed I think unRAID would benefit from the ability to fix the flashdrive without having to use Windows.  I just setup a remote, headless (with IPMI) system for my sister and I need to be able to manage the system without having physical access to it.

I think there is a bit of a chicken and egg problem here.  If there is a problem on the flash device, wouldn't the boot process not occur at all anyway?

I think there is a bit of a chicken and egg problem here.  If there is a problem on the flash device, wouldn't the boot process not occur at all anyway?

Depends on how severe the problem with the flash is. Many syslogs from running systems have been posted with lines similar to this:

Jan  7 12:41:24 Unraid kernel: FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

Sometimes followed by this:

Jan  7 12:41:24 Unraid kernel: FAT-fs (sda1): Filesystem has been set read-only

so no configuration changes can be written.

Hmm.  I'll ask Tom about this.

Having chimed in on this, I'm not sure an automatic checkdisk on bootup is the right solution to this. Maybe alert the user instead of having to discover this if you happen to look at the syslog.

I'm sure there's a way to do it in the rc.S file,

check if UNRAID exists and issue the chkdsk command.

 

However we may want to consider doing it via a /proc/cmdline option.

 

i.e. if  FSCKUNRAID exists in /proc/cmdline, do the fsck on the UNRAID boot device.

 

Another idea is to check for a FSCKUNRAID flag as /boot/FSCKUNRAID

then umount the device, fsck it, then remount it and remove the flag.

 

Are there tell-tale signs in /var/log/syslog that can be tested with grep for this condition.

If so that could be used for an automatic unmount, fsck and remount.

 

I'm just not sure how safe it would be to automate this rather then having a /proc/cmdline option from the syslinux.cfg.

I'm just not sure how safe it would be to automate this rather then having a /proc/cmdline option from the syslinux.cfg.

Please do NOT automate it, at least not without the option to persistently disable the automation with a gui checkbox. Since the repair process could be run on a failing drive, I'd rather have the option to attempt a backup before any writes are done. There is a good reason why drives are set to read only when corruption is detected.

I think this has been implemented?  I see this in the 6.1 release notes:

 

slack: check USB Flash device upon startup (set 6th field of fstab to 1)

 

And then jonp's comment here:

 

6.1 runs a check disk automatically.

 

Are we really done with manually running chkdsk in another computer?  That would be great!

I think this has been implemented?  I see this in the 6.1 release notes:

 

slack: check USB Flash device upon startup (set 6th field of fstab to 1)

 

And then jonp's comment here:

 

6.1 runs a check disk automatically.

 

Are we really done with manually running chkdsk in another computer?  That would be great!

Just for the USB flash.

Just for the USB flash.

 

woohoo!  that is great news

So fsck is run when the server is started or is it run on boot? Just curious.

 

And how do I see the results?

So fsck is run when the server is started or is it run on boot? Just curious.

 

And how do I see the results?

 

It happens on boot, after the boot menu is shown and unRAID is selected and loaded, and a minimal kernel is running, but before anything on it is opened, probably before it was mounted at /boot.  It's not logged in syslog or dmesg, the only place I saw the output was on the attached console.

So I'm guessing it would repair the file structure but no notifications?

That was true for my system, and appears to be true for others.

Sorry for re-activating a 9 year old post, but has this feature been activated?

 

I ask as this morning I got  message "FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck."

 

And I am assuming if this feature was indeed enabled, I would not have gotten the above message.

 

Again sorry for re-activating this post.

 

Cheers from Nova Scotia...

See if your flash drive has FSCK files at the top level. These will result from running fsck

I was having web ui connection issue and found "May 29 10:37:58 unraid kernel: FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck." issue. I checked the flash drive and there is no FSCK files so far. I am running unraid: 6.12.10 in safe mode (right now). Any insights?