Superb quality and spec AB-Com PULSe 4K SE. Crazy offer! Only £99! FREE UK DELIVERY! 4K UHD, Enigma 2, Multiboot 4 images & more!...
Superb quality and spec AB-Com PULSe 4K Rev II Twin Satellite tuner only £149! FREE UK DELIVERY! 4K UHD, Enigma 2, SATA HDD facility, Multiboot 4 images & more!...

[Mut@nt HD2400] Can't Start Samba

  • Thread starter Thread starter JeanReno
  • Start date Start date
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.
 
Last edited:
Code:
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 ??


Code:
wget http://www.openvix.co.uk/feeds/openvix/release/4.2/[COLOR="#0000FF"]et10000[/COLOR]/mips32el/[COLOR="#0000FF"]cifs_5.9-r3_mips32el.ipk[/COLOR]
 
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.
 
Last edited:
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...
Code:
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.
 
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 ?

Code:
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.

Code:
 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#
 
Last edited:
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:

Code:
 opkg --no-install-recommends  install packagegroup-base-smbfs-server
 
Still doesn't look right......

Code:
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?
 
Last edited:
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.....


Code:
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.
 
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:
Code:
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"):
Code:
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:

Code:
[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 :)
Code:
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:

Code:
[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.
 

OpenViX Feeds Status

Back
Top