dying USB rootfs Iomega EZ

Hi,

I've got a Iomega EZ running Debian at my parents house for doing local backups of their phones and tablets. I just logged in to check everything is still running OK and it seems the USB drive with the rootfs is dying. I can't use sudo to run apt-get update and there seem to be file system issues. dmesg shows the following output:

[2163755.377304] EXT2-fs (sdb1): error: ext2_check_page: bad entry in directory #64001: : unaligned directory entry - offset=0, inode=64001, rec_len=1038, name_len=1
[2163755.391933] EXT2-fs (sdb1): error: remounting filesystem read-only
[2163755.398707] EXT2-fs (sdb1): error: ext2_readdir: bad page in #64001
[2163755.405410] EXT2-fs (sdb1): error: remounting filesystem read-only
[2163784.892649] EXT2-fs (sdb1): error: ext2_readdir: bad page in #64001
[2163784.899571] EXT2-fs (sdb1): error: remounting filesystem read-only

Is there anything that can be done through vpn / ssh to fix the file system errors or should I just replace the USB drive next time I visit them?

Koen

I can't use sudo but su still works. Unfortunately fsck gives a segmentation fault. Are there any other options to check and fix the filesystem?

root@debian:/# fsck.ext2 /dev/sdb1
Segmentation fault

Koen,


-------------------------------------------------------
> I can't use sudo but su still works. Unfortunately
> fsck gives a segmentation fault. Are there any
> other options to check and fix the filesystem?
>
>

> root@debian:/# fsck.ext2 /dev/sdb1
> Segmentation fault
>

I dont think this can be fixed remotely. You can send them a USB rootfs if you have backup. And use EXT3 for rootfs, EXT2 is prone to be corrupted like that.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

OK thanks. I can't connect using openvpn anymore so I guess it must have died completely in the mean time. I tried to setup a ext3 rootfs originally but couldn't get it to work. I'm not sure if ext3 booting is supported in stock uboot. I'll order a proper Sandisk USB stick instead of this unbranded one and redo the setup when I visit them next week.

Koen

Koen Wrote:
-------------------------------------------------------
> OK thanks. I can't connect using openvpn anymore
> so I guess it must have died completely in the
> mean time. I tried to setup a ext3 rootfs
> originally but couldn't get it to work. I'm not
> sure if ext3 booting is supported in stock uboot.
> I'll order a proper Sandisk USB stick instead of
> this unbranded one and redo the setup when I visit
> them next week.
>
> Koen

Yes, Ext3 and Ext2 use the same driver in stock Marvell uboot. This Iomega EZ uboot is practically same as other Kirwood boxes uboot.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Koen Wrote:
-------------------------------------------------------
> I can't use sudo but su still works. Unfortunately fsck gives a segmentation fault. Are there any other options to check and fix the filesystem?
>
>

> root@debian:/# fsck.ext2 /dev/sdb1
> Segmentation fault
>

>
I haven't encountered a segfault like that. However, you can try it with a force check and/or fix using the -fy switches, i.e. fsck.ext2 -fy /dev/sdb1. Remember, this will forcefully write to your storage and may cause some further damages. So, if you have some data you can still access, try to back up those data first before you perform this operation.

When you see the segfault executing commands, please stop, don’t try to fix it without a reboot.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

> Yes, Ext3 and Ext2 use the same driver in stock
> Marvell uboot. This Iomega EZ uboot is practically
> same as other Kirwood boxes uboot.

Thanks for the additional info. I'll prepare an etx3 rootfs on the new Sandisk USB stick when it arrives.

bodhi Wrote:
-------------------------------------------------------
> When you see the segfault executing commands, please stop, don’t try to fix it without a reboot.

Bodhi,

Yes, when a running rootfs gives the segfault messages, the best options are either to reboot and/or shutdown the system. For a shutdown, the the rootfs on an external storage can be simply checked for its integrity using another Linux computer. After all, it just makes no sense trying to fix a running rootfs.