HELP!: Can't get WebIF up or login via SSH

I don't think it matters what is already on the Hard Disk or what condition it is in, If there is a USB device holding a valid firmware image it should be installed. It has been reported (I have had it happen myself) that a Flash that has worked in the past won't work now, I would ensure that flash device is re-formatted (FAT32) because the Humax can't handle fragmented files
 
Ok thanks for the tip, another USB stick is now working.

Just put the CF on, but the WebIF full install is still failing:

Code:
* pkg_write_filelist: Failed to open /mod/var/opkg/info/jim.list: Input/output error.
* opkg_install_pkg: Failed to extract data files for jim. Package debris may remain!
* opkg_install_cmd: Cannot install package webif.
 
Error installing packages. Please try again.

I could do a HDD format, but I'd really like to get all my programs off first.
 
Ok thanks for the tip, another USB stick is now working.

Just put the CF on, but the WebIF full install is still failing:

Code:
* pkg_write_filelist: Failed to open /mod/var/opkg/info/jim.list: Input/output error.
* opkg_install_pkg: Failed to extract data files for jim. Package debris may remain!
* opkg_install_cmd: Cannot install package webif.
 
Error installing packages. Please try again.

I could do a HDD format, but I'd really like to get all my programs off first.
Is the FTP working. If so copy everything off, even encrypted stuff, format the disk load the factory firmware, then the CF, then ftp all the files back. The CF will then decrypt the files.
 
This looks like the problem:

Code:
humax# ls -la
ls: ./jim.list: Input/output error
drwxr-xr-x    2 root    root        12288 Jul 31 19:23 .
drwxrwxrwx    4 root    root        4096 Jul 31 17:54 ..
?---rwxrwx  72 4194389  3932223  5570623 Dec 13  1901 inotify-tools.list
?--x--xrwx  124 4128844  6160401  4980815 Apr  5  1970 jim-oo.control
?--x-wxrw- 40960 100      root      6553694 Mar 17  1970 jim-oo.list
?---------  82 32768    -21474832189591170 Mar  4  1970 jim-sqlite3.control
?--x------  78 4587596  5111868  4980800 Mar  1  1970 jim-sqlite3.list
-rw-r--r--    1 root    root          173 Jan 28  2012 jim.control
-rw-r--r--    1 root    root          18 Apr 13  2011 mongoose.conffiles
-rw-r--r--    1 root    root          195 Jan 19  2012 mongoose.control
-rw-rw-rw-    1 root    root          96 Jul 31 17:54 mongoose.list
-rwxr-xr-x    1 root    root          481 Jan 19  2012 mongoose.postinst
-rwxr-xr-x    1 root    root          53 Apr 13  2011 mongoose.prerm
-rw-r--r--    1 root    root          190 Jun 28 18:53 webif-channelicons.control
-rw-rw-rw-    1 root    root        35954 Jul 31 17:54 webif-channelicons.list
humax#
humax#
 
Not sure if fix-disk is running correctly. I run ./fix-disk and it ask if I'm sure (Y/N)

If I reply 'Y', it looks like it aborts. If I type 'yes', I just get an endless screen of 'y' scrolling up. Is that whats supposed to happen, the Wiki pages says it reboots into maintenance mode?
 
I'm not sure what the fix-disk package does but it probably automates what I suggest you do :

1. Start telnet then type (without the numbering)
2. open [humax quad IP address]
3. touch /mod/boot/maintenance.boot
4. reboot (yes type it and wait for it to restart)
5. open [humax quad IP address]
6. umount /dev/sda1
7. umount /dev/sda2
8. umount /dev/sda3
9. e2fsck /dev/sda1
10. WAIT while it finishes - if it asks to confirm fixes say Y
11. e2fsck /dev/sda2
12. This could take 20 or more minutes for 500GB drive - WAIT while it finishes - confirm fixes if it asks - there could be hundreds - be patient
13. e2fsck /dev/sda3
14. as 10.
15. reboot


Do this with any external devices/USB removed
Do not attempt it with a wireless connection - use wire
By doing this manually you may see where things fall over

The endless stream of "y's" is disturbing.... I have a niece like that ....
 
I'm not sure what the fix-disk package does but it probably automates what I suggest you do :

It also creates and uses a swap file on sda1 while checking sda2 (or something like that). Otherwise you definitely run out of memory with a 1TB disk and sometimes with a 500GB.
 
So it it actually running when the 'y' scroll up the screen? Because I've had this on for the last 4 hours or so!
 
No - I'd say you have a big problem there...
If you ran fix-disk I'd say follow my instructions above and see where it stops - this will tell you something
If you did do it my way - and get the "y's" you may have a serious issue not drive related or a corrupt fix-disk package maybe - where did it crash
 
Lots of errors on /dev/sda2, failed on pass 2 due to lack of memory. Giving it another pass now to see if it gets further.

Code:
humax# umount /dev/sda1
humax# umount /dev/sda2
humax# umount /dev/sda3
 
humax# e2fsck /dev/sda1
e2fsck 1.41.14 (22-Dec-2010)
/dev/sda1 has been mounted 140 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found.  Create<y>? yes
 
