• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

[ntfs-3g] - HD-FOX: ntfs-3g (virtual-disk2) bug.

MontysEvilTwin

MontysEvilTwin

Well-Known Member
I wanted to use my HD-FOX to download some recordings. It had been left in standby but I hadn't used it for a while. Webif gave the 'no disk detected' page and the telnet landing page warned of 'areas of the disk being unmounted'. I ran the 'df' command and got the following:
Code: 
HDFox# df -h                                                                       
Filesystem                Size      Used Available Use% Mounted on                 
/dev/root                20.7M     20.7M         0 100% /                         
tmpfs                    61.0M    116.0K     60.9M   0% /tmp                       
tmpfs                    61.0M         0     61.0M   0% /media                     
/dev/mtdblock1            2.0M    568.0K      1.4M  28% /var/lib/humaxtv           
/dev/mtdblock2            2.0M    520.0K      1.5M  25% /var/lib/humaxtv_backup   
/dev/mtdblock2            2.0M    520.0K      1.5M  25% /etc/opkg                 
/dev/sda1                53.0K     53.0K         0 100% /media/drive1             
/dev/sdb1               458.4G     27.4G    407.7G   6% /media/drive2
Oddly, a temporary file system was mounted as drive1, with the actual hard drive mounted as drive2. I ran e2fsck on the hard drive: there were no errors. I had a hunch and did some digging. The current version of ntfs-3g also installs virtual-disk2. This is necessary with the HDR-FOX, if mounting a large NTFS drive with gpt, to make the USB menu available with the SUI. The HD-FOX does not need virtual-disk2 as the USB menu is always available. The problem seems to be that the virtual disk is preferentially mounted as 'drive1', forcing the hard drive to 'drive2'. This causes problems as the custom firmware is looking for the 'mod' folder on 'drive1'. A temporary fix is to uninstall virtual-disk2. If you are already having this problem, you can only uninstall the package from maintenance mode. The command is:
Code: 
opkg remove virtual-disk2 --force-depends
A permanent fix is for the package provider (@xyz321, I think) to prevent virtual-disk2 from being installed when installing ntfs-3g on the HD-FOX.
 
Removing virtual-disk2 is a work-around. It is also possible to disable virtual-disk2 without uninstalling it, which might be a way forward for ntfs-3g, as:
Code: 
/mod/etc/init.d/S89virtual-disk disable

More generally, there is the problem of how the CF can predict which device and mount-point will be used by the Humax settop binary for the /mod filesystem. To summarise the start-up sequence as I understand it:
  1. executables in /etc/init.d are started in lexicographical order;
  2. at /etc/init.d/S80xinit, executables in (flash) /var/lib/humaxtv/mod/xinit.d are started in lexicographical order;
  3. at /etc/init.d/S90settop, the Humax settop binary is run, discovering devices, mounting storage, connecting to LAN, etc, not to mention presenting ads for BT Broadband, interspersed with occasional programme content;
  4. a hook script /etc/mdev/run-and-gun runs on each storage device discovery which attempts to find the /mod filesystem once the device has been mounted and if successful starts the CF by running /sbin/modinit; and finally runs the scripts in /mod/etc/mdev for the device;
  5. initialising the CF causes the executables in /mod/etc/init.d to be started in lexicographical order.
Steps 4 is tricky. Consider model=HD in particular. The script doesn't know how the devices discovered in step 3 will be named and mounted. There might be several USB storage devices with ext2/3 format and a /mod in the root: which to use? Here and elsewhere, it is assumed that the mount-point will be /media/drive1/. It's also assumed that the device is /dev/sda1:
/df said:
...
...
It might be undesirable for the CF to initialise every /mod found on mounted disks, but the test in /etc/mdev/run-and-gun for the HD seems too restrictive.

The HDR case looks for any second partition ~ /sd.2/.

Wouldn't it be reasonable for the HD case to do something similar but ~/sd.1/ ?
Click to expand...
For virtual-disk2, it is desired to have the device available before the Humax settop binary starts but also to control its mount-point. Suppose the virtual disk image were created as a GPT disk. The Humax mount routine would ignore it, making it possible for virtual-disk2's /mod/boot/xinit.d/vdisk routine to mount it in a known way. Could that be a good solution?
 
