DSM-G600, DNS-3xx and NSA-220 Hack Forum

Swapping 36 & 37 seems have done the trick. So it went from this:

36 cp -f /mnt/HD_a2/ffp/share/e2fsck/libext2fs.so.2.4 /lib
37 rm -r /lib/libext2fs.so*

to this:

36 rm -r /lib/libext2fs.so*
37 cp -f /mnt/HD_a2/ffp/share/e2fsck/libext2fs.so.2.4 /lib

Now the badblock checking is working...

Thanks for the script, and the help on the small fix too!!



Of course now I look at that, it makes sense, we were copying it, then immediately removing it...oops!!

So for anyone who might want this script here it is in it's modified form:

#!/bin/sh

## This is for ffp (Fonz' Fun_Plug) 0.5 modified by SilentException
# write a log, in case sth goes wrong
FFP_LOG=/mnt/HD_a2/ffp.log
exec >>$FFP_LOG 2>&1

# Prepare terminal (simplified fun_plug, based on 0.4)
# maybe not needed, cannot do any harm tho :)
if [ ! -e "/dev/ptmx" ]; then
mknod -m 0666 /dev/ptmx c 5 2
fi
if [ ! -d "/dev/pts" ]; then
mkdir -p /dev/pts
fi
mount | grep devpts 1>/dev/null 2>/dev/null
if [ $? -ne 0 ]; then
mount -t devpts devpts /dev/pts
fi

# Replace busybox
cp -f /mnt/HD_a2/ffp/share/e2fsck/busybox /bin

# Set up telnetd
ln -snf /bin/busybox /sbin/telnetd

# Start telnetd
/sbin/telnetd -l /bin/sh

# Create killall for choking smbd and nmbd
ln -s /bin/busybox /bin/killall
ln -s /bin/busybox /sbin/fdisk

# Copy newer version of e2fsck
cp -f /mnt/HD_a2/ffp/share/e2fsck/e2fsck /sbin
cp -f /mnt/HD_a2/ffp/share/e2fsck/badblocks /sbin
rm -r /lib/libext2fs.so*
cp -f /mnt/HD_a2/ffp/share/e2fsck/libext2fs.so.2.4 /lib
ln -s /lib/libext2fs.so.2.4 /lib/libext2fs.so
ln -s /lib/libext2fs.so.2.4 /lib/libext2fs.so.2
cp -f /mnt/HD_a2/ffp/share/e2fsck/libcom_err.so.2.1 /lib/
ln -s /lib/libcom_err.so.2.1 /lib/libcom_err.so.2
ln -s /lib/libcom_err.so.2.1 /lib/libcom_err.so

# Run this manually from the command line
# Do not ever kill samba in fun plug
#
# killall smbd
# killall nmbd
# umount /dev/md0
# e2fsck /dev/md0
#
# or
#
# umount /dev/md0
# e2fsck -v -f -c /dev/md0
# you could also add the -y flag to answer yes to any questions, but you might not want that...
# or
# badblocks -v -s -n /dev/md0

You'll still need to download the package from SilentException from here http://dns323.kood.org/forum/p14563-Tod … tml#p14563
but replace the fun_plug.disk_check with this one. Place them in /mnt/HD_a2 as instructed there and manually unpack the e2fsck....tgz and so forth.

This script is generally for temporary use to create a modified environment to allow for the disk check, so likely you'll want to do something like this

cd /mnt/HD_a2
mv fun_plug fun_plug.normal
cp fun_plug.disk_check fun_plug
chmod a+x fun_plug
reboot

You'll now have a minimal environment with only a telnet shell. Login via telnet and run the 2 killall commands listed, and the umount. Then choose one of the e2fsck or badblocks commands you want to run...then wait, and wait, and wait, etc...

When it's done you can remount your drive like so:

mount /dev/md0 /mnt/HD_a2
cd /mnt/HD_a2

## swap your fun_plug scripts
mv fun_plug fun_plug.disk_check