Pass 4: Checking reference counts
Pass 5: Checking group summary information
 
/dev/sda1: ***** FILE SYSTEM WAS MODIFIED *****
/dev/sda1: 14/65808 files (7.1% non-contiguous), 14394/263064 blocks
 
 
humax# e2fsck /dev/sda2
e2fsck 1.41.14 (22-Dec-2010)
/dev/sda2 has been mounted 140 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
 
Inodes that were part of a corrupted orphan linked list found.  Fix<y>? yes
Inode 23028466 was part of the orphaned inode list.  FIXED.
Inode 23028466 has a extra size (346) which is invalid
Fix<y>? yes
Inode 23028467 has EXTENTS_FL flag set on filesystem without extents support.
Clear<y>? yes
Inode 23028468 has EXTENTS_FL flag set on filesystem without extents support.
Clear<y>? yes
Inode 23028469 was part of the orphaned inode list.  FIXED.
Inode 23028470 has EXTENTS_FL flag set on filesystem without extents support.
Clear<y>? yes
Inode 23028472 is in use, but has dtime set.  Fix<y>? yes
 
Inode 23028474 has EXTENTS_FL flag set on filesystem without extents support.
Clear<y>? yes
 
-------------
 
 
Pass 2: Checking directory structure
Entry '..' in ??? (23029396) has deleted/unused inode 23028471.  Clear<y>? yes
Entry 'lib' in /mod (23027713) has deleted/unused inode 23028471.  Clear<y>? yes
Entry 'inotifywait' in /mod/bin (23027714) has deleted/unused inode 23028475.  Clear<y>? yes
Entry '..' in ??? (25854062) has deleted/unused inode 23028471.  Clear<y>? yes
Entry 'jim-oo.list' in /mod/var/opkg/info-old (23027725) has deleted/unused inode 23028474.  Clear<y>? yes
Inode 23028478 (/mod/var/opkg/info-old/jim-sqlite3.control) has invalid mode (00).
Clear<y>? yes
 
 
e2fsck: Memory allocation failed while retrying to read bitmaps for /dev/sda2
e2fsck: aborted
humax#
 
Yep - I have the 1TB HDR. I'll give it another go jack's way and then try fix-disk overnight. If it still doesn't finish, I'll just have to bite the bullet and pick up a big HDD tomorrow.
 
You willl need to create a swap file for jack's method to work.

I wonder if the version of busybox under the /mod directory is corrupt or perhaps the fix-disk package has become corrupted. Did you copy it to the hard disk first?
Try:

Code:
export PATH=/bin:/sbin
/var/lib/humaxtv/mod/fix-disk

If it successfully enters maintenance mode you will have to repeat the above for it to perform the disk checking.
 
I have just noticed that the link I gave above does not include a download link. If you have used the usual package management 'opkg' to download fix-disk or via the web-if then it may have become corrupted due to the disk corruption. See this link for full details.

BTW you will probably have to completely reinstall the mod after fixing the disk because the disk corruption looks quite severe. It is usually best to fix it at the first sign of a problem and not allow the box to write any new data to the disk whilst it is in a corrupted state. That should help reduce any data loss to a minimum.
 
You may wish to check that the files associated with fix-disk are not corrupt. This assumes that you are running CF 2.11

Code:
/mod/bin/busybox/md5sum /bin/busybox /var/lib/humaxtv/mod/fix-disk /var/lib/humaxtv/mod/minibb /mod/bin/busybox/busybox /sbin/e2fsck /lib/libc.so.0 /lib/ld-uClibc.so.0 /lib/libcrypt.so.0 /lib/libpthread.so.0 /lib/libdl.so.0
1f749c76f4e88c3966b6b979fc8829c3  /bin/busybox
0d40008aff1cd81801f957311fe18283  /var/lib/humaxtv/mod/fix-disk
efb97f04463b79dcc20a21b168c2d9f1  /var/lib/humaxtv/mod/minibb
b588c1d0957f629a91f0867c4f0a95d2  /mod/bin/busybox/busybox
d3927abb22ff5cea8113a000a5a910e3  /sbin/e2fsck
c0ca5235f4c79369c2750dd8f5bd8bab  /lib/libc.so.0
d8d9d222f8934cf6fb2235bf04103245  /lib/ld-uClibc.so.0
66e5589c43bf85713ef1afed4b96b327  /lib/libcrypt.so.0
e049d123e73afaf690e19948040ebabb  /lib/libpthread.so.0
a1b5a77ab03e276b7a18dcbc60724df5  /lib/libdl.so.0
 
Thanks for that! The MD5 check sums appear to match, so fix-disk and the library files seem to be ok. I ran e2fsck on sda3 and that was fine, so the only errors now are on sda2. I think I'll get a big USB drive and copy everything over and reformat TBH.
 
If youre happy swapping out drives - maybe you could run e2fsck on a PC or laptop? That shouldn't produce memory errors.
Doing as you just said could take quite a while - assuming the files themselves can be copied but would be easiest.
 
Back
Top