HOWTO Install Samsung Unified Printer Driver

[winningthepowerball]

This was very helpfull.

thanks

[tweedledee]

Another little problem! I want to investigate the configurator so I've used Synaptic to install samsungmfp-netdiscovery-oldlibc (which had a dependency: samsungmfp-eglibc32) and samsungmfp-configurator-data.

However, I don't know how to run the configurator - I don't see any new entries in the Applications or System menus .... so where does the executable go and what is it called?

You'll need to install either the samsungmfp-configurator-qt3 or -qt4 package as well. (Believe me - I'd love to simplify the complexity of the number of packages.) Good luck with the router/USB hookup, but I think it should work at this point. I'm not sure why the different port generated the usb errors; I used to see reports of issues like that with hubs all the time and had some bad experiences myself a long time ago, but less commonly in recent years.

[tweedledee]

I have similar issuses as gaboro while using Lucid, but just thought I'd report that I did a fresh install of Natty Narwhal (from index of dailylive 19/02/2011). I enabled the repositories and installed the following packages (all version 3.00.80-4) samsungmfp-configurator-data, samsungmfp-configurator-qt3, samsungmfp-data, samsungmfp-driver, samsungmfp-netdiscovery-oldlibc, samsungmfp-scanner, samsungmfp-lpr and samsungmfp-eglibc (samsung2.12.1-1). Instant success - I can print and scan via wireless network.

That's a relief. I was worried that Natty would fail with the 2.12 build, since it's using 2.13. Maybe I won't have to recompile the eglibc library for every release, just some....

[tweedledee]

I would file the sh-problem as a bug but I need your help once again to understand what the problem really is. As far as I got it (not having too much experience in compiling c-programs), the dash package has been with dependency of libc6 2.11 compiled instead of leaving out the compile-time dependency and having package-level dependency only. Is that right that way?

You've explained as much as I really understand. However, yahs' post suggests that the issue has been resolved (at least for now) with Natty, so there may not be much point. I doubt the Ubuntu devs will release a fix for Lucid at this point, even though it is LTS. It's still a valid bug, but if you can deal with it by upgrading to 10.10 and the problem does reappear, it's not likely to get much attention.

[tweedledee]

I know this is a silly question as I have read most of this thread, however - Has anyone actually gleaned out a straightforward procedure to install this particular printer driver? I myself am an Ubuntu/Linux noob and am slowly but surely expanding my understanding bit by precious bit. It seems like there should be a thread/post somewhere describing a such a thing. I apologize if it sounds like I am being lazy - I assure you I am not. But judging by the size of the thread ( hours of reading ) this seems like a really big issue for at least the Samsung owners. I certainly appreciate the wealth of know-how displayed here.


TDYK.

The first post is a regularly updated summary of (nearly) everything important in all the other comments. Basically, my recommend if the printer doesn't "just work" is to install the Samsung drivers via my repository as described in the first post. All the caveats and whatnot are there only if you run into problems.

[tapanit]

There's one extra problem with the Samsung drivers: the scanner can only be used within the same network segment, it can't be reached from a machine behind a router or firewall. (Printing works fine, just enter the machine name/address manually.)

Here's a workaround for those in this situation (works for me):
replace /opt/Samsung/mfp/bin/netdiscovery with this:

#!/bin/sh
if [ -f $HOME/.samsung.netdiscovery ]
then cat $HOME/.samsung.netdiscovery
else
LD_LIBRARY_PATH=/opt/Samsung/eglibc32/lib /opt/Samsung/mfp/bin/netdiscovery32 $*
fi

Then, in some machine that *is* in the same network segment with the Samsung, do

/opt/Samsung/mfp/bin/netdiscovery >.samsung.netdiscovery

and copy the resulting .samsung.netdiscovery to the machine(s) in other network segments.

If you have several Samsung's in different network segments this obviously won't work, but I think simply appending netdiscovery results from each might do it (I don't have many of them son can't test this).

[tapanit]

/opt/Samsung/mfp/bin/netdiscovery >.samsung.netdiscovery

Oops, that should have been

/opt/Samsung/mfp/bin/netdiscovery --all --scanner >.samsung.netdiscovery

Without those options it only finds printers.

[hokiejp]

I somehow overlooked that Lucid 32-bit was also now acting up. Does it work on lucid if you force-install the eglibc32-amd64 package?

This would be much simpler if there wasn't the stupid error with sh requiring particular versions of eglibc as well. Please open a bug on launchpad about the sh errors you saw, as I am not looking forward to creating dozens of version of libraries to match every Ubuntu update because something is compiling wrong, when it all works fine on Debian. (Well, actually, it'd all be much simpler if Samsung produced decent drivers, but I'm less optimistic about resolving that problem.)

The main reason why I built a 32bit glibc to work around this problem was because I knew it wouldn't conflict with any of the native utilities on my system (i.e. the shell in this case). It seems silly, but would it be possible to build a 64bit glibc for 32 bit systems and use the 64 bit version of netdiscovery?

I think another way to do it would be to build a shell against the new glibc and distribute the shell binary as well.

[tweedledee]

Oops, that should have been

/opt/Samsung/mfp/bin/netdiscovery --all --scanner >.samsung.netdiscovery

Without those options it only finds printers.

I suspect this is a somewhat rare case, but I've added a note about this solution to the main post.

[tweedledee]

The main reason why I built a 32bit glibc to work around this problem was because I knew it wouldn't conflict with any of the native utilities on my system (i.e. the shell in this case). It seems silly, but would it be possible to build a 64bit glibc for 32 bit systems and use the 64 bit version of netdiscovery?

No. 32-bit libraries will work on a 64-bit system, but not the other way around. I agree it would probably solve the problem if it would work, but the actual implementation requires completely isolating the 64-bit processes and is a lot more involved.

I think another way to do it would be to build a shell against the new glibc and distribute the shell binary as well.

Actually, you probably could just compile a new shell, even without worrying about the new glibc. However, I haven't figured out how to package such a solution. I can't actually distribute a recompiled shell for general use, because installation would conflict too severely to be resolved. And I haven't worked out a solution that would reliably isolate all the Samsung-related process to their own shell (or chroot, or other separate process area) and still be general enough to package up. (If I ever have a few solid days to work on this, which seems unlikely, I might get it to work, in which case most of these other ongoing problems could also be dealt with. But that's perhaps just wishful thinking and not realistic given my free time right now.)