Please test: improved Linux access to URC-6440+OARUSB04G

[davecs]

I think I know what to do now but it's late in UK, so can I write it out nicely tomorrow sometime?

What I'll do is to add a section headed Systemd between Any User Method and Unmounting which will explain the additional steps you have to take with distributions that use systemd, which is the majority.

I think that it might be best to delete the old method, and replace it with a section called Manual Method which is basically the one that HH1 refers to in this thread. Any User Method will be renamed Automatic Method.

Is that OK?

[mathdon]

With the line
Code:
/dev/disk/by-id/usb-UEI_Remotes_UEI_Mass_Storage_000000000001-0:0-part1 /urc6440 vfat user,noauto,umask=0,nosuid,nodev,nofail,x-gvfs-show 0 0

in /etc/fstab you can mount it without root/sudo. Just
Code:
mount /urc6440

The directory in the second position can be any existing directory. Before removing the remote, do
Code:

umount /urc6440

otherwise the system might misbehave.

That is the previous solution that I had. Although it works as you have described, it does require that extra step of running mount /urc6440. With the method from davecs as I now have it working, no extra step is required. Plug the remote in and RMIR will download it in autodetect mode without further intervention.

[mathdon]

I think that it might be best to delete the old method, and replace it with a section called Manual Method which is basically the one that HH1 refers to in this thread. Any User Method will be renamed Automatic Method.

Is that OK?

Absolutely, I think that is a good idea.

[mathdon]

I found another site which told me to remove a further line in system-udevd.service but I hashed it out as follows:

# SystemCallFilter=@system-service @module @raw-io bpf

Once I did this, after a reboot, my 6440 remote started mounting, though it also put up an error to say it was already mounted!

That line is not present in the file in my Ubuntu, but I will add a sentence to my instructions in this draft to delete it or comment it out in the file copy in /etc/systemd/system. I would be grateful if you could look at that that draft and give me any comments before I include it in the RMIR release.

[mathdon]

I found another site which told me to remove a further line in system-udevd.service but I hashed it out as follows:

# SystemCallFilter=@system-service @module @raw-io bpf

I have an alternative suggestion that I would like you to try, instead of commenting out this line. Based on the System Call Filtering section in this article, I suggest adding @mount after @system-service, as @system-service excludes mount from the allowed system calls. If that works, it seems to be a more specific fix than deleting the filters entirely.

[davecs]

I have an alternative suggestion that I would like you to try, instead of commenting out this line. Based on the System Call Filtering section in this article, I suggest adding @mount after @system-service, as @system-service excludes mount from the allowed system calls. If that works, it seems to be a more specific fix than deleting the filters entirely.

Yeah, why not? In for a penny...

When I've got all this done, I'll go through that document you sent me. Not able to get on computer at present due to wife's daughter.

EDIT: aaaaaaaaaAAAND ... it worked!

[davecs]

I have now added the systemd section to the wiki page, and edited around it. I will work on the Manual method later. Let me know if anything can be improved.

[HamburgerHelper1]

On the wiki page you have the mount_ofa script to be placed in /usr/local/bin folder
but I do not have a bin folder in /usr/local.
Where do you suggest this script be placed?

[mathdon]

On the wiki page you have the mount_ofa script to be placed in /usr/local/bin folder
but I do not have a bin folder in /usr/local.
Where do you suggest this script be placed?

My /usr/local/bin folder only has files that I have created, of which there is just one other than the two added by this method. So I suggest you simply create the bin folder.

[davecs]

On the wiki page you have the mount_ofa script to be placed in /usr/local/bin folder
but I do not have a bin folder in /usr/local.
Where do you suggest this script be placed?

/usr/bin would be OK.

Or you could create /usr/local/bin/ it wouldn't hurt as the full path to the script is declared in the rules file. That would be my favoured suggestion.

[davecs]

I have posted a draft for your comments of what I suggest for inclusion in the next RMIR release, It is a folder with full instructions that I hope will be more understandable than the web sources on which it is based.

Two little things: One, you have to add @mount to the other line where present.

Two, the opening of the mount in an alternate universe ... er ... userspace has nothing to do with the kernel. It is to do with systemd which is an initialisation system but which persists and controls everything, and has divided the linux community. Linux is generally modular, with each module performing a specific task, but systemd is monolithic. Sadly, the big hitters in Linux have adopted it. You can see how something which ought to work simply becomes complicated as a result.

[davecs]

@mathdon

Graham

OK I'd like to suggest a couple of things about the /etc/fstab solution:

One, that the mount point isn't based off root. For an fstab entry, it should start with /mnt/ I suggest somthing like /mnt/REMOTE as opposed to /media/REMOTE which is appropriate for an automounting system.

So the mount and unmount commands would be

mount /mnt/REMOTE and umount /mnt/REMOTE.

What I suggest is that two more .desktop files, which will Mount and Unmount the remote, are added to the next version in order that they can be used the same way as the RMIR/RMDU/RMPB.desktop files. In a number of distros/desktops they can be dragged onto panels etc to have shortcuts, in the same way that we can with RMIR etc. Or they can be run directly from the folder (as can RMIR etc.).

Get this in place and I will complete the "Manual" part of the wiki.

[mathdon]

Two little things

That draft was from yesterday. I have now posted a second draft in the same location. I have amended the instructions to take account of your two things. Following Randy's query I have also added a conditional in the script to create the /usr/local/bin file if it does not exist.

I would be grateful if you could check both of these. It has been a bumpy ride but I think all possibilities have now been covered - hopefully - so we are almost there. RMIR v3.0.1 is ready to post once you are happy with this draft.

[mathdon]

My post crossed with yours. I don't understand what you are now asking. I have no intention of adding any mention of the /etc/fstab solution to RMIR. I have no views on the changes you suggest. It is inferior to the solution you have now come up with, and which is in v3.0.1 of RMIR, so why muddy the waters? What the Wiki says about it is up to you, including leaving it out if you so wish.

[davecs]

My post crossed with yours. I don't understand what you are now asking. I have no intention of adding any mention of the /etc/fstab solution to RMIR. I have no views on the changes you suggest. It is inferior to the solution you have now come up with, and which is in v3.0.1 of RMIR, so why muddy the waters? What the Wiki says about it is up to you, including leaving it out if you so wish.

Different Linuxes behave differently. Some don't really support sudo. Some that do, will require it to be specified. Maybe the best bet is to start a root terminal.

In some distros, you'll have to do a line

Code: Select all

sudo su

in the terminal to change it into a root terminal. In others you might have to do:

Code: Select all

su
password:

i.e., enter a line su and you will be prompted for a password, yours or the root password depending on the distro. Once you are in a root terminal, you can run

Code: Select all

sh Linux6440fix.sh

which ought to work for any linux.

Otherwise that stuff looks excellent!

I'll think about the fstab stuff. My worry is that they'll mess about with systemd again and it will stop working. So it will be a good idea to have a fallback in the wiki.