On 6/16/22 03:58, Anssi Saari wrote:
gene heskett <ghesk...@shentel.net> writes:
now my additional reply is munged, backspaces or Del's will not "take"
What the heck is this vertical bar it uses for a quote level, whats wrong
with > >> etc for quote indicators? There's a button containing an A
overlaid by a graphical double square as the last line above the window
that claims to "remove text styling" but it does nothing. Under options
->delivery format, plain text is checked, but obviously its still sending
and rendering what I see as HTML. That's not the end of the bug list
Just a note, in my end your post is just text:
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Not HTML, not multipart/alternative with one part text and one HTML. I
don't know if there's any filtering in-between, I read this list via
Gmane's NNTP server.
This install feels good yet, but at 36 hours uptime, I've used
half the typical uptime I've managed in 30 previous installs.
I have had to replace some memory, but now memtest can't
be found, I guess because it is a 16 bit build, and can't be
changed. But it ran ON THIS 6 core i5, probably 8 or 9 times
pre bullseye.
Debian 11 packages memtest86 and memtest86+ in the main repository with
those package names exactly. Those are quite old and if you managed a
UEFI installation they aren't bootable.
So what replaces it? From the thread about its MIA status, I
am not the only one wanting it or a 64 bit substitute back
on the grub menu.
I have a $100 bill for the talented coder who brings that
or a new 64 bit from scratch version back.
The commercial memtest86 v9 Pro from Passmark goes for $44 today. They
have a free edition too with limited features.
I now have that one installed on an sd card in a reader, works fine.
I rebooted, found it in the bios, and ran it one pass, no errors.
It does not!!!!!!!!!! That's what I'm screaming about.
It sets the perms so only root can use them. I just
plugged at least one of them in:
root@coyote:/lib/udev/rules.d# ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Jun 15 05:31 /dev/ttyUSB0
020660. The common user can't touch it. So what IS
the "approved fix" so the user CAN use it? A fix that
will actually survive a reboot. That's the question
asked that every reply so far has ignored.
I've looked into this and I have a draft of another post about that but
basically it looks like it'll amount to just "I don't know why" and "it
works for me." I need to test a few things though.
A rude hack to fix the permissions would be to setup /etc/rc.local and
do your chgrps and/or chmods in there. Instructions at
https://blog.wijman.net/enable-rc-local-in-debian-bullseye/ for example.
I just did all that, so now I have an /etc/rc.local but not an rc-local
but he changes from rc.local to rc-local in the middle. confusing.
So which is it. I originally created an rc.local, changed it to
rc-local, and back with mv.
But a
root@coyote:/etc# systemctl status rc-local
● rc-local.service - /etc/rc.local Compatibility
Loaded: loaded (/lib/systemd/system/rc-local.service;
enabled-runtime; vendor preset: enabled)
Drop-In: /usr/lib/systemd/system/rc-local.service.d
└─debian.conf
Active: active (exited) since Thu 2022-06-16 07:50:14 EDT; 19min ago
Docs: man:systemd-rc-local-generator(8)
Process: 49522 ExecStart=/etc/rc.local start (code=exited,
status=0/SUCCESS)
CPU: 764us
Jun 16 07:50:14 coyote systemd[1]: Starting /etc/rc.local Compatibility...
Jun 16 07:50:14 coyote systemd[1]: Started /etc/rc.local Compatibility.
Which looks good. So now I put what I want in which file? in this rc.local?
or do I create an rc-local and put the needed chowns, chgrps chmods in
yet another new file?
What I have done is unplugged them in order to delete the /dev entries,
so an ls -l /dev/ttyUSB* returns this:
ls: cannot access '/dev/ttyUSB*': No such file or directory
Then I plugged them back in, getting this for an ls -l /dev/ttyUSB*
root@coyote:/etc# ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Jun 16 08:18 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 Jun 16 08:18 /dev/ttyUSB1
Now, I'm not aware of who heyu runs as, probably gene since I'm the
one running it and there is no user heyu.
Now, 2 new questions:
So what do I put in this rc.local to allow me, gene, to use /dev/ttyUSB0,
which has the cm11a on the other side of an fdti adaptor?
Then:
root@coyote:/etc# grep nut group
nut:x:122:
root@coyote:/etc# grep nut passwd
nut:x:115:122::/var/lib/nut:/usr/sbin/nologin
So what do I put in this rc.local to enable nut to use /dev/ttyUSB1,
which is
an APC 1500 UPS.
Both are returning no perms errors now
gene@coyote:~$ heyu info
starting heyu_relay
HEYU: Can't open tty line. Check the permissions.
and as root:
root@coyote:/dev# /etc/init.d/nut-server start
Starting nut-server (via systemctl): nut-server.service.
root@coyote:/dev# /etc/init.d/nut-client start
Starting nut-client (via systemctl): nut-client.service.
And journalctl -xe:
Jun 16 08:43:00 coyote systemd[1]: Starting Network UPS Tools - power
device monitor and shutdown controller...
░░ Subject: A start job for unit nut-monitor.service has begun execution
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit nut-monitor.service has begun execution.
░░
░░ The job identifier is 7210.
Jun 16 08:43:00 coyote upsmon[51112]: fopen /run/nut/upsmon.pid: No such
file or directory
Jun 16 08:43:00 coyote upsmon[51112]: UPS: myups@localhost (master)
(power value 1)
Jun 16 08:43:00 coyote upsmon[51112]: Using power down flag file
/etc/killpower
Jun 16 08:43:00 coyote upsmon[51112]: /etc/nut/upsmon.conf line 234:
invalid directive REPLBATT : The UPS battery is bad and needs to be replaced
Jun 16 08:43:00 coyote upsmon[51112]: /etc/nut/upsmon.conf line 260:
invalid directive WALL - Write the message to all users on the system
Jun 16 08:43:00 coyote systemd[1]: nut-monitor.service: Can't open PID
file /run/nut/upsmon.pid (yet?) after start: Operation not permitted
Jun 16 08:43:00 coyote upsmon[51113]: Startup successful
Jun 16 08:43:00 coyote systemd[1]: nut-monitor.service: Supervising
process 51114 which is not our child. We'll most likely not notice when
it exits.
Jun 16 08:43:00 coyote systemd[1]: Started Network UPS Tools - power
device monitor and shutdown controller.
░░ Subject: A start job for unit nut-monitor.service has finished
successfully
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ A start job for unit nut-monitor.service has finished successfully.
░░
░░ The job identifier is 7210.
Jun 16 08:43:00 coyote upsmon[51114]: Init SSL without certificate database
Jun 16 08:43:00 coyote upsmon[51114]: Login on UPS [myups@localhost]
failed - got [ERR ACCESS-DENIED]
Jun 16 08:43:05 coyote upsmon[51114]: Poll UPS [myups@localhost] failed
- Driver not connected
Jun 16 08:43:05 coyote upsmon[51114]: Communications with UPS
myups@localhost lost
Jun 16 08:43:10 coyote upsmon[51114]: Poll UPS [myups@localhost] failed
- Driver not connected
Jun 16 08:43:10 coyote upsmon[51114]: UPS myups@localhost is unavailable
The nut people say the first line error about SSL can be ignored.
root:ls -l /run/nut:
total 8
-rw-r--r-- 1 nut nut 6 Jun 16 08:42 upsd.pid
-rw-r--r-- 1 root root 6 Jun 16 08:43 upsmon.pid
nut-server?
but upsmon, running as root. has no perms either.
new install, comes totall unconfigured, could be miss-configured, but
little is available
as help files, and I've changed mail agents so don't recall the nut
lists server address.
Thanks, Anssi Saari, take care and stay well.
Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
