• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

HD-FOX and Custom Software - USB Stick Issue

Black Hole

Black Hole

May contain traces of nut
Preface: to skip the head-scratching and blind alleys, refer to the summary HERE (click).

Something to be aware of: the current roll-out of the custom software relies on file system facilities which are present in Ext3 but not FAT32. This explains the random difficulties I have had running the mods from a USB stick (HD-FOX) instead of the internal drive of an HDR-FOX or (as most HD-FOX owners would do) from an external Ext3-formatted HDD (which would be needed if you intend to record).

I have had no success trying to format a USB stick as Ext3 (the Hummy doesn't offer the option, and last time I tried on a Linux PC I ended up with a dead stick and had to rebuild it).

It doesn't bother me much, I don't need the MSP on my HD-FOX (though it might be nice to mount the HDR's drive as a network share once decrypt-in-place is out of beta), and it seems to me the neatest way forward is when we get NTFS support built into the core CF (which should have similar capabilities to Ext3).

Update: Actually, I do need the custom software: without an aerial I have no source of system time, without which I cannot access the TV portal functions - af123 rolled me a "set system time from the Internet" utility; and even more seriously it has been demonstrated that streamed playback is limited (by a firmware bug) to 4GB per file, the work-around for this being to install network file sharing.
 
At least we now know what was different about your HD box.

You won't have much success formatting the USB stick as Ext3, and you wouldn't want to since the journaling will quickly kill the stick, but Ext2 should be fine - I just formatted a spare 2GB stick with Ext2 from my HDR and it worked fine, although it isn't being mounted automatically (that could be fixed with a CF update though).

Baking NTFS support into the Customised Firmware would probably be possible but because it requires running the filesystem in userspace it's not entirely straightforward, and everything would need recompiling for the new location.

If the Ext2 option sounds useful, I'll look at adding support to the next version of the CF.
 
Here's a procedure for getting the customised firmware up and running on an HD-Fox T2 with a USB Flash Drive running ext2. I don't know if you're willing to try it. If it works then I could wrap this into a script for the next version of the customised firmware so that it becomes relatively easy for others to do the same.
  • First, make sure the USB drive has a single partition on it and is formatted as FAT32;
  • Install the Customised Firmware;
  • Connect the USB Flash Drive;
  • Gain access to the command prompt on the Humax (via telnet);
  • Install the e2fsprogs package;
/sbin/modinit​
opkg update​
opkg install e2fsprogs​
  • Copy the formatting utility off the flash drive;
cp /mod/sbin/mkfs.ext2 /tmp​
  • Determine the device name and mount point for the flash drive:
cd /mod
df -h .​
  • The device name is the first column in the output of the df command, something like /dev/sda1;
  • The mount point it the last column, something like /media/drive1
  • Unmount the flash drive (replace the mount point with that determined above):
cd /​
umount /media/drive1​
  • Format the drive (replace the device number with that determined above):
/tmp/mkfs.ext2 /dev/sda1​
  • Change the partition type of the new drive. Note that the last part of the command is the root name of the device determined above, so for /dev/sda1 omit the trailing 1 in the following command:
echo t83 | fdisk /dev/sda​
  • Now remove and re-insert the USB disk and reinitialise the package repository
/sbin/modinit​
opkg update​
 
Yes, I'll give it a go. If it doesn't mount automatically (presumably every boot), what do you do?
 
You were right about /dev/sda1 and /media/drive1.

af123 said:
umount /media/drive1
Click to expand...
I got stuck at that point because it said "umount: can't umount /media/drive1: Device or resource busy"

I also tripped up, spelling "umount" as the more obvious "unmount". Why???
 
I've tried a few things to get the device to unmount, including "eject" (on the hidden menu) and even ripping it out and deleting the /mod directory on a PC, but as soon as it goes back in mkfs.ext2 complains that the "device is busy".

My next idea is to boot GPartEd on my PC, and format it that way, but I would prefer not.
 
Black Hole said:
I got stuck at that point because it said "umount: can't umount /media/drive1: Device or resource busy"
Click to expand...

As long as you did the cd / before the umount then it is most likely mongoose that's using the drive - that can be stopped with service stop mongoose

If that doesn't work, then I suggest removing the /mod directory on a PC then going through the process again. If the only modded software that's installed on the stick is e2fstools, then there shouldn't be anything to keep it busy.
 
af123 said:
As long as you did the cd / before the umount then it is most likely mongoose that's using the drive - that can be stopped with service stop mongoose

If that doesn't work, then I suggest removing the /mod directory on a PC then going through the process again. If the only modded software that's installed on the stick is e2fstools, then there shouldn't be anything to keep it busy.
Click to expand...
That's where I've got to - no /mod any more, and mkfs.ext2 refusing to run. I presume with mkfs.ext2 copied to /tmp I don't need to do the preliminaries, go straight in at umount. The only thing I havent doen is reboot the HD-FOX - that should kill any processes lurking in RAM I suppose.
 
I just had one of my warm restart lock-ups, only relieved by a hard reset followed by a warm start. Now the clock is back to 1970!

Why isn't mkfs.ext2 still in /tmp?
 
Success!!!

Having deleted /mod and started again from the top, all went well. Edit your instructions to include a "delete /mod" step (which I did on a PC) and kill any processes which might still be using it (which I did with a reset - I'm sure there must be a more elegant command-line method for both these). I have now done the basic web interface download, without all the error messages.
 
Failure!!!!!!!!!

That's interesting. I have now ended up in the same position as infracom2011 - the web server is not running. I still have Telnet access.

I have tried a few flailings in the dark, hoping the information might be useful:

Code: 
humax#
humax#
humax# opkg update
Collected errors:
* make_directory: Cannot create directory `/mod/': File exists.
* make_directory: Cannot create directory `/mod': File exists.
* make_directory: Cannot create directory `/mod': File exists.
* make_directory: Cannot create directory `/mod': File exists.
* make_directory: Cannot create directory `/mod': File exists.
* rm_r: Failed to open dir : No such file or directory.
humax#
humax# opkg install webif
Unknown package 'webif'.
Collected errors:
* make_directory: Cannot create directory `/mod/': File exists.
* make_directory: Cannot create directory `/mod': File exists.
* make_directory: Cannot create directory `/mod': File exists.
* make_directory: Cannot create directory `/mod': File exists.
* opkg_install_cmd: Cannot install package webif.
* opkg_finalize_intercepts: Failed to open dir : No such file or directory.
* rm_r: Failed to open dir : No such file or directory.
* rm_r: Failed to open dir : No such file or directory.
humax#
humax# ls /mod
ls: /mod: No such file or directory
humax#
humax#

Guess: the Ext2 UPD has not mounted following the restart required by the MSP install. The MSP downloaded OK (no error messages anyway), so I imagine /mod got written at that time. But why doesn't the web server default back to the basic page?
 
Oops! Seems to have ended up as FAT16 somehow:

Code: 
humax# df -h
Filesystem                Size      Used Available Use% Mounted on
rootfs                   15.2M     15.2M         0 100% /
/dev/root                15.2M     15.2M         0 100% /
tmpfs                    61.0M    136.0k     60.9M   0% /tmp
tmpfs                    61.0M         0     61.0M   0% /media
/dev/mtdblock1            2.0M    416.0k      1.6M  20% /var/lib/humaxtv
/dev/mtdblock2            2.0M      1.2M    812.0k  60% /var/lib/humaxtv_backup
humax#
humax# echo p | fdisk /dev/sda
The number of cylinders for this disk is set to 3399.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
Command (m for help):
Disk /dev/sda: 2004 MB, 2004877312 bytes
64 heads, 18 sectors/track, 3399 cylinders
Units = cylinders of 1152 * 512 = 589824 bytes
   Device Boot      Start         End      Blocks  Id System
/dev/sda1   *           4        3400     1956096   6 FAT16
Command (m for help): humax#
humax#
I thought of trying a df command, but your instructions led me to believe it lived in the /mod directory.
 
Last edited:
Ok, you just need to flag the partition as a Linux one. I'll post instructions when I get home.
 
In the mean time, I have fired up the PC in Linux mode and used GPartEd to look at the UPD - it reports it as Ext2, and has 30MB in use... but when I mount it to look at it all there is is a "lost+found" folder and nothing else. Would I be barking up the wrong tree to suggest the /mod stuff is on there somewhere but somehow rendered inaccessible?
 
Plug the disk into the humax then use the fdisk utility to change the partition type:

Code: 
humax# fdisk /dev/sdb

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 83
Command (m for help): w
The partition table has been altered!

The bits you are type are effectively
Code: 
fdisk /dev/sdb
t
83
w
 
You must log in or register to reply here.
Back
Top