Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
In short:
1. Hd_a4 (sda4) and HD_b4 (sdb4) are regular ext2 partitions (not swap) that on my system are used by the firmware to store some samba and other user configurations. They may also be used with Bittorent (but I don't use them). They are purely regular ext2 partitions and should be fscked just like any other linux partition
2. sda1 and sdb1 are the swap partitions - they should not/can not be fscked. They are by definition volatile between boots
3. As waal mentioned, you can't get permanently rid of the last message since the RAMDISK linux filesystem is in firmware and must have exceeded its mount count before it got burned to firmware. But it works so don't worry about it (if you are worried, you can run fsck against it once and reassure yourself that the filesystem is intact)
Offline
Thanks for the so-elaborate explanation! It really clears up things for me now - sounded so straightforward once I read through it! I will ignore the last issue for now. Hopefully the imminent 1.6 firmware may fix it?! We will see..
Just curious though, if this is in the firmware, would everyone with 1.5 see this error?
Now that the filesystems are taken care of, on to the next project of installing Twonky
Offline
It's not really an error at all. All it means is that the writers of the firmware haven't run fsck recently. Since the filesystem is clearly fine there is nothing wrong.
And since mortal users were not meant to read the kernel syslog, there is really no reason for them to remove something that after all is only really a "suggestion" to run fsck.
Offline
puterboy wrote:
In short:
Ah, it *can* be done
Offline
fonz wrote:
skydreamer wrote:
# Do not ever kill samba in fun plug
What's the problem with killing samba in fun_plug?
I think he is concerned that if the fun_plug is buggy and fails to get any telnet or ssh access up AND the samba server is dead, you're locked out of the box.
I think that the op_server does respawn the samba servers from time to time. If you do get locked out this way, there would be a couple of options which are more or less painful depending on your setup. You could mount the disk on a PC linux system and delete the fun_plug. You could install this disk as disk 2 and a new or working fun_plug on disk 1, ....
Offline
waal70 wrote:
fonz wrote:
Mind sharing your scripts?
Nope, not at all...
...
So far so good. On my device, however, most of the times the umount /mnt/HD_a2 command needs to be repeated. Right now I lost the SSH-session, so I can only use less secure telnet to go the device. For me this is okay, luckily, e2fsck is not necessary all that often and right now I could not really be bothered with changing the temp fs to also do the SSH-thing. Still, it could be considered a TO-DO...
....
I like this basic idea. I really like being able to get reliably back out of the filecheck mode into run mode with no problems and no reboot. I'm going to try to combine it with the way I've been doing this and see if I can end up with a best of both worlds somehow. My script kills everything except the minimum needed to log in and reboot, namely utelnetd and chkbutton. I'm not entirely sure how to get back up from there though. I like having the tools on a ramdisk.
By the way, mount -t tmpfs has -o options, one of which is size=
If you use size=9M, it should be plenty. The default size is 30M.
I believe that either I have a misunderstanding, or you have a bug in your first script. You are calling the bash that lives on the hard drive to run a script that lives on the hard drive, then you try to unmount the drive. I don't think you will be able to unmount that drive from that script. Also, it looks like samba might remain active and prevent an unmount. Have you seen that?
Offline
I had one more question about this.
It looks like you're trying very hard not to use the e2fsck on the flash.
Is there something known bad about this version?
Offline
talkingRock wrote:
I believe that either I have a misunderstanding, or you have a bug in your first script. You are calling the bash that lives on the hard drive to run a script that lives on the hard drive, then you try to unmount the drive. I don't think you will be able to unmount that drive from that script. Also, it looks like samba might remain active and prevent an unmount. Have you seen that?
Hehe, that's what made it necessary to re-unmount sometimes. Well spotted!
I've been happily obliging my unit by re-running the umount command. I think I will go and fix it. Obvious solution would be to hand over to temp volume, ofcourse...
Offline