## or if you did a "cp fun_plug.disk_check fun_plug" previously
# rm fun_plug

cp fun_plug.normal fun_plug

## make sure fun_plug is executable
chmod a+x fun_plug

## reboot to get back to your normal environment
reboot

Last edited by SuperInsanity (2008-05-11 23:11:22)

UPDATE from post above

Took the plundge and rebooted the DNS, all started fine.

just running a `cp` copy from one drive to the other, may give a full reformat and start fresh. (always nice)

A shame that theres no CheckDisk function built in to the DNS, I read in the forum about a firmware that had scandisk built in (1.05b3 I think) did that ever happen?? Would be nice to perform regular maintenance on the file system.

Food for thought, as my mum always says

Hallo,
i also need this package, is it possibe to re-upload or send me this file?

thx very much.

Patrick

SilentException wrote:

i hope i didnt forget anything, let me know how it goes

Hi, thank you very much for sharing!

Unfortunately, I did not get it to work:

/mnt/HD_a2 # umount /dev/md0
umount: /mnt/HD_a2: device is busy
umount: /mnt/HD_a2: device is busy

I killed nearly every daemon but the error persists

/mnt/HD_a2 # ps
PID   USER     COMMAND
    1 root     init
    2 root     [ksoftirqd/0]
    3 root     [events/0]
    4 root     [khelper]
    5 root     [kthread]
   11 root     [kblockd/0]
   14 root     [khubd]
   50 root     [pdflush]
   51 root     [pdflush]
   53 root     [aio/0]
   52 root     [kswapd0]
  190 root     [scsi_eh_0]
  191 root     [scsi_eh_1]
  201 root     [mtdblockd]
  219 root     [kcryptd/0]
  220 root     [kmirrord/0]
  232 root     [loop0]
1107 root     [md0_raid1]
1379 root     SyncMms
1380 root     getMsg
1392 root     -sh
1500 root     /sbin/telnetd -l /bin/sh
1511 root     /bin/sh
1551 root     ps

Any ideas?

SilentException wrote:

try to do cd ..

Sorry, I don't get it (I'm a linux noob!)... cd .. where to? Even cd / did not work...
I tried fuser -m /dev/md0 (the only option that seems reasonable) to check on used files etc. but there was no return either.

silversurfer wrote:

lsof | grep HD

Silversurfer,

thank you very much for your hint! I tracked down the "bugger":

/ # lsof | grep HD
telnetd   1500 root  cwd       DIR        9,0   4096         2 /mnt/HD_a2

This is strange, since telnetd seems to be the run from /sbin:

1500 root     /sbin/telnetd -l /bin/sh


I'm still stuck.

silversurfer wrote:

Maybe it helps to change the start of telnet a bit. In the funplug change:

Code:

# Start telnetd
/sbin/telnetd -l /bin/sh

to

Code:

# Start telnetd
cd /
/sbin/telnetd -l /bin/sh

Good luck!

Thank you very much, your valuable hints helpt me out to get it working finally!

Last edited by thomaskunze (2008-07-20 19:49:49)

I had a small idea recently how this approach might become simpler to use.

You're copying busybox, e2fsck and libs to/over the firmware files in /sbin, /lib, etc. You're clearly restricted in how much you copy by the remaining free space in the ramdisk (2M on my box). Also, you need to swap fun_plug scripts, and a reboot to enter the filesystem check mode.

I think it's possible to increase the ramdisk size, and to switch to the fsck tools in ramdisk without swapping fun_plug scripts and without reboot. Here's the idea.

Instead of adding/replacing files in the firmware ramdisk, create a separate, ram-based, tree using tmpfs:

mkdir /fsck
mount -t tmpfs tmpfs /fsck

I don't know the exact limits, but in a quick test, I could easily put 30MB into /fsck before getting out of space errors. Of course, the more you put in /fsck the less RAM you will have to run programs - but there's pleanty of swap, and speed isn't that important for fsck.

