Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
I'm running into a weird behavior. I've got a DSM-G600 running a custom kernel (but derived, as all seem to be, from D-Link's version of 2.4.19-pre4), and hdboot-ing gentoo-embedded. However, I've also noticed the behavior I'm about to describe when using the custom firmware from this site.
Basically, I can't fsck the largest partition on the hard drive.
/dev/sda1 512MB swap
/dev/sda2 5GB ext3
/dev/sda3 150GB ext3
/dev/sda4 5GB ext3
I can fsck both sda2 and sda4, but when I try to do sda3, I get the following message after about 5 minutes:
/dev/sda3: e2fsck cancelled
/dev/sda3: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda3: ***** REBOOT LINUX *****
/dev/sda3: ********** WARNING: Filesystem still has errors **********
But I didn't cancel anything. It's as if there a watchdog I don't know about somewhere, observing this process taking a long time, and doing a lot of disk activity, and deciding, "No, bad doggie!"
Does anybody know about something like this, either built into D-Link's kernel or (ugh) a hardware watchdog?
Offline
For larger file systems, e2fsck needs a lot of (virtual) memory. In my early experiments with it, it always got killed by the OOM killer - until I activated swap. Have you had a look at the syslog?
Offline
BertandB: yes. In the first case (hdboot) I'm (trying to do) it at bootup during the normal gentoo boot sequence. In the second case (custom firmware), yes, I unmount /dev/sda3 and run the firmware's e2fsck binary.
I can't manually run fsck on /dev/sda3 when hdbooting because /dev/sda3 is my gentoo root partition.
fonz: well, no, I haven't been able to look at syslog when in hdboot mode, because this is the root partition-- there is no syslog running yet as I'm fsck-ing the gentoo root partition during bootup. When I tried it in firmware mode, I didn't think to look at the syslog at that time. I'll flash the firmware kernel back in and try it.
But I do have swap activated: 512MB of it. Surely that's enough?
Oh. Wait. By default, the firmware doesn't use swap unless you explicitly swapon, right? And during checkrootfs in gentoo-hdboot, maybe swap has not yet been mounted....yes, that is the case.
OK, maybe the OOM killer got me. I'll try to re-order the boot sequence so that swap is activated prior to checkrootfs. (There's nothing inherent in swapon that requires root to be mounted read-write, correct?)
Offline
Well, that did it: I moved swapon to earlier in the boot process, and then fsck succeeded. Thanks!
Offline