This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I
can't log in via ssh, how can one then shut down safely?
I guess the risk of simply pulling the power isn't *that* bad but one
would prefer not to.
Chris Green <cl@isbd.net> wrote:
This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I
can't log in via ssh, how can one then shut down safely?
I guess the risk of simply pulling the power isn't *that* bad but one
would prefer not to.
Unless you're prepared to plug in a monitor, or enable and connect a serial console, then pulling the plug is the only way.
Theo
On 11/12/2023 12:28, Theo wrote:
Chris Green <cl@isbd.net> wrote:
This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I
can't log in via ssh, how can one then shut down safely?
I guess the risk of simply pulling the power isn't *that* bad but one
would prefer not to.
Unless you're prepared to plug in a monitor, or enable and connect a serial console, then pulling the plug is the only way.
Not quite Theo.
You *could* set up a hardware interrupt on a GPIO pin that invokes some
kind of (more or less) orderly shutdown.
And attach a 'reset' button. Or a 'power off' button. Depending on what
you did in the interrupt service routine
I run a number of headless Pis, sometimes I get something wrong and I
can't log in via ssh, how can one then shut down safely?
Chris,
I run a number of headless Pis, sometimes I get something wrong and I
can't log in via ssh, how can one then shut down safely?
Maybe adding a "shutdown" button as per the below ?
https://raspberrypi.stackexchange.com/questions/117013/raspberry-pi-4-b-gpio-boot-and-shutdown-buttons
OP here, thank you, that's really useful, and not only for the
shutdown button. I'm using the RPi to read/control several I2C
devices (taking over from a BBB) and that page has lots of useful I2C information as well.
Chris,
OP here, thank you, that's really useful, and not only for the
shutdown button. I'm using the RPi to read/control several I2C
devices (taking over from a BBB) and that page has lots of useful I2C information as well.
You're welcome, even though the I2C extras where (ofcourse) a lucky shot.
:-)
One question though : I don't think that your above BBB means "Better Business Bureau", but than what /does/ it mean ?
This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I
can't log in via ssh, how can one then shut down safely?
I guess the risk of simply pulling the power isn't *that* bad but one
would prefer not to.
On 12/11/23 5:39 AM, Chris Green wrote:
This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I
can't log in via ssh, how can one then shut down safely?
I guess the risk of simply pulling the power isn't *that* bad but one
would prefer not to.
You can SSH into them and then "(sudo) shutdown now".
That works.
One question though : I don't think that your above BBB meansIt means Beaglebone Black, a single board computer quite similar
"Better Business Bureau", but than what /does/ it mean ?
in some ways to the Pi.
However it hasn't got updated like the Pi and so is now somewhat
behind as regards processor power etc.
Chris,
One question though : I don't think that your above BBB meansIt means Beaglebone Black, a single board computer quite similar
"Better Business Bureau", but than what /does/ it mean ?
in some ways to the Pi.
Ah yes, I've heard about that one. Never seen one though.
However it hasn't got updated like the Pi and so is now somewhat
behind as regards processor power etc.
:-) Not everyone yearns for having the newest-and-fastest thingamagotchy.
Take me, I've got a swell time working with a RPi... One? (one of the earliest versions, without mounting holes) running a Lite version (CLI interface only) of BullsEye.
I have quite a selection of Pis back to quite early versions and
all of them are CLI only.
Chris,
OP here, thank you, that's really useful, and not only for the
shutdown button. I'm using the RPi to read/control several I2C
devices (taking over from a BBB) and that page has lots of useful I2C
information as well.
You're welcome, even though the I2C extras where (ofcourse) a lucky shot.
:-)
One question though : I don't think that your above BBB means "Better Business Bureau", but than what /does/ it mean ?
Regards,
Rudy Wieser
On 12/11/23 5:39 AM, Chris Green wrote:
This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I
*can't log in via ssh*, how can one then shut down safely?
*You can SSH into them* and then "(sudo) shutdown now".
That works.
Chris,
I have quite a selection of Pis back to quite early versions and
all of them are CLI only.
I did install the full, GUI based version of BullsEye, just to see if it would work. It did.
But the lack of any kind of speed made me quickly decide that maybe a CLI version would work better. :-)
To be honest, I was pleasantly surprised that that not-too-old BullsEye wanted to boot on that rather ancient RPi.
Regards,
Rudy Wieser
This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I
can't log in via ssh, how can one then shut down safely?
56g.1173 <56g.1173@ztq9.net> wrote:
On 12/11/23 5:39 AM, Chris Green wrote:Didn't you see the bit that says "...I can't log in via ssh."? :-)
This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I
can't log in via ssh, how can one then shut down safely?
I guess the risk of simply pulling the power isn't *that* bad but one
would prefer not to.
You can SSH into them and then "(sudo) shutdown now".
That works.
In article <hg5j4k-um341.ln1@esprimo.zbmc.eu>, cl@isbd.net says...
This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I
can't log in via ssh, how can one then shut down safely?
What I do on my Pis is run an application which watches for the
insertion of a USB stick labelled SHUTDOWNPI.
https://github.com/jps-aldridge/shutdownthumb
On 12/12/2023 05:16, 56g.1173 wrote:
On 12/11/23 5:39 AM, Chris Green wrote:
This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I
*can't log in via ssh*, how can one then shut down safely?
*You can SSH into them* and then "(sudo) shutdown now".
That works.
Edited to display idiocy more clearly
On 12/12/23 5:13 AM, The Natural Philosopher wrote:SSH is only as bulletproof as the underlying operating system
On 12/12/2023 05:16, 56g.1173 wrote:
On 12/11/23 5:39 AM, Chris Green wrote:
This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I
*can't log in via ssh*, how can one then shut down safely?
*You can SSH into them* and then "(sudo) shutdown now".
That works.
Edited to display idiocy more clearly
SSH is almost bulletproof ... hoped he'd figured
it out ......
On 12/12/23 4:17 AM, Chris Green wrote:
56g.1173 <56g.1173@ztq9.net> wrote:
On 12/11/23 5:39 AM, Chris Green wrote:Didn't you see the bit that says "...I can't log in via ssh."? :-)
This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I
can't log in via ssh, how can one then shut down safely?
I guess the risk of simply pulling the power isn't *that* bad but one
would prefer not to.
You can SSH into them and then "(sudo) shutdown now".
That works.
I'd hoped he'd figured that out already ... he CAN, ifSeriously, dont be such a fucking twat. Obviously he can until his
he sets it up correctly.
On Wed Dec 13 02:59:00 2023, The Natural Philosopher wrote to All <=-
On 13/12/2023 01:17, 56g.1173 wrote:
On 12/12/23 4:17 AM, Chris Green wrote:
56g.1173 <56g.1173@ztq9.net> wrote:
On 12/11/23 5:39 AM, Chris Green wrote:Didn't you see the bit that says "...I can't log in via ssh."? :-)
This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I >>>> can't log in via ssh, how can one then shut down safely?
I guess the risk of simply pulling the power isn't *that* bad but one >>>> would prefer not to.
You can SSH into them and then "(sudo) shutdown now".
That works.
I've been having a similar issue with one of my Pis acting as a PiHole. Every week or so, it totally locks up, can't SSH in, can't even get a serial terminal, have to hard reboot. Luckily it's actually the secondary DNS so stuff on my network stays up and running, but it's annoying because it also is connected to my UPS and a RTL-SDR that reports to FlightAware. Their emails telling me my feed is down is usually the first time I notice it's locked up again.I'd hoped he'd figured that out already ... he CAN, ifSeriously, dont be such a fucking twat. Obviously he can until his
he sets it up correctly.
system locks up, and then he CANT.
And that is his problem. That he cant ssh in. Ive had this occasionally
with my remote virtual private servers. Something like a memory leak or
a full disk or someone DOSing it stops me getting in.
Only solution is a console reboot and hit the server logs before it restarts, firewall out whoever is doing it, if they are, or delete the
logs of them trying which have flooded the limited disk...
--
"Anyone who believes that the laws of physics are mere social
conventions is invited to try transgressing those conventions from the windows of my apartment. (I live on the twenty-first floor.) "
Alan Sokal
--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
On 12/12/23 4:17 AM, Chris Green wrote:
56g.1173 <56g.1173@ztq9.net> wrote:
On 12/11/23 5:39 AM, Chris Green wrote:Didn't you see the bit that says "...I can't log in via ssh."? :-)
This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I
can't log in via ssh, how can one then shut down safely?
I guess the risk of simply pulling the power isn't *that* bad but one
would prefer not to.
You can SSH into them and then "(sudo) shutdown now".
That works.
I'd hoped he'd figured that out already ... he CAN, if
he sets it up correctly. Most common err on a Pi is to
forget to enable the service ... either using the config
GUI or manually with systemctl. I change the default port
and the too-liberal login stuff in sshd_config too, just
to be safe.
On Tue, 12 Dec 2023 23:49:49 -0000, John Aldridge wrote:
In article <hg5j4k-um341.ln1@esprimo.zbmc.eu>, cl@isbd.net says...
This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I
can't log in via ssh, how can one then shut down safely?
What I do on my Pis is run an application which watches for the
insertion of a USB stick labelled SHUTDOWNPI.
https://github.com/jps-aldridge/shutdownthumb
The standard Linux "su - shutdown" or "su - shutdown --poweroff" should do the trick, while "man 8 shutdown" or "su - shutdown --help" tells you all about it.
Hint: If you're not quite sure what a command is called, but you want to
see its manpage, running the command "apropos whatIwant" will show you all the manual pages whose NAME sentence contains that character string or something similar.
On Wed Dec 13 02:59:00 2023, The Natural Philosopher wrote to All <=-
> And that is his problem. That he cant ssh in. Ive had this occasionally
> with my remote virtual private servers. Something like a memory leak or
> a full disk or someone DOSing it stops me getting in.
I've been having a similar issue with one of my Pis acting as a PiHole. Every week or so, it totally locks up, can't SSH in, can't even get a serial terminal, have to hard reboot. Luckily it's actually the secondary DNS so stuff
on my network stays up and running, but it's annoying because it also is connected to my UPS and a RTL-SDR that reports to FlightAware. Their emails telling me my feed is down is usually the first time I notice it's locked up again.
OP here. What I meant when I said "...I can't log in via ssh." is a situation where the software has crashed or something like that. I
know quite well how to configure a Pi to let me log in using ssh.
56g.1173 <56g.1173@ztq9.net> wrote:
On 12/11/23 5:39 AM, Chris Green wrote:Didn't you see the bit that says "...I can't log in via ssh."? :-)
This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I
can't log in via ssh, how can one then shut down safely?
I guess the risk of simply pulling the power isn't *that* bad but one
would prefer not to.
You can SSH into them and then "(sudo) shutdown now".
That works.
On 12/12/23 4:17 AM, Chris Green wrote:
56g.1173 <56g.1173@ztq9.net> wrote:
On 12/11/23 5:39 AM, Chris Green wrote:Didn't you see the bit that says "...I can't log in via ssh."? :-)
This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I
can't log in via ssh, how can one then shut down safely?
I guess the risk of simply pulling the power isn't *that* bad but one
would prefer not to.
You can SSH into them and then "(sudo) shutdown now".
That works.
I'd hoped he'd figured that out already ... he CAN, if
he sets it up correctly.
Most common err on a Pi is to
forget to enable the service ... either using the config
GUI or manually with systemctl. I change the default port
and the too-liberal login stuff in sshd_config too, just
to be safe.
However a "clean shutdown" BUTTON would be a really good
thing - ergo the description of how to go for that. Ya
can also write your OWN little daemon, send "STOP" on
port whatever, separate from SSH.
On Wed Dec 13 02:59:00 2023, The Natural Philosopher wrote to All <=-
> On 13/12/2023 01:17, 56g.1173 wrote:
> > On 12/12/23 4:17 AM, Chris Green wrote:
> >> 56g.1173 <56g.1173@ztq9.net> wrote:
> >>> On 12/11/23 5:39 AM, Chris Green wrote:
> >>>> This sort of continues from my earlier question.
> >>>>
> >>>> I run a number of headless Pis, sometimes I get something wrong and I
> >>>> can't log in via ssh, how can one then shut down safely?
> >>>>
> >>>> I guess the risk of simply pulling the power isn't *that* bad but one
> >>>> would prefer not to.
> >>>
> >>> You can SSH into them and then "(sudo) shutdown now".
> >>> That works.
> >>>
> >> Didn't you see the bit that says "...I can't log in via ssh."? :-)
> >
> >
> > I'd hoped he'd figured that out already ... he CAN, if
> > he sets it up correctly.
> Seriously, dont be such a fucking twat. Obviously he can until his
> system locks up, and then he CANT.
>
> And that is his problem. That he cant ssh in. Ive had this occasionally
> with my remote virtual private servers. Something like a memory leak or
> a full disk or someone DOSing it stops me getting in.
I've been having a similar issue with one of my Pis acting as a PiHole. Every week or so, it totally locks up, can't SSH in, can't even get a serial terminal, have to hard reboot. Luckily it's actually the secondary DNS so stuff
on my network stays up and running, but it's annoying because it also is connected to my UPS and a RTL-SDR that reports to FlightAware. Their emails telling me my feed is down is usually the first time I notice it's locked up again.
In article <hg5j4k-um341.ln1@esprimo.zbmc.eu>, cl@isbd.net says...
This sort of continues from my earlier question.
I run a number of headless Pis, sometimes I get something wrong and I
can't log in via ssh, how can one then shut down safely?
What I do on my Pis is run an application which watches for the
insertion of a USB stick labelled SHUTDOWNPI.
https://github.com/jps-aldridge/shutdownthumb
ou could use a heart-beat type mechanism.
The PiHole repeatedly sends a check to remote service, the heart-beat
If the heart-beat stops, you can first get a script on the PiHole to
trigger a reboot itself, if the PiHole hasn't locked up.
If the PiHole has genuinely frozen, doesn't recover in a timely way, the remote end of the heart beat serivice could signal a seperate tasmota
style power switch to cycle the power on the PiHole.
I've been having a similar issue with one of my Pis acting as a PiHole. Every week or so, it totally locks up, can't SSH in, can't even get a serial terminal, have to hard reboot. Luckily it's actually the secondary DNS so stuff
on my network stays up and running, but it's annoying because it also is connected to my UPS and a RTL-SDR that reports to FlightAware. Their emails telling me my feed is down is usually the first time I notice it's locked up again.
Try the hardware watchdog, there's plenty of info on it, here is the
first page that came to hand
https://diode.io/blog/running-forever-with-the-raspberry-pi-hardware-watchdog
---druck
On 12/12/2023 09:52, R.Wieser wrote:
Chris,
I have quite a selection of Pis back to quite early versions and
all of them are CLI only.
I did install the full, GUI based version of BullsEye, just to see if it
would work. It did.
But the lack of any kind of speed made me quickly decide that maybe a CLI
version would work better. :-)
To be honest, I was pleasantly surprised that that not-too-old BullsEye
wanted to boot on that rather ancient RPi.
Regards,
Rudy Wieser
I've got Bookworm running (no gui) on
Hardware : BCM2835
Revision : 900032
Serial : 00000000c72dee2a
Model : Raspberry Pi Model B Plus Rev 1.2
I got it for £10 (still in it's box) on ebay.
On 13/12/2023 23:12, Pancho wrote:
ou could use a heart-beat type mechanism.
The PiHole repeatedly sends a check to remote service, the heart-beat
If the heart-beat stops, you can first get a script on the PiHole to
trigger a reboot itself, if the PiHole hasn't locked up.
If the PiHole has genuinely frozen, doesn't recover in a timely way,
the remote end of the heart beat serivice could signal a seperate
tasmota style power switch to cycle the power on the PiHole.
Experience shows that there are a range of situations that can disable
user access. Some of them will also disable any self-rebooting type
systems you might employ.
In such cases the only option is a power cycle.
BUT if its happening regularly, the answer is to FIX THE CODE that is
causing it or replace the hardware.
I remember one SPARC machine sent in to us that 'always worked for half
an hour, but then stopped'
CPU fan was wrecked by dust.
Pis are cheap enough that a total swapout wont cost an ARM (sic!) and a
leg so that is the easiest way to eliminate a hardware fault.
Code wise, you can disable services one at a time until its stable, or
look in the log files,
Linux/PI is good, but some kinds of errors and/or
memory leaks DO seem to accumulate despite best
efforts.
@INTL 3:770/1 3:770/3
@REPLYADDR news@druck.org.uk
@REPLYTO 3:770/3.0 UUCP
@MSGID: <un4isp$3b8gn$1@dont-email.me> 2bba35bb
@REPLY: <vbWdnS0X77_3agn4nZ2dnZfqnPednZ2d@earthlink.com> 2694f141
@PID: SoupGate-Win32 v1.05 T24gMDMvMDEvMjAyNCAwNTo1OCwgNTZnLjExODMgd3JvdGU6DQo+ICDCoCBUaGUgV29ybS
Aq d29ya3MqIC4uLiBidXQgSSByZWFsbHkgZG8gTk9UIGxpa2UgaXQuDQo+ICDCoCBDaGF
uZ2Vz IFRPTyBtYW55IHRoaW5ncyB0byBOTyBvYnZpb3VzIHB1cnBvc2UuDQpbc25pcF0N Cj4gICAg R290IGEgUGk1IGNvbWluZyAuLi4gaXQncyBnb25uYSBiZSBmb3IgIm11bHRpL Q0KPiAgICBt ZWRpYSIgKHN0cmVhbWluZykgc3R1ZmYuIEkndmUgZ290IFdvcm0vUEkNCj 4gICAgcmVhZHkg Zm9yIGl0IC4uLiBidXQgbWlnaHQgTk9UIHN0aWNrIHdpdGggaXQuDQo +ICAgIFZFUlkgZGlz YXBwb2ludGVkIGluIERlYiBub3cuDQoNCkdpdmVuIHRoZSB3YXJu aW5ncyB0aGF0IGEgQnVs bHNleWUgdG8gQm9va3dvcm0gdXBncmFkZSB3YXNuJ3QgdmlhY mxlLCBJIA0KZGlkIGEgZnJl c2ggaW5zdGFsbCBvZiBCb29rd29ybSBvbiBteSBuZXcgUG kgNSwgYW5kIHdhcyBsZXNzIHRo YW4gDQppbXByZXNzZWQuIEl0IGNvbXBsZXRlbHkgaWd ub3JlZCBteSBhdHRlbXB0cyB0byBy ZXBsYWNlIFBpeGVsIHdpdGggbXkgDQpwcmVmZXJy ZWQgTWF0ZSBkZXNrdG9wLCBhbmQgSSB3 YXMgaG9ycmlmaWVkIHRvIGZpbmQgcnN5c2xvZ yB3YXNuJ3QgDQphY3RpdmUgYW5kIG9ubHkg am91cm5hbGQgc2hpdGUuDQoNClNvIEkgYW JhbmRvbmVkIHRoYXQsIGFuZCB3ZW50IGJhY2sg dG8gaXQncyBwcmVkZWNlc3NvciBQaSA 0Qiwgd2hpY2ggd2FzIA0KcnVubmluZyBCdWxsc2V5 ZSA2NCBiaXQgKGhhbmQgdXBncmFk ZWQgZnJvbSAzMiBiaXQsIGFuZCBwcmlvciB0byB0aGF0 IGluIA0KcGxhY2UgdXBncmFkZ WQgYWxsIHRoZSB3YXkgZnJvbSB0aGUgdmVyeSBmaXN0IE9T IHJ1bm5pbmcgYW4gdGhlIG 9yaWdpbmFsIA0KMjU2TUIgUGkgQikgYW5kIHVwZ3JhZGVkIHRo YXQgdG8gQm9va3dvcm0 gd2l0aG91dCBhbnkgcHJvYmxlbXMsIHVzaW5nIA0KaW5mbyBvbiBo dHRwczovL3BpbXls aWZldXAuY29tL3Jhc3BiZXJyeS1waS1vcy1idWxsc2V5ZS10by1ib29r d29ybS8NCg0KV GhhdCByZXN1bHRlZCBpbiBhIFBpIDVCIHJ1bm5pbmcgQm9va3dvcm0gd2l0 aCBhIGZ1bG x5IHdvcmtpbmcgTWF0ZSANCmRlc2t0b3AsIG5vIFdheWxhbmQgY3J1ZCwgcnN5 c2xvZyB hY3RpdmUgYW5kIGFsbCB0aGUgb3RoZXIgDQpjdXN0b21pc2F0aW9ucyBJJ3ZlIG1h ZGUg b3ZlciB0aGUgbGFzdCAxMiB5ZWFycy4NCg0KLS0tZHJ1Y2sNCg==
SEEN-BY: 1/120 18/0 25/0 21 123/0 25 126 180 200 755 3001 135/115
153/757 7715
SEEN-BY: 218/840 220/70 221/1 6 222/2 226/17 100 240/1120 250/0 1 3 4
5 6 7 8
SEEN-BY: 250/10 11 13 14 263/0 5 267/800 275/1000 299/6 301/1 113 812
310/31
SEEN-BY: 335/364 341/66 463/68 467/4 888 633/280 712/848 1321 770/1 3
100 330
SEEN-BY: 770/340 772/210 220 230 2320/105 3634/0 12 56 57 119 5001/100 5005/49
SEEN-BY: 5020/1042 4441 5030/49 5054/8 5058/104 5061/133 5075/128
5090/958
@PATH: 770/3 1 218/840 221/6 301/1 5020/1042 3634/12 250/1
@INTL 3:770/1 3:770/3
@REPLYADDR news@druck.org.uk
@REPLYTO 3:770/3.0 UUCP
@MSGID: <un4isp$3b8gn$1@dont-email.me> 2bba35bb
@REPLY: <vbWdnS0X77_3agn4nZ2dnZfqnPednZ2d@earthlink.com> 2694f141
@PID: SoupGate-Win32 v1.05
T24gMDMvMDEvMjAyNCAwNTo1OCwgNTZ....
Any chance you can discontinue this message format as for myself as one I cannot read it and it does not comply with the standards for any messaging that I have found including fido and Usenet.
Hello druck!
Wednesday January 03 2024 21:17, you wrote to All:
> @INTL 3:770/1 3:770/3
> @REPLYADDR news@druck.org.uk
> @REPLYTO 3:770/3.0 UUCP
> @MSGID: <un4isp$3b8gn$1@dont-email.me> 2bba35bb
> @REPLY: <vbWdnS0X77_3agn4nZ2dnZfqnPednZ2d@earthlink.com> 2694f141
> @PID: SoupGate-Win32 v1.05
> T24gMDMvMDEvMjAyNCAwNTo1OCwgNTZnLjExODMgd3JvdGU6DQo+ICDCoCBUaGUgV29ybS
> Aq d29ya3MqIC4uLiBidXQgSSByZWFsbHkgZG8gTk9UIGxpa2UgaXQuDQo+ICDCoCBDaGF
> uZ2Vz IFRPTyBtYW55IHRoaW5ncyB0byBOTyBvYnZpb3VzIHB1cnBvc2UuDQpbc25pcF0N
> Cj4gICAg R290IGEgUGk1IGNvbWluZyAuLi4gaXQncyBnb25uYSBiZSBmb3IgIm11bHRpL
> Q0KPiAgICBt ZWRpYSIgKHN0cmVhbWluZykgc3R1ZmYuIEkndmUgZ290IFdvcm0vUEkNCj
> 4gICAgcmVhZHkg Zm9yIGl0IC4uLiBidXQgbWlnaHQgTk9UIHN0aWNrIHdpdGggaXQuDQo
> +ICAgIFZFUlkgZGlz YXBwb2ludGVkIGluIERlYiBub3cuDQoNCkdpdmVuIHRoZSB3YXJu
> aW5ncyB0aGF0IGEgQnVs bHNleWUgdG8gQm9va3dvcm0gdXBncmFkZSB3YXNuJ3QgdmlhY
> mxlLCBJIA0KZGlkIGEgZnJl c2ggaW5zdGFsbCBvZiBCb29rd29ybSBvbiBteSBuZXcgUG
> kgNSwgYW5kIHdhcyBsZXNzIHRo YW4gDQppbXByZXNzZWQuIEl0IGNvbXBsZXRlbHkgaWd
> ub3JlZCBteSBhdHRlbXB0cyB0byBy ZXBsYWNlIFBpeGVsIHdpdGggbXkgDQpwcmVmZXJy
> ZWQgTWF0ZSBkZXNrdG9wLCBhbmQgSSB3 YXMgaG9ycmlmaWVkIHRvIGZpbmQgcnN5c2xvZ
> yB3YXNuJ3QgDQphY3RpdmUgYW5kIG9ubHkg am91cm5hbGQgc2hpdGUuDQoNClNvIEkgYW
> JhbmRvbmVkIHRoYXQsIGFuZCB3ZW50IGJhY2sg dG8gaXQncyBwcmVkZWNlc3NvciBQaSA
> 0Qiwgd2hpY2ggd2FzIA0KcnVubmluZyBCdWxsc2V5 ZSA2NCBiaXQgKGhhbmQgdXBncmFk
> ZWQgZnJvbSAzMiBiaXQsIGFuZCBwcmlvciB0byB0aGF0 IGluIA0KcGxhY2UgdXBncmFkZ
> WQgYWxsIHRoZSB3YXkgZnJvbSB0aGUgdmVyeSBmaXN0IE9T IHJ1bm5pbmcgYW4gdGhlIG
> 9yaWdpbmFsIA0KMjU2TUIgUGkgQikgYW5kIHVwZ3JhZGVkIHRo YXQgdG8gQm9va3dvcm0
> gd2l0aG91dCBhbnkgcHJvYmxlbXMsIHVzaW5nIA0KaW5mbyBvbiBo dHRwczovL3BpbXls
> aWZldXAuY29tL3Jhc3BiZXJyeS1waS1vcy1idWxsc2V5ZS10by1ib29r d29ybS8NCg0KV
> GhhdCByZXN1bHRlZCBpbiBhIFBpIDVCIHJ1bm5pbmcgQm9va3dvcm0gd2l0 aCBhIGZ1bG
> x5IHdvcmtpbmcgTWF0ZSANCmRlc2t0b3AsIG5vIFdheWxhbmQgY3J1ZCwgcnN5 c2xvZyB
> hY3RpdmUgYW5kIGFsbCB0aGUgb3RoZXIgDQpjdXN0b21pc2F0aW9ucyBJJ3ZlIG1h ZGUg
> b3ZlciB0aGUgbGFzdCAxMiB5ZWFycy4NCg0KLS0tZHJ1Y2sNCg==
> SEEN-BY: 1/120 18/0 25/0 21 123/0 25 126 180 200 755 3001 135/115
> 153/757 7715
> SEEN-BY: 218/840 220/70 221/1 6 222/2 226/17 100 240/1120 250/0 1 3 4
> 5 6 7 8
> SEEN-BY: 250/10 11 13 14 263/0 5 267/800 275/1000 299/6 301/1 113 812
> 310/31
> SEEN-BY: 335/364 341/66 463/68 467/4 888 633/280 712/848 1321 770/1 3
> 100 330
> SEEN-BY: 770/340 772/210 220 230 2320/105 3634/0 12 56 57 119 5001/100
> 5005/49
> SEEN-BY: 5020/1042 4441 5030/49 5054/8 5058/104 5061/133 5075/128
> 5090/958
> @PATH: 770/3 1 218/840 221/6 301/1 5020/1042 3634/12 250/1
Any chance you can discontinue this message format as for myself as one I cannot read it and it does not comply with the standards for any messaging that I have found including fido and Usenet.
Vincent
Gosh I didn't see that it was base 64 encoded!
No reason for that.
Thunderbird doesnt normally encode usenet that way...
Andy Burns wrote:
I think it needs Chris Elvidge and/or 56g.1183 to use 7-bit encoding
for their UTF-8 messages
The mail.strictly_mime=true setting also has an influence
But it seems Thunderbird isn't as well behaved as I thought, it is
easily tempted into using base64 encoding instead of 7bit encoding with quoted-printable characters :-(
Has anyone got any better settings?
Hello druck!
> @INTL 3:770/1 3:770/3
> @REPLYADDR news@druck.org.uk
> @REPLYTO 3:770/3.0 UUCP
> @MSGID: <un4isp$3b8gn$1@dont-email.me> 2bba35bb
> @REPLY: <vbWdnS0X77_3agn4nZ2dnZfqnPednZ2d@earthlink.com> 2694f141
> @PID: SoupGate-Win32 v1.05
> SEEN-BY: 1/120 18/0 25/0 21 123/0 25 126 180 200 755 3001 135/115
> 153/757 7715
> SEEN-BY: 218/840 220/70 221/1 6 222/2 226/17 100 240/1120 250/0 1 3 4
> 5 6 7 8
> SEEN-BY: 250/10 11 13 14 263/0 5 267/800 275/1000 299/6 301/1 113 812
> 310/31
> SEEN-BY: 335/364 341/66 463/68 467/4 888 633/280 712/848 1321 770/1 3
> 100 330
> SEEN-BY: 770/340 772/210 220 230 2320/105 3634/0 12 56 57 119 5001/100
> 5005/49
> SEEN-BY: 5020/1042 4441 5030/49 5054/8 5058/104 5061/133 5075/128
> 5090/958
> @PATH: 770/3 1 218/840 221/6 301/1 5020/1042 3634/12 250/1
Any chance you can discontinue this message format as for myself as one I cannot read it and it does not comply with the standards for any messaging that I have found including fido and Usenet.
I think it needs Chris Elvidge and/or 56g.1183 to use 7-bit encoding for their UTF-8 messages
So I abandoned that, and went back to it's predecessor Pi 4B, which
was running Bullseye 64 bit (hand upgraded from 32 bit, and prior to
that in place upgraded all the way from the very fist OS running an
the original 256MB Pi B)
druck <news@druck.org.uk> writes:
So I abandoned that, and went back to it's predecessor Pi 4B, which
was running Bullseye 64 bit (hand upgraded from 32 bit, and prior to
that in place upgraded all the way from the very fist OS running an
the original 256MB Pi B)
What's "hand upgraded"? I have this Pi that I kinda would like to keep running for a while yet but it has Ubuntu 20.04 LTS on it. Canonical
extended the support for 20.04 LTS until 2030 but not for the armhf architecture which I have. I've considered cross grading it to arm64 but
I'm not sure it's worth the trouble or if that would even work. And this
is a CM3+ so there's no SD card, only soldered eMMC for storage.
On 04/01/2024 12:40, Andy Burns wrote:
But it seems Thunderbird isn't as well behaved as I thought, it isAccording to those what know better than I Usenet and Mime base 64 are
easily tempted into using base64 encoding instead of 7bit encoding with
quoted-printable characters :-(
Has anyone got any better settings?
now a standard.
druck <news@druck.org.uk> writes:
So I abandoned that, and went back to it's predecessor Pi 4B, which
was running Bullseye 64 bit (hand upgraded from 32 bit, and prior to
that in place upgraded all the way from the very fist OS running an
the original 256MB Pi B)
What's "hand upgraded"? I have this Pi that I kinda would like to keep running for a while yet but it has Ubuntu 20.04 LTS on it. Canonical
extended the support for 20.04 LTS until 2030 but not for the armhf architecture which I have. I've considered cross grading it to arm64 but
I'm not sure it's worth the trouble or if that would even work. And this
is a CM3+ so there's no SD card, only soldered eMMC for storage.
druck <news@druck.org.uk> writes:
So I abandoned that, and went back to it's predecessor Pi 4B, which
was running Bullseye 64 bit (hand upgraded from 32 bit, and prior to
that in place upgraded all the way from the very fist OS running an
the original 256MB Pi B)
What's "hand upgraded"? I have this Pi that I kinda would like to keep running for a while yet but it has Ubuntu 20.04 LTS on it. Canonical
extended the support for 20.04 LTS until 2030 but not for the armhf architecture which I have. I've considered cross grading it to arm64 but
I'm not sure it's worth the trouble or if that would even work. And this
is a CM3+ so there's no SD card, only soldered eMMC for storage.
I don't know if anyone has a working cross-grade for Raspbian then,
so I created a new partition with a clean 64 bit Bullseye on it,
installed all the same optional packages as the 32 bit partition, then
copied over all /home, /opt, bits of /var and lastly looked at
/etc. That was the trickiest bit, machine-id and ssh/ssh_host* were
copied across to preserve the identity, but all the other files had to
be diffed and changes integrated so as to keep the legit configuration
and to shed some of the cruft from multiple previous OS releases.
These are about converting VPS systems from Ubuntu to Debian, but
the process ought to be the same except for any special driver
requirements for the RPis: https://gist.github.com/4abhinavjain/893ec13c651bee08088c8f4661998952 https://github.com/bohanyang/debi
I don't know if anyone has a working cross-grade for Raspbian then, so
I created a new partition with a clean 64 bit Bullseye on it,
installed all the same optional packages as the 32 bit partition, then
copied over all /home, /opt, bits of /var and lastly looked at
/etc. That was the trickiest bit, machine-id and ssh/ssh_host* were
copied across to preserve the identity, but all the other files had to
be diffed and changes integrated so as to keep the legit configuration
and to shed some of the cruft from multiple previous OS releases.
druck <news@druck.org.uk> writes:
I don't know if anyone has a working cross-grade for Raspbian then, so
I created a new partition with a clean 64 bit Bullseye on it,
installed all the same optional packages as the 32 bit partition, then
copied over all /home, /opt, bits of /var and lastly looked at
/etc. That was the trickiest bit, machine-id and ssh/ssh_host* were
copied across to preserve the identity, but all the other files had to
be diffed and changes integrated so as to keep the legit configuration
and to shed some of the cruft from multiple previous OS releases.
That's the thing, isn't it? Either copy all the cruft over or spend
months in transition, going from wondering "didn't I have a script/config/whatever for this" to "oh right, it was on the old system,
time to copy that over too." BTDT...
| Sysop: | Coz |
|---|---|
| Location: | Anoka, MN |
| Users: | 2 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 140:14:18 |
| Calls: | 166 |
| Files: | 5,389 |
| Messages: | 223,236 |