31 replies to this topic

[Tom0000]

I decided to move all old recording created by dm8000 to second disk of my NAS. I will mount this share using iocharset=utf8 . The default recording place I will mount without it for prevent future problems. It is time for it. Default disk is almost full.

Again , thank you all for a help.

(I will not renaming all because it is too big set of files. I will not move because it does not work from console , and for do it from enigma2 gui it is too big set of files)

Edited by Tom0000, 24 February 2017 - 08:24.

[Erik Slagter]

For once I agree with spacerat, busybox (and all it's "features") IS a sorry excuse for the real thing.

 

On the other hand, we do have a package util-linux-mount in the feed and it DOES seem to be installed in the image by default, the only thing is, it never gets activated:

root@solo4k:~# opkg install --force-reinstall util-linux-umount
Reinstalling util-linux-umount (2.28.1-r0.0) on root.
Installing util-linux-umount (2.28.1) on root.
update-alternatives: Linking /bin/umount to /bin/busybox.nosuid
Configuring util-linux-umount.
update-alternatives: Linking /bin/umount to /bin/busybox.nosuid

I am not sure if this is intentional or just a bug.

 

So if someone would use /bin/umount.util-linux explicitly, it might just work, although it's the reals solution.

Edited by Erik Slagter, 24 February 2017 - 11:05.

[SpaceRat]

On the other hand, we do have a package util-linux-umount in the feed and it DOES seem to be installed in the image by default, the only thing is, it never gets activated:

That's not the package I mean.

There is some comment about that mount-util you just mentioned in its OE recipe: It's installed as an alternative with lower/same priority than/as the busybox counterpart.
Has something to do with "util-linux" having to be built fully, but OE always wants the busybox version.



I mean this one:
http://cgit.openembe...fs-utils_git.bb

You probably do not want to make the transition to it in OpenPLi 4.0 though, because in the old OE core you still got Samba 3.0.37 and with Samba 3.0.x it was still part of the Samba package, so if you try to use a newer cifs-utils, you would also drag the newer Samba in, causing conflicts.
Or you have to stick with the cifs-util from Samba 3.0.37 (Which is probably still better than busybox' version).

[Erik Slagter]

I am just glad once more I'm never using SMB. Someone who feels like it may try to sort it out

[SpaceRat]

Oh, it works great.

In oe-a we have Samba 3.6.25 as server side, which brings these additional features:
- SMBv2 support instead of just SMBv1
- Full IPv6 support on the server side
- NTLMSSP security (Ok, that doesn't matter much if you configure access to be wide open )
- reduced size, comparing our special (= using patches from OpenWrt to remove parts not needed on an E2 box) build of Samba 3.6.25 with the former Samba 3.0.37
plus cifs-utils 5.9 for the client side.

But I remember that the ViX team was close to killing me during the transition

During the last days we also added WS-Discovery and LLMNR (Link Local Multicast Name Resolution) daemons, so we got rid of the dependency on the legacy NetBIOS as well.

My main reason to monitor the progress of OpenPLi 5.0 actually is Samba 4.x .... and it's enormeous size.
The Samba.org team seems to think "As long as it is smaller than Windows Server 2012 running inside a VM it's ok.".

There are OpenWrt/LEDE patches for Samba 4.x too, I don't think that an E2 box really needs to have the capability to act as an Active Domain Server.

[SpaceRat]

Is it normal that OpenPLi 4.0 doesn't build on current Linuxes as build system?

I tried to make OpenPLi 4.0 on the same machine that can properly build OpenPLi 5.0, but it fails in ncurses ...

[betacentauri]

Try master-for-gcc5 branch.

https://github.com/O...master-for-gcc5

[Erik Slagter]

Yes, there is "some gap" between the OE version we use and the current state of the normal building tools. The good news is that this branch also appears to work on gcc-6.

[SpaceRat]

Just for you, I spend some hours of work in building a Samba 3.6.25 plus cifs-utils 6.6 for OpenPLi.
This time I made it a drop-in-replacement for the existing packages, so there were no files moved across packages (Which opkg loves) and I patched some modified defaults back to those from Samba 3.0.37, so that old configs continue to work.

https://github.com/O...e-core/pull/173

[Erik Slagter]

Hmmm, you'd better have stated your intention first, OpenPLi-4 is on it's last legs and it's ready to be frozen as current "stable" release. We're not ging to make such changes there. Development now only continues in the master-next branch (for the time being, until the new development model is deployed).

[SpaceRat]

I am aware that OpenPLi 4.0 is going to be EOLed soon ... but the intention was this:
You will probably have to drop certain machines in OpenPLi 5.0 or they will end up with far less features.

As you will have noticed yourself, the new Samba 4.x in OpenPLi 5.0 is huge, even with all optimization power spent on it so far you can't get a Samba 4.x smaller than 12 (twelve) Megabytes.
Too much for all machines with 64 MB Flash and probably - especially when not patching Samba 4.x for size - for machines with 128 MB Flash as well.

So the only reason to spend the work on the old OpenPLi 4.0 was to hopefully get this in before dawn.
It would greatly enhance interoperability of those machines that will be stuck with OpenPLi 4.0 and those with other distros and the newer OpenPLi 5.0.

New OpenPLi 5.0 will speak SMBv2 (and even up to SMBv3.1) thanks to the new Samba 4.x inside, the old ones shouldn't be stuck with SMBv1 and flaky charsets.

[Erik Slagter]

The only machines that have too little flash to run a current devel OpenPLi image with samba 4 are the ones that are not going to be supported for other reasons anyway. So no, I don't think this will be an issue. And that's good, because we have already enough issues, the next OpenPLi image should have been out about two years ago.