On Feb 19, 2015, at 11:23 PM, Gene Heskett <[email protected]> wrote:
> Almost $800 dollars and worthless
> on wheezy. I am asking a few ?? over that on their mailing list as it
> worked perfectly on ubuntu-10.04.4 LTS.
If you still have a backup of /etc from the Ubuntu install, there might be some
clues in /etc/cups about the duplex settings (or which drivers support duplex,
more likely).
My printer is still chugging along from the grad school days where I didn't
have nearly that much to spend on a printer, so I tend to do the manual duplex
method: print odd-numbered pages, flip the stack over, make a sacrifice to the
gods of static electricity, and print the even pages.
> I don't even know if I am using the correct driver, the ups-scanner seems
> only to exist in my 2.7.2 src tree, but its not installed as its looking
> for a much older libssl than I now have.
I can't say I really buy into the nut-scanner notion. For the amount of work
that went into it, I feel that we could have written some better procedural
documentation that would have worked with whatever tools were on hand. And I
don't think it's capable of saying "try this driver, but if that doesn't work,
here are the older ones that might also work".
So let's do it the manual way. Brand name? Any vendor-included software that is
currently being used as a beverage coaster? USB or serial? If USB, what does
lsusb say about it? (Might have to run lsusb as root, if the udev permissions
are working as intended.)
> And the error messages from an
> attempted start are so generic they aren't a lot of help. So and so
> didn't start, but no reason why is given.
Don't laugh, but there are two levels of indirection between
/etc/init.d/nut-server and the driver. There's the init script itself, and
upsdrvctl. Both were optimized for starting several drivers.
We probably should be more explicit in the documentation about the possibility
of starting the drivers manually at first (or using upsdrvctl "-D", with the
appropriate number of "-D"s to print the driver name). Once the driver works on
its own (and you can add "-D" to that command line to get more detail), you can
kill the driver (important) and either try upsdrvctl or jump straight to the
init.d script.
> After mv'ing that file, I still get:
> root@coyote:/etc/init.d# ./nut-server start
> [ ok ] Starting NUT - power devices information server and drivers:
> (driver(s) failed). upsd.
>
> Why can it not name the failed driver, so I would know to try another?
The debian maintainers switched to systemd from the init.d scripts, and that
caused a release-critical bug in the Debian package of NUT for new
installations. (Upgrades from pre-systemd days just worked, but if NUT was not
configured yet, the post-install script would error out.) They were not willing
to drop back to the init.d compatibility wrappers (which I think Ubuntu is
still using) so I don't know if NUT is even going to make it into jessie, the
release after wheezy.
So that doesn't really answer your question, but it should explain a bit of the
mess behind the init scripts. (And at the same time, we have been trying to
coordinate a release of NUT 2.7.3.)
If you have a github account, I would recommend creating an issue so that we
don't forget about printing the driver name(s) at startup:
https://github.com/networkupstools/nut/issues
(The combination of cold temperatures and a recent power outage seems to have
taken out the one UPS in the house that I can't easily replace without voiding
warranties: the DC supply for the broadband connection. While pairing a
bluetooth keyboard to a smartphone works for the occasional email, the screen
is a bit small to actually do anything useful on github, and I need to stop
staring at the tiny screen for a while.)
- Charles
_______________________________________________
Nut-upsuser mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsuser
