Questions for peaslaker and other Goflex net owners

[sambul13]

Do you connect it via a wireless router? Try ethernet port instead.

As to SATA disk, in addition to checking disk performance and bad blocks, run fsck to check rootfs partition integrity regularly, decrease SWAP to 128MB, reformat your movie partition to ext4 or XFS to combat file fragmentation, hook your 3.5" SATA HD to an external 12V power adapter. Make a habit to wait until your HD stops spinning completely before switching Off power to GFH, or run shutdown -hP now from SSH terminal that would dismount the drive before shutdown.

[maihoaomv]

I think I may have found the problem on my GFH that causes it not to boot. The RTC (real time clock, aka "hardware clock") is failing to keep proper time.

My unit has a bad battery that is supposed to keep the hardware clock running when the unit is powered off. When first powered on the date is set to a date prior to the current date causing e2fsck to fail. Thus it would stop at single user asking for user input. Netconsole, for me, was useless. You need a serial connection to the unit to see the problem.

A failing battery might explain the randomness of it not booting. Once I knew what the problem was and how to get around it I reinstalled a backup I had made of the OS after it refused to boot and for the most part it was working.

[moonman]

This should not affect boot as PogoPlugs don't even have hardware clock and only rely on ntpd. Since your battery died you can do the same: "nano /etc/rc.conf", scroll down to daemons, remove "hwclock" and insert "openntpd" instead.

[maihoaomv]

That's all fine and dandy except for one thing: the hwclock is still physically there, only it doesn't keep the time correctly. When the unit is powered on the hwclock regesiter defaults to some odd ball date like Apr 1903. It's causing problems with starting nfs, samba as well as causing fsck to fail. From what I've read, I take it that any date less than 1/1/1970 will cause problems.

I pulled the battery out but it still is causing problems. I looked on the internet for a replacement battery but was unable to find an AG13 (watch battery) with solder tabs welded to it to replace the bad one. But that could easily be fixed by adding an external AAA battery then soldering the leads to the pcb pads, but for now that's not what I want to do. I would rather do a software work around for the problem.

Is there some way I can tell it set the hwclock to some specific date (i.e. 10-28-2012) before it starts any of the daemons so that the hwclock date is reasonably within some time bracket so it doesn't cause the boot process to fail?

[sambul13]

As moonman said, its time to move on with hwclock by replacing it with openntpd. Really!

As to updating the date temporarily, use date MMDDhhmmYYYY command to set system clock.

[maihoaomv]

Yes, yes, yes I installed openntp when I first installed the tar ball on the hard drive so I've been using it for a long time and it's always worked fine until the battery failed and hwclock started coming up with extreme dates such as 1903. But openntp has the same problem as ntp: it refuses to reset the time because the date is so far out-of-range.

The hardware clock is the problem, that I'm fairly certain of, because if I set the hwclock to the correct time then reboot without removing power, the hardware keeps the correct time. Only when powered off does it go ape on me. Sometimes hwclock will randomly reset to a date (such as 2035) that openntp likes and the unit will boot all the way up without failing. I would like to find a temporary software solution for the problem until I can come up with a solution for the battery so I can use the server in the mean time.

Guess I'm going to have to do something about the battery instead, because I'm certainly not getting any useful input from here.

[bodhi]

@maihoamv,
Can you set up ntpdate to run earlier to set the time?

[sambul13]

My Dockstar doesn't have a place to put such battery into, but it keeps accurate time nonetheless.

[maihoaomv]

It's not a matter of keeping accurate time. It does that once I get it set correctly and provided I don't power it off again. Instead it's a matter of setting the hwclock to the correct time in the first place so OPENNTP (or ntp or whatever) takes over the job of keeping the time accurate. The hwclock is still physically on the goflex home. Battery or no battery the kernel sees it at boot time.

My understanding was that the hwclock's job is to keep a reasonably correct time during the time the unit is in a powered off state (thus the reason for a battery). Once the OS is up and running, system time, a kernel interrupt function, takes over the function of real time keeping. Other than getting it up and running at boot time the hwclock has little other function.

