On 20/04/15 09:42, Mark Rogers wrote:
On 17 April 2015 at 20:05, steve-ALUG@hst.me.uk wrote:
Just a thought - did you create forcefsk in the the correct place? Try creating one in each "root" directory of each SD card, then rebooting.
There is only one SD card, although the device has on-board flash which isn't being used (and which is /dev/sda, which confused me previously).
I suspect it's irrelevant, but if you have multiple partitions on the SD card, create a forcefsck in each of the partitions and try again, but I suspect that's futile. I'll comment below.
It isn't mounted, although may well be where grub is installed (how do I check?)
er.... Let Me Google That For You.... http://lmgtfy.com/?q=where+is+grub+installed
"mount" says that / is /dev/root, and /dev/root is a symlink to /dev/sdb2
Something isn't quite right here; looking at the output of dumpe2fs the disk is well past the point at which a scheduled fsck should have run but it isn't happening, any ideas? (Mount count = 62, vs maximum mount count 23; last check Sept 2011, check interval 6 months, next check Feb 2012...)
(Also of note: the "Last mounted on" doesn't make any sense, as clearly it was last mounted as / on the device, but what it's showing is from mounting in a card reader on a colleagues' PC months ago.)
$ sudo /sbin/dumpe2fs /dev/sdb2 dumpe2fs 1.42.5 (29-Jul-2012) Filesystem volume name: dp-rootfs Last mounted on: /media/glenn/dp-rootfs Filesystem UUID: e671a042-62bc-4888-b8f6-7f68dbe6b941 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file Filesystem flags: unsigned_directory_hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 238560 Block count: 954009 Reserved block count: 47700 Free blocks: 277956 Free inodes: 212179 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 232 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 7952 Inode blocks per group: 497 Filesystem created: Thu Sep 1 18:00:30 2011 Last mount time: Fri Apr 17 16:48:48 2015 Last write time: Fri Apr 17 16:48:48 2015 Mount count: 62 Maximum mount count: 23 Last checked: Thu Sep 1 18:00:30 2011 Check interval: 15552000 (6 months) Next check after: Tue Feb 28 18:00:30 2012 Lifetime writes: 1736 kB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 First orphan inode: 135223 Default directory hash: half_md4 Directory Hash Seed: 947f9517-4f4a-4c2d-b87a-7315cc8869eb Journal backup: inode blocks Journal features: journal_incompat_revoke Journal size: 64M Journal length: 16384 Journal sequence: 0x00253b6b Journal start: 8660
Mark
I suspect it's borked, big-time rub-a-dub-style. I don't think you're going to fix this with a power-on fsck. I think you're going to have to attach it to another computer and run fsck on it whilst the drive isn't mounted on the file system. I suspect that copying off the files, then formatting it and starting again is going to be the quickest way of proceeding. Alternatively, if you need to keep the machine running mostly, could you duplicate the sd card with DD or similar, then swap to using the duplicated sd card, then send the original faulty card to you for you to check at your leisure?
Good luck, Steve