View Full Version : [Mut@nt HD2400] Can't Start Samba
I can't seem to get Samba to install since my USB update to 4.2.016 and subsequently to 4.2.020.
When entering Samba Setup it just gets stuck in a loop of trying to install "packagegroup-base-smbfs-server". It tries to install, reboots and when entering Samba Setup it wants to install again.
Any ideas please? Previous threads I searched for didn't help.
51620
Try installing Samba after the usb flash, but before you restore any plugins/settings.
Thanks, I saw your previous posts suggesting this, but yet another USB install is my very last resort. I'm fed up of restoring and having to manually download and reconfigure everything that didn't backup.
Can't you do a settings backup, usb flash and restore them when Samba has started ok?
Do an image backup at the same time, and then if you can't get Samba going, you can get back to where you were in a few minutes.
I will if there's no alternative such as a manual samba install from the command line. Whenever I do a settings backup it never seems to backup everything :(
I always lose my skins, LCD skins, and numerous plugins such as Kodi Direct and AceStream. I've got pretty quick at setting it all back up, but I'd rather avoid it if possible.
This might help a bit.....
http://www.world-of-satellite.com/showthread.php?52787-How-to-create-an-image-that-includes-Kodi-setup-and-addons&p=412947&viewfull=1#post412947
What happens if you execute
opkg install packagegroup-base-smbfs-server
right on the shell of the box (via Telnet or ssh)?
I get:
root@mutant2400:~# opkg install packagegroup-base-smbfs-server
Installing packagegroup-base-smbfs-server (1.0-r83.1) on root.
cifs: unsatisfied recommendation for kernel-module-cifs
packagegroup-base-smbfs: unsatisfied recommendation for kernel-module-cifs
packagegroup-base-smbfs: unsatisfied recommendation for kernel-module-smbfs
Installing packagegroup-base-smbfs (1.0-r83.1) on root.
Installing cifs (5.9-r3) on root.
Downloading http://www.openvix.co.uk/feeds/openvix/release/4.2/hd2400/mips32el/cifs_5.9-r3_mips32el.ipk.
Removing corrupt package file /var/cache/opkg/2ba12fb29cdcf9635720deec506d59d5_cifs_5.9-r3_mips32el.ipk.
Collected errors:
* opkg_install_pkg: Failed to download cifs. Perhaps you need to run 'opkg update'?
* opkg_install: Cannot install package packagegroup-base-smbfs-server.
Seems either your download of cifs is corrupt or the file on the feed.
OK, I managed to work around the issue by:
1) Manually dowmloading http://www.openvix.co.uk/feeds/openvix/release/4.2/hd2400/mips32el/cifs_5.9-r3_mips32el.ipk and installing it with extension manager.
2) Running "opkg install packagegroup-base-smbfs-server" again
3) Profit :)
1) Manually dowmloading http://www.openvix.co.uk/feeds/openvix/release/4.2/hd2400/mips32el/cifs_5.9-r3_mips32el.ipk and installing it with extension manager.
cd /tmp
wget http://www.openvix.co.uk/feeds/openvix/release/4.2/hd2400/mips32el/cifs_5.9-r3_mips32el.ipk
opkg install cifs_5.9-r3_mips32el.ipk
would have done then too ... unless it's wget on the box that breaks the download, but I wouldn't know why.
This problem first started about 9 months ago, but only a few users were ever effected by it, so it was never fully investigated.
cd /tmp
wget http://www.openvix.co.uk/feeds/openvix/release/4.2/hd2400/mips32el/cifs_5.9-r3_mips32el.ipk
opkg install cifs_5.9-r3_mips32el.ipk
would have done then too ... unless it's wget on the box that breaks the download, but I wouldn't know why.
I tried that first and can't recall the error, but it may well have been wget that broke the download.
Actually I already start to fail understanding at the point why ViX comes without Samba support out of the box.
Gesendet von meinem Siemens C25 mit Tapatalk
Agree entirely. It always used work out of the box, but that seems to have changed along the line somewhere.
Actually I already start to fail understanding at the point why ViX comes without Samba support out of the box.
I think Samba is installed in VIX, it's switching it on which can cause problems.
Nah, it's really missing as in not pre-installed.
JeanReno had to install the packages to get it running.
Gesendet von meinem Siemens C25 mit Tapatalk
Yes, you're absolutely right.
As you were posting, I was trying to start Samba from a fresh install with no network access, and it didn't work.
Actually I already start to fail understanding at the point why ViX comes without Samba support out of the box.Well, I don't have any network file shares at all (I add them for testing, but would never use them otherwise).
But then, I suppose you could easily argue that boxes don't come with local hard-disk by default, so why do they have local hardware support built-in.
The Samba issue was looked as because of the way it splits client-side and server side. the client side is really just the kernel cifs module. The server side is smbd (and nmbd). Then there is smbclient, which isn't either and is needed in the base image to look for network shares. There are also the layered packages above all this. Perhaps it needs a re-visit.
But looking at the dependencies packagegroup-base-smbfs-server should, from what I can see, have pulled in all you need - assuming the feeds are available.
cd /tmp
wget http://www.openvix.co.uk/feeds/openvix/release/4.2/hd2400/mips32el/cifs_5.9-r3_mips32el.ipk
opkg install cifs_5.9-r3_mips32el.ipk
would have done then too ... unless it's wget on the box that breaks the download, but I wouldn't know why.
Old-ish thread, but I can't get Samba started on a fresh install of 4.2.027.
Does the wget url still apply when I replace hd2400 with et10000 ??
wget http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/mips32el/cifs_5.9-r3_mips32el.ipk
No joy, I'm afraid, it just reboots, and returns with status of stopped.
Before I started anything, Openwebif packages section said packagegroup-base-smbfs-server (1.0-r83.1) and cifs (5.9-r3) were already installed.:confused:
The opkg install didn't help, although it did appear to run ok the 1st time I ran it.
A 2nd opkg install says already installed.
Were you originally getting the same loop of trying to install "packagegroup-base-smbfs-server" that I had?
I manually downloaded the cifs ipk, copied to tmp and installed through extension manager in Vix, it wouldn't work any other way. Then ran "opkg install packagegroup-base-smbfs-server" through Putty.
Were you originally getting the same loop of trying to install "packagegroup-base-smbfs-server" that I had?
I manually downloaded the cifs ipk, copied to tmp and installed through extension manager in Vix, it wouldn't work any other way. Then ran "opkg install packagegroup-base-smbfs-server" through Putty.Yes to your first question.
opkg install packagegroup-base-smbfs-server gives me this error...
Couldn't find anything to satisfy 'packagegroup-base-smbfs-server'.
Unknown package 'packagegroup-base-smbfs-server'.
Collected errors:
* opkg_install: Cannot install package packagegroup-base-smbfs-server.
root@et10000:/var/volatile/tmp#
Here's a couple of debug logs, I don't think they show anything.
Install samba, reboot, install samba.
Looks like it's not finding the package from the feeds - hopefully someone will be along soon who can check it's availability.
What's supposed to happen is that installing packagegroup-base-smbfs-server pulls in two dependencies, packagegroup-base-smbfs and samba-base. It's the latter which contains the samba server (smbd).
These packages are all there. The urls are:
http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/et10000/packagegroup-base-smbfs-server_1.0-r83.1_et10000.ipk
http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/et10000/packagegroup-base-smbfs_1.0-r83.1_et10000.ipk
http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/mips32el/samba-base_3.6.25-r6_mips32el.ipk
Many thanks for that, I found that only installing samba-base has started up Samba, do I need to install the other 2 ipk's ?
opkg install samba-base_3.6.25-r6_mips32el.ipk
Installing samba-base (3.6.25-r6) on root.
Removing any system startup links for samba ...
Configuring samba-base.
Adding system startup for /etc/init.d/samba.
Starting Samba: smbd nmbd.
root@et10000:/var/volatile/tmp#
Edit: I'll have to get back to this later, Samba says it is running, and then asks to install packagegroup-base-smbfs-server which I can't get to install using opkg.
opkg install packagegroup-base-smbfs_1.0-r83.1_et10000.ipk
Installing packagegroup-base-smbfs (1.0-r83.1) on root.
packagegroup-base-smbfs: unsatisfied recommendation for kernel-module-cifs
packagegroup-base-smbfs: unsatisfied recommendation for kernel-module-smbfs
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-base-smbfs:
* cifs *
* opkg_install: Cannot install package packagegroup-base-smbfs.
root@et10000:/media/hdd/tmp# opkg install packagegroup-base-smbfs-server_1.0-r83.1_et10000.ipk
Installing packagegroup-base-smbfs-server (1.0-r83.1) on root.
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-base-smbfs-server:
* packagegroup-base-smbfs *
* opkg_install: Cannot install package packagegroup-base-smbfs-server.
root@et10000:/media/hdd/tmp#
Edit: I'll have to get back to this later, Samba says it is running, and then asks to install packagegroup-base-smbfs-server which I can't get to install using opkg.I thought this had all been sorted out, but clearly not. There seems to be a lot of confusion between samba (a file server), cifs (was known as smbfs) which is a filesystem client and smbclient, which allows you to browse for remote cifs shares and this seems to continue into the packaging details.
packagegroup-base-smbfs-server only really installs samba-base. It has indirect dependencies on kernel-module-cifs and kernel-module-smbfs but cifs and smbfs are now the same thing (several years ago they were not) and neither exists as a separate module, as cifs support is compiled into the standard kernel image. So there is actually nothing else to do.
So if you keep getting prompted to install packagegroup-base-smbfs-server you could try:
opkg --no-install-recommends install packagegroup-base-smbfs-server
Still doesn't look right......
opkg --no-install-recommends install packagegroup-base-smbfs-server_1.0-r83.1_et10000.ipk
Installing packagegroup-base-smbfs-server (1.0-r83.1) on root.
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-base-smbfs-server:
* packagegroup-base-smbfs *
* opkg_install: Cannot install package packagegroup-base-smbfs-server.
root@et10000:/media/hdd/tmp#
force-depends maybe?
abu baniaz
25-01-17, 22:20
Don't add the version number to ipk name.
There is a slight mistake in your explanation:
The package "cifs" actually is the cifs-helper, which helps to mount SMB shares.
The dependency on kernel-module-cifs exists, because there are some (few) boxes which do not have the cifs-fs built into the kernel.
Gesendet von meinem Siemens C25 mit Tapatalk
Don't add the version number to ipk name.I tried that first and got.....
opkg --no-install-recommends install packagegroup-base-smbfs-server
Couldn't find anything to satisfy 'packagegroup-base-smbfs-server'.
Unknown package 'packagegroup-base-smbfs-server'.
Collected errors:
* opkg_install: Cannot install package packagegroup-base-smbfs-server.
root@et10000:~#
There is a slight mistake in your explanation:
The package "cifs" actually is the cifs-helper, which helps to mount SMB shares.So nothing to do with samba, which is a file server, not client. Although, IIRC, they may use the same config file....
The dependency on kernel-module-cifs exists, because there are some (few) boxes which do not have the cifs-fs built into the kernel. Then either the build should only add that dependency for those, or those systems which have it directly in the kernel need a dummy package to satisfy the dependency.
Or all systems could have it as a loadable module....for consistency.
Anyway - it's broken, and inconsistencies between systems don't help.
I've always been able to keep Samba running when simply couch flashing new images and doing a settings and plugins restore.
I guess it explains why most boxes can install samba, so no complaints, but one or two boxes struggle.
I noticed NFS had a similar? problem earlier today...
http://www.world-of-satellite.com/showthread.php?55234-Base-nfs-IPK&p=436244&viewfull=1#post436244
So nothing to do with samba, which is a file server, not client.
Uhm, technically speaking ... yes and no.
From the package point of view no, the cifs-helper used to be a part of the Samba package, the switch from Samba 3.0 to 3.6 made it a separate package.
From the technical point of view, it's part of the client side, together with the kernel-module-cifs.
On the other hand, the Samba project also maintains the kernel-module-cifs and the Samba package also contains client tools.
Then either the build should only add that dependency for those, or those systems which have it directly in the kernel need a dummy package to satisfy the dependency.
In detail, kernel-module-cifs is not a RDEPEND, but only an RRECOMMEND.
Carefully check the output of the install process:
Installing packagegroup-base-smbfs (1.0-r83.1) on root.
Now:
packagegroup-base-smbfs: unsatisfied recommendation for kernel-module-cifs
packagegroup-base-smbfs: unsatisfied recommendation for kernel-module-smbfs
These are only notices/warnings, these modules are recommendations only, they do not cause the process to fail!
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-base-smbfs:
* cifs *
This makes the process fail, the lack of the package "cifs" (The cifs-helper).
Or all systems could have it as a loadable module....for consistency.
Cripple all boxes just to be consistent with the worst junk around?
It's a loadable module only on old Dreamboxes (Like DM800) and Azboxes and there also just because they have very tight limits on how large the kernel may become.
Anyway - it's broken, and inconsistencies between systems don't help.
The problem is that the package cifs appears to be missing on the et10000 feeds.
For tests, I have removed all Samba/CIFS packages under OpenATV 6.0:
root@solo2 ~ # opkg list-installed *smb*
root@solo2 ~ # opkg list-installed *samb*
root@solo2 ~ # opkg list-installed *cifs*
root@solo2 ~ #
Now I install the "packagegroup-base-samba" (The "Samba complete meta-package"):
root@solo2 ~ # opkg install packagegroup-base-samba
cifs: unsatisfied recommendation for kernel-module-cifs
packagegroup-base-smbfs: unsatisfied recommendation for kernel-module-cifs
packagegroup-base-smbfs: unsatisfied recommendation for kernel-module-smbfs
Installing cifs (5.9) on root.
Downloading http://feeds2.mynonpublic.com/6.0/vusolo2/mips32el/cifs_5.9-r3_mips32el.ipk.
Installing packagegroup-base-smbfs (1.0) on root.
Downloading http://feeds2.mynonpublic.com/6.0/vusolo2/vusolo2/packagegroup-base-smbfs_1.0-r83.1_vusolo2.ipk.
Installing smbclient (3.6.25) on root.
Downloading http://feeds2.mynonpublic.com/6.0/vusolo2/mips32el/smbclient_3.6.25-r6_mips32el.ipk.
Installing packagegroup-base-smbfs-client (1.0) on root.
Downloading http://feeds2.mynonpublic.com/6.0/vusolo2/vusolo2/packagegroup-base-smbfs-client_1.0-r83.1_vusolo2.ipk.
Installing samba-base (3.6.25) on root.
Downloading http://feeds2.mynonpublic.com/6.0/vusolo2/mips32el/samba-base_3.6.25-r6_mips32el.ipk.
Removing any system startup links for samba ...
Installing packagegroup-base-smbfs-server (1.0) on root.
Downloading http://feeds2.mynonpublic.com/6.0/vusolo2/vusolo2/packagegroup-base-smbfs-server_1.0-r83.1_vusolo2.ipk.
Installing samba (3.6.25) on root.
Downloading http://feeds2.mynonpublic.com/6.0/vusolo2/mips32el/samba_3.6.25-r6_mips32el.ipk.
Installing packagegroup-base-smbfs-utils (1.0) on root.
Downloading http://feeds2.mynonpublic.com/6.0/vusolo2/vusolo2/packagegroup-base-smbfs-utils_1.0-r83.1_vusolo2.ipk.
Installing packagegroup-base-samba (1.0) on root.
Downloading http://feeds2.mynonpublic.com/6.0/vusolo2/vusolo2/packagegroup-base-samba_1.0-r83.1_vusolo2.ipk.
Configuring smbclient.
Configuring samba.
Configuring packagegroup-base-smbfs-utils.
Configuring samba-base.
Adding system startup for /etc/init.d/samba.
Starting Samba: smbd.
Configuring cifs.
Configuring packagegroup-base-smbfs.
Configuring packagegroup-base-smbfs-client.
Configuring packagegroup-base-smbfs-server.
Configuring packagegroup-base-samba.
Everything is fine.
Cripple all boxes just to be consistent with the worst junk around?
It's a loadable module only on old Dreamboxes (Like DM800) and Azboxes and there also just because they have very tight limits on how large the kernel may become.In what way does a loadable module cripple a box? It's how the dvb module gets loaded, and that's quite important.
The system I'm on at the moment has 89 loaded modules.
The problem is that the package cifs appears to be missing on the et10000 feeds.Well, the file is there:
[parent]: wget -nv http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/mips32el/cifs_5.9-r3_mips32el.ipk
2017-01-26 10:07:07 URL:http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/mips32el/cifs_5.9-r3_mips32el.ipk [14794/14794] -> "cifs_5.9-r3_mips32el.ipk.2" [1]
In what way does a loadable module cripple a box? It's how the dvb module gets loaded, and that's quite important.
It's a binary blob and it taints the kernel, it will even tell you so :)
bcm_event: module license 'Proprietary' taints kernel.
It cripples the system in so far, as most boxes have a fixed size reserved mtd partition for the kernel, let's say 8 MB.
You can of course make all modules loadable modules and put them on the rootfs mtd partition, wasting space there instead of making good use of the kernel partition.
What's better, especially on a box with only 128 MB (That's most likely only 120 MB in reality) of flash:
Creating an 8 MB kernel which puts 5 MB worth of kernel modules on the rootfs, leaving 5 MB on the kernel partition unused or creating the same kernel which fits completely on the kernel partition?
For modules that get loaded anyways, making them external modules is the most inefficient method.
They should be built-in, as long as the kernel partition allows.
Two more points:
1. For kernel-modules that get loaded anyways as they are required for proper operation, making them loadable also increases the risk they get uninstalled.
2. Revise about hundred defconfigs to unify if driver x is going to be build as a module or compiled into the kernel? Are you serious?
Point 2 isn't a sed inplace job even, as we have different kernel versions and Linux devs LOVE to rename everything whenever they can. The switch to enable/modularize/disable kernel-module-blah might be CONFIG_DVB_USB_BLAH on one kernel revision and and CONFIG_USB_DVB_BLAH on another.
There is another reason against point 2: For some unmaintained boxes with old kernels, Linux kernel backports would be an option to get support for current DVB or WiFi peripherals. Everything that gets added using kernel backports has different config switches in kconfig than on the originating kernel.
So there is actually no good reason to fix what isn't broken (There is just some recommendation for a kernel-module that can not be fulfilled, because it's already fulfilled by the kernel itself), but quite a lot against.
Well, the file is there:
[parent]: wget -nv http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/mips32el/cifs_5.9-r3_mips32el.ipk
2017-01-26 10:07:07 URL:http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/mips32el/cifs_5.9-r3_mips32el.ipk [14794/14794] -> "cifs_5.9-r3_mips32el.ipk.2" [1]
Then check the Packages.gz if it properly lists that file.
And as a side note:
I will never understand how OpenViX came up with the idea of removing one of the basic features of an E2 box, network connectivity, from the base image.
I've tried @SpaceRat's "test" and at the end get the following.....
root@et10000:~# opkg install packagegroup-base-samba
Couldn't find anything to satisfy 'packagegroup-base-samba'.
Unknown package 'packagegroup-base-samba'.
Configuring ntpdate.
Collected errors:
* opkg_install: Cannot install package packagegroup-base-samba.
root@et10000:~#
Ok, I think I found the reason:
As OpenViX has crippled their base image by wiping out Samba entirely, there is nothing that pulls packagegroup-base-samba and its dependencies onto the feed.
https://github.com/oe-alliance/oe-alliance-core/commit/7d6e383d83bce6fcd6da00f7ec509916f6f350bc
should fix that.
Well that's done it!!!
I can't say I understand, but has something changed since yesterday? (just seen your previous post - I understand now, many thanks)
Last login: Thu Jan 26 11:04:46 GMT 2017 on pts/0
root@et10000:~# opkg update
Downloading http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/3rdparty/Packages.gz.
Updated source 'openvix-3rdparty'.
Downloading http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/all/Packages.gz.
Updated source 'openvix-all'.
Downloading http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/et10000/Packages.gz.
Updated source 'openvix-et10000'.
Downloading http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/et10000_3rdparty/Packages.gz.
Updated source 'openvix-et10000_3rdparty'.
Downloading http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/mips32el/Packages.gz.
Updated source 'openvix-mips32el'.
root@et10000:~#
root@et10000:~# opkg install packagegroup-base-samba
Installing packagegroup-base-samba (1.0-r83.1) on root.
Downloading http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/et10000/packagegroup-base-samba_1.0-r83.1_et10000.ipk.
cifs: unsatisfied recommendation for kernel-module-cifs
packagegroup-base-smbfs: unsatisfied recommendation for kernel-module-cifs
packagegroup-base-smbfs: unsatisfied recommendation for kernel-module-smbfs
Installing packagegroup-base-smbfs-client (1.0-r83.1) on root.
Downloading http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/et10000/packagegroup-base-smbfs-client_1.0-r83.1_et10000.ipk.
Installing packagegroup-base-smbfs (1.0-r83.1) on root.
Downloading http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/et10000/packagegroup-base-smbfs_1.0-r83.1_et10000.ipk.
Installing cifs (5.9-r3) on root.
Downloading http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/mips32el/cifs_5.9-r3_mips32el.ipk.
Installing smbclient (3.6.25-r6) on root.
Downloading http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/mips32el/smbclient_3.6.25-r6_mips32el.ipk.
Installing packagegroup-base-smbfs-utils (1.0-r83.1) on root.
Downloading http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/et10000/packagegroup-base-smbfs-utils_1.0-r83.1_et10000.ipk.
Installing samba (3.6.25-r6) on root.
Downloading http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/mips32el/samba_3.6.25-r6_mips32el.ipk.
Installing packagegroup-base-smbfs-server (1.0-r83.1) on root.
Downloading http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/et10000/packagegroup-base-smbfs-server_1.0-r83.1_et10000.ipk.
Installing samba-base (3.6.25-r6) on root.
Downloading http://www.openvix.co.uk/feeds/openvix/release/4.2/et10000/mips32el/samba-base_3.6.25-r6_mips32el.ipk.
Removing any system startup links for samba ...
Configuring smbclient.
Configuring samba.
Configuring packagegroup-base-smbfs-utils.
Configuring samba-base.
Adding system startup for /etc/init.d/samba.
Starting Samba: smbd nmbd.
Configuring cifs.
Configuring packagegroup-base-smbfs.
Configuring packagegroup-base-smbfs-client.
Configuring packagegroup-base-smbfs-server.
Configuring packagegroup-base-samba.
root@et10000:~#
This is what I had before the "test"...
root@et10000:~# opkg list-installed *smb*
smbclient - 3.6.25-r6
root@et10000:~# opkg list-installed *samb*
root@et10000:~# opkg list-installed *cifs*
and now.....
root@et10000:~# opkg list-installed *smb*
packagegroup-base-smbfs - 1.0-r83.1
packagegroup-base-smbfs-client - 1.0-r83.1
packagegroup-base-smbfs-server - 1.0-r83.1
packagegroup-base-smbfs-utils - 1.0-r83.1
smbclient - 3.6.25-r6
root@et10000:~# opkg list-installed *samb*
packagegroup-base-samba - 1.0-r83.1
samba - 3.6.25-r6
samba-base - 3.6.25-r6
root@et10000:~# opkg list-installed *cifs*
cifs - 5.9-r3
root@et10000:~#
Ok, I think I found the reason:
As OpenViX has crippled their base image by wiping out Samba entirely, there is nothing that pulls packagegroup-base-samba and its dependencies onto the feed.
https://github.com/oe-alliance/oe-alliance-core/commit/7d6e383d83bce6fcd6da00f7ec509916f6f350bc
should fix that.That would be because there is great confusion about what "samba" is.
As far as mounting remote CIFS shares (and looking for them) on a system the only thing needed was smbclient (to find them) as the cifs kernel module was already in place. The number of package splits for samba and cifs seems to be way too complicated.
Well that's done it!!!
I can't say I understand, but has something changed since yesterday? (just seen your previous post - I understand now, many thanks)
Well, if "opkg update" fixed things for you, my commit on Github has nothing to do with it, that won't be instant.
It shouldn't harm either, it just ensures that each and every distro has complete Samba support on the feed, even if they haven't built it into the image (Most have it in the base image anyways).
Your problem appears to be that you were unaware of opkg update:
It refreshs the box' list of what is available on the feeds.
"opkg update" is required before you can do any opkg install or opkg upgrade action.
Without current lists for the feeds, opkg only knows about packages that are already installed.
We shouldn't really have to be manually refreshing feeds to obtain modules that are (albeit, now an 'optional') part of Vix.
That would be because there is great confusion about what "samba" is.
As far as mounting remote CIFS shares (and looking for them) on a system the only thing needed was smbclient (to find them) as the cifs kernel module was already in place. The number of package splits for samba and cifs seems to be way too complicated.
Well, OpenViX introduced all those Samba meta-packages ...
And you are still wrong.
Requirements are
Kernel support for CIFS/SMB (Actually nobody will really be using CIFS, at least not intentionally, but SMB), referred to as "kernel-module-cifs", either built-in (Almost all boxes) or as a loadable module (Very old boxes with tight space on kernel partition)
Mount helper mount.cifs, shipped in package "cifs".
These two form the actual client. Nothing more is required for client use, as long as you edit /etc/auto.network (Preferred) or /etc/fstab (Not so good for Windows servers) yourself.
The package "smbclient" offers highly limited support for attempts to find legacy (IBM OS/2, Windows 9x, Windows NT 4.0, Windows 2000, Windows XP, Windows Vista) types of shares on the net.
It assists the NetworkBrowser in making bad entries to auto.network or fstab.
The actual server is split across the packages samba and samba-base:
While the core server is in samba-base, the package samba contains some utilities to control the server, of which one (testparm) is required for the start script of Samba.
We shouldn't really have to be manually refreshing feeds to obtain modules that are (albeit, now an 'optional') part of Vix.
That's how all package managers work.
For "apt-get install blah" to work you also need to perform "apt-get update" first.
The only thing the distro could make to fake remove the need to perform "opkg update" first would be to silently do it for you, e.g. when installing Samba via the E2 network menu.
But not everybody has unlimited traffic - there actually are E2 users with only cellular (UMTS/LTE) internet access - and initiating useless downloads for any package install wouldn't do your traffic any good.
That's how all package managers work.
For "apt-get install blah" to work you also need to perform "apt-get update" first.
The only thing the distro could make to fake remove the need to perform "opkg update" first would be to silently do it for you, e.g. when installing Samba via the E2 network menu.
But not everybody has unlimited traffic - there actually are E2 users with only cellular (UMTS/LTE) internet access - and initiating useless downloads for any package install wouldn't do your traffic any good.
I wouldn't call it a useless download. 'Useless' would be Vix trying to download packages that don't exist because it hasn't bothered to check it's reading from an up-to-date list, surely?
abu baniaz
26-01-17, 13:11
We applied fixes some time back. If you follow the normal process, it should work. I tried it yesterday.
Please repeat exactly how you do/would do things from square one on a newly installed image.
I wouldn't call it a useless download. 'Useless' would be Vix trying to download packages that don't exist because it hasn't bothered to check it's reading from an up-to-date list, surely?
That depends on how you define "up-to-date".
For OpenATV where builds happen nightly the list is usually up-to-date for about 24hrs.
Once you have for example done "opkg update && opkg upgrade", there is no need to do another "opkg update" before package installations until the next build.
For OpenViX with its "releases", the principle remains the same, except that the lists would stay up-to-date for even longer, provided OpenViX doesn't update the feeds in between "releases".
In that case, "opkg update" once would stay up-to-date until the next "release", making automated "opkg update" in between even more useless.
The only thing OpenViX could do, provided their feed stays frozen in between "releases", would be to add the lists into the image at build time.
But I suggest you rather get used to how things work, because it's that way with any other package manager on any other Linux system too.
The point is that the GUI user shouldn't need to perform manual workarounds and shouldn't care about what happens in the background. Its a menu option, it should work for them without technical intervention.
abu baniaz
26-01-17, 16:51
You shouldn't. Please answer as to what steps you did/would do from a new install. We can compare what's gone on and improve things even more.
You shouldn't. Please answer as to what steps you did/would do from a new install. We can compare what's gone on and improve things even more.I ran @SpaceRat's "test" from a clean install of 4.2.027, posted here..
http://www.world-of-satellite.com/showthread.php?54466-Can-t-Start-Samba&p=436388&viewfull=1#post436388
I posted all steps in detail (apart from needing "opkg --force-depends remove smbclient" to get rid of smbclient).
Whether all were actually needed, pass.
I haven't tried this, but "opkg update", followed by a GUI samba install might work - do you want me to have a go?
I haven't tried this, but "opkg update", followed by a GUI samba install might work - do you want me to have a go?
The answer is (from a clean install of 027) - it does work.
You shouldn't. Please answer as to what steps you did/would do from a new install. We can compare what's gone on and improve things even more.
I need to do an update this evening since I'm on .026. It's a (yet another, grrr) Linux kernel update, so will use Image Manager.
It will be something along the lines of . . .
Setup - Vix - Backup Manager - New Backup
Setup - Vix - Image Manager - Downloads (choose latest image)
Setup - Vix - Image Manager - Restore (choose latest image)
Restore plugins and settings upon boot
Re-download LCD skins and skin etc since they never seem to be retained
Check Samba . . .
I'll see how it goes this evening and report back (toddler willing).
abu baniaz
26-01-17, 17:45
Setup - Vix - Backup Manager - New Backup
This is done automatically, has been for a while. No harm doing it manually though.
Setup - Vix - Image Manager - Downloads (choose latest image)
Setup - Vix - Image Manager - Restore (choose latest image)
Restore plugins and settings upon boot
Re-download LCD skins and skin etc since they never seem to be retained
They should be now, provided they are on server. The list of installed plugins now only lists packages, not dependencies. Dependencies will be installed automatically. We have removed the kernel restriction, so everything that is on server should install.
As an extra measure, you can use this: http://www.world-of-satellite.com/showthread.php?50873-List-of-installed-plugins&p=435697&viewfull=1#post435697
Check Samba . . .
The answer is (from a clean install of 027) - it does work.
I'm going to have to qualify that. Everything looks ok, I can see the ET10K from my pc and the ET10K can see my NAS.
However, playing a recording in another room using a fire tv is constantly buffering and unwatchable, it's never happened before.
The box is actually on 4.2.028 now. I've moved back to 4.2.026 and playback thru' the fire tv is working fine.
I did notice some odd delays using telnet when messing about earlier today on 027, but thought nothing about it at the time.
Just a thought - my Sundtek usb tuner doesn't work on 027, and my rtl8192cu usb wireless dongle isn't too happy either.
abu baniaz
26-01-17, 19:53
Just a thought - my Sundtek usb tuner doesn't work on 027, and my rtl8192cu usb wireless dongle isn't too happy either.
The Xtrends had a kernel change which has affected USB tuners. Other brands won't be affected by the Xtrend kernel changes.
The Xtrends had a kernel change which has affected USB tuners. Other brands won't be affected by the Xtrend kernel changes.Odd that my usb wireless dongle appears to have similar problems - timing out/powering down(?). 026 works fine.
abu baniaz
26-01-17, 19:58
What kernel is on 026?
What kernel is on 028?
What kernel is on 026?
What kernel is on 028?
Why do you ask? I know there has been a change in the kernel.
abu baniaz
26-01-17, 20:10
And you know it is faulty. That kernel change won't affect the OP as he has a different brand of receiver.
It is no point reporting issues on a receiver we know has an issue with a kernel.
There was an update to Wifi. With all due respect, if there is an issue with Wi-Fi, other users with an unaffected kernel are better placed to report the issues.
If you are adamant that there is an issue in that will affect everyone, please flash 026, and manually update the changed python files.
And you know it is faulty. That kernel change won't affect the OP as he has a different brand of receiver.
It is no point reporting issues on a receiver we know has an issue with a kernel.
There was an update to Wifi. With all due respect, if there is an issue with Wi-Fi, other users with an unaffected kernel are better placed to report the issues.
If you are adamant that there is an issue in that will affect everyone, please flash 026, and manually update the changed python files.
So you're not interested in wifi issues with an updated kernel, only if there are wifi issues without a kernel change?
I'd have thought any issues after a kernel change need to be reported. One might be easier to trace than another.
How could I have known that there were any significant wifi updates to all boxes?
abu baniaz
26-01-17, 20:25
You are using a kernel with issues. Your perpetuating/suggesting that all receivers will have the issue is not helpful.
Your issue is a valid issue, but not in this thread. I shall ask Admin to report it to Xtrend, but we would need to rule out other changes on "clean kernels".
It's like someone with deflated tyres getting the tracking fixed.
You are using a kernel with issues. Your perpetuating/suggesting that all receivers will have the issue is not helpful.
I don't ever remember implying that all receivers are effected.
It was established very early on that the Samba issue was box specific, only a few being effected.
The kernel change prompted me to do a clean install of 027, which then brought back the Samba issue which I first reported a year ago.
The only reason I mentioned wifi in this thread was because I was using samba to access files over wifi, and the installation of samba was non standard (as far as I was concerned).
I then linked the usb wifi problem to the usb tuner problem, which seems to be more than likely.
abu baniaz
26-01-17, 20:41
Apologies. Please continue.
Apologies. Please continue.
No need to apologise, all I'm trying to do is provide as much information as possible. It doesn't always join together very well.
You say Xtrend need to get involved.
Is that because it's a driver problem interacting with the new kernel or can the kernel be fixed without any Xtrend involvment?
Setup - Vix - Backup Manager - New Backup
This is done automatically, has been for a while. No harm doing it manually though.
Setup - Vix - Image Manager - Downloads (choose latest image)
Setup - Vix - Image Manager - Restore (choose latest image)
Restore plugins and settings upon boot
Re-download LCD skins and skin etc since they never seem to be retained
They should be now, provided they are on server. The list of installed plugins now only lists packages, not dependencies. Dependencies will be installed automatically. We have removed the kernel restriction, so everything that is on server should install.
As an extra measure, you can use this: http://www.world-of-satellite.com/showthread.php?50873-List-of-installed-plugins&p=435697&viewfull=1#post435697
Check Samba . . .
Everything restored perfectly (skins and all); first time in a while :eek: :thumbsup: I ran your script before and after to check and the files listed are identical.
Very happy, thanks.
abu baniaz
27-01-17, 00:37
Glad you are sorted.
The script is not mine, you must thank Huevos for that.
I can't seem to get Samba to install since my USB update to 4.2.016 and subsequently to 4.2.020.
When entering Samba Setup it just gets stuck in a loop of trying to install "packagegroup-base-smbfs-server". It tries to install, reboots and when entering Samba Setup it wants to install again.Still happening on a clean install of 4.2.029
Changelog has Make sure that packagegroup-base-samba is available
That change modifies the feed, not the OpenViX image.
I guess doing "opkg update" first still solves the problem?
I guess doing "opkg update" first still solves the problem?
Yes - it starts ok via the GUI interface after the opkg update.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.