What is so hard about understanding that the hwclock (my guess would be a TOD chip on the board) still physically exist on my gfh even though there is no battery or a bad battery (the dockstar probably doesn't have a TOD chip. I don't have a schematic so I can't verify that either wayl). In case you don't know what a TOD is see this site for an explanation http://www.linuxmisc.com/3-solaris/da71e1a1092d7fe8.htm .

My guess would be the kernel probably sees the TOD (hwclock) when it's configuring hardware. If the hwclock happens to power up with some off-the-wall date like 1903 in the register then it can and does screw up fsck or causes nfs and samba not to start correctly. A very large out-of-date differential I suspect could cause other problems as well especially if the date happens to be a month or so less than what it should be.

The following is one of the problems I was having that I'm fairly certain was causing my gfh to fail to boot to a level where I could actually use it. Netconsle/ncat is useless once the kernel starts running and showed no output beyond "decompressing the kernel" message. Once I got the serial cable installed and working I was able to see what the real problem was. Pay special attention to what it says: "is in the future".

$this->bbcode_second_pass_code('', ': Checking filesystems [BUSY] DataDisk: Superblock last mount time (Tue Apr 14 07:35:30 1903,
now = Sun Oct 28 09:39:56 2012) is in the future.


DataDisk: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
[FAIL]

***************** FILESYSTEM CHECK FAILED ****************
* *
* Please repair manually and reboot. Note that the root *
* file system is currently mounted read-only. To remount *
* it read-write, type: mount -o remount,rw / *
* When you exit the maintenance shell, the system will *
* reboot automatically. *
* *
************************************************************

Give root password for maintenance
(or type Control-D to continue): ')

This is not a very good example I know but unfortunately I didn't capture the very first time I seen this problem. This was my data disk and other than the fsck times being screwed up it didn't fail fsck for any bad blocks.

While I had the unit open I checked the battery with a voltmeter and it was reading about .7 volts. The mfg spec sheet says that the AG13 battery is a 1.5V button cell with a 145mAh rating. It has a Cut-off Voltage of .9V which I interpreted to mean that when the voltage drops to less than .9V then the battery is considered bad. At .7V it's terminal, period.

I kind of come up with a software solution that seems to work most of the time. It's probably not the best solution being I'm still learning the inner workings of Linux. It's sometimes doesn't work but at least it's better than it was before where I couldn't get it booted to multiuser at all.

I dug into it deeper and after much google'ing I came across a site that talked about /etc/rc.sysint being the file that is ran at boot time. Just commenting out the hwclock (!hwclock) daemon in /etc/rc.conf is not enough to keep it from checking the hwclock. To do that I had to comment it out in the rc.sysint file (or hwclock excutable could be renamed). That helped and allowed it to come up so openntp could set the time correctly but it still occasionally screws up. I also ran tune2fs -i 0 to set the time interval fsck check to never and instead set it to run fsck every 10 or so boots (fsck ever so many boots seems to be more reasonable anyway for the way I'm using it).

$this->bbcode_second_pass_code('', 'File: /etc/rc.sysinit is ran at boot time

************commented out line 57*****************
hwclock $HWCLOCK_PARAMS && stat_done || stat_fail

************commented out lines 141-153 ************

#if [[ -f /etc/adjtime ]]; then
# ( read ; read ; read ADJTIME) < /etc/adjtime
#
# if [[ $ADJTIME == 'LOCAL' ]]; then
# if [[ $HARDWARECLOCK == 'UTC' ]]; then
# printf "${C_FAIL}/etc/rc.conf says the RTC is in UTC, but /etc/adjtime says it is in localtime.\n${C_OTHER}."
# fi
# else
# if [[ $HARDWARECLOCK == 'LOCALTIME' ]]; then
# printf "${C_FAIL}/etc/rc.conf says the RTC is in localtime, but hwclock (/etc/adjtime) thinks it is in UTC.\n${C_OTHER}."
# fi
# fi
#fi')

I power on the gfh and run it up when I need to use it then shut it down when I'm done (yeah I know it uses very little power in idle mode, but what the heck, a watt not used is a smaller electric bill) so leaving it on and running all the time is not an option for me. When it works it works great but when it doesn't it's frustrating. I just want to get a really better fix for this problem so I can forget about it and move on to the next problem.

So in conclusion if there is anyone out there who might know a better work around for this problem please let me know.

Thanks
maihoaomv

[WarheadsSE]

Just a heads up: this is from the dmesg on my GoFlex Net. It does not have an RTC chip/clock on the board.
$this->bbcode_second_pass_code('', '[ 3.692595] rtc-mv rtc-mv: internal RTC not ticking
[ 6.122878] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)')