Getting 'not currently mounted /cf' on embedded system running on flash

[ttblum]

Hello,

I just noticed I am getting 'Bandwidthd has nothing to graph' on one of my Alix 2D13 routers with a SanDisk SDCFH-004G card.  The log shows:

Dec 6 10:00:50 bandwidthd: Cannot open htdocs/index4.html for writing
Dec 6 10:00:50 bandwidthd: Cannot open htdocs/index4.html for writing
Dec 6 10:00:50 kernel: ad0: FAILURE - READ status=51 <ready,dsc,error>error=10 <nid_not_found>LBA=7813119
Dec 6 10:00:50 kernel: ad0: FAILURE - READ status=51 <ready,dsc,error>error=10 <nid_not_found>LBA=7813119
Dec 6 10:00:50 php: /pkg_edit.php: The command '/sbin/mount -u -w -o sync,noatime /cf' returned exit code '1', the output was 'mount: not currently mounted /cf'
Dec 6 10:00:50 php: /pkg_edit.php: The command '/sbin/mount -u -w -o sync,noatime /cf' returned exit code '1', the output was 'mount: not currently mounted /cf'
Dec 6 10:00:50 php: /pkg_edit.php: The command '/sbin/mount -u -r -f -o sync,noatime /cf' returned exit code '1', the output was 'mount: not currently mounted /cf'

I think the ad0 FAILURE message is supposed to be a harmless warning, but are the others more serious?

Is it recommended to run bandwidthd on a flash drive?</nid_not_found></ready,dsc,error></nid_not_found></ready,dsc,error>

[stephenw10]

Hmm, well that looks odd. /cf should definitely be mounted otherwise the config file cannot be read. Or anything in conf for that matter.
What do you see if you run the mount command from the CLI?
Here's some output from my local nanobsd box:

[2.0.1-RELEASE][root@pfsense.fire.box]/root(1): mount
/dev/ufs/pfsense0 on / (ufs, local, noatime, read-only, synchronous)
devfs on /dev (devfs, local)
/dev/md0 on /tmp (ufs, local)
/dev/md1 on /var (ufs, local)
/dev/ufs/cf on /cf (ufs, local, noatime, read-only, synchronous)
devfs on /var/dhcpd/dev (devfs, local)
[2.0.1-RELEASE][root@pfsense.fire.box]/root(2): cd /cf
[2.0.1-RELEASE][root@pfsense.fire.box]/cf(3): ls
.snap conf
[2.0.1-RELEASE][root@pfsense.fire.box]/cf(4): cd conf
[2.0.1-RELEASE][root@pfsense.fire.box]/cf/conf(5): ls
WGXepc                                  ez-ipupdate.cache                       rrd.tgz
backup                                  fdisk_upgrade_log.txt                   sshd
config.xml                              file_upgrade_log.txt                    upgrade_log.txt
dhcpleases.tgz                          firmware_update_misc_log.txt
dyndns_wannoip'******.hopto.org'.cache  readio

Steve

[ttblum]

2.0.1-RELEASE][admin@pfsense.localdomain]/root(1): mount

/dev/ufs/pfsense0 on / (ufs, local, noatime, read-only, synchronous)
devfs on /dev (devfs, local)
/dev/md0 on /tmp (ufs, local)
/dev/md1 on /var (ufs, local)

[2.0.1-RELEASE][admin@pfsense.localdomain]/root(2): cd /cf

[2.0.1-RELEASE][admin@pfsense.localdomain]/cf(3): ls

conf

[2.0.1-RELEASE][admin@pfsense.localdomain]/cf(4): cd conf

[2.0.1-RELEASE][admin@pfsense.localdomain]/cf/conf(5): ls

backup            config.xml        dhcpleases.tgz    ez-ipupdate.cache rrd.tgz          sshd

[2.0.1-RELEASE][admin@pfsense.localdomain]/cf/conf(6):

[stephenw10]

Hmm. So the config slice is not mounted as /cf but you can still cd into it and list it's contents. What….  :-\

How does that compare with your other Alix boxes?
Not something I know about I'm afraid.  :(

Steve

[ttblum]

Hi,

My other Alix routers look normal like the example you posted.

I'm just concerned about rebooting it in case there is a hardware problem, such as bad disk, etc.

Thanks,

Todd

[stephenw10]

Is that the only one running bandwidthd?

Steve

[ttblum]

I have bandwidthd running OK on at least two other Alix routers.  I have had the CF card fail on one of them before, but never this specific error.

[jimp]

If the /cf slice fails to mount, it would still write files into /cf/ on / - a little odd, but it happens.

I'd run:

fsck -y /dev/ufs/cf

And then see what that reports. If it's dead/not mounting, you may have a disk issue.

The main problem you'll have in your current state is that if you do a firmware update, you will lose your config because it's not on the shared config slice.

[ttblum]

OK. If there were a disk problem, any chance the fsck would bring the router down?

[jimp]

No, the /cf slice is already unmounted so unless the entire CF is about to blow, it's unlikely running a check on an unmounted/inactive slice will hurt anything.

[ttblum]

[2.0.1-RELEASE][admin@pfsense.localdomain]/root(1): fsck -y /dev/ufs/cf

Can't stat /dev/ufs/cf: No such file or directory
Can't stat /dev/ufs/cf: No such file or directory

[2.0.1-RELEASE][admin@pfsense.localdomain]/root(2):

[jimp]

sure you didn't do something like write an image to the card that was far too large?

I can't think of any reason why the slice would have just disappeared like that unless it was never written to the card. And since the cf slice is at the end of the card, if the image was too big (think writing a 2GB image to a 1GB card) then it may behave like that.

I suppose if the CF had a large number of bad sectors causing the disk to "shrink" it may also do that, but I don't think I've seen one act quite like that when it happens.