search for: pi4b

Displaying 20 results from an estimated 37 matches for "pi4b".

2020 Feb 05
1
smbd fails to start after upgrade to version 4.11.6
Hai Roy, I had a good look and most look ok, not much exiting going on but still a few points. >From teh logs. Feb 5 08:41:48 pi4b ifup[303]: ifup: couldn't open interfaces file "/etc/network/interfaces": No such file or directory So re-create the file with the folling content, : /etc/network/interfaces And add : # This file describes the network interfaces available on your system # and how to activate them....
2020 Feb 04
4
smbd fails to start after upgrade to version 4.11.6
...> >I would try and fix it first, can you download and run > Louis's script: > >https://github.com/thctlo/samba4/blob/master/samba-collect-de bug-info.sh > >Sanitise the output and post the output into a reply to this. > > > >Rowland > > OK: > root at pi4b:~/scripts# ./samba-collect-debug-info.sh > Please wait, collecting debug info. > > Password for Administrator at SAMDOM.ORG: > grep: : No such file or directory Around line 144 in the script, which means its just not running. > Load smb config files from /etc/samba/smb.conf >...
2020 Feb 05
0
smbd fails to start after upgrade to version 4.11.6
...192.168.2.51/24 > > (note instructions have the name of the file wrong - it gave > it as lan-dev-eth0.network but it's actually called > lan-member-dev-eth0.network) > > I implemented the changes per the instructions, and the > result of timedatectl status: > root at pi4b:~# timedatectl status > Local time: Tue 2020-02-04 20:49:50 GMT > Universal time: Tue 2020-02-04 20:49:50 UTC > RTC time: n/a > Time zone: Europe/London (GMT, +0000) > System clock synchronized: no > NTP serv...
2020 Jan 08
0
nut on armhf, r-pi4b IOW
On Tue, 7 Jan 2020, Gene Heskett wrote: > ● nut-monitor.service - Network UPS Tools - power device monitor and > shutdown controller > Loaded: loaded (/lib/systemd/system/nut-monitor.service; enabled; > vendor preset: enabled) > Active: failed (Result: protocol) since Tue 2020-01-07 07:19:19 EST; > 116ms ago > Process: 32343 ExecStart=/sbin/upsmon (code=exited,
2020 Jan 09
0
nut on armhf, r-pi4b IOW
On Thursday 09 January 2020 16:59:12 Charles Lepple wrote: > On Jan 9, 2020, at 4:39 PM, Gene Heskett <gheskett at shentel.net> wrote: > > So for starters, what's the best ./configure command line? > > There’s this page for matching the layout of an existing Debian > install: > https://github.com/networkupstools/nut/wiki/Building-NUT-on-Debian,-Ra
2020 Jan 11
0
nut on armhf, r-pi4b IOW
On Jan 10, 2020, at 5:29 PM, Gene Heskett wrote: > > input.transfer.high: 0 ???? Shouldn't these two be something real ???? > input.transfer.low: 0 ???? ditto Known issue, but only cosmetic: https://github.com/networkupstools/nut/issues/482
2020 Jan 11
0
nut on armhf, r-pi4b IOW
On Friday 10 January 2020 20:43:55 Gene Heskett wrote: > On Friday 10 January 2020 19:04:11 Charles Lepple wrote: > > On Jan 10, 2020, at 5:29 PM, Gene Heskett wrote: > > > input.transfer.high: 0 ???? Shouldn't these two be something real > > > ???? input.transfer.low: 0 ???? ditto > > > > Known issue, but only cosmetic: > >
2020 Jan 12
0
nut on armhf, r-pi4b IOW
On Jan 12, 2020, at 9:56 AM, Gene Heskett wrote: > >> >> Instant return, logging this: > in /tmp/info > >> 0.000000 Error: too many non-option arguments. Try -h for help. >> Network UPS Tools - Generic HID driver 0.41 (2.7.4) >> USB communication driver 0.33 > > This I assumed was with nut-server and nut-client, both stopped, which > they
2020 Jan 14
0
nut on armhf, r-pi4b IOW
On Sunday 12 January 2020 12:09:04 Gene Heskett wrote: > On Sunday 12 January 2020 11:14:13 Charles Lepple wrote: > > On Jan 12, 2020, at 9:56 AM, Gene Heskett wrote: > > >> Instant return, logging this: > > > > > > in /tmp/info > > > > > >> 0.000000 Error: too many non-option arguments. Try -h for > > >> help. Network
2020 Jan 14
0
nut on armhf, r-pi4b IOW
On Monday 13 January 2020 22:42:46 Charles Lepple wrote: > On Jan 13, 2020, at 10:17 PM, Gene Heskett wrote: > >>> (I was looking at the hid-subdrivers.txt file in the latest NUT > >>> tree, which has the command line amended to not generate that "too > >>> many non-option arguments" error. Also, I wanted it to use the > >>> existing
2020 Jan 22
0
nut on armhf, r-pi4b IOW
On Jan 21, 2020, at 7:50 AM, Gene Heskett <gheskett at shentel.net> wrote: > > Now I've got another of those WTF questions. This ups doesn't ID itself > the same to an lsusb as it does to upsc. > From an lsusb: > Bus 001 Device 004: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS The two IDs are vendor (VID) and product (PID). lsusb looks them up in a text
2020 Jan 22
0
nut on armhf, r-pi4b IOW
On Jan 21, 2020, at 10:34 PM, Gene Heskett wrote: > > On Tuesday 21 January 2020 19:52:01 Charles Lepple wrote: > >> sudo lsusb -v -d 0764:0501 > copious output, containing this: > idVendor 0x0764 Cyber Power System, Inc. > idProduct 0x0501 CP1500 AVR UPS > bcdDevice 0.01 > iManufacturer 3 CPS > iProduct
2020 Jan 11
0
nut on armhf, r-pi4b IOW
On Saturday 11 January 2020 17:00:19 Charles Lepple wrote: > On Jan 11, 2020, at 3:50 PM, Gene Heskett wrote: > >> The problem is further downstream. Even after you map HID names to > >> NUT names, then you run into the fact that CPS and NUT are > >> interpreting the HID Report Descriptor differently. (Some details > >> here:
2020 Jan 09
0
nut on armhf, r-pi4b IOW
On Wednesday 08 January 2020 12:01:08 Gene Heskett wrote: > On Wednesday 08 January 2020 09:37:10 Roger Price wrote: > > On Tue, 7 Jan 2020, Gene Heskett wrote: > > > ● nut-monitor.service - Network UPS Tools - power device monitor > > > and shutdown controller > > > Loaded: loaded (/lib/systemd/system/nut-monitor.service; > > > enabled; vendor
2020 Jan 22
2
nut on armhf, r-pi4b IOW
On Tuesday 21 January 2020 19:52:01 Charles Lepple wrote: > sudo lsusb -v -d 0764:0501 copious output, containing this: idVendor 0x0764 Cyber Power System, Inc. idProduct 0x0501 CP1500 AVR UPS bcdDevice 0.01 iManufacturer 3 CPS iProduct 1 CP625HGa I take it that this is evidence they don't follow the spec to the letter.
2020 Jan 12
0
nut on armhf, r-pi4b IOW
On Sunday 12 January 2020 12:09:04 Gene Heskett wrote: > On Sunday 12 January 2020 11:14:13 Charles Lepple wrote: > > On Jan 12, 2020, at 9:56 AM, Gene Heskett wrote: > > >> Instant return, logging this: > > > > > > in /tmp/info > > > > > >> 0.000000 Error: too many non-option arguments. Try -h for > > >> help. Network
2020 Jan 07
0
nut on armhf, r-pi4b IOW
...use the RPi3's as nut-servers to monitor and manage my Tripp-Lite UPS systems, the other local systems run nut-client and communicate with the RPi. --Larry On Tue, Jan 7, 2020 at 6:28 AM Gene Heskett <gheskett at shentel.net> wrote: > Greetings all; > > Does nut build on an r-pi4b? > > I have an r-pi4b running one of my cnc machines and the power bump > performance due to the size of its psu and the fairly rapid start time > of my standby generator, does not allow a full powerdown restart to take > place, leaving the pi in a crashed state. > > I've p...
2020 Jan 10
0
nut on armhf, r-pi4b IOW
On Friday 10 January 2020 07:28:13 Charles Lepple wrote: > On Jan 9, 2020, at 5:51 PM, Gene Heskett wrote: > > On Thursday 09 January 2020 16:59:12 Charles Lepple wrote: > >> On Jan 9, 2020, at 4:39 PM, Gene Heskett <gheskett at shentel.net> wrote: > >>> So for starters, what's the best ./configure command line? > >> > >> There’s this
2020 Jan 10
2
nut on armhf, r-pi4b IOW
On Friday 10 January 2020 07:52:47 Gene Heskett wrote: > > Not sure where that message is coming from, but glad it worked with > > the newer aclocal. (Did you use the release tarball, or a Git > > checkout?) > > Release 2.7.4 tarball. Docs are years out of date, man pages claim > 2.7.3 dated in 2015... But it works, and thats what counts. :) Got it wired up and
2020 Jan 14
1
nut on armhf, r-pi4b IOW
On Jan 12, 2020, at 12:58 PM, Gene Heskett wrote: > > But this doesn't pass the smell test, 3 other machines that are trained > to reboot when power returns and have no ups fitted, were NOT rebooted > as evidenced by their reported uptimes, one of which shows a 144 day > uptime. So why should this have been logged via a -wall bc to every > login it is servicing? >