View Full Version : [VU+ Duo4K SE] Cannot move up and down in a Setup screen
I'm installing a new machine and am having trouble with one Setup screen - specifically, the "Recording and playback" Setup screen. When I enter I can see lots of lines of settings but pressing the up or down buttons has no effect - it won't budge from the first item ("Default movie location"). This is weird because I have no trouble moving up and down in the other Setup screens and changing settings as I see fit. Just in this one Setup screen it will let me edit that first item but won't let me go to any other lines to change them.
Could it be that there's a problem with my "Default movie location" and it won't let me move on until that's fixed?
Thanks for any help.
Dan
abu baniaz
17-12-21, 20:12
I am on 6.0 004 Release and cannot reproduce the issue. can you enable debug logs, restart, try the procedure again, then upload debug log.
I'm installing a new machine and am having trouble with one Setup screen - specifically, the "Recording and playback" Setup screen. When I enter I can see lots of lines of settings but pressing the up or down buttons has no effect - it won't budge from the first item ("Default movie location"). This is weird because I have no trouble moving up and down in the other Setup screens and changing settings as I see fit. Just in this one Setup screen it will let me edit that first item but won't let me go to any other lines to change them.
Could it be that there's a problem with my "Default movie location" and it won't let me move on until that's fixed?
Thanks for any help.
DanYou need to select a valid device.
The error message explains what is wrong.
You need to select a valid device.
The error message explains what is wrong.
I've tried selecting every device I can think of but whatever I put there it just won't let me past that line. My HDD is an external drive mounted on /media/sda2 and it seems to work OK. I've tried recording something and it records to that location. So it seems to be a valid device. I've tried selecting /media/sda2/movie (the folder exists - I can see it via Samba). I've tried /media/sda2. I've tried /media/hdd. Regardless of what I enter into that field the user interface for the Recording and playback settings will not budge from the first line.
There's no error message. I press the down button on the remote and nothing happens. Same with the up button. The only buttons that have any effect are the left and right buttons (scrolling between the different values for this field), the OK button (to find another bookmark) and the red button or exit button which take me up a level in the menus. The remote is fine because I can scroll up and down no problem on all the other settings screens.
I'm baffled. Seems like I'm doing something stupid but I can't figure out what it is :-(
Thanks
I've tried selecting every device I can think of but whatever I put there it just won't let me past that line. My HDD is an external drive mounted on /media/sda2 and it seems to work OK. I've tried recording something and it records to that location. So it seems to be a valid device. I've tried selecting /media/sda2/movie (the folder exists - I can see it via Samba). I've tried /media/sda2. I've tried /media/hdd. Regardless of what I enter into that field the user interface for the Recording and playback settings will not budge from the first line.
There's no error message. I press the down button on the remote and nothing happens. Same with the up button. The only buttons that have any effect are the left and right buttons (scrolling between the different values for this field), the OK button (to find another bookmark) and the red button or exit button which take me up a level in the menus. The remote is fine because I can scroll up and down no problem on all the other settings screens.
I'm baffled. Seems like I'm doing something stupid but I can't figure out what it is :-(
Thanks
Post a screenshot with the error message.
How to take a screenshot here: https://www.world-of-satellite.com/showthread.php?44054-How-to-take-screen-shots-How-to-attach-files
abu baniaz
18-12-21, 13:47
Have you tried to reboot the box ( not just restart enigma2) after connecting the HDD? What filesystem is the box in?
Can you send this command to your box using Putty/terminal post back the result?
df -Th
I am on 6.0 004 Release and cannot reproduce the issue. can you enable debug logs, restart, try the procedure again, then upload debug log.
I enabled debug logs and rebooted. I wasn't sure which logs to attach and where to find them - I've browsed around using Samba and found the attached in /var/log - are these the ones you need?
Thanks
https://www.world-of-satellite.com/showthread.php?64862-Cannot-move-up-and-down-in-a-Setup-screen&p=520196&viewfull=1#post520196
Post a screenshot with the error message.
How to take a screenshot here: https://www.world-of-satellite.com/showthread.php?44054-How-to-take-screen-shots-How-to-attach-files
But that's what I'm trying to say - there is no error message. Nothing happens when I press the up or down buttons, not even an error message. I can send a screenshot of the Settings screen if that would help?
Thanks
But that's what I'm trying to say - there is no error message. Nothing happens when I press the up or down buttons, not even an error message. I can send a screenshot of the Settings screen if that would help?
ThanksIf you can't move the selection there will be a message in the hints field.
abu baniaz
18-12-21, 14:11
Dec 18 12:10:04 vuduo4kse kern.notice kernel: [ 14.861516] scsi 2:0:0:0: Direct-Access Seagate Backup+ Hub BK D781 PQ: 0 ANSI: 6
The manual for the device says that the windows device comes formatted in NTFS. You will need to install the ntfs drivers.
Menu > Plugins > Green (download) > drivers > ntfs-3g
Edit: Reboot will be required
Please note:
It may not allow you to record to it. I might be wrong, but I think there was a commit to only allow ext devices even though we have always been able to record to other filesystems before.
Edit 2:
Link to guide on issuing commands here:
https://www.world-of-satellite.com/showthread.php?40948-How-to-use-Putty-for-Unix-Linux-commands
Disc needs to be EXT formatted.
I enabled debug logs and rebooted. I wasn't sure which logs to attach and where to find them - I've browsed around using Samba and found the attached in /var/log - are these the ones you need?
ThanksFrom that messages file.
Dec 18 12:10:04 vuduo4kse kern.notice kernel: [ 15.023967] sd 2:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
Dec 18 12:10:04 vuduo4kse kern.notice kernel: [ 15.031908] sd 2:0:0:0: [sda] Attached SCSI disk
Dec 18 12:10:04 vuduo4kse kern.warn kernel: [ 15.423841] UDF-fs: warning (device sda1): udf_fill_super: No partition found (2)
...
Dec 18 12:10:04 vuduo4kse kern.warn kernel: [ 17.151420] UDF-fs: warning (device sda2): udf_fill_super: No partition found (2)
so there is nothing there that can (yet) be used.
PS: Those are OS logs. The enigma2 debug logs will be in /media/hdd/logs.
abu baniaz
18-12-21, 14:42
Disc needs to be EXT formatted.
Which files do users change to re-allow usage of fat32 devices. This will once again allow users to plugin their USB stick to other devices which do not allow ext filesystem.
abu baniaz
18-12-21, 14:44
PS: Those are OS logs. The enigma2 debug logs will be in /media/hdd/logs.
Default is /home/root/logs
He does not have a hdd mountpoint :)
Dec 18 12:10:04 vuduo4kse kern.notice kernel: [ 14.861516] scsi 2:0:0:0: Direct-Access Seagate Backup+ Hub BK D781 PQ: 0 ANSI: 6
The manual for the device says that the windows device comes formatted in NTFS. You will need to install the ntfs drivers.
Menu > Plugins > Green (download) > drivers > ntfs-3g
Edit: Reboot will be required
Please note:
It may not allow you to record to it. I might be wrong, but I think there was a commit to only allow ext devices even though we have always been able to record to other filesystems before.
Edit 2:
Link to guide on issuing commands here:
https://www.world-of-satellite.com/showthread.php?40948-How-to-use-Putty-for-Unix-Linux-commands
Yup. I installed the NTFS drivers yesterday and they seem to be working - I can successfully record and play back recordings so the box is definitely seeing and working with the disk. I just have this weird problem trying to change the settings.
New information is that I've found that the green button works when in that Settings screen and gives an error message: "Directory 'media/sda2/movie/' not valid. Partition must be ext or nfs. Please select an acceptable directory." OK, that makes sense, except for the facts reported above. The directory does exist and can be seen by the box. So why does the Settings screen not recognise what appears to be accepted by the wider operating system?
I've used a similar setup with another box (Gigablue X2) in the past - plugging in an external Windows USB drive and it works fine, although that's using an older version of OpenVix. Maybe I should try swapping the drives between the Vu and the Gigablue?
Thanks to everyone for your help with this. Any further suggestions gratefully received.
If you can't move the selection there will be a message in the hints field.
Thanks Huevos. I'm not sure where to find the Hints field but as per my message a minute ago I can now get an error message.
Default is /home/root/logs
He does not have a hdd mountpoint :)
Thanks - logs are where you said. This morning's log attached. I've had a look and can see my numerous attempts to get past the error message but I have insufficient understanding to be able to work out why they are happening :-(
Have you tried to reboot the box ( not just restart enigma2) after connecting the HDD? What filesystem is the box in?
Can you send this command to your box using Putty/terminal post back the result?
df -TH
It didn't like df -TH (no "H" option) but allowed df -Th. Output is below.
Thanks
Filesystem Type Size Used Available Use% Mounted on
/dev/root ext4 3.5G 416.0M 2.9G 12% /
devtmpfs devtmpfs 782.4M 8.0K 782.4M 0% /dev
tmpfs tmpfs 64.0K 0 64.0K 0% /media
tmpfs tmpfs 790.6M 180.0K 790.4M 0% /var/volatile
/dev/sda2 fuseblk 5.5T 1.7T 3.7T 31% /media/sda2
abu baniaz
18-12-21, 15:48
< 7307.9526> [InfoBarGenerics] Key: 399 (Make) KeyID='KEY_GREEN' Binding='('GREEN',)'.
< 7307.9530> [ActionMap] Keymap 'ConfigListActions' -> Action = 'save'.
< 7307.9554> [Skin] Processing screen 'MessageBox', position=(380, 355), size=(520 x 10) for module 'MessageBox'.
< 7307.9611> [ePNG] loadSVG /usr/share/enigma2/skin_default/icons/input_question.svg 53x53 from 53x53
< 7307.9633> [ePNG] loadSVG /usr/share/enigma2/skin_default/icons/input_info.svg 53x53 from 53x53
< 7307.9650> [ePNG] loadSVG /usr/share/enigma2/skin_default/icons/input_error.svg 53x53 from 53x53
< 7307.9660> [Screen] Warning: Skin is missing element 'icon' in <class 'Screens.MessageBox.MessageBox'>(Directory '/media/sda2/' not valid. Partition must be ext or nfs
Sorry, out of ideas. Might be related to this commit
https://github.com/OpenViX/enigma2/commit/2420492d17a236c6f7629c50e3061a66b1e3894f
Post a screenshot with the error message.
How to take a screenshot here: https://www.world-of-satellite.com/showthread.php?44054-How-to-take-screen-shots-How-to-attach-files
Thanks for the tip on saving a screenshot - neat.
vu 1.jpg shows that the box has successfully made recordings. You can see a couple of recordings and, from the top of the screen, see where they have been recorded - /media/sda2/movie. You can also see at the bottom of the screen that there's tons of space available on the disk.
vu 2.jpg shows the Settings screen that is giving me trouble. The Default movie location is showing as /media/hdd/movie. I cannot move the cursor down the list to change other settings. I have tried changing this setting as described previously but cannot get any value accepted. But the fact that I can record and view my recordings indicates that things are, at some level, OK with the disk.
vu 3.jpg is the same, but with me having selected /media/sda2/movie for the default movie location and just about to hit the green button.
vu 4.jpg shows the error message when I hit the green button.
I guess the question in my mind is: "Why does the interface not allow this NTFS location to be specified as the default location but the underlying system is happy with that location?"
The irony in all this is that I'm not actually trying to change the Default location - I just want to change some of the other settings but cannot reach them.
Thanks for all the help. If anyone can suggest a way I can bypass this issue so that I can change other settings then please do.
Thanks for the tip on saving a screenshot - neat.
vu 1.jpg shows that the box has successfully made recordings. You can see a couple of recordings and, from the top of the screen, see where they have been recorded - /media/sda2/movie. You can also see at the bottom of the screen that there's tons of space available on the disk.
vu 2.jpg shows the Settings screen that is giving me trouble. The Default movie location is showing as /media/hdd/movie. I cannot move the cursor down the list to change other settings. I have tried changing this setting as described previously but cannot get any value accepted. But the fact that I can record and view my recordings indicates that things are, at some level, OK with the disk.
vu 3.jpg is the same, but with me having selected /media/sda2/movie for the default movie location and just about to hit the green button.
vu 4.jpg shows the error message when I hit the green button.
I guess the question in my mind is: "Why does the interface not allow this NTFS location to be specified as the default location but the underlying system is happy with that location?"
The irony in all this is that I'm not actually trying to change the Default location - I just want to change some of the other settings but cannot reach them.
Thanks for all the help. If anyone can suggest a way I can bypass this issue so that I can change other settings then please do.
Apologies - left off the attachments.
Which files do users change to re-allow usage of fat32 devices. This will once again allow users to plugin their USB stick to other devices which do not allow ext filesystem.I wasn't aware of it being disabled.
abu baniaz
18-12-21, 17:03
I wasn't aware of it being disabled.
It seems I am wrong then, a thousand apologies.
How do we resolve the OP's issue?
Will creating a bookmark allow the drive to be selected?
There's already a lot of space used on the disc, I'd just let the box format it to EXT4 if it's not wanted.
FAT and NTFS do not support hardlinks. Therefore they are not valid.
The fuse NTFS driver (which is what I think is used?) allows hard-links.
This is on my laptop, with the Windows partition mounted under Linux.
[gmllaptop]: touch afile
[gmllaptop]: ln afile hlink
[gmllaptop]: ls -l
total 4
drwxrwxrwx 1 gml4410 ukgcs 240 Dec 18 20:29 ./
drwxrwxrwx 1 gml4410 ukgcs 4096 Dec 18 20:29 ../
-rwxrwxrwx 2 gml4410 ukgcs 0 Dec 18 20:29 afile*
-rwxrwxrwx 2 gml4410 ukgcs 0 Dec 18 20:29 hlink*
[gmllaptop]: rm afile
rm: remove regular empty file 'afile'? y
[gmllaptop]: ls -l
total 4
drwxrwxrwx 1 gml4410 ukgcs 144 Dec 18 20:29 ./
drwxrwxrwx 1 gml4410 ukgcs 4096 Dec 18 20:29 ../
-rwxrwxrwx 1 gml4410 ukgcs 0 Dec 18 20:29 hlink*
[gmllaptop]: df -T .
Filesystem Type 1K-blocks Used Available Use% Mounted on
/dev/nvme0n1p4 fuseblk 230719108 59777500 170941608 26% /media/gml4410/Windows
So allow the NTFS device in timeshift setup and see if it passes the hard link test.
abu baniaz
18-12-21, 23:34
Are hardlinks used for recordings, just timeshift or both? If just for timeshift, is it possible to apply the newly added prohibition just for timeshift?
So allow the NTFS device in timeshift setup and see if it passes the hard link test.The test is done by hasHardLinks() in Screens/Timeshift.py.
If I extract that and run it with a simple call for ext4, ntfs, vfat, exfat and hfs+ locations on my desktop I get this:
[parent]: ./TStest.py
Filesystem Type Mounted on
/dev/sda6 ext4 /var
sda6 ext4 /var
hasHardLinks for: /var/tmp returns True
Filesystem Type Mounted on
/dev/sdb2 fuseblk /media/gml4410/windows
sdb2 ntfs /media/gml4410/windows
hasHardLinks for: /media/gml4410/windows returns True
Filesystem Type Mounted on
/dev/sdf1 vfat /media/gml4410/PC-Spcl
sdf1 vfat /media/gml4410/PC-Spcl
[Timeshift] DEBUG: Create link - I/O Error 1: Operation not permitted!
[Timeshift] DEBUG: Remove target - I/O Error 2: No such file or directory!
hasHardLinks for: /media/gml4410/PC-Spcl returns False
Filesystem Type Mounted on
/dev/sdh1 exfat /media/gml4410/ExFat
sdh1 exfat /media/gml4410/ExFat
[Timeshift] DEBUG: Create link - I/O Error 1: Operation not permitted!
[Timeshift] DEBUG: Remove target - I/O Error 2: No such file or directory!
hasHardLinks for: /media/gml4410/ExFat returns False
Filesystem Type Mounted on
/dev/sdi1 hfsplus /media/gml4410/MacTest
sdi1 hfsplus /media/gml4410/MacTest
hasHardLinks for: /media/gml4410/MacTest returns True
so an ntfs file-system passes the test.
So if they work they can be added here... and here:
https://github.com/OpenViX/enigma2/blob/Dev-python3-compatible/lib/python/Screens/Recordings.py#L88
https://github.com/OpenViX/enigma2/blob/Dev-python3-compatible/lib/python/Screens/Timeshift.py#L72
Are hardlinks used for recordings, just timeshift or both? If just for timeshift, is it possible to apply the newly added prohibition just for timeshift?
Hardlinks are used for Timeshift, which is why the test is done in that module, but it makes sense we use identical file systems in both modules.
So if they work they can be added here... and here:
https://github.com/OpenViX/enigma2/blob/Dev-python3-compatible/lib/python/Screens/Recordings.py#L88
https://github.com/OpenViX/enigma2/blob/Dev-python3-compatible/lib/python/Screens/Timeshift.py#L72That won't work.
That code picks up the file system type from /proc/mounts, which for ntfs will list it as fuseblk, as it's run by a user-space daemon. Other file-systems could also show up as fuseblk there and not work (such as exfat).
The only real test for a file-system is to try hard-linking and check the result.
vfat shows as vfat. The tests for writeablility and hardlinks happen additionally.
vfat shows as vfat.Which has no relevance at all to ntfs, which doesn't show as ntfs.
The tests for writeablility and hardlinks happen additionally.So why bother checking the file-system type at all? Although I can see why you might want a blacklist (e.g. to rule out tmpfs, which would pass the tests while not being useful for recordings).
You said:
Other file-systems could also show up as fuseblk there and not work (such as exfat).
The only real test for a file-system is to try hard-linking and check the result.
Which is why I mentioned vfat (fat32).
Anyway if it works add it to the list.
Anyway if it works add it to the list.>>Sigh<<.. There is no point, as it won't show up as ntfs but as fuseblk! And exfat would also show up as fuseblk, but that won't work.
(Let's hope this doesn't go round the loop again.)
So, why not make that list a blacklist rather then a whitelist, which makes much more sense if the writeable and hard-linkable tests also have to pass anyway.
Add fuseblk. And anything that fails the hard link test won't be allowed.
Also, if you want a black list can you compile one?
abu baniaz
19-12-21, 18:27
I don't see any reason why we should prevent users from using devices with working file systems for recording. As in the OP's case, even though he has been locked out of the menu, he can record/playback fine. For arguments sake, somebody's internal HDD on receiver fails, he can use an external ntfs one until replacement arrives.
The hardlinks issue is specific to timeshift only, so any prohibitions should apply to that functionality only.
Also, if you want a black list can you compile one?I expect so. I'll track them down (whether a Vix system might have them or not).
OK. Based on my laptop, plus a few more obvious ones (such as assuming you wouldn't want to use the UBI storage for recordings?) I've got a blacklist of:
autofs binfmt_misc bpf cgroup2 configfs debugfs devpts
devtmpfs efivarfs exfat fuse.portal fuseblk fusectl
hugetlbfs isofs jffs2 mqueue proc pstore securityfs sysfs
tmpfs tracefs ubi ubifs udf vfat
There are others, but I can't see that they'd ever end up on a Vix box.
Still leaves an issue for picons, which are only allowed on
frozenset(('ext4', 'ext3', 'ext2', 'reiser', 'reiser4', 'jffs2', 'ubifs', 'rootfs'))
There's no hard-link test, so adding ntfs would be an issue. (And I have my picons on a vfat file-system, as I put them there "by-hand" rather than using the Plugin Browser, so have no hard links)
I don't see any reason why we should prevent users from using devices with working file systems for recording. As in the OP's case, even though he has been locked out of the menu, he can record/playback fine. For arguments sake, somebody's internal HDD on receiver fails, he can use an external ntfs one until replacement arrives.
The hardlinks issue is specific to timeshift only, so any prohibitions should apply to that functionality only.We are not stopping anyone from anything. Birdman and I are just discussing a formula we can all agree on. And anyway the project is open source so users can do what they like on there own box.
Still leaves an issue for picons, which are only allowed on
frozenset(('ext4', 'ext3', 'ext2', 'reiser', 'reiser4', 'jffs2', 'ubifs', 'rootfs'))
There's no hard-link test, so adding ntfs would be an issue. (And I have my picons on a vfat file-system, as I put them there "by-hand" rather than using the Plugin Browser, so have no hard links)Anyway picons use softlinks not hardlinks.
Anyway picons use softlinks not hardlinks.Which also work on ntfs, but not on exfat.
I now think this is going the wrong way..
It might be simple (and better) to get the code that detects mounted filesystem to expand any fuseblk entry top be the filesystem type of whatever is behind it (which is discoverable).
If getProcMounts() in Components/Harddisk.py is changed to be:
def getProcMounts():
try:
with open("/proc/mounts", "r") as fd:
lines = fd.readlines()
except (IOError, OSError) as err:
print("[Harddisk] Error: Failed to open '/proc/mounts':", err)
return []
result = [line.strip().split(" ") for line in lines]
for item in result:
item[1] = item[1].replace("\\040", " ") # Spaces are encoded as \040 in mounts.
# Also, map any fuseblk fstype to the real file-system behind it...
# Use blkid to get the info we need....
#
if item[2] == 'fuseblk':
import subprocess
res = subprocess.run(['blkid', '-sTYPE', '-ovalue', item[0]], capture_output=True)
if res.returncode == 0:
item[2] = res.stdout.decode().strip()
return resultthne the file-type will show up as ntfs (or exfat, ...).
The same change can also be made in Plugins/SystemPlugins/ViX/MountManager.py so that the actual filesystem show up in the Vix Mount manager.
(There are some other /proc/mounts users, which might also benefit - haven't checked yet).
Shall I submit PRs for this, then we can revert to a whitelist, as that's easier once the correct info is there to look at.
Well my personal opinion is blacklist is wrong.
I'm going to revert that commit.
https://github.com/OpenViX/enigma2/commit/5b3c1fabf5f803c7e80ef6815ad9a2f7d6d98020
Then just update as you think is required.
Two PRs to get the real file-system behind a fuseblk entry.
https://github.com/OpenViX/enigma2/pull/735
https://github.com/OpenViX/vix-core/pull/127
Then ntfs can be added to the supported_filesystem list.
Thanks, all, for your help with this - I appreciate that people give up their own time to develop and maintain OpenVix.
I was wondering when I might expect the fix to make it into a new build? I'm not sure I have sufficient understanding of the platform to put the changes in myself by dropping .py files in so I thought it best to wait until it's in a new build and let the update process do it properly. I'd like to get this in and then start investigating whether it also fixes the other closely related issue I'm having (OpenVix crash when attempting to set mount point).
Cheers, and merry Christmas.
Dan
The next release could be some time away, OE changes mean that the build process will take an age to complete, even a week or two.
The commits you need alter 3 files (in 2 folders).....
https://github.com/OpenViX/enigma2/commit/ff8d68241b789f0fc4559c50f0fae56ae83ff10c
https://github.com/OpenViX/enigma2/commit/e2c126e53331d0790c953daefebdf0573cdbdd44
All you need to do in theory, is rename the 3 existing files to *.orig, copy over the new versions, and restart the gui.
FileZilla makes it very easy.
The next release could be some time away, OE changes mean that the build process will take an age to complete, even a week or two.
The commits you need alter 3 files (in 2 folders).....
https://github.com/OpenViX/enigma2/commit/ff8d68241b789f0fc4559c50f0fae56ae83ff10c
https://github.com/OpenViX/enigma2/commit/e2c126e53331d0790c953daefebdf0573cdbdd44
All you need to do in theory, is rename the 3 existing files to *.orig, copy over the new versions, and restart the gui.
FileZilla makes it very easy.
Ok, I gave it a go. I made copies of the 3 files in their location and edited them to have the modified / changed lines from GitHub. I then rebooted.
Now I can update the "Default movie location" and subsequently move to other lines in the Recording and Playback settings screen. Success. Many thanks.
Although I don't use Timeshift, I thought I would check to see if that change worked too. I was able to select another location for Timeshift and save that setting too.
Then I moved on to the error that I mentioned earlier - a crash when attempting to setup mounts. If I go to Setup -> ViX -> Mount manager, then select the USB drive I have connected, press the green button to "Setup mounts", and then try to save a change (eg. to change the mount point to /media/hdd, as things seem to work more smoothly if the disk is mounted there), I get a crash. I've attached a log file.
If anyone can shed any light on what I am doing wrong to cause this crash (which can be reliably reproduced) then please do. As stated above, I encountered this trying to change the mount point to /media/hdd as that's what seems to work best. But maybe that's misguided and I should leave the mount point as /media/sda2 anyway. Thoughts welcome.
Thanks,
Dan
.... you don't need to edit the files, much safer this way.....
https://www.world-of-satellite.com/showthread.php?64480-IMDb-No-details&p=517460&viewfull=1#post517460
Actually, that might be a bug.
It's possible that result also needs to be made into a string, although I did test the code with an ntfs file system present, I don't think I tried to actually set its mountpoint.
If so, the code can be simplified by doing it once.
EDIT: It's a bug. I can reproduce the crash when trying to set the mountpoint for an ntfs drive.
And I have a fix....
The PR is here:
https://github.com/OpenViX/vix-core/pull/128
Actually, that might be a bug.
It's possible that result also needs to be made into a string, although I did test the code with an ntfs file system present, I don't think I tried to actually set its mountpoint.
If so, the code can be simplified by doing it once.
EDIT: It's a bug. I can reproduce the crash when trying to set the mountpoint for an ntfs drive.
And I have a fix....
The PR is here:
https://github.com/OpenViX/vix-core/pull/128
Should this file be used to replace the MountManager.py that belongs in:
\usr\lib\enigma2\python\Plugins\SystemPlugins\Netw orkBrowser
or the one that belongs in:
\usr\lib\enigma2\python\Plugins\SystemPlugins\ViX
or both?
Thanks,
Dan
The one in the plugin. Then restart.
The one in the plugin. Then restart.
Hmmm. Did that, but still getting the crash. Log file attached,
Specific action to cause this: select the USB drive in the mount manager; Green button for Setup mounts; select new mount point of /media/hdd; Green button to save. Dialog box appears: "Updating mount locations..." Crash happens.
On one occasion it got past this instead of crashing and said a reboot was necessary. But when I agreed to reboot I got the same crash.
Cheers,
Dan
Hmmm. Did that, but still getting the crash. Log file attached,
Specific action to cause this: select the USB drive in the mount manager; Green button for Setup mounts; select new mount point of /media/hdd; Green button to save. Dialog box appears: "Updating mount locations..." Crash happens.
On one occasion it got past this instead of crashing and said a reboot was necessary. But when I agreed to reboot I got the same crash.
Cheers,
Dan
Please use the attached version and get the debug log.
No idea what you are testing but certainly not the version on the repo. Not even from a 6.0 (Py3) build.
Ah, maybe I screwed up in copying the file from GitHub to the box - apologies, I'm new to this. I followed the instructions suggested by ccc (View file on GitHub, then Raw, then Save As) to copy the file to:
\usr\lib\enigma2\python\Plugins\SystemPlugins\ViX
I can see it in that location now and, on a quick visual inspection, it looks like it has the new lines in addconfFstab that I can see in green on GitHub instead of the old red lines. Perhaps I am misinterpreting the green and red and what I've actually got is the old version! I've attached the version on the box to this message just to be sure.
Also, the last callback in the crash log is for:
< 129.7834> File "/usr/lib/enigma2/python/Plugins/SystemPlugins/ViX/MountManager.py", line 444, in addconfFstab
< 129.7842> self.device_type = result.split("TYPE=")[1].split(" ")[0].replace('"', '')
...which looks like one of the new green lines rather than the old red ones.
So, I'm a bit baffled. Have I put the file in the wrong place? Or have I messed it up somehow in copying it from GitHub?
Thanks,
Dan
The one in the plugin. Then restart.Those are both in SystemPlugins!
But you do seem to have updated the correct one, and have now moved on to a different problem.
The output from /sbin/blkid seems to be unexpected. (missing a TYPE= field?)
Please use the attached version and get the debug log.
I copied that to \usr\lib\enigma2\python\Plugins\SystemPlugins\ViX, rebooted, and tried again. Same result. New log file attached.
Thanks,
Dan
You seem to be trying to mount /dev/sda1 (or something does) but you don't want to do that.
But why would you have a "Microsoft reserved partition" on an external drive?
Although it does seem that there may be no way to not mount a partition in this menu once Vix sees it.
Those are both in SystemPlugins!
But you do seem to have updated the correct one, and have now moved on to a different problem.
The output from /sbin/blkid seems to be unexpected. (missing a TYPE= field?)
This is the output from my debug:
'/dev/sda2: LABEL="Ext HDD 01" BLOCK_SIZE="512" UUID="C610F94F10F946C9" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="aa0d2d63-c7e2-4647-98c9-7f2b446f08f7"
ntfs-3g - 2017.3.23-r0
'
>>> result = """/dev/sda2: LABEL="Ext HDD 01" BLOCK_SIZE="512" UUID="C610F94F10F946C9" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="aa0d2d63-c7e2-4647-98c9-7f2b446f08f7"
... ntfs-3g - 2017.3.23-r0
... """
>>>
>>> result.split("UUID=")[1].split(" ")[0].replace('"', '')
'C610F94F10F946C9'
>>>
>>> result.split("TYPE=")[1].split(" ")[0].replace('"', '')
'ntfs'
>>>
So why is it crashing?
This is the output from my debug:
'/dev/sda2: LABEL="Ext HDD 01" BLOCK_SIZE="512" UUID="C610F94F10F946C9" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="aa0d2d63-c7e2-4647-98c9-7f2b446f08f7"
ntfs-3g - 2017.3.23-r0
'
But the crash occurs after:
< 104.7565> addconfFstab result '/dev/sda1: PARTLABEL="Microsoft reserved partition" PARTUUID="dd0c18f4-b858-4387-b568-a71e4531fa65"
ntfs-3g - 2017.3.23-r0
as there is no TYPE= field.
You seem to be trying to mount /dev/sda1 (or something does) but you don't want to do that.
But why would you have a "Microsoft reserved partition" on an external drive?
It's a bog-standard USB drive that was previously attached to a Windows PC. I just attached it to the Vu+ box instead. I guess that might explain the Microsoft reserved partition. But the drive works fine for everyday purposes - I can record to it, and view the recordings etc. I've done the same thing with another box a couple of years ago - attached a USB drive that was previously attached to a Windows PC.
Obviously, I could reformat it as Ext2 but then I would lose the flexibility of being able to reattach it to the Windows PC (for example, to do a mammoth file transfer, which I do from time to time).
/media/sda2 is where it is currently mounted. I'm not sure why something is trying to mount /dev/sda1. Could that be the unused other USB port? Perhaps I should try my USB drive in that port rather than the one I randomly chose.
Dan
/media/sda2 is where it is currently mounted. I'm not sure why something is trying to mount /dev/sda1. Could that be the unused other USB port? Perhaps I should try my USB drive in that port rather than the one I randomly chose.When you set-up mounts in the MountManager.py it seems to want to mount every partition it can see.
And it can see /dev/sda1.
I would have expected it to let you select the mountpoints one at a time (and hence not select one for something that you don;t want).
Obviously, I could reformat it as Ext2 but then I would lose the flexibility of being able to reattach it to the Windows PC (for example, to do a mammoth file transfer, which I do from time to time)If you reformat it as ntfs, but get rid of the first partition (i.e. just put ne file-system on the disk) then that would work.
Reformatting /dev/sda2 to ext4 won't help, as /dev/sda1 will still be there, and that's the problem one.
But the crash occurs after:
as there is no TYPE= field.
Nope, it crashes on this line:
def addconfFstab(self, result=None, retval=None, extra_args=None):
# print("[MountManager] RESULT:", result)
if result:
self.device = extra_args[0]
self.mountp = extra_args[1]
result = six.ensure_str(result)
print("addconfFstab result '%s'" % result)
self.device_uuid = "UUID=" + result.split("UUID=")[1].split(" ")[0].replace('"', '')
self.device_type = result.split("TYPE=")[1].split(" ")[0].replace('"', '')
>>> result = """/dev/sda2: LABEL="Ext HDD 01" BLOCK_SIZE="512" UUID="C610F94F10F946C9" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="aa0d2d63-c7e2-4647-98c9-7f2b446f08f7"
... ntfs-3g - 2017.3.23-r0
... """
>>>
>>> result.split("UUID=")[1].split(" ")[0].replace('"', '')
'C610F94F10F946C9'
>>>
>>> result.split("TYPE=")[1].split(" ")[0].replace('"', '')
'ntfs'
>>>
< 104.7539> [Console] finished: /sbin/blkid | grep sda2 && opkg list-installed ntfs-3g
< 104.7541> addconfFstab result '/dev/sda2: LABEL="Ext HDD 01" BLOCK_SIZE="512" UUID="C610F94F10F946C9" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="aa0d2d63-c7e2-4647-98c9-7f2b446f08f7"
ntfs-3g - 2017.3.23-r0
'< 104.7542>
< 104.7565> [Console] finished: /sbin/blkid | grep sda1 && opkg list-installed ntfs-3g
< 104.7565> addconfFstab result '/dev/sda1: PARTLABEL="Microsoft reserved partition" PARTUUID="dd0c18f4-b858-4387-b568-a71e4531fa65"
ntfs-3g - 2017.3.23-r0
'< 104.7565>
< 104.7567> Traceback (most recent call last):
< 104.7568> File "/usr/lib/enigma2/python/Components/Console.py", line 51, in finishedCB
< 104.7577> callback(data, retval, self.extra_args)
< 104.7577> File "/usr/lib/enigma2/python/Plugins/SystemPlugins/ViX/MountManager.py", line 445, in addconfFstab
< 104.7585> self.device_type = result.split("TYPE=")[1].split(" ")[0].replace('"', '')
< 104.7586> IndexError: list index out of range
LOL, don't worry I can see it now. :D
It's a bog-standard USB drive that was previously attached to a Windows PC. I just attached it to the Vu+ box instead. I guess that might explain the Microsoft reserved partition. But the drive works fine for everyday purposes - I can record to it, and view the recordings etc. I've done the same thing with another box a couple of years ago - attached a USB drive that was previously attached to a Windows PC.
Obviously, I could reformat it as Ext2 but then I would lose the flexibility of being able to reattach it to the Windows PC (for example, to do a mammoth file transfer, which I do from time to time).
/media/sda2 is where it is currently mounted. I'm not sure why something is trying to mount /dev/sda1. Could that be the unused other USB port? Perhaps I should try my USB drive in that port rather than the one I randomly chose.
Dan
Ok, can you try this: https://github.com/OpenViX/vix-core/commit/21102144daa54c88986f83e024d7fa01a83ac54d
The logic looks OK (only run if you have both shoes on).
However, I reckon that there should be a "no mount" option when running through the mount locations to get the code to ignore a partition. (This is a separate issue).
Ok, can you try this: https://github.com/OpenViX/vix-core/commit/21102144daa54c88986f83e024d7fa01a83ac54d
That seems to have eliminated the crash. I copied the file across and attempted to change the mount point to /media/hdd as before. No crash, and mount point changed. Thanks for fixing this.
I then tried to go back and change the Default Movie Location to /media/hdd/movie, but couldn't do so. I get "Directory '/media/hdd/movie/' not valid. Partition must be ext or nfs. Please select an acceptable directory".
I thought we had dealt with that issue with the new version of Recordings.py? I've attached the version I currently have in /usr/lib/enigma2/python/Screens. I think it's the new version so I'm puzzled why this behaviour has reverted. I've also attached the version of Harddisk.py I currently have in /usr/lib/enigma2/python/Components - again, I think it's the new version.
Thanks,
Dan
Please post debug log
Debug log attached. I reattempted the operation just before copying the log so you can see the relevant lines at the end.
It's weird because I can see that the Default Movie Location was indeed changed to /media/hdd/movie yesterday, despite the UI telling me it couldn't do so. If I create a test timer it defaults to /media/hdd/movie and it works fine. So this seems to be an issue with the UI for the settings screen.
Dan
Debug log attached. I reattempted the operation just before copying the log so you can see the relevant lines at the end.
It's weird because I can see that the Default Movie Location was indeed changed to /media/hdd/movie yesterday, despite the UI telling me it couldn't do so. If I create a test timer it defaults to /media/hdd/movie and it works fine. So this seems to be an issue with the UI for the settings screen.
Dan
Is the disk actually mounted. Go in to mount manager and resave.
In your debug you have this:
[RecordingSettings] valid partitions ['/']
Should be something like this:
[RecordingSettings] valid partitions ['/media/hdd/', '/media/usb/']
supported_filesystems = ('ext4', 'ext3', 'ext2', 'nfs', 'cifs', 'ntfs')
valid_partitions = []
for partition in Components.Harddisk.harddiskmanager.getMountedPart itions():
print("partition.mountpoint", partition.mountpoint)
print("partition.filesystem()", partition.filesystem())
if partition.filesystem() in supported_filesystems:
valid_partitions.append(partition.mountpoint)
print("[" + self.__class__.__name__ + "] valid partitions", valid_partitions)
My guess is you are using the wrong Harddisk.py so not outputting "ntfs".
Add the red line above to your Recordings.py and get more debug.
Is the disk actually mounted. Go in to mount manager and resave.
In your debug you have this:
[RecordingSettings] valid partitions ['/']
Should be something like this:
[RecordingSettings] valid partitions ['/media/hdd/', '/media/usb/']
I went in to Mount Manager and re-saved as suggested (with the mount as /media/hdd) and the system asked me to reboot, so I did. Result is very confusing. When it came back up the mountpoint was not /media/hdd but it had reverted to its old value of /media/sda2. I've gone back in and attempted a few more times to change it to /media/hdd and have carried out the requested reboot each time, but regardless, when it comes back up the mount point is /media/sda2. I've tried unmounting it and remounting it. Same result. This is really odd because it had seemed stable with /media/hdd and now just won't go there.
Some debug logs from the last 3 reboots attached.
My guess is you are using the wrong Harddisk.py so not outputting "ntfs".Or that part of the code gets ntfs-3g as the answer?
..... you're running 6.0.003, not sure if that might be confusing things?
Can you actually get the debug from Recordings.py making the changes I posted earlier.
Can you actually get the debug from Recordings.py making the changes I posted earlier.
Here it is.
So now the disc is showing:
[RecordingSettings] valid partitions ['/', '/media/sda2/']
So can you move now? Or is there a warning message showing?
So now the disc is showing:
[RecordingSettings] valid partitions ['/', '/media/sda2/']
So can you move now? Or is there a warning message showing?
Just tried selecting /media/hdd/movie and it won't let me move. Green button produces the usual "... Partition must be ext of nfs ..." message. But that seems fair enough in the current circumstances because that location is not currently the mount point for the disk (as per my other message today, the machine seems determined to mount the disk now on /media/sda2, despite my efforts to change this).
If instead I select /media/sda2/movie I am allowed to move on to other settings.
Thanks,
Dan
Just an observation from a user of one of those Seagate hubs. I found that the USB interface on it is quite proprietary and that it doesn't pass standard HDPARM commands to the disk controller which makes it difficult to control disk spin down etc. I found it quite difficult to use on my linux desktop as a general purpose disk so it is now used only for occasional backups of my folders. A generic USB to SATA caddy is probably a better bet in the long run. My quick look through your log file shows that timeshift is not configured as it's reporting less than 1GB of space available. In addition your EPG is set to use the internal flash, which may cause issues if flash space is limited. A better location for EPG is on the HDD. It's only written to disk at shutdown or read from disk at startup. All other times EPG is stored and updated in RAM.
Just tried selecting /media/hdd/movie and it won't let me move. Green button produces the usual "... Partition must be ext of nfs ..." message. But that seems fair enough in the current circumstances because that location is not currently the mount point for the disk (as per my other message today, the machine seems determined to mount the disk now on /media/sda2, despite my efforts to change this).
If instead I select /media/sda2/movie I am allowed to move on to other settings.
Thanks,
Dan
Please post a screen grab of Recording.py exactly as per the test.
Please post a screen grab of Recording.py exactly as per the test.
Shot 1 shows me about to select /media/sda2/movie
Shot 2 shows that I can move down the screen after this
Shot 3 shows me about to select /media/hdd/movie
Shot 4 shows the error message after hitting the green button from the position shown in shot 3.
Shot 5 shows Recordings.py in the \Root\usr\lib\enigma2\python\Screens directory
Recordings.py is the file itself, from that location
Current debug log also attached for good measure.
Cheers,
Dan
Just an observation from a user of one of those Seagate hubs. I found that the USB interface on it is quite proprietary and that it doesn't pass standard HDPARM commands to the disk controller which makes it difficult to control disk spin down etc. I found it quite difficult to use on my linux desktop as a general purpose disk so it is now used only for occasional backups of my folders. A generic USB to SATA caddy is probably a better bet in the long run. My quick look through your log file shows that timeshift is not configured as it's reporting less than 1GB of space available. In addition your EPG is set to use the internal flash, which may cause issues if flash space is limited. A better location for EPG is on the HDD. It's only written to disk at shutdown or read from disk at startup. All other times EPG is stored and updated in RAM.
That's an interesting observation - thanks. I am thinking it might be best just to buy a disk for the internal caddy and give up on my preferred approach of using an existing USB drive, as the latter approach seems less than smooth. I use the same approach on another box and it works OK but I did have teething problems getting that working when I first put them together.
I haven't configured timeshift yet as I wanted to sort these problems first. And thanks also for the tip re. EPG storage - again, I want to get the disk problems sorted first before transferring the EPG location there.
The Seagate Hub was fine on a Windows box when I was using the supplied software (which also enabled disk spin down). On linux I just use it for backups. Most of the time it is powered off.
As regards your screenshots - are you saying that the menu interface is changing the movie location to media/hdd/movie when you get to "Timer Recording Location"? You need to use the right/left arrow keys to select media/sda2/movie which is the actual mount point. Or maybe I'm misunderstanding your actual setup process.
The Seagate Hub was fine on a Windows box when I was using the supplied software (which also enabled disk spin down). On linux I just use it for backups. Most of the time it is powered off.
As regards your screenshots - are you saying that the menu interface is changing the movie location to media/hdd/movie when you get to "Timer Recording Location"? You need to use the right/left arrow keys to select media/sda2/movie which is the actual mount point. Or maybe I'm misunderstanding your actual setup process.
Yes, I can select a different location using the left/right buttons. But after selecting a different location I'm then unable to move to the second line of the screen if it's a location it doesn't like. I can press the green button , resulting in the error message shown in shot 4.
Thanks,
Dan
Ok - but why are you selecting a different location? The only valid location for you is /media/sda2/movie
Ok - but why are you selecting a different location? The only valid location for you is /media/sda2/movie
I agree, but there's a history here :-) I'm doing it this time at huevos's request as he seeks to track down what Recordings.py is seeing and doing. He and the others on the forum have already updated Recordings.py as a result of my original posting. I then moved on to another issue - crashes on trying to set the mount point. This also appeared to have been fixed but now does not seem to be, as the mount point reset itself on rebooting and now stubbornly remains at /media/sda2 despite repeated efforts to change it. Once this problem is fixed I intend to change the mount point and then change the default movie location as per shot 3. But I agree that it can't work right now because of the problem I'm having setting the mount point.
..... you're running 6.0.003, not sure if that might be confusing things?
That's the version that was on the box when it arrived a couple of weeks ago from World of Satellite. I assumed it was the most up-to-date version so have not updated it. Should I be running something else?
Thanks,
Dan
Thanks for the screenshots.
You can access the disc by name as mounted, so not a bug.
Thanks for the screenshots.
You can access the disc by name as mounted, so not a bug.
Yes. I just need to work out why I'm now no longer able to change the mount point from /media/sda2 to /media/hdd. Then I'm confident I'll be able to change the default movie location to match.
Thanks,
Dan
Yes. I just need to work out why I'm now no longer able to change the mount point from /media/sda2 to /media/hdd. Then I'm confident I'll be able to change the default movie location to match.
Thanks,
Dan
I don't know, but it is not related to Recordings.py. Right now you should be up and running with the current partition name.
Please post a screen grab of Recording.py exactly as per the test.
You really want to see the contents of /etc/fstab.
You really want to see the contents of /etc/fstab.
Latest (for any of you not utterly sick of my saga by now) is that I tried once again to change the mount point for the USB drive. This time, instead of using the "Setup mounts" (green button) option in the Mount Manager, I demounted the drive, which worked, and then remounted it using the mount point I wanted. This seems to have worked. I won't fully believe it's finally fixed until the box has been rebooted a few times and not changed the mount point, but for the moment, the disk is mounted where I wanted it. I will test whether I can change the Default movie location to this mount after it's had a reboot.
I probably should have posted /etc/fstab before. Attached. I presume the last line is for the USB drive. The second last line looks odd to me but I'm no expert on fstab
Happy New Year everyone.
Dan
The second last line looks odd to me but I'm no expert on fstab.
Me too !!!
I don't know, but it is not related to Recordings.py.It's still a bug. The acceptable list contains ntfs, but the fstab (or /proc/mounts) entry has ntfs-3g.
And that supported_filesystems list is in Recordings.py (in isValidPartition()).
Well earlier /proc/mounts was returning "/media/sda2/", so something must have changed in the mean time.
Well earlier /proc/mounts was returning "/media/sda2/", so something must have changed in the mean time.The detection of "ntfs" to allow it to be mounted was changed.
But it shows up in /proc/mounts as ntfs-3g (since "ntfs" is the kernel-verson, not the fuseblk one). And that ("ntfs-3g") isn't on the list of things that can be used for the movies location.
The detection of "ntfs" to allow it to be mounted was changed.
But it shows up in /proc/mounts as ntfs-3g (since "ntfs" is the kernel-verson, not the fuseblk one). And that ("ntfs-3g") isn't on the list of things that can be used for the movies location.
< 7374.9796> [Setup] DEBUG: Config list has changed!
< 7374.9960> partition.mountpoint /
< 7375.0121> partition.filesystem() ext4
< 7375.0281> partition.mountpoint /media/sda2/
< 7375.0440> partition.filesystem() ntfs
< 7375.0602> [RecordingSettings] valid partitions ['/', '/media/sda2/']
Happy New Year.
< 7374.9796> [Setup] DEBUG: Config list has changed!
< 7374.9960> partition.mountpoint /
< 7375.0121> partition.filesystem() ext4
< 7375.0281> partition.mountpoint /media/sda2/
< 7375.0440> partition.filesystem() ntfs
< 7375.0602> [RecordingSettings] valid partitions ['/', '/media/sda2/']
Happy New Year.And the relevance is?
The user still has a problem.
And the relevance is?
The user still has a problem.No, he does not have a problem. He was trying to use a name that was not the partition name. But as the log shows the correct partition name is present and file system is ntfs. Later he managed to change the partition name to what he wanted in MountManager.
No, he does not have a problem. He was trying to use a name that was not the partition name. But as the log shows the correct partition name is present and file system is ntfs. Later he managed to change the partition name to what he wanted in MountManager.But has not yet reported being able to use it for the default movie location.
Which I reckon should be checking "ntfs-3g" against a list that doesn't contain it (it contains "ntfs").
I did just manage to get a "Partition must be ext or nfs" message. But it went away when I restarted the GUI so might just have been an artefact of moving a different disk into the /media/hdd position.
I suspect I confused myself by asking for the contents of /etc/fstab (which actually now contains auto, but did at one point contain ntfs-3g), but the code actually looks at /proc/mounts (which makes sense, as that won't ever contain "auto").
So yes, it does seem to be working, although it might take a few restarts to get it in place.
Also, how can you create the initial movie directory?
The important thing is to make sure the disc is properly mounted and with the right name before trying to set up recording locations. The reason the OP had failures was because that was not the case.
To OP, try this: Menu -> Setup -> System -> User interface -> Settings: Sort settings screens alphabetically YES
< 7307.9526> [InfoBarGenerics] Key: 399 (Make) KeyID='KEY_GREEN' Binding='('GREEN',)'.
< 7307.9530> [ActionMap] Keymap 'ConfigListActions' -> Action = 'save'.
< 7307.9554> [Skin] Processing screen 'MessageBox', position=(380, 355), size=(520 x 10) for module 'MessageBox'.
< 7307.9611> [ePNG] loadSVG /usr/share/enigma2/skin_default/icons/input_question.svg 53x53 from 53x53
< 7307.9633> [ePNG] loadSVG /usr/share/enigma2/skin_default/icons/input_info.svg 53x53 from 53x53
< 7307.9650> [ePNG] loadSVG /usr/share/enigma2/skin_default/icons/input_error.svg 53x53 from 53x53
< 7307.9660> [Screen] Warning: Skin is missing element 'icon' in <class 'Screens.MessageBox.MessageBox'>(Directory '/media/sda2/' not valid. Partition must be ext or nfs
Sorry, out of ideas. Might be related to this commit
https://github.com/OpenViX/enigma2/commit/2420492d17a236c6f7629c50e3061a66b1e3894f
Funnily enough, I'm getting the "partition must be ext or nfs" error on OpenVix 6 2 010 on my Formuler F1 box (previously posted here (https://www.world-of-satellite.com/showthread.php?65440-GUI-Freeze-and-hang))
I'm trying to save to a mounted ZFS partition - I've had to mount using nfsvers=4 option in /etc/fstab so I can get at all my datasets.
Looking at that commit, I notice the supported filesystem includes "nfs" but not the "nfs4" that df -Th shows me - could this be the reason for my problem?
Funnily enough, I'm getting the "partition must be ext or nfs" error on OpenVix 6 2 010 on my Formuler F1 box (previously posted here (https://www.world-of-satellite.com/showthread.php?65440-GUI-Freeze-and-hang))
I'm trying to save to a mounted ZFS partition - I've had to mount using nfsvers=4 option in /etc/fstab so I can get at all my datasets.
Looking at that commit, I notice the supported filesystem includes "nfs" but not the "nfs4" that df -Th shows me - could this be the reason for my problem?
Why don't you try?
Why don't you try?
Fair point! To be honest, I thought compiling the Python was a bit more difficult.
I did give it a go but it didn't work. I did a bit more debugging. Specifically, I added this to Timeshift.py as part of the isValidPartition function:
print("[Timeshift] DEBUG: mountpoint %s and filesystem %s" % (partition.mountpoint, partition.filesystem()))
Results I got as I was cycling through the various partitions was:
[Timeshift] DEBUG: mountpoint / and filesystem ubifs
I read that as it not actually checking the actually directory, but rather always / which is failing (because it's always ubifs)
Will do a bit more digging tomorrow hopefully
"/" is not a valid timeshift location.
This is what I get on my working system:
for partition in Components.Harddisk.harddiskmanager.getMountedPart itions():
print("[Timeshift] DEBUG: mountpoint %s and filesystem %s" % (partition.mountpoint, partition.filesystem()))
print("Valid", partition.filesystem() in supported_filesystems)
if partition.filesystem() in supported_filesystems:
< 41323.0026> 10:21:58.5063 [Timeshift] DEBUG: mountpoint / and filesystem rootfs
< 41323.0034> 10:21:58.5071 Valid False
< 41323.0044> 10:21:58.5080 [Timeshift] DEBUG: mountpoint /media/hdd/ and filesystem ext4
< 41323.0050> 10:21:58.5087 Valid True
< 41323.0060> 10:21:58.5096 [Timeshift] DEBUG: mountpoint /media/usb/ and filesystem ext4
< 41323.0067> 10:21:58.5103 Valid True
I get a different result. I tweaked the code:
for partition in Components.Harddisk.harddiskmanager.getMountedPart itions():
print("[Timeshift] DEBUG: path %s, mountpoint %s and filesystem %s" % (path, partition.mountpoint, partition.filesystem()))
print("Valid", partition.filesystem() in supported_filesystems)
if partition.filesystem() in supported_filesystems:
valid_partitions.append(partition.mountpoint)
These are the results in my log:
< 210.0182> [Timeshift] DEBUG: path /beast/, mountpoint / and filesystem ubifs
< 210.0202> Valid False
< 221.3488> [Timeshift] DEBUG: path /media/, mountpoint / and filesystem ubifs
< 221.3506> Valid False
< 224.8464> [Timeshift] DEBUG: path /e2/timeshift/, mountpoint / and filesystem ubifs
< 224.8483> Valid False
< 228.7765> [Timeshift] DEBUG: path /beast/enigma2/timeshift/, mountpoint / and filesystem ubifs
< 228.7786> Valid False
So the getMountedPartitions() function is not picking up my mounted NFS partition (/beast). Not sure why - trying to track down the getMountedPartitions function to see what's going on.
For reference, the partition does show up in mount:
172.30.1.2:/beast on /beast type nfs4 (rw,relatime,vers=4.0,rsize=8192,wsize=8192,namlen =255,soft,proto=tcp,port=0,timeo=14,retrans=2,sec= sys,clientaddr=172.30.1.18,local_lock=none,addr=17 2.30.1.2)
(and equivalent in df)
I get a different result. I tweaked the code:
for partition in Components.Harddisk.harddiskmanager.getMountedPart itions():
print("[Timeshift] DEBUG: path %s, mountpoint %s and filesystem %s" % (path, partition.mountpoint, partition.filesystem()))
print("Valid", partition.filesystem() in supported_filesystems)
if partition.filesystem() in supported_filesystems:
valid_partitions.append(partition.mountpoint)
These are the results in my log:
< 210.0182> [Timeshift] DEBUG: path /beast/, mountpoint / and filesystem ubifs
< 210.0202> Valid False
< 221.3488> [Timeshift] DEBUG: path /media/, mountpoint / and filesystem ubifs
< 221.3506> Valid False
< 224.8464> [Timeshift] DEBUG: path /e2/timeshift/, mountpoint / and filesystem ubifs
< 224.8483> Valid False
< 228.7765> [Timeshift] DEBUG: path /beast/enigma2/timeshift/, mountpoint / and filesystem ubifs
< 228.7786> Valid False
So the getMountedPartitions() function is not picking up my mounted NFS partition (/beast). Not sure why - trying to track down the getMountedPartitions function to see what's going on.
For reference, the partition does show up in mount:
172.30.1.2:/beast on /beast type nfs4 (rw,relatime,vers=4.0,rsize=8192,wsize=8192,namlen =255,soft,proto=tcp,port=0,timeo=14,retrans=2,sec= sys,clientaddr=172.30.1.18,local_lock=none,addr=17 2.30.1.2)
(and equivalent in df)
Harddisk.py
def getMountedPartitions(self, onlyhotplug=False, mounts=None):
if mounts is None:
mounts = getProcMounts()
parts = [partition for partition in self.partitions if (partition.is_hotplug or not onlyhotplug) and partition.mounted(mounts)]
devs = set([partition.device for partition in parts])
for devname in devs.copy():
if not devname:
continue
dev, part = self.splitDeviceName(devname)
if part and dev in devs: # If this is a partition and we still have the wholedisk, remove wholedisk.
devs.remove(dev)
# Return all devices which are not removed due to being a wholedisk when a partition exists.
return [partition for partition in parts if not partition.device or partition.device in devs]
def addMountedPartition(self, device, desc):
for partition in self.partitions:
if partition.mountpoint == device:
return # Already_mounted.
self.partitions.append(Partition(mountpoint=device , description=desc))
abu baniaz
30-10-22, 07:09
Recording is one thing, timeshift is another. The requirements for timeshift do not need to be applied to those for recording.
?... who are you replying to?
I get a different result. I tweaked the code:
for partition in Components.Harddisk.harddiskmanager.getMountedPart itions():
print("[Timeshift] DEBUG: path %s, mountpoint %s and filesystem %s" % (path, partition.mountpoint, partition.filesystem()))
print("Valid", partition.filesystem() in supported_filesystems)
if partition.filesystem() in supported_filesystems:
valid_partitions.append(partition.mountpoint)
These are the results in my log:
< 210.0182> [Timeshift] DEBUG: path /beast/, mountpoint / and filesystem ubifs
< 210.0202> Valid False
< 221.3488> [Timeshift] DEBUG: path /media/, mountpoint / and filesystem ubifs
< 221.3506> Valid False
< 224.8464> [Timeshift] DEBUG: path /e2/timeshift/, mountpoint / and filesystem ubifs
< 224.8483> Valid False
< 228.7765> [Timeshift] DEBUG: path /beast/enigma2/timeshift/, mountpoint / and filesystem ubifs
< 228.7786> Valid False
So the getMountedPartitions() function is not picking up my mounted NFS partition (/beast). Not sure why - trying to track down the getMountedPartitions function to see what's going on.
For reference, the partition does show up in mount:
172.30.1.2:/beast on /beast type nfs4 (rw,relatime,vers=4.0,rsize=8192,wsize=8192,namlen =255,soft,proto=tcp,port=0,timeo=14,retrans=2,sec= sys,clientaddr=172.30.1.18,local_lock=none,addr=17 2.30.1.2)
(and equivalent in df)
So using the attachment below:
Putty to receiver: init 4 (space between)
Filezilla: copy attachment to /usr/lib/enigma2/python/Components
Putty: init 6 (space between)
Post the debug log here.(do not zip log)
Thanks for looking at this. Log attached.
64437
Thanks for looking at this. Log attached.
64437
afraid need more debug from boot startup......so use the following version of Harddisk.py and reboot as before, then post debug log.
afraid need more debug from boot startup......so use the following version of Harddisk.py and reboot as before, then post debug log.
Updated log attached
64440
Updated log attached
64440
Thanks - can you also mount via E2----------> menu/setup/Network/Mounts
and then run with a further updated Harddisk.py
Thanks - can you also mount via E2----------> menu/setup/Network/Mounts
and then run with a further updated Harddisk.py
First log is updated Harddisk.py with NFS mount through E2. I had specified nfsvers=4 in the mount options in E2, but then nfsvers=3 was added. Seems to mount with NFSv3. Getting errors that /media/net/beast/subdir is not writable (to see the data in the ZFS sets, you need to mount with nfsvers=4)
64445
So I then edited /etc/fstab on my E2 box to remove the nfsvers=3 (and, therefore, leave nfsvers=4). Reboot and here's the log (sets now visible in shell but getting same errors about it not being ext/nfs partition)
64444
Thanks… away until Sunday, so may not be able to do much until then … but will have a look later today at logs
First log is updated Harddisk.py with NFS mount through E2. I had specified nfsvers=4 in the mount options in E2, but then nfsvers=3 was added. Seems to mount with NFSv3. Getting errors that /media/net/beast/subdir is not writable (to see the data in the ZFS sets, you need to mount with nfsvers=4)
64445
So I then edited /etc/fstab on my E2 box to remove the nfsvers=3 (and, therefore, leave nfsvers=4). Reboot and here's the log (sets now visible in shell but getting same errors about it not being ext/nfs partition)
64444
so both logs show 224.5516> [RecordingSettings] valid partitions ['/media/net/beast/', '/media/net/beast'] from Records.py ----> isValidPartition (called by TimeShift & Recordings.py)
so where is it being rejected??? i.e. "Getting errors that /media/net/beast/subdir is not writable"
so both logs show 224.5516> [RecordingSettings] valid partitions ['/media/net/beast/', '/media/net/beast'] from Records.py ----> isValidPartition (called by TimeShift & Recordings.py)
so where is it being rejected??? i.e. "Getting errors that /media/net/beast/subdir is not writable"
Thanks for your help. After a lot of adding lines , rebooting and looking at logs, I think I've found the issue - though how to fix it, I'm not sure.
I added this into Recordings.py as part of isValidPartition
rp = realpath(path)
cp_rp = Components.Harddisk.findMountPoint(realpath(path))
print("[Recordings] Path is: %s, realpath is: %s, realpath from findMountPoint: %s" % (path, rp, cp_rp))
Result is:
[Recordings] Path is: /e2/recordings/, realpath is: /media/net/beast/enigma2/recordings, realpath from findMountPoint: /media/net/beast/enigma2
The NFS mount in /etc/fstab is /media/net/beast - but nfs4 will result in each ZFS dataset displaying as a separate mount - hence the path doesn't match with the result from findMountPoint.
I have gone back through the source and I don't think the findMountPoint has changed in a long time so don't know why it worked for me in 5 but not in 6. My guess is it's some difference in how python3 deals with os.path
The NFS mount in /etc/fstab is /media/net/beast - but nfs4 will result in each ZFS dataset displaying as a separate mount - hence the path doesn't match with the result from findMountPoint.An NFS mount should be just an NFS mount. How it actually exists on the server should be irrelevant.
My guess is it's some difference in how python3 deals with os.pathDifficult to see how someone would have made the code deliberately perverse.
But it's also interesting how realpath() converts it to the correct result.
def isValidPartition(self, path):
print("path", path)
if path is not None:
supported_filesystems = ('ext4', 'ext3', 'ext2', 'nfs', 'cifs', 'ntfs')
valid_partitions = []
for partition in Components.Harddisk.harddiskmanager.getMountedPart itions():
if partition.filesystem() in supported_filesystems:
valid_partitions.append(partition.mountpoint)
print("[" + self.__class__.__name__ + "] valid partitions", valid_partitions)
if valid_partitions:
from os.path import abspath
print("Components.Harddisk.findMountPoint(abspath(path))", Components.Harddisk.findMountPoint(abspath(path)))
print("Components.Harddisk.findMountPoint(realpath(path))", Components.Harddisk.findMountPoint(realpath(path)) )
return Components.Harddisk.findMountPoint(realpath(path)) +'/' in valid_partitions or Components.Harddisk.findMountPoint(realpath(path)) in valid_partitions
return False
Please post debug.
supported_filesystems = ('ext4', 'ext3', 'ext2', 'nfs', 'cifs', 'ntfs')
nfs version 4 was mentioned. I think that will show up as nfs4.
Please post debug.
64525
I've cut it just after it picked up the log lines I added to Recordings.py. Interestingly, the getMountedPartition lines that twol added pick up both /media/net/beast and /media/net/beast/enigma2 (125.6412) in the dump but not in the individual lines (125.6425, 125.6428, 125.6432). I note valid_partitions has a double entry of ['/media/net/beast/', '/media/net/beast']. Wonder if /media/net/beast/enigma2 is getting cut down by some function.
nfs version 4 was mentioned. I think that will show up as nfs4.
Yes, correct. If I use nfs/nfs3, the datasets won't mount so I can effectively only get at the root directory. I have added ext4 to supported_filesystems (and it seems to work).
64525
I've cut it just after it picked up the log lines I added to Recordings.py. Interestingly, the getMountedPartition lines that twol added pick up both /media/net/beast and /media/net/beast/enigma2 (125.6412) in the dump but not in the individual lines (125.6425, 125.6428, 125.6432). I note valid_partitions has a double entry of ['/media/net/beast/', '/media/net/beast']. Wonder if /media/net/beast/enigma2 is getting cut down by some function.
Yes, correct. If I use nfs/nfs3, the datasets won't mount so I can effectively only get at the root directory. I have added ext4 to supported_filesystems (and it seems to work).
This log is not from my debug.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.