Next step is to populate /fsck with the filesystem check tools. For simplicity of the description, I'll use my filesystem check ramdisk archive ( http://www.inreto.de/dns323/fsck/fsck-initramfs.gz ), but this can easily be replaced with something different. To unpack the archive, you need the cpio-2.9 package (busybox's cpio doesn't support the 'newc' cpio archive format).

cd /fsck
zcat /ffp/fsck/fsck-initramfs.gz | cpio -id

fsck-initramfs.gz is actually ffp again. It contains an ffp directory where all the programs are installed. This way, we can later relink  /ffp to /fsck/ffp to switch to the filesystem check tools in RAM.

Approach 1 Using the above simple steps, and a slightly modified fun_plug can already be sufficient. Some Linux distributions allow the user the set a flag (by creating some special file, e.g. /ffp/etc/run-fsck) to trigger a filesystem check after reboot. A modified fun_plug script could check for such a flag file, and if found, do the steps above, link /ffp to /fsck/ffp (instead of /mnt/HD_a2/ffp) and proceed as normal (i.e. run /ffp/etc/rc). The ffp installed in fsck-initramfs.gz will start a telnet server. You should then be able to log in as usual and do your filesystem check after killing samba. The modified fun_plug script should remove the special flag file, so the next boot will be back to normal.

