Anssi Saari <anssi.saari@usenet.mail.kapsi.fi> wrote:
> 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.

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

--
__ __
#_ < |\| |< _# | Note: I won't see posts made from Google Groups |

On 04/01/2024 14:11, Anssi Saari wrote:
> 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.

---druck

druck <news@druck.org.uk> writes:
> I don't know if anyone has a working cross-grade for Raspbian then,

I have done crossgrades with Debian (x86->amd64) and while it worked[1],
I can’t really recommend it unless you are very confident indeed. I’d
expect a similar situation with Raspbian/RPi OS.

[1] meaning I have a working system that’s been continously upgraded
since the mid 1990s:

$ ls -l /etc/hostname
-rw-r--r-- 1 root root 6 Mar 24 1995 /etc/hostname
$ cat /etc/debian_version
12.4
$ uname -r
6.1.0-16-amd64

> 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.

Makes me wonder how practical it would be to automate this: a tool which
captured the configuration of one host (list of packages, configuration
that’s been customized relative to installed versions, extra state in
/var, etc) and modified a second host to match. I suspect doing it
properly would be more work than is worthwhile (architecture transitions
just don’t happen very often) but that doesn’t always stop people l-)

--
https://www.greenend.org.uk/rjk/

Andy Burns <usenet@andyburns.uk> writes:
> The base64 coding does come from druck's Thunderbird, but it's
> probably not his fault, there's a longer chain of "blame" ...
>
> The message from <56g.1183@ztq4.net> uses 8bit encoding and seems to
> have needlessly changed spaces into sequences of 0xC3 0x82 0x20
> possibly triggered by Chris Elvidge's message also using 8bit coding
> and including non US ASCII characters (e.g. a British pound sign £)

None of Chris’s message is quoted in David’s message, so I don’t see how
that can be relevant.

I don’t see the C3... sequence you mention in 56g’s message:

# grep From: 34062
From: "56g.1183" <56g.1183@ztq4.net>
# hd 34062|grep c3
#

However David’s message does use U+00A0 (i.e. NO-BREAK SPACE, C2 A0 in
UTF-8), as part of the quoting of 56g’s message:

# tail +27 34073|base64 -id|hd|head
00000000 4f 6e 20 30 33 2f 30 31 2f 32 30 32 34 20 30 35 |On 03/01/2024 05|
00000010 3a 35 38 2c 20 35 36 67 2e 31 31 38 33 20 77 72 |:58, 56g.1183 wr|
00000020 6f 74 65 3a 0d 0a 3e 20 20 c2 a0 20 54 68 65 20 |ote:..> .. The |
^^^^^
00000030 57 6f 72 6d 20 2a 77 6f 72 6b 73 2a 20 2e 2e 2e |Worm *works* ...|

I think that’s a quoting decision made by Thunderbird, perhaps triggered
by an internal trip through an HTML representation where the redundant
multiple spaces at the start of 56g’s lines need to be converted to
something else to avoid whitespace collapsing.

Thunderbird’s decision to use base64 is certainly not what I’d do (NNTP
is 8-bit clean so Content-Transfer-Encoding: 8bit would be perfectly
adequate) but it is in-spec and has been for many years.

--
https://www.greenend.org.uk/rjk/

not@telling.you.invalid (Computer Nerd Kev) writes:

> 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

Wow, I've actually followed exactly that gist on my Oracle freebie
VPS. It's a good guide but not suitable for the old Pi. I'm not sure of
the other one. Anyways, I'm not looking to install Debian on this.

I did see a blog post here
https://k1024.org/posts/2023/2023-10-31-raspberry-pi-upgrade-crossgrade/
about armhf to arm64 crossgrading which isn't really positive on the
process although he was apparently successful. Then again, he had
Raspberry PI OS and a Pi4 and a Zero 2 W, my CM3+ and Ubuntu might hit
other snags.

What I'm planning is either retire or replace the thing, I actually have
a cheap refurb mini-PC to take its place running Debian currently or
cross grade to amd64 so I would need no changes and have support until
2030 or maybe upgrade to Ubuntu 22.04 LTS. But I have until 2025 to
decide.

As it happens, during the Xmas break I got around to playing with my
RTL-SDR software radio and getting some weather data from my outdoor
wireless temperature/humidity sensor. Works fine but the rtl_433 package
on Ubuntu 20.04 is too old, I'd need a newer rtl_433 to easily support
the sensor I have. One point in favor of upgrading Ubuntu.

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...

On 08/01/2024 09:50, Anssi Saari wrote:
> 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...

No everything useful was copied over, but I spent some time looking at
/etc to weed out config for packages which are no longer installed. For
the stuff that is still installed the config files have often gained new
options over time, and it's useful to add these in to my copies, so they
can be altered in future.

---druck