Last edited:
/df said:
Removing virtual-disk2 is a work-around. It is also possible to disable virtual-disk2 without uninstalling it, which might be a way forward for ntfs-3g, as:
Code: 
/mod/etc/init.d/S89virtual-disk disable
Click to expand...
Have you created a script to disable virtual-disk2 that runs from /mod/etc/init.d? Bear in mind that there is also an optional virtual-disk package; should that be 'S89virtual-disk2' in the above example?
/df said:
For virtual-disk2, it is desired to have the device available before the Humax settop binary starts but also to control its mount-point. Suppose the virtual disk image were created as a GPT disk. The Humax mount routine would ignore it, making it possible for virtual-disk2's /mod/boot/xinit.d/vdisk routine to mount it in a known way. Could that be a good solution?
Click to expand...
AFAIA the point of virtual-disk2, and the reason why it is installed with the latest version of ntfs-3g, is that it creates a mount point that is recognised by the Humax software, thus making the USB menu available on the HDR-FOX without needing a physical disk to be connected to either USB port. The latest version of ntfs-3g supports GPT disks, so without virtual-disk2 it would be possible to connect an NTFS drive with GPT and have it mounted and available through Webif/ SMB etc. without being accessible through the Humax SUI.
With the respect to the issue described in this thread, would the simplest solution be to make the virtual-disk2 package HDR-FOX only and modify the relevant package installation scripts not to install it on the HD-FOX?
 
MontysEvilTwin said:
With the respect to the issue described in this thread, would the simplest solution be to make the virtual-disk2 package HDR-FOX only and modify the relevant package installation scripts not to install it on the HD-FOX?
Click to expand...
That would stop ntfs-3g from installing at all on the HD-FOX unless you also modify that package.
 
MontysEvilTwin said:
Have you created a script to disable virtual-disk2 that runs from /mod/etc/init.d? Bear in mind that there is also an optional virtual-disk package; should that be 'S89virtual-disk2' in the above example?
...
Click to expand...
Below I've annotated the contents of the virtual-disk2 package.
Code: 
humax# opkg files virtual-disk2
Package virtual-disk2 (2.0-2) is installed on root and has the following files:
/mod/boot/2/vdisk/dummy_hcd.ko        USB Host+Gadget Emulator kernel driver
/mod/etc/init.d/S89virtual-disk          service control script
/mod/boot/2/vdisk/disk.img               empty disk image
/mod/etc/modservice.d/virtual-disk    service control file
/mod/boot/2/vdisk/g_file_storage.ko   File-backed Storage Gadget kernel driver
/mod/boot/xinit.d/vdisk                        xinit startup routine
/mod/etc/init.d/S89virtual-disk can be called with parameter 1: start, stop, enable, disable. It's called with start in what I listed as step 5 of startup in the post above. If you run the disable command that I posted, the xinit routine will not load the drivers on future restarts and so your original problem should be solved. You can use the enable parameter value to undo this.
...
AFAIA the point of virtual-disk2, and the reason why it is installed with the latest version of ntfs-3g, is that it creates a mount point that is recognised by the Humax software, thus making the USB menu available on the HDR-FOX without needing a physical disk to be connected to either USB port. The latest version of ntfs-3g supports GPT disks, so without virtual-disk2 it would be possible to connect an NTFS drive with GPT and have it mounted and available through Webif/ SMB etc. without being accessible through the Humax SUI.
...
Click to expand...
virtual-disk2 is needed to make storage available from the HDR SUI but may uncontrollably get mounted as /media/drive1, so breaking the CF. If the virtual-disk2 blank disk image is formatted as GPT, the Humax settop binary should find the corresponding dummy disk device but as it isn't MBR it won't mount it, especially not as /media/drive1. virtual-disk2 could then mount the virtual disk in a known way, say /media/vdrive, using additional script code in its xinit routine.
With the respect to the issue described in this thread, would the simplest solution be to make the virtual-disk2 package HDR-FOX only and modify the relevant package installation scripts not to install it on the HD-FOX?
Click to expand...
As noted by prpr, there isn't an easy way (or I couldn't see one) to make package dependencies vary by model. You can have a postinst script in the package that detects the model and tweaks the configuration, eg by disabling virtual-disk2 on HD as I suggested.
 
Last edited:
prpr said:
That would stop ntfs-3g from installing at all on the HD-FOX unless you also modify that package.
Click to expand...
I have been having different problems with the latest version of ntfs-3g (2013.1.13-4) on the HDR-FOX (I'll post in another thread on this) so I think it needs some changes anyway. It might be better to put this version back in the beta-repository and revert to version 2013.1.13-2 if there is no quick fix. Hopefully @xyz321will see this thread and comment.
 
And another thing: ntfs-3g needs the blkid program, so it needs e2fsprogs in its dependencies.

As ntfs-3g doesn't appear to have a package thread, perhaps this one should be designated?
 
Updates are now available in the repository.
ntfs-3g: Added e2fsprogs to the dependency list
virtual-disk2: Startup script now disables this package when installed on the HD.
 
Black Hole said:
I said brackets, not parentheses!

[ntfs-3g] - HD-FOX: ntfs-3g (virtual-disk2) bug
Click to expand...
I apologise. When most people say 'brackets' they mean parentheses. I automatically adjust for this and take it that they do mean parentheses. If anyone was going to use the word correctly....
 
Thanks. It's only that it has become a convention to identify a package name in the thread title that way, especially then the thread is the primary one for that package (as /df has nominated).
 
You must log in or register to reply here.
Back
Top