Approach 2 A little more tricky approach is needed to switch to /fsck/ffp on demand, without reboot and flag file. We need to stop all processes that keep the disks busy. Unfortunately, this includes killing the telnet/ssh server that we're connected to. Here's a sketch of a bash script ( http://www.inreto.de/dns323/fun-plug/0. … .html#bash ):

Before killing processes, we need to detach so killing the telnet server won't kill the script, too:

cd /tmp
exec >/dev/console 2>&1 </dev/null
trap 'echo HUP' HUP

We cd to /tmp to ensure that the current working directory is on the ramdisk. The 'exec' command will redirect script output to the console (serial port), detaching from the telnet session. 'trap' will catch the 'hangup signal' that, if not trap'ped, would terminate the script when the telnet/ssh server dies.

Now stop the currently running ffp:

reverse_list()
{
        _list=
        while [ $# -gt 0 ]; do
                _list="$1 $_list"
                shift
        done
        echo $_list
}
files=$(reverse_list $(rcorder /ffp/start/*.sh))
for f in $files; do
        if [ -x "$f" ]; then
                echo "$f stop"
                $f stop
        fi
done

'reverse_list' is a simple helper function to reverse the order of the start scripts. It's used to run the scripts in /ffp/start in reverse order.

If desired/necessary, we can now kill everything that's left:

killall5 -TERM
sleep 2
killall5 -KILL
sleep 1

'killall5' is an oldish, but useful utility, that kills everything except us.

The remainder is straight forward: unmount disks, relink /ffp, start it

sync
for f in /mnt/HD_*; do
        umount $f
done

ln -snf /fsck/ffp /ffp
/ffp/etc/rc

What do you think?

waal70 wrote:

Works like a charm for me (I am on a CH3SNAS, ffp 0.5, firmware 1.04rc5). I went with the on-line flip-flopping of the ffp-runtime (no reboot required).

Thanks for confirming that it actually works. Mind sharing your scripts?

Well this may be cheating, but one way to avoid all this is to use a cheap USB stick and run fun_plug from there. Then you can unmount the drives at will and have the full power of the fun_plug add-ins.

I use the following version of setup.sh which must be placed in /mnt/HD_a2/.bootstrap (unless you modify the location defined in the default fun_plug script). The goal here was to write a script that requires no modification of fun_plug.
Note the section on redirecting the logging to a log directory is optional -- I only do it to clean up the root directory of HD_a2.

All you need to do is format a usb disk in ext2 and make sure that the shell variable USBPART is set correctly. You also need the module usb-storage.ko which I place in the directory /mnt/HD_a2/.bootstrap but can be changed using the shell variable USBMODULE

To boot from the usb disk, just "touch" (i.e. create) the file .usb-boot in the root directory of the usb disk. To go back to "standard" booting from the hard drive either remove the file .usb-boot or remove the usb disk

Note that I *purposely* formatted an ext2 partition on /dev/sdc5 since that will avoid confusion/conflicts with standard default vfat-formatted usb disks that usually used /dev/sdc1. But you can choose any partition number if you change the variable USBPART.

[NOTE I would have *loved* to use mount -U <UUID> but the version of mount on the dns-323 doesn't support it]

NOTE: most of the script consists of sanity tests.


#!/bin/sh
### setup.sh - Custom initialization script
USBMODULE=/mnt/HD_a2/.bootstrap/usb-storage.ko
USBPART=/dev/sdc5
USBMOUNT=/mnt/usb
LOGDIR=/mnt/HD_a2/log

# Redirect boot logging
[ -z $FFP_LOG ] && FFP_LOG=/mnt/HD_a2/ffp.log
OLDFFP_LOG=$FFP_LOG
FFP_LOG=$LOGDIR/ffp.log
touch $FFP_LOG 2> /dev/nul
if [ -d $LOGDIR -a -w $FFP_LOG ] ; then
     cp $FFP_LOG ${FFP_LOG}.bak
     [ -r $OLDFFP_LOG ] && cat $OLDFFP_LOG >> $FFP_LOG
     exec >>$FFP_LOG 2>&1
     [ -w $OLDFFP_LOG ] && rm -f $OLDFFP_LOG
fi

# Install usb module
( /usr/sbin/lsmod | grep -q usb_storage )
RETVAL=$?
if [ "$RETVAL" -eq 1 ] ; then
    /usr/sbin/insmod $USBMODULE
    sleep 60  # Wait for disk to be recognized
fi

mkdir -p -m 755 $USBMOUNT
( /bin/mount | grep -q $USBPART ) || \
  /bin/mount $USBPART -t ext2 $USBMOUNT 2>/dev/null
RETVAL=$?
if [ "$RETVAL" -eq 1 ] ;then
    echo "Failed to mount $USBPART on $USBMOUNT"
    exit
fi

/bin/mount | grep -q "$USBPART on $USBMOUNT type ext2 (rw)" 2>/dev/null
RETVAL=$?
if [ "$RETVAL" -eq 0 -a -f $USBMOUNT/.usb-boot -a -d $USBMOUNT/ffp ] ; then
    echo Booting from usb...
    FFP_PATH=$USBMOUNT/ffp
else
    echo Booting from /mnt/HD_a2/ffp...
fi

waal70 - you are correct - but it is still a safe and easy alternative to allowing user to unmount the main disk partitions.

sarge_in wrote:

e2fsck 1.40.6 (09-Feb-2008)
/dev/sda1 is mounted.

WARNING!!!  Running e2fsck on a mounted filesystem may cause
SEVERE filesystem damage.

Do you really want to continue (y/n)? no

check aborted.
--------------

Should I go ahead with the check anyways?!

Hi sarge_in,
Never ever ever ever run e2fsck on a mounted filesystem, unless you're a super-expert and know exactly what you are doing. You could seriously damage your filesystem by running it on an mounted FS! The warning is there for a good reason.
Unmounting should always be possible (...), no matter what difficulty you have in doing the actual unmount. It's just a matter of troubleshooting up to the point of finding what is preventing an unmount. So that's where we're at with your situation right now...

You say you've followed the thread and used the replace/move of the original fun_plug. A bit later in the thread there is a suggestion on how to do this without actually replacing your fun_plug (that's where I start meddling in the thread as well). Could you also try this method to see what happens?

Hang on in there, chances are the "e2fsck is recommended" is not indicative of a serious problem (yet). I guess there are literally 1000s of people running their NAS'es with this (unseen) message. So take your time in figuring it out (for example try the alternative unmount suggested above) and resist the temptation of running e2fsck on a mounted volume!

Cheers!

Last edited by waal70 (2008-10-23 10:50:59)

sarge_in wrote:

RAMDISK: Compressed image found at block 0
EXT2-fs warning: maximal mount count reached, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).

So, the question I now have is:
1. Is having sda4 and sdb4 'normal'? None of the posts I have seen here seem to reference them.
2. I also see a sda1 and sdb1 in log messages. Is that normal, and do I need to run e2fsck on them as well?
3. Will (2) take care of the 1 last e2fsck message I am getting? And if not, what am I missing?!

Thanks!!

Hi sarge_in,

Looks like you did a nice job troubleshooting your situation. The BASH-error may be related to not having the actual BASH (shell) available on your system. To do this, you should get the bash-package (http://www.inreto.de/dns323/fun-plug/0. … -3.2-3.tgz) from Fonz's site and install it. 'My' script will then take care of putting it in the right location.
Anyway, this for future reference, as you already seemed to manage quite well with an alternative.

Now for your questions:
1. Yes, having sda4 and sdb4 is quite normal (they're also on my system). I believe these devices have the swap volumes for the drives configured on them. e2fsck'ing them is also perfectly normal.

2. I don't think I have those, I certainly never ran an e2fsck on them. If they are proper drive-devices (like sdb2 and sdb4), e2fsck will inform you whether it is safe to run on there and there is no harm in doing so.

3. The answer is no, but OK, bear with me on this one, as it requires a little more text and could be a tough read:
I think the last e2fsck message you're getting is related to a volume that gets mounted from a fixed image.
Allow me to elaborate: Think of an .ISO file for CDs. The .ISO actually represents a whole filesystem, which is pretty obvious to see after you've burned this image.
The DNS-323's so-called 'root volume' gets loaded from your device's firmware (like from an .ISO). So there is a 'whole filesystem' somewhere in the firmware image, which on device boot-up gets loaded ("burned") into the device's memory. If you shut down the device, power will be lost on the memory and therefore the 'burned filesystem' will be lost from memory.
After you reboot the device, the cycle starts again, putting the root volume image back into memory again. The OS, Linux, doesn't really care if the filesystem it's using is on a HDD, or is actually more like a RAM-drive. As far as the OS is concerned, it is a proper volume.
If you were to create a file on this root-volume, you would notice that it would disappear after powerdown. This is due to the fact that the file you created is actually not in the filesystem image (it's not in the ISO, it's not in the firmware), and therefore on a reload of this image it will not return. This is also the reason why the things like Fonz's fun plug are based on an 'actual' drive, ensuring any changes you make will be kept after powerdown (this is I think core business for any HDD ).
So the thing to remember is that any change to this filesystem will be canceled upon reboot.

Now here is the catch: as you would with creating an ISO, this volume was probably created using another system and the developers probably went through several cycles in improving the image. In doing so, they could have affected things like mount-count, filesystem integrity, e2fsck status etc. If they then went on and created the image from this system without first running e2fsck, these things would get imprinted into the image. You could go ahead and fix those errors, but on every reboot, the image would be reloaded and since all changes to this volume are canceled upon reboot, also the filesystem-fix changes would be canceled.

So in short, it looks like the error is coming from the root volume (check the neighboring lines for the last e2fsck-message in your logfile), but since this is a fixed image (embedded somewhere in the firmware), there is no way to permanently fix this, unless you would create your own firmware and/or we are provided with a new firmware without these FS-errors.

To re-cap: I don't think this last e2fsck is coming from the sda1/sdb1 devices, but rather from the device's firmware, so e2fsck'ing them will not clear the error. e2fsck'ing the root volume is quite an arduous task I think, and any effort you put in, will be lost on reboot, so I think you'll have to live with this error. The good part is that the errors cannot lead to any permanent damage, as you start off with a brand new root-volume every time. This could also be the reason the firmware-guys left it in: if it is not in any way degrading functionality now, it will never 'grow' to be a bigger problem and therefore safe to keep in.

That's a long story, hope it helped clear things up a little.

Cheers

Last edited by waal70 (2008-10-24 15:06:37)