Hello All!

Just purchased a pi 4B 8Gb along with Argon One M.2 case and PSU with a WD 240 SSD M.2 (sata?) 2280 card.

First starting installing Ubuntu O/S (x64) (20.1 LTS server on the SD card then
after booting with it successfully, realised I could install direct to the SSD using a USB3 plugged cable connected to a Win 10 laptop so did that and boxed the SSD unit up back up with the Argon case and started it - great works, installs and configures the server and sit waiting for me to use bash commands to add anything else but must have missed the message regarding how, as I decided to have dinner.

So next again using the Pi O/S install software installed Ubuntu overwriting the SSD with Desktop 21.04? x64 and rebooted.

With the gui fully up and running I loaded a terninal and the system locked up - solid. Powered off and restarted with the same thing happening again including without loading terminal.

The case was very warn as I could not use terminal to load the special script to set up the fan and power button.

I have no idea what is the problem BUT decided to load Bullseye x64 instead into the SSD and it did its thing including checking for updates (none) and has
been sitting here running for 2+ hours and yes did load the argon script :)

Anyone any idea of why the system locked up with Ubuntu desktop ?

I am "assuming" here that 8Gb Ram is more than enough for it !

After the first install of ubuntu (server) onto the SD card, I have not continued to update it or use it, so it is not installed in the Pi at all.



Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Vincent Coen wrote to All <=-

Hello All!

Just purchased a pi 4B 8Gb along with Argon One M.2 case and PSU
with a WD 240 SSD M.2 (sata?) 2280 card.

First starting installing Ubuntu O/S (x64) (20.1 LTS server on
the SD card then
after booting with it successfully, realised I could install
direct to the SSD using a USB3 plugged cable connected to a Win
10 laptop so did that and boxed the SSD unit up back up with the
Argon case and started it - great works, installs and configures
the server and sit waiting for me to use bash commands to add
anything else but must have missed the message regarding how, as
I decided to have dinner.

So next again using the Pi O/S install software installed Ubuntu overwriting the SSD with Desktop 21.04? x64 and rebooted.

With the gui fully up and running I loaded a terninal and the
system locked up - solid. Powered off and restarted with the
same thing happening again including without loading terminal.

The case was very warn as I could not use terminal to load the
special script to set up the fan and power button.

I have no idea what is the problem BUT decided to load Bullseye
x64 instead into the SSD and it did its thing including checking
for updates (none) and has
been sitting here running for 2+ hours and yes did load the argon
script :)

Anyone any idea of why the system locked up with Ubuntu desktop ?

I am "assuming" here that 8Gb Ram is more than enough for it !

After the first install of ubuntu (server) onto the SD card, I
have not continued to update it or use it, so it is not installed
in the Pi at all.

I would guess that it's because of "X64". Surprised it even installed.
The RPi is an ARM processor and not capable of 64 bit X64, I believe.



... What was the best thing BEFORE sliced bread?
=== MultiMail/Linux v0.52
--- SBBSecho 3.14-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)

I would guess that it's because of "X64". Surprised it even installed. The RPi is an ARM processor and not capable of 64 bit X64, I believe.

Sorry, sir, but that is incorrect. The Pi4B's processor is indeed capable of 64-bit operation. There's also a 64-bit version of PiOS.

However, I agree that there may be some incompatibility with Ubuntu, as it
was primarily designed for x86_64, and not armhf_64.

Didn't Ubuntu make a mobile version in the past, though? I wonder if that is armhf-compatible...

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

nospam.Shaun.Buzza@f110.n229.z1.fidonet.org (Shaun Buzza) writes:

I would guess that it's because of "X64". Surprised it even
installed. The RPi is an ARM processor and not capable of 64 bit
X64, I believe.

Sorry, sir, but that is incorrect. The Pi4B's processor is indeed capable of 64-bit operation. There's also a 64-bit version of PiOS.

x64 means the same as x86-64. However the OP is probably just
misreporting and really used an arm64 install. x86-64 would simply not
work at all.

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Shaun Buzza wrote:

DC> I would guess that it's because of "X64". Surprised it even installed.
DC> The RPi is an ARM processor and not capable of 64 bit X64, I believe.

Sorry, sir, but that is incorrect. The Pi4B's processor is indeed capable of 64-bit operation.

Yes but 64 bit doesn't necessarily imply x64 (aka x86_64), a pi is AArch64 (aka ARM64)

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Shaun Buzza wrote to Dan Clough <=-

I would guess that it's because of "X64". Surprised it even installed. The RPi is an ARM processor and not capable of 64 bit X64, I believe.

Sorry, sir, but that is incorrect. The Pi4B's processor is indeed
capable of 64-bit operation. There's also a 64-bit version of
PiOS.

Sorry, you're incorrect. Nowhere did I say that the RPi4's processor
isn't capable of 64-bit operation. I said (look right up there above)
that it's not capable of *X64*. That's a true statement.

However, I agree that there may be some incompatibility with
Ubuntu, as it was primarily designed for x86_64, and not
armhf_64.

Yes, and the OP stated that he installed "Ubuntu X64". Again I say that
it's surprising that it even installed. It probably did NOT install correctly, or he installed something different than what he said.

Didn't Ubuntu make a mobile version in the past, though? I wonder
if that is armhf-compatible...

I don't know, and that is irrelevant to this thread, as he didn't say he installed that.


... Strip mining prevents forest fires.
=== MultiMail/Linux v0.52
--- SBBSecho 3.14-Linux
* Origin: Palantir * palantirbbs.ddns.net * Pensacola, FL * (1:123/115)

x64 means the same as x86-64. However the OP is probably just
misreporting and really used an arm64 install. x86-64 would simply not work at all.

That's more or less what I figured. But I think that it's possible that some part of Ubuntu is just not happy working in armhf_64, and that's what may be causing the crashes.

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

I would guess that it's because of "X64". Surprised it even installe The RPi is an ARM processor and not capable of 64 bit X64, I believe.

Sorry, sir, but that is incorrect. The Pi4B's processor is indeed capable of 64-bit operation. There's also a 64-bit version of
PiOS.

Sorry, you're incorrect. Nowhere did I say that the RPi4's processor isn't capable of 64-bit operation. I said (look right up there above) that it's not capable of *X64*. That's a true statement.

Did you mean 'x86_64'? Because, if you did, that would indeed be true. *X64*
is not a term I am familiar with, and therefore I assumed your phrase "64 bit X64" to mean, basically, "64 bit 64-bit". Correct terminology is important.
The confusion over this term should have been apparent with my next statement:

However, I agree that there may be some incompatibility with
Ubuntu, as it was primarily designed for x86_64, and not
armhf_64.

Yes, and the OP stated that he installed "Ubuntu X64". Again I say that it's surprising that it even installed. It probably did NOT install correctly, or he installed something different than what he said.

Again, I assumed you meant "Ubuntu 64-bit", because of the terminology error. This could mean *any* 64-bit version of Ubuntu. Indeed, if OP had tried to install x86_64 Ubuntu, it would have serious problems, and probably wouldn't even have booted.

Didn't Ubuntu make a mobile version in the past, though? I wonder
if that is armhf-compatible...

I don't know, and that is irrelevant to this thread, as he didn't say he installed that.

I disagree. OP is trying to install Ubuntu on an ARM device, which a mobile version would be much more likely to support. It is entirely relevant to suggest possible alternate versions in order to achieve that goal.

Enjoy your day, Dan!

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

Oh dear. Lots of squabbling but not much help for the OP.
For the record there is a version of Ubuntu for the Pi. It's even
referenced on the RPI website ...

https://www.raspberrypi.com/software/operating-systems/#third-party-software

Lots of people run it, so obviously the OP has some problem. I thought
it might be overheating but I thought the processors throttled on
overheating to reduce the heat generated, and you got a slower system. I
know many people recommend a fan for the Pi4. I use the Aluminium Armour Heatsinks for my 2 Pi4B's - 4Gb nd 8Gb versions, and they run fine but
aren't in an enclosed box.

The OP might get more help by using the RPI forums.

On 2022-02-24, Shaun Buzza <nospam.Shaun.Buzza@f110.n229.z1.fidonet.org> wrote:

I would guess that it's because of "X64". Surprised it even installe
The RPi is an ARM processor and not capable of 64 bit X64, I believe.

Sorry, sir, but that is incorrect. The Pi4B's processor is indeed capable of 64-bit operation. There's also a 64-bit version of
PiOS.

Sorry, you're incorrect. Nowhere did I say that the RPi4's processor isn't capable of 64-bit operation. I said (look right up there above) that it's not capable of *X64*. That's a true statement.

Did you mean 'x86_64'? Because, if you did, that would indeed be true. *X64* is not a term I am familiar with, and therefore I assumed your phrase "64 bit X64" to mean, basically, "64 bit 64-bit". Correct terminology is important. The confusion over this term should have been apparent with my next statement:

However, I agree that there may be some incompatibility with Ubuntu, as it was primarily designed for x86_64, and not
armhf_64.

Yes, and the OP stated that he installed "Ubuntu X64". Again I say that it's surprising that it even installed. It probably did NOT install correctly, or he installed something different than what he said.

Again, I assumed you meant "Ubuntu 64-bit", because of the terminology error. This could mean *any* 64-bit version of Ubuntu. Indeed, if OP had tried to install x86_64 Ubuntu, it would have serious problems, and probably wouldn't even have booted.

Didn't Ubuntu make a mobile version in the past, though? I wonder if that is armhf-compatible...

I don't know, and that is irrelevant to this thread, as he didn't say he installed that.

I disagree. OP is trying to install Ubuntu on an ARM device, which a mobile version would be much more likely to support. It is entirely relevant to suggest possible alternate versions in order to achieve that goal.

Enjoy your day, Dan!

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 23/02/2022 10:50, Vincent Coen wrote:

So next again using the Pi O/S install software installed Ubuntu overwriting the SSD with Desktop 21.04? x64 and rebooted.

Is that ARM 64 bit, or x86/64 ?
You need the former.

---druck

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

"Shaun Buzza" <nospam.Shaun.Buzza@f110.n229.z1.fidonet.org> wrote in message news:219912709@f110.n229.z1.fidonet.org...

However, I agree that there may be some incompatibility with Ubuntu, as it was primarily designed for x86_64, and not armhf_64.

Is there anything in the source code of Ubuntu (or any other flavour of
Linux) which, when compiled, makes it run better on x86_64 than armhf_64 (or the 32-bit equivalents, for that matter)? Does arm have the same
byte-ordering as Intel, or is it the opposite way round (like SPARC is)? I would have thought that little/big endian would have been the main stumbling block of porting source code between different CPUs. I have "fond" memories many years ago of having to go through loads of C source code (*), looking
for any code which *assumed* that the high byte of an int would always
follow rather than precede the low byte in data structures, and insert
#ifdefs with a macro to reverse the bytes - this was for source code that
was designed for Intel which we also wanted to run on SPARC-based servers as well as Intel-based ones. I think the order of bytes was a standard in the packets that came over the network, and may or may not (according to CPU)
have to be reversed when processing any int or long values.


(*) For a Unix port of Microsoft's LAN Manager: being Microsoft software it designed its network packets to assume Intel byte-ordering because Windows
only ran on Intel. Porting to SPARC meant a certain amount of extra work...

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Vincent Coen <nospam.Vincent.Coen@f1.n250.z2.fidonet.org> wrote:

So next again using the Pi O/S install software installed Ubuntu overwriting the SSD with Desktop 21.04? x64 and rebooted.

[as usual this NG goes off into the weeds about x86_64 when it's clear the
Pi is working enough to get to a GUI - so that's an irrelevant tangent.
It's clear the OP is running 64-bit ARM Linux aka aarch64 and arm64]

With the gui fully up and running I loaded a terninal and the system
- locked up solid. Powered off and restarted with the same thing
- happening again
including without loading terminal.

First things to try when it's frozen:

- press Ctrl-Alt-F1 (and other F keys, see if you can get to a console where you can login)

- if not, can you ping it over the network? (if plugged into ethernet, your router should tell you the IP)

It's possible it's just the GUI that's crashed, rather than a hard lockup.

The case was very warn as I could not use terminal to load the special
script to set up the fan and power button.

You can also try downclocking it via config.txt. Open config.txt on the
first partition on the SD card/SSD (from another machine) and add:

arm_freq=600
gpu_freq=400

That will slow down the processor, perhaps enough to get in and run the
script. You may need to play around with the numbers (in MHz) as I'm just guessing and I don't know what's accepted.

Anyone any idea of why the system locked up with Ubuntu desktop ?

Possibly worth checking your power supply - maybe Ubuntu takes more current?

I am "assuming" here that 8Gb Ram is more than enough for it !

Plenty.

After the first install of ubuntu (server) onto the SD card, I have not continued to update it or use it, so it is not installed in the Pi at all.

Another possible thing to try is this: https://ubuntu-mate.community/t/single-user-mode/5104
(I *think* Ubuntu on the Pi is using GRUB like other platforms - that 'e' keystroke is when you're in GRUB)

Theo

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Is there anything in the source code of Ubuntu (or any other flavour of Linux) which, when compiled, makes it run better on x86_64 than armhf_64 (or the 32-bit equivalents, for that matter)?

Not exactly. But the x86 and x86_64 instruction set is not the same as armhf and armhf_64. So, the software has to be compiled specifically for that instruction set.

Does arm have the same
byte-ordering as Intel, or is it the opposite way round (like SPARC is)?

Honestly, I'm not sure about that. I haven't written any code for armhf. But
I do know that armhf has a different instruction set, and different features, when compared to its x86 counterparts, in a similar way that Intel and SPARC chips have.

I would have thought that little/big endian would have been the main stumbling block of porting source code between different CPUs.

Haha, that's less of a problem than you might think these days. After all, Intel's newest chip lineup uses a very similar design philosophy with their Efficiency and Performance cores. But, that certainly was a bit of an issue
in the past.

I have
"fond" memories many years ago of having to go through loads of C source code (*), looking for any code which *assumed* that the high byte of an int would always follow rather than precede the low byte in data structures, and insert #ifdefs with a macro to reverse the bytes - this was for source code that was designed for Intel which we also wanted to run on SPARC-based servers as well as Intel-based ones.

I could see how that would be annoying. But imagine trying to write Assembler code for both systems; they're so different, that your entire program would have to be rewritten. Which is exactly the problem with armhf vs x86.

Keep in mind, I'm making assumptions about SPARC systems that may not be correct. I haven't done any coding for that system, nor anything specific to servers. My little games and demos would probably compile and run perfectly
on any system with a Free Pascal compiler...

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

Hello Dan!

Wednesday February 23 2022 20:37, you wrote to me:

Vincent Coen wrote to All <=-

Hello All!

Just purchased a pi 4B 8Gb along with Argon One M.2 case and PSU
with a WD 240 SSD M.2 (sata?) 2280 card.

First starting installing Ubuntu O/S (x64) (20.1 LTS server on
the SD card then
after booting with it successfully, realised I could install
direct to the SSD using a USB3 plugged cable connected to a Win
10 laptop so did that and boxed the SSD unit up back up with the
Argon case and started it - great works, installs and configures
the server and sit waiting for me to use bash commands to add
anything else but must have missed the message regarding how, as
I decided to have dinner.

So next again using the Pi O/S install software installed Ubuntu
overwriting the SSD with Desktop 21.04? x64 and rebooted.

With the gui fully up and running I loaded a terninal and the
system locked up - solid. Powered off and restarted with the
same thing happening again including without loading terminal.

The case was very warn as I could not use terminal to load the
special script to set up the fan and power button.

I have no idea what is the problem BUT decided to load Bullseye
x64 instead into the SSD and it did its thing including checking
for updates (none) and has
been sitting here running for 2+ hours and yes did load the argon
script :)

Anyone any idea of why the system locked up with Ubuntu desktop ?

I am "assuming" here that 8Gb Ram is more than enough for it !

After the first install of ubuntu (server) onto the SD card, I
have not continued to update it or use it, so it is not installed
in the Pi at all.

I would guess that it's because of "X64". Surprised it even
installed. The RPi is an ARM processor and not capable of 64 bit X64,
I believe.

Sorry, that's my typing but it is 64 bit (Arm) Pi4B so using the same for Linux.


Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Hello Shaun!

Thursday February 24 2022 09:53, you wrote to Dan Clough:

I would guess that it's because of "X64". Surprised it even
installed. The RPi is an ARM processor and not capable of 64 bit
X64, I believe.

Sorry, sir, but that is incorrect. The Pi4B's processor is indeed
capable of 64-bit operation. There's also a 64-bit version of PiOS.

However, I agree that there may be some incompatibility with Ubuntu,
as it was primarily designed for x86_64, and not armhf_64.

Didn't Ubuntu make a mobile version in the past, though? I wonder if
that is armhf-compatible...

McDoob
SysOp, PiBBS
pibbs.sytes.net

There is a specific version both Desktop and server for the Pi at 64 bit.

I have to 'assume' that the raspberry installer as found on their website downloaded and installed the right one - hmm, just grabbing the SD card with a copy on it ---- Nope not a X64 version plus it created 2 partitions, very Pi :)



Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Hello druck!

Thursday February 24 2022 20:08, you wrote to me:

On 23/02/2022 10:50, Vincent Coen wrote:

So next again using the Pi O/S install software installed Ubuntu
overwriting the SSD with Desktop 21.04? x64 and rebooted.

Is that ARM 64 bit, or x86/64 ?
You need the former.

Just had a look at the SD and it has 2 partitions and it failed to load when I selected it in a AMD X64 system so yes I am reasonably confident that it's for a Pi.


Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Hello All!

So an update:

I gave up at least for the moment on the ubuntu distro and installed using the same tool Bullseye X64 direct to the SSD M.2 device using a usb3 plugged cable and booted it (all today) after I was wide awake.

Needless to say it is working fine for a Debian Pi distro but I do not like the
basic Gui interface and would like to use KDE or Gnome (if I have to), how ever
there is not a procedure the install one of them without picking each element for say KDE and that would be a accident waiting to happen.

Why the devil don't they offer a change of gui system instead of the very basic
one they use ?

Yes, I know I am getting older but was hoping I am not that senile yet !

When I get a chance or have to shut the system down I will install the SD card on the offchance the boot sequence will see the card and load from it.
Failing that I will disconnect the USB link and try it - perhaps try that method first :)


Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

nospam.Vincent.Coen@f1.n250.z2.fidonet.org (Vincent Coen) writes:

Why the devil don't they offer a change of gui system instead of the
very basic one they use ?

Sure they do, you just need to know which package to install. For KDE
it's plasma-desktop.

Or actually, there are some helper packages whose names in Debian start
with task-

So, installing package task-kde-desktop installs KDE and so on. On
Debian. For Ubuntu, the similar package would be kde-standard.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Thu, 24 Feb 2022 21:13:03 +1200,
nospam.Shaun.Buzza@f110.n229.z1.fidonet.org (Shaun Buzza) declaimed the following:

Does arm have the same
byte-ordering as Intel, or is it the opposite way round (like SPARC is)?

Honestly, I'm not sure about that. I haven't written any code for armhf. But >I do know that armhf has a different instruction set, and different features, >when compared to its x86 counterparts, in a similar way that Intel and SPARC >chips have.

ARM doesn't make chips -- they license the design to various chip makers. Chip makers, in effect, go down a list of components and [X] those
they want included in the design. One of those options just happens to be
the endianess of the resulting processor (I'm pretty sure it's a foundry
level decision -- only because having a run-time flag in the chip to switch between BE and LE would make booting rather complex).

So... any specific ARM design could be either endianess; there is no "all ARM are LE" (or BE).



--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Thu, 24 Feb 2022 13:01:24 +1200,
nospam.Shaun.Buzza@f110.n229.z1.fidonet.org (Shaun Buzza) declaimed the following:

Did you mean 'x86_64'? Because, if you did, that would indeed be true. *X64* >is not a term I am familiar with, and therefore I assumed your phrase "64 bit >X64" to mean, basically, "64 bit 64-bit". Correct terminology is important. >The confusion over this term should have been apparent with my next statement:

I'd suspect an inadvertent extension of the old "iAPX-##" notation. "intel application architecture" -- the main entries being the iAPX-432 and
the iAPX-86 (X86). That said, to me "X64" still implies Intel core. So I
concur that precision is called for and the ARM port should have been
specified to reduce confusion (bad enough x86-64 and amd64 are essentially
the same)



--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Fri, 25 Feb 2022 11:47:42 -0500, Dennis Lee Bieber wrote:

On Thu, 24 Feb 2022 21:13:03 +1200, nospam.Shaun.Buzza@f110.n229.z1.fidonet.org (Shaun Buzza) declaimed the following:

Does arm have the same NY> byte-ordering as Intel, or is it the

opposite way round (like SPARC is)?

Honestly, I'm not sure about that. I haven't written any code for armhf. >>But I do know that armhf has a different instruction set, and different >>features,
when compared to its x86 counterparts, in a similar way that Intel and >>SPARC chips have.

ARM doesn't make chips -- they license the design to various chip makers. Chip makers, in effect, go down a list of components and [X]
those they want included in the design. One of those options just
happens to be the endianess of the resulting processor (I'm pretty sure
it's a foundry level decision

Nope. By design, ARM processors support both big-endian /and/ little-
endian modes:

"ARM cores support both modes, but are most commonly used in, and
typically default to little-endian mode." (https://developer.arm.com/documentation/den0013/d/Porting/Endianness)

-- only because having a run-time flag in
the chip to switch between BE and LE would make booting rather complex).

Actually, there /is/ such a flag:
"Cortex-A series processors provide support for systems of either endian
configuration, controlled by the CPSR E bit that enables software to
switch dynamically between viewing data as little or big-endian.
Instructions in memory are always treated as little-endian." (https://developer.arm.com/documentation/den0013/d/Porting/Endianness)

So... any specific ARM design could be either endianess; there is
no "all ARM are LE" (or BE).

--
Lew Pitcher
"In Skills, We Trust"

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Shaun Buzza <nospam.Shaun.Buzza@f110.n229.z1.fidonet.org> wrote:

Does arm have the same
byte-ordering as Intel, or is it the opposite way round (like SPARC is)?

Honestly, I'm not sure about that.

ARM is little-endian by default, like x86 or AMD64 (or, going back further,
the 6502 :-) ). Unlike those two, it can be kicked into big-endian mode if
you need it, though I don't know of anything that uses that mode. The different flavors of Linux available for the Raspberry Pi are all little-endian.

--
_/_
/ v \ Scott Alfter (remove the obvious to send mail)
(IIGS( https://alfter.us/ Top-posting!
\_^_/ >What's the most annoying thing on Usenet?

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Hello Anssi!

Friday February 25 2022 17:11, you wrote to me:

nospam.Vincent.Coen@f1.n250.z2.fidonet.org (Vincent Coen) writes:

Why the devil don't they offer a change of gui system instead of the
very basic one they use ?

Sure they do, you just need to know which package to install. For KDE
it's plasma-desktop.

Or actually, there are some helper packages whose names in Debian
start with task-

So, installing package task-kde-desktop installs KDE and so on. On
Debian. For Ubuntu, the similar package would be kde-standard.

Before I go and screw the system up - What exactly has to be installed and what
needs to be changed if any thing AND is there a document such as Installing the
system and adding extra functionality etc available and if so where?

I am not looking for the simplistic how to install on a SD card etc but more like the other Linux distributions such as RH, Magiea etc that provides for a new distribution version of full instructions on updating from a previous version, or adding another GUI interface with all the primary bits needed, current reported bugs and way of getting around them plus other scenarios etc.

For example in Mageia there is Release Notes, complete docs for the installer, Errata etc. The release notes covers such items as :

--
1 Introduction
1.1 Available installation media
1.2 The Mageia online repositories
1.2.1 32 bit repos on 64 bit systems
2 Release highlights
2.1 Faster package metadata parsing
2.2 Python2 is mostly dead
2.3 ARM support
3 Major developments
3.1 Installation
3.1.1 Stage 1
3.1.2 Stage 2
3.1.3 Rescue
3.1.4 Live ISO
3.1.5 Hardware support
3.2 Localisation (l10n) / Internationalisation (i18n)
3.2.1 Manuals
3.2.2 Software translations
3.3 Package management
3.3.1 New RPM
3.3.2 DNF: the alternative package manager
3.3.3 AppStream
3.3.4 perl-URPM and urpmi
3.4 Tools
3.4.1 Mageia Control Center
3.4.2 Other
3.4.2.1 MageiaWelcome
3.4.2.2 Isodumper
3.4.2.3 Docker
3.4.2.4 LiveCD

Vincent Coen <nospam.Vincent.Coen@f1.n250.z2.fidonet.org> wrote:

Before I go and screw the system up - What exactly has to be installed and what
needs to be changed if any thing AND is there a document such as Installing the
system and adding extra functionality etc available and if so where?

I am not looking for the simplistic how to install on a SD card etc but more like the other Linux distributions such as RH, Magiea etc that provides for a new distribution version of full instructions on updating from a previous version, or adding another GUI interface with all the primary bits needed, current reported bugs and way of getting around them plus other scenarios etc.

Raspberry Pi OS is a fork of Debian, so look at Debian's instructions. For example this is the 'tasksel' tool that selects common bundles of packages
to install:

https://wiki.debian.org/tasksel
and on the subject of desktop environment: https://wiki.debian.org/DesktopEnvironment

The full Debian documentation starter page is here:
https://www.debian.org/doc/
and not to forget the RPi documentation: https://www.raspberrypi.com/documentation/
(from a Linux perspective this is mostly covering RPi specifics)

In general the RPi folks tend to preconfigure things so you don't need to
do major system changes like this, but the Debian documentation is there if
you need it.

Theo

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 25-02-2022 09:18, Vincent Coen wrote:

Before I go and screw the system up - What exactly has to be installed

I think every Pi 4 user looking to try things out needs at least two SD
cards:

1. One card for "Raspberry Pi OS 32-bit (Bullseye) with desktop and
recommended software". This is the tried & tested OS with all the Pi customisations from the people at Pi HQ. Can't get more compatible than
this. Leave this card alone, except for updating with apt (same as
Debian and all its flavours) and installing the tools you want. Don't go
& switch desktops if you don't want trouble. The Pi people are OK at
brewing their own distro but in my experience they don't check things
for even 1 nanometre outside that realm and they often come up with
their own solutions, so general Linux interoperability sometimes suffers.

1a. If you don't care about Mathematica for the moment (free!
Mathematica!) and want some speed-ups in exchange for a system that's a
little less tested but will be the standard going forward, choose
"Raspberry Pi OS 64-bit (Bullseye) with desktop" instead.

2. One card for the other OS. Ones that I know work really well out of
the box, that don't need any special treatment, and will install & work flawlessly, are:

2a. "Ubuntu Desktop 21.10 64-bit", the top choice from https://ubuntu.com/download/raspberry-pi . Same Debian-based apt update
system as RasPiOS. Changing desktop environments on Ubuntu works great
if you follow the guides. Lots & lots & lots of customisation info to be
found all over the web.

2b. Manjaro from https://manjaro.org/download/#raspberry-pi-4 . Not
Debian but Arch-based; it's good to learn about OSs that are more
fundamentally different, I think. Their updater (sudo pacman -Syu) seems superior to apt: useful & impressive visuals in the terminal and very
smooth operation every time I used it. All versions are 64-bit and
there's a great selection of desktops if you know which one you want
(you kinda have to because they come in separate images): Gnome, KDE
Plasma, Mate, Xfce, Sway. I have not tried switching desktops with
Manjaro but it has been a PC distro since forever so I imagine that it
is a well-tested scenario.

Installing on SD card is the easiest/cheapest option for the short term.
But if you found an OS or flavour you like, one that works, installing
it on any USB drive (preferably a USB3 SSD for lots of extra speed) will
also work out of the box. Really, the Pi 4 is primed to check both the
SD card slot and USB devices for boot drives, and will just find them.
No more need to keep the /boot partition on SD card and the rest of / on
the external drive. See https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#raspberry-pi-4b-and-raspberry-pi-400

Important: if you install an OS on the Pi 4 that is not the official
"Raspberry Pi OS", do NOT install older versions, even if they're LTS.
You will almost certainly run into some sort of trouble.

The only major disadvantage of any(!) desktop OS alternative to RasPiOS
is that there will be no video hardware acceleration in the browser, if
you like that sort of thing. I never use that on a Pi so I don't care. LibreElec, the media player OS, reportedly does have it but I guess
that's not in a browser? I don't know, haven't installed that in years.

Generally: A) use a good power supply with a good USB cord. But what is
good? You may think that that old wall plug you had will just work but
chances are it will not, or not well. Can't go wrong with the official
RPi power adapter. Buy three. B) Avoid el cheapo SD cards at all cost.
Sandisk Extreme are OK but probably more optimised for large block
transfers. In my experience, Sandisk Extreme Pro (different from just "Extreme"!) are faster, *very* reliable and don't lose speed over time.
But now I only use Lexar "High Performance 633x" which are better
optimised for small read/writes and not as expensive as Sandisk Extreme
Pro. No faults yet. C) Samsung Portable SSD T5 are not the cheapest ever
but work well in my experience. Absolutely no advantage whatsoever going
to T7 unless they happen to be cheaper. Apparently some USB SSD drives
(or controllers) don't (or didn't) work well with the Pi or with RaspiOS
but the T5 ones I have definitely do and always did.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 26-02-2022 08:27, A. Dumas wrote:

The only major disadvantage of any(!) desktop OS alternative to RasPiOS
is that there will be no video hardware acceleration in the browser,

Or even on RaspiOS, perhaps because they botched another update, like
Bob just posted...

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Re: Re: Pi 4B problem
By: A. Dumas to Vincent Coen on Sat Feb 26 2022 08:27 am

I think every Pi 4 user looking to try things out needs at least two SD cards:

This is a great post. Thank you.

I'd also like to throw RetroPie into the ring. Worth having an SD card for all your retro gaming goodness, and RetroPie is a great way of doing that.

Tristan.
--- SBBSecho 3.14-Linux
* Origin: Extricate BBS - bbs.extricate.org (2:250/11)

Hello All!

Looks like from at least one poster Ubuntu Desktop should be working on a Pi4 so need to retry it but this time only on a SD card - may be with the USB plug removed to stop it booting to the SSD drive.

I will need to find a USB driven SSD or HDD to use to speed the testing up if the first tests work as it could be an issue with the PiHut supplied SSD which is a WD 240 GB M.2 2280 (Sata interface I understand) as the interface card cannot use M.2 NVME which is a real shame.

One thing I have noticed with the M.2 SSD is that when running
sudo fstrim -av it exits with the implied not finding a SSD so I have to guess that the WD M.2 SSD is not being treated as a SSD and that is a worry if there is no garbage collection taking place.

I may try contacting WD (assuning they have a tech support dept) and see if they can shed any light on this as PiHut does not seem to have that level of technical support in-house like wise Argon who do not respond to emails.

I am using a Argon One M.2 case which includes a board to install a M.2 SSD in that is liked to the Pi via a USB bridge double plug.

Anyone any experiences on these points ?

Thanks for every one's help on these issues,

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Vincent Coen <nospam.Vincent.Coen@f1.n250.z2.fidonet.org> wrote:

Anyone any experiences on these points ?

If PiHut sells that drive it will be fully compatible. They are a long
standing & respected Pi shop. I'd say, stop trying custom things like
manually fstrimming until you get a bog standard installation working. An installation of a recent desktop OS, not Ubuntu server 20.04!

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Hello A!

Saturday February 26 2022 15:32, you wrote to me:

Vincent Coen <nospam.Vincent.Coen@f1.n250.z2.fidonet.org> wrote:

Anyone any experiences on these points ?

If PiHut sells that drive it will be fully compatible. They are a long standing & respected Pi shop. I'd say, stop trying custom things like manually fstrimming until you get a bog standard installation working.
An installation of a recent desktop OS, not Ubuntu server 20.04!

Point made, currently I am running Ubuntu Desktop using a SD which is very slow and so far I have noticed two issues :
1. Running auto update via the gui tool is basically not working after a few seconds as the progress bar has only moved a little then has stopped but I see drive light does come on but the Time display has stopped.

2. Starting the Terminal program has locked up to the point of not being able to entry any thing from the keyboard.

I have to conclude that this build for the Pi has not been really tested against it so I will have to try one of the other distros that was mentioned from a poster over the last day or so and see if any of these are any better.

That said it has been pointed out on one of the Pi forums that using a WS
240 SSD is almost as slow as using a SD card and in some instances I have to agree although I have not tried to run a stop watch against specific processes to compare SD vis SSD dispite my 'assumption' that a Sata ssd via a USB 3 interface should provide reasonable through put but it is a lot slower than using a Pi 3B+ to a Sata HDD via USB 2 using Geekwork casing etc.

Of course there could well be clashing in the USB interface between HDD accesses and any other data bus processing.

After all the Pi is still a basic Arm system with a very basic data bus design as far as I can tell.

.. and no I was not expecting fast performance compared to my multi core system
using Sata 3 drives and a SSD.

Will see if there is a difference using the other distro's as it is possible that Ubuntu only recompiled their system for it without modding the hardware drivers etc to take into account Pi architecture.

Mind you, that is another "Assumption".

The expression "Pay peanuts must expect monkey's", comes to mind :)


Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Hello A!

Saturday February 26 2022 15:32, you wrote to me:

Vincent Coen <nospam.Vincent.Coen@f1.n250.z2.fidonet.org> wrote:

Anyone any experiences on these points ?

If PiHut sells that drive it will be fully compatible. They are a long standing & respected Pi shop. I'd say, stop trying custom things like manually fstrimming until you get a bog standard installation working.
An installation of a recent desktop OS, not Ubuntu server 20.04!

Running fstrim is a required process if you are running with a SSD at least in two primary Linux based systems that have it as a boot drive otherwise failing to do so will make the SSD run out of disk space when the only fault is that it
has not run Garbage collection to clean up the unused clusters.

Only drawback to using SSD's under *nix. Windows does it automatically some how but for *nix you have to specify fstrim to run once every 24 hours for lightly used systems and 12 hourly for heavier load systems - it might need to be more often if using them in a busy server.

Now I have had a quick look at the SD card in use and it has Ubuntu Desktop 21.10 so I will continue using Bullseye and give up on it.
There is a wee list of issues with the Pi in the release notes (for 21.10) but they do not mention these noticed issues.

I will look in on the Debian website for their release notes for v11 and see what the procedure is to upgrade the distro to use KDE or failing that Gnome, however that does not mean they will work with a Pi in a reasonable manner - suck it and see, I guess.

Worse come to it then I will revert to server mode as it will be used un-attended mode once the special software is tested and installed.

Thanks for you help,

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

"Shaun Buzza" <nospam.Shaun.Buzza@f110.n229.z1.fidonet.org> wrote in message news:3453215492@f110.n229.z1.fidonet.org...

Is there anything in the source code of Ubuntu (or any other flavour

of

Linux) which, when compiled, makes it run better on x86_64 than

armhf_64

(or the 32-bit equivalents, for that matter)?

Not exactly. But the x86 and x86_64 instruction set is not the same as
armhf
and armhf_64. So, the software has to be compiled specifically for that instruction set.

Well yes, obviously. But *surely* the OP wasn't trying to run an Intel
binary on an ARM CPU (or vice versa). The chances of that working are sqrt(bugger_all).

But I thought the person I replied to above was saying that Ubuntu was
designed for Intel, implying that the same source code, compiled for a
variety of computers with different CPUs, would run best (by some criterion)
on Intel.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

"Dennis Lee Bieber" <wlfraed@ix.netcom.com> wrote in message news:jl1i1hld0lr6np99ft5d8hc59k61mobjll@4ax.com...

On Thu, 24 Feb 2022 21:13:03 +1200, nospam.Shaun.Buzza@f110.n229.z1.fidonet.org (Shaun Buzza) declaimed the following:

Does arm have the same
byte-ordering as Intel, or is it the opposite way round (like SPARC

is)?

Honestly, I'm not sure about that. I haven't written any code for armhf. >>But
I do know that armhf has a different instruction set, and different >>features,
when compared to its x86 counterparts, in a similar way that Intel and >>SPARC
chips have.

ARM doesn't make chips -- they license the design to various chip
makers. Chip makers, in effect, go down a list of components and [X] those they want included in the design. One of those options just happens to be
the endianess of the resulting processor (I'm pretty sure it's a foundry level decision -- only because having a run-time flag in the chip to
switch
between BE and LE would make booting rather complex).

So... any specific ARM design could be either endianess; there is no
"all ARM are LE" (or BE).

I didn't know that. Or at least, I knew that ARM didn't fabricate the chips, but I rather assumed that *all* ARM chips, as a fundamental part of the
design, had a fixed endian-ness, in the same way that all x86-compatible
chips (even if designed by AMD rather than Intel) are fixed endian-ness and
all SPARC are the opposite to Intel.

If what you are saying were true, then how could binaries that were compiled for one manufacturer's ARM CPU be guaranteed to run on all other
manufacturers' ARM CPUs?

As it happens, it seems that ARM chips are clever buggers and can run in
either endian-ness according to a flag. Well aren't they little show-offs?
;-)

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

<scott@alfter.diespammersdie.us> wrote in message news:8l9SJ.49823$Y1A7.14509@fx43.iad...

Shaun Buzza <nospam.Shaun.Buzza@f110.n229.z1.fidonet.org> wrote:

Does arm have the same
byte-ordering as Intel, or is it the opposite way round (like SPARC

is)?

Honestly, I'm not sure about that.

ARM is little-endian by default, like x86 or AMD64 (or, going back
further,
the 6502 :-) ). Unlike those two, it can be kicked into big-endian mode
if
you need it, though I don't know of anything that uses that mode. The different flavors of Linux available for the Raspberry Pi are all little-endian.

Silly question: is there any fundamental advantage of LE over BE or
vice-versa, or is it a fairly arbitrary choice that once a given chip has
been designed, needs to be adhered for in perpetuity so any future CPU of
that type can run binaries compiled for an older version of the CPU.

Was there any reason that all CPUs designed after the very first one didn't *all* adopt the same endian-ness as that first one?

Were any of the CPUs used in early domestic computers (eg Z80, 6809, 68000)
BE, or were the all LE like the 6502? Was SPARC in the minority in being BE? What about CPUs in early mainframes - were they all the same byte-ordering?

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 26 Feb 2022 at 22:04:22 GMT, "NY" <me@privacy.invalid> wrote:

<scott@alfter.diespammersdie.us> wrote in message news:8l9SJ.49823$Y1A7.14509@fx43.iad...

Shaun Buzza <nospam.Shaun.Buzza@f110.n229.z1.fidonet.org> wrote:

Does arm have the same
byte-ordering as Intel, or is it the opposite way round (like SPARC >>> is)?

Honestly, I'm not sure about that.

ARM is little-endian by default, like x86 or AMD64 (or, going back
further,
the 6502 :-) ). Unlike those two, it can be kicked into big-endian mode
if
you need it, though I don't know of anything that uses that mode. The
different flavors of Linux available for the Raspberry Pi are all
little-endian.

Silly question: is there any fundamental advantage of LE over BE or vice-versa, or is it a fairly arbitrary choice that once a given chip has been designed, needs to be adhered for in perpetuity so any future CPU of that type can run binaries compiled for an older version of the CPU.

Was there any reason that all CPUs designed after the very first one didn't *all* adopt the same endian-ness as that first one?

Were any of the CPUs used in early domestic computers (eg Z80, 6809, 68000) BE, or were the all LE like the 6502? Was SPARC in the minority in being BE? What about CPUs in early mainframes - were they all the same byte-ordering?

68000 is BE, and all IBM and similar mainframes are too.

--
Tim

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 26 Feb 2022 at 22:04:22 GMT, "NY" <me@privacy.invalid> wrote:

Were any of the CPUs used in early domestic computers (eg Z80, 6809, 68000) BE, or were the all LE like the 6502? Was SPARC in the minority in being BE? What about CPUs in early mainframes - were they all the same byte-ordering?

Well-written software doesn't care, anyway. A good example is the SQLite library, where you can write a database file on LE and read on BE and vice versa.

--
Tim

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

NY <me@privacy.invalid> wrote:

<scott@alfter.diespammersdie.us> wrote in message

ARM is little-endian by default, like x86 or AMD64 (or, going back
further,
the 6502 :-) ). Unlike those two, it can be kicked into big-endian mode
if
you need it, though I don't know of anything that uses that mode. The
different flavors of Linux available for the Raspberry Pi are all
little-endian.

Silly question: is there any fundamental advantage of LE over BE or vice-versa, or is it a fairly arbitrary choice that once a given chip has been designed, needs to be adhered for in perpetuity so any future CPU of that type can run binaries compiled for an older version of the CPU.

Was there any reason that all CPUs designed after the very first one didn't *all* adopt the same endian-ness as that first one?

Were any of the CPUs used in early domestic computers (eg Z80, 6809, 68000) BE, or were the all LE like the 6502? Was SPARC in the minority in being BE? What about CPUs in early mainframes - were they all the same byte-ordering?

The Wikipedia article on Endianness claims to answer those
questions:
https://en.wikipedia.org/wiki/Endianness

See "Hardware" for systems using different endianness "The Motorola
6800 / 6801, the 6809 and the 68000 series of processors used the
big-endian format". For some advantages/disadvantages, see
"Optimization".

--
__ __
#_ < |\| |< _#

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Sat, 26 Feb 2022 22:04:22 -0000, "NY" <me@privacy.invalid> declaimed the following:

Silly question: is there any fundamental advantage of LE over BE or >vice-versa, or is it a fairly arbitrary choice that once a given chip has >been designed, needs to be adhered for in perpetuity so any future CPU of >that type can run binaries compiled for an older version of the CPU.

Was there any reason that all CPUs designed after the very first one didn't >*all* adopt the same endian-ness as that first one?

Were any of the CPUs used in early domestic computers (eg Z80, 6809, 68000) >BE, or were the all LE like the 6502? Was SPARC in the minority in being BE? >What about CPUs in early mainframes - were they all the same byte-ordering?

Early computers were NOT BYTE ORIENTED. They used "words" of whatever the native size on the machine happened to be. Common mainframes used
32-bit words, some used 36-bit -- I believe CDC used a 60-bit word. And
many have used a 6-bit "character", basically uppercase A..Z, 0..9, and a
few punctuation characters. <https://en.wikipedia.org/wiki/BCD_(character_encoding)>
A 36-bit word could hold 6 text characters, and a 60-bit word would hold
10.

When looking at an integer value, it was common to see bits numbered

31 ... 0
MSB LSB

with the more significant bits on the "left". This is no problem on a word addressable computer (on the Xerox Sigma-6, used by my college in the late
70s, there were instructions for LB/STB [load/store byte] BUT... They
required the use of a second index register.

LB,9 word, ix

locates the 32-bit word at address "word", then takes the value of the
index register to select which byte in that word... and as I recall index 0
was bits 31..24 [so effectively big end]).

Big/Little only became a matter when accessing byte-addressable memory. Does the processor write

Memory Bits
0 31..24
1 23..16
2 15..8
3 7..0

or does it write

0 7..0
1 15..8
2 23..16
3 31..24

https://www.techtarget.com/searchnetworking/definition/big-endian-and-little-endian
"""
IBM's 370 mainframes, most reduced instruction set computers (RISC)-based computers and Motorola microprocessors use the big-endian approach. Transmission Control Protocol/Internet Protocol (TCP/IP) also uses the big-endian approach. For this reason, big-endian is sometimes called
network order.

On the other hand, Intel processors, DEC Alphas and at least some programs
that run on them are little-endian.

There are also mixed forms of endianness. For example, VAX floating point
uses mixed-endian, also referred to as middle-endian. The ordering of bytes
in a 16-bit word differs from the ordering of 16-bit words within a 32-bit word.
"""

Remember that Intel's first processors were just 4-bit! ... and grew to
8-bit, 16-bit, etc.
https://en.wikipedia.org/wiki/Intel_4004 And some of the later ones used smaller memory channels than the internal register size (meaning it took
two byte accesses to load one 16-bit word -- see the Intel 8088), so
streaming little end may have made sense to them in that it allowed use
with 8-bit memory cards.
.


--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

NY <me@privacy.invalid> wrote:

Silly question: is there any fundamental advantage of LE over BE or vice-versa, or is it a fairly arbitrary choice that once a given chip has been designed, needs to be adhered for in perpetuity so any future CPU of that type can run binaries compiled for an older version of the CPU.

Was there any reason that all CPUs designed after the very first one didn't *all* adopt the same endian-ness as that first one?

In brief:

Big endian is useful because the most significant part comes first.
For example, when comparing two decimal numbers aaa and bbb you start with the hundreds digit, and if the hundred digit from a is greater than the hundreds digit from b, then you have your answer and can skip the rest. This is
useful in eg network routing, eg if you want to pattern match 192.168.x.x
you only need wait for the 192.168 bytes to arrive on the wire before you
can route the packet.

Little endian is useful because the address of an object does not depend on
its type. In other words:

uint32_t x = 5;
uint8_t *y = &x;
printf("%d\n", *y);

will still print '5'. On a big endian machine it would print '0' (being the most significant byte of x). You have to know that the object is 32 bits to offset the calculation for the LSB:

uint32_t x = 5;
uint8_t *y = &x;
printf("%d\n", y[3]);

but that would need to be adjusted to y[1] if x was a 16 bit type.

Were any of the CPUs used in early domestic computers (eg Z80, 6809,
68000) BE, or were the all LE like the 6502? Was SPARC in the minority in being BE? What about CPUs in early mainframes - were they all the same byte-ordering?

8 bit CPUs didn't have much of an endianness, because you had to do 16
bit ops by joining together 8 bit ones, so you could do it either way round. Where there was hardware support for 16 bit values, I think it was mostly
LE. Wikipedia tells me 6800, 6809, 68K were BE.

A reason for LE's rise and BE's decline is that the memory conversion
between different types has become more important, but the sorting thing is less important - you're now doing comparisons on 32 or 64 bit chunks, or in networking hardware, where the byte-by-byte comparison doesn't matter.

Theo

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Theo <theom+news@chiark.greenend.org.uk> writes:

Big endian is useful because the most significant part comes first.
For example, when comparing two decimal numbers aaa and bbb you start with the
hundreds digit, and if the hundred digit from a is greater than the hundreds digit from b, then you have your answer and can skip the rest. This is useful in eg network routing, eg if you want to pattern match 192.168.x.x
you only need wait for the 192.168 bytes to arrive on the wire before you
can route the packet.

Little endian is useful because the address of an object does not depend on its type. In other words:

uint32_t x = 5;
uint8_t *y = &x;
printf("%d\n", *y);

will still print '5'. On a big endian machine it would print '0' (being the most significant byte of x). You have to know that the object is 32 bits to offset the calculation for the LSB:

uint32_t x = 5;
uint8_t *y = &x;
printf("%d\n", y[3]);

but that would need to be adjusted to y[1] if x was a 16 bit type.

BE mostly makes reading hexdumps easier l-) An exception is
multiprecision arithmetic, where word order within a bignum is often little-endian regardless of platform byte order. In that case a
big-endian platform means you have mix-endian bignums, which are no fun
at all to read in a raw hexdump.

Apart from I’m not convinced there’s much to choose between them in a modern general-purpose computer, unless you’re trying to run legacy code
with deeply embedded endianness assumptions (which I gather is an issue
for some businesses).

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Sat, 26 Feb 2022 22:04:22 +0000, NY wrote:

Was there any reason that all CPUs designed after the very first one
didn't *all* adopt the same endian-ness as that first one?

I suspect not. In any case a number (most) early mainframes except IBM
(?) used memory organised as words rather than bytes and AFAIK all word- addressed systems were bigendian.

Were any of the CPUs used in early domestic computers (eg Z80, 6809,
68000) BE, or were the all LE like the 6502? Was SPARC in the minority
in being BE?

<
All Motorola MPUs (6800, 6809, 68xxx families) were big-endian. just as
AFAIK all Intel devices are little-endian. Thank Bog all mpus I've seen
used ASCII encoding rather than EBCDIC, where the collation sequence was defined by card handling equipment and is a total mess.

What about CPUs in early mainframes - were they all the same
byte-ordering?

Somebody else can speak for IBM, but I *think* they all used byte
addressing, little endian arithmetic and EBCDIC .

It oldest machine I used was an Elliott 503, built using discrete
transistors. I/O was via 8 track paper tape and a lineprinter. It was a scientific machine, with 8K of 39 bit words implemented in ferrite core
memory. It did floating point calculations a little bit faster than
integer ones. Each word could hold 2 19 bit instructions and if the B
digit (bit 19, the centre bit) was set, the first instruction could
modify the second instruction. Several programs could be loaded at once
but only one ran at a time: the user-provided program was run by the
operator via a 75 word control program and typewriter, had full control.
It treated other programs in memory as co-resident function libraries and
i/o handlers for the tape reader/punches and the lineprinter. IIRC there
was no linker: the Algol 60 compiler left your program in a 32 kWord
ferrite code backing store: if there were no compilation errors it was automatically loaded into main memory and run.

A lot of the later mainframes such as ICL 2900/3900 were far more software-defined:

Burroughs B series were microcoded and used different microcode
interpreters depending on the language a program was written in, with wach program runnin in its own virtual machine.

ICL 1900 series memory, and so also its accumulators, were 24 bit words. Characters were ISO coded 6 bits, packed 4 per word. Each program had its
own address space and there was no stack.

ICL 2900/3900 series architecture was software defined. VME/B, the 2900
OS, ran each user application in a separate virtual machine whose
architecture was software defined. COBOL programs used byte oriented addressing, bytes were EBCDIC coded 8 bits, a stack was used for function calls, register lengths were software definable. Each VM implemented
rings of protection to protect code at different lower levels in the VM
from interference: user-level code could call functions at a lower level
but not modify anything at the lower level, and of course programs could
only communicate with those in other VMs via OS-level system calls. Last,
but not least, the machine could run George 3 and VME/B programs simultaneously. The only sign this was happening was that the operators
had two control consoles - one for each OS. I don't know for surem but
strongly suspect that George 3 was actually running in its own VME/B
defined virtual machine which contained microcode that emulated 1900
hardware.

I was told, on an ICL-run course, that the microcode used to run VME/B in
an OCP (Order Code Processor) in a 2966 mid-range mainframe was executed
by a single 2MHz 6809 MPU.

You may have also heard of the ICL 2903. This was a desk-size box,
capable of running on an office environment, was contained the hardware
of a 2900 disk file controller running microcode that emulated a 1900 mainframe: it would not surprise me if this was the exact same microcode
used under VME/B to run a copy of George 3 on a 2966.

I believe that IBM AS/400 (now called i-Series) used s similar software structure to ICL's VME/B. This would would make sense since both VME/B
and OS/400 were developed at about the same time and both could draw in
the ideas behind the earlier MULTICs OS.

I've also done a lot of work on AS/400 systems and noticed that there
wewre a lot of similarities between the way that VME/B and OS/400 did
things and organised disk space, etc. which also points to the likelihood
that MULTICS was a common ancestor.

ls

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 26/02/2022 07:10, Vincent Coen wrote:

Running fstrim is a required process if you are running with a SSD at least in
two primary Linux based systems that have it as a boot drive otherwise failing
to do so will make the SSD run out of disk space when the only fault is that it
has not run Garbage collection to clean up the unused clusters.

This seems to be a case of unadulterated wombat turds

- *nix ext2/3/4 type systems do not benefit from garbage collection
- SSDs do nor benefit from garbage collection as seek times are
essentially zero
- garbage collection has no effect on available disk space
- fstrim, whilst beneficial in theory, is probably redundant as SSD
lifetimes in terms of write cycles already exceed that of spinning
rust. It is certainly *not* mandatory.

In short if you want to increase SSD lifetime from 20 years to 21 years,
use FSTRIM. :-)


--
"Strange as it seems, no amount of learning can cure stupidity, and
higher education positively fortifies it."

- Stephen Vizinczey

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 26/02/2022 22:16, TimS wrote:

On 26 Feb 2022 at 22:04:22 GMT, "NY" <me@privacy.invalid> wrote:

<scott@alfter.diespammersdie.us> wrote in message
news:8l9SJ.49823$Y1A7.14509@fx43.iad...

Shaun Buzza <nospam.Shaun.Buzza@f110.n229.z1.fidonet.org> wrote:

NY> Does arm have the same
NY> byte-ordering as Intel, or is it the opposite way round (like SPARC >>>> is)?

Honestly, I'm not sure about that.

ARM is little-endian by default, like x86 or AMD64 (or, going back
further,
the 6502 :-) ). Unlike those two, it can be kicked into big-endian mode >>> if
you need it, though I don't know of anything that uses that mode. The
different flavors of Linux available for the Raspberry Pi are all
little-endian.

Silly question: is there any fundamental advantage of LE over BE or
vice-versa, or is it a fairly arbitrary choice that once a given chip has
been designed, needs to be adhered for in perpetuity so any future CPU of
that type can run binaries compiled for an older version of the CPU.

Was there any reason that all CPUs designed after the very first one didn't >> *all* adopt the same endian-ness as that first one?

Were any of the CPUs used in early domestic computers (eg Z80, 6809, 68000) >> BE, or were the all LE like the 6502? Was SPARC in the minority in being BE? >> What about CPUs in early mainframes - were they all the same byte-ordering?

68000 is BE, and all IBM and similar mainframes are too.

I think - not sure - memory rusty - some of the minicomoputers were big
endian as well.

--
Karl Marx said religion is the opium of the people.
But Marxism is the crack cocaine.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 27 Feb 2022 at 13:22:14 GMT, The Natural Philosopher <tnp@invalid.invalid> wrote:

On 26/02/2022 22:16, TimS wrote:

On 26 Feb 2022 at 22:04:22 GMT, "NY" <me@privacy.invalid> wrote:

<scott@alfter.diespammersdie.us> wrote in message
news:8l9SJ.49823$Y1A7.14509@fx43.iad...

Shaun Buzza <nospam.Shaun.Buzza@f110.n229.z1.fidonet.org> wrote:

NY> Does arm have the same
NY> byte-ordering as Intel, or is it the opposite way round (like SPARC >>>>> is)?

Honestly, I'm not sure about that.

ARM is little-endian by default, like x86 or AMD64 (or, going back
further,
the 6502 :-) ). Unlike those two, it can be kicked into big-endian mode >>>> if
you need it, though I don't know of anything that uses that mode. The >>>> different flavors of Linux available for the Raspberry Pi are all
little-endian.

Silly question: is there any fundamental advantage of LE over BE or
vice-versa, or is it a fairly arbitrary choice that once a given chip has >>> been designed, needs to be adhered for in perpetuity so any future CPU of >>> that type can run binaries compiled for an older version of the CPU.

Was there any reason that all CPUs designed after the very first one didn't >>> *all* adopt the same endian-ness as that first one?

Were any of the CPUs used in early domestic computers (eg Z80, 6809, 68000) >>> BE, or were the all LE like the 6502? Was SPARC in the minority in being BE?
What about CPUs in early mainframes - were they all the same byte-ordering? >>

68000 is BE, and all IBM and similar mainframes are too.

I think - not sure - memory rusty - some of the minicomoputers were big endian as well.

PDP-11 and VAX were LE.

--
Tim

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 27/02/2022 13:55, TimS wrote:

On 27 Feb 2022 at 13:22:14 GMT, The Natural Philosopher <tnp@invalid.invalid>

I think - not sure - memory rusty - some of the minicomoputers were big
endian as well.

PDP-11 and VAX were LE.

There were a lot more minicomputer makers than DEC..

Prior to the development of LSI CPUs, in the ECL TTL and CMOS eras, you
could build a CPU and architecture any way you wanted.



--
Climate is what you expect but weather is what you get.
Mark Twain

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 27 Feb 2022 at 13:35:45 GMT, Martin Gregorie <martin@mydomain.invalid> wrote:

On Sat, 26 Feb 2022 22:04:22 +0000, NY wrote:

What about CPUs in early mainframes - were they all the same
byte-ordering?

Somebody else can speak for IBM, but I *think* they all used byte
addressing, little endian arithmetic and EBCDIC .

BE.

--
Tim

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Hello The!

Sunday February 27 2022 13:32, you wrote to me:

On 26/02/2022 07:10, Vincent Coen wrote:

Running fstrim is a required process if you are running with a SSD
at least in two primary Linux based systems that have it as a boot
drive otherwise failing to do so will make the SSD run out of disk
space when the only fault is that it has not run Garbage collection
to clean up the unused clusters.

This seems to be a case of unadulterated wombat turds

- *nix ext2/3/4 type systems do not benefit from garbage collection
- SSDs do nor benefit from garbage collection as seek times are
essentially zero
- garbage collection has no effect on available disk space
- fstrim, whilst beneficial in theory, is probably redundant as SSD lifetimes in terms of write cycles already exceed that of spinning
rust. It is certainly *not* mandatory.

In short if you want to increase SSD lifetime from 20 years to 21
years, use FSTRIM. :-)

The purpose of the SSD garbage collection process for want of a better name is to find all clusters no longer in use and make them available in the - yes available lists/index.

Failure to do this process whether within the SSD's controller or by application s/w on the platform will result in no free clusters available to create, add, extend replace a file or file record.

A case in point my media system which uses a Samsung SSD was over loaded a year
or so ago when I loaded up around 1 Tb of video despite saving them on a HDD as
clearly the system was first saving all data to the boot (SSD) drive.

This process took up many time more than the total video content being transferred and the facility stopped because there was no more clusters available until I ran fstrim -av and left it some minutes. At which point I could continue with the load.

I have now changed the cron process to run it 2 times per day and before when ever I have a large video load up to do as a safeguard.

Windows does this process using it's own version of a similar process to fstrim
but thats as far as I know or can guess as I have never bothered to look closely into it.

I am sure you can research this in more detail than outlined above if required.

Using fstrim has absolutely nothing to do with extending the life of a SSD and possibly could decrease it slightly but it is a needed function unless the SSD controller does it automatically and for the SSD's designed for server use they
do so but you have to pay the extra cost for those devices - a lot more.
The cost increase is not justified for a desktop type system unless you need the faster write speeds they tend to have but the closest to which is a M.2 NVME or similar device set.

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

On 27 Feb 2022 13:55:06 GMT
TimS <timstreater@greenbee.net> wrote:

On 27 Feb 2022 at 13:22:14 GMT, The Natural Philosopher
<tnp@invalid.invalid> wrote:

On 26/02/2022 22:16, TimS wrote:

On 26 Feb 2022 at 22:04:22 GMT, "NY" <me@privacy.invalid> wrote:

Were any of the CPUs used in early domestic computers (eg Z80, 6809,
68000) BE, or were the all LE like the 6502? Was SPARC in the
minority in being BE? What about CPUs in early mainframes - were they
all the same byte-ordering?

68000 is BE, and all IBM and similar mainframes are too.

I think - not sure - memory rusty - some of the minicomoputers were big endian as well.

PDP-11 and VAX were LE.

But the PDP-10 was BE as was early SPARC, MIPS could go either way.
A lot of the minis were based on 68K, MIPS or SPARC so yes there would
have been a number of big endian minis around - especially during the era
of samey unix boxes with a QIC tape on the front and bunch of serial ports
on the back.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 24/02/2022 14:39, Vincent Coen wrote:

Hello druck!

Thursday February 24 2022 20:08, you wrote to me:

> On 23/02/2022 10:50, Vincent Coen wrote:
>> So next again using the Pi O/S install software installed Ubuntu
>> overwriting the SSD with Desktop 21.04? x64 and rebooted.

> Is that ARM 64 bit, or x86/64 ?
> You need the former.

Just had a look at the SD and it has 2 partitions and it failed to load when I
selected it in a AMD X64 system so yes I am reasonably confident that it's for
a Pi.

AMD is not ARM, so it wont work on a Pi

---druck

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Mon, 28 Feb 2022 09:58:43 +0000
druck <news@druck.org.uk> wrote:

On 24/02/2022 14:39, Vincent Coen wrote:

Hello druck!

Thursday February 24 2022 20:08, you wrote to me:

> On 23/02/2022 10:50, Vincent Coen wrote:
>> So next again using the Pi O/S install software installed Ubuntu
>> overwriting the SSD with Desktop 21.04? x64 and rebooted.

> Is that ARM 64 bit, or x86/64 ?
> You need the former.

Just had a look at the SD and it has 2 partitions and it failed to load when I selected it in a AMD X64 system so yes I am reasonably confident that it's for a Pi.

AMD is not ARM, so it wont work on a Pi

Er Druck - he said it *didn't* work on an AMD so it probably is ARM.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Hello druck!

Monday February 28 2022 09:58, you wrote to me:

On 24/02/2022 14:39, Vincent Coen wrote:

Hello druck!

Thursday February 24 2022 20:08, you wrote to me:

> On 23/02/2022 10:50, Vincent Coen wrote:
>> So next again using the Pi O/S install software installed
Ubuntu
>> overwriting the SSD with Desktop 21.04? x64 and rebooted.

> Is that ARM 64 bit, or x86/64 ?
> You need the former.

Just had a look at the SD and it has 2 partitions and it failed to
load when I selected it in a AMD X64 system so yes I am reasonably
confident that it's for a Pi.

AMD is not ARM, so it wont work on a Pi

Yes I am more than aware of such hence the comment!

My Pi is using the 64 bit operational properties which is why I specified X64 and this is NOT exclusive to Intel, Amd, Zilog, IBM etc.

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

First things to try when it's frozen:

- press Ctrl-Alt-F1 (and other F keys, see if you can get to a console where you can login)

- if not, can you ping it over the network? (if plugged into ethernet, your router should tell you the IP)

It's possible it's just the GUI that's crashed, rather than a hard
lockup.

This is good advice, on *any* Linux machine.

You can also try downclocking it via config.txt. Open config.txt on the first partition on the SD card/SSD (from another machine) and add:

arm_freq=600
gpu_freq=400

That will slow down the processor, perhaps enough to get in and run the script. You may need to play around with the numbers (in MHz) as I'm
just guessing and I don't know what's accepted.

I think those numbers would work. But, the more important issue is making the device useable.

Possibly worth checking your power supply - maybe Ubuntu takes more current?

I don't think this is possible. It shouldn't matter which OS is installed,
the CPU uses a certain maximum.

I am "assuming" here that 8Gb Ram is more than enough for it !

A good assumption. Lubuntu, or Xubuntu, can run fine with only 1 GB of RAM.
And older versions of Ubuntu (I don't like their version of Gnome) worked
just fine with 4 GB.

Another possible thing to try is this: https://ubuntu-mate.community/t/single-user-mode/5104
(I *think* Ubuntu on the Pi is using GRUB like other platforms - that 'e' keystroke is when you're in GRUB)

I wonder about this. Normally, on a Pi, the "shift" key is reserved on boot, for NOOBS or PINN. Perhaps, after that, this would work?

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

Hello All!

So an update:

I gave up at least for the moment on the ubuntu distro and installed
using the same tool Bullseye X64 direct to the SSD M.2 device using a
usb3 plugged cable and booted it (all today) after I was wide awake.

Needless to say it is working fine for a Debian Pi distro but I do not like the
basic Gui interface and would like to use KDE or Gnome (if I have to),
how ever
there is not a procedure the install one of them without picking each element for say KDE and that would be a accident waiting to happen.

Why the devil don't they offer a change of gui system instead of the
very basic
one they use ?

PiOS specifically chose a UI that definitely works on *any* Pi. Can you blame them? However, it is still a Debian-based system. I don't see why you
couldn't 'sudo apt-get install' any other UI, like kde or gnome.

Yes, I know I am getting older but was hoping I am not that senile yet !

That remains to be proven! (o_-)

When I get a chance or have to shut the system down I will install the
SD card on the offchance the boot sequence will see the card and load
from it. Failing that I will disconnect the USB link and try it -
perhaps try that method first :)

I am confused. I was under the impression that your Pi was locking up *after* the boot process. Meaning, it has already started loading from your USB
device, and locked up while trying to load Ubuntu...

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

I think every Pi 4 user looking to try things out needs at least two SD cards:

1. One card for "Raspberry Pi OS 32-bit (Bullseye) with desktop and recommended software".

2. One card for the other OS.

This is very good advice!

Always have one card with a working OS. Then, even if you totally destroy the other one, you'll still have some way of working with the Pi.

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

Hello All!

One thing I have noticed with the M.2 SSD is that when running
sudo fstrim -av it exits with the implied not finding a SSD so I have to guess that the WD M.2 SSD is not being treated as a SSD and that is a worry if there is no garbage collection taking place.

To be clear, any modern SSD performs its own garbage collection. You
shouldn't have to use fstrim.

I may try contacting WD (assuning they have a tech support dept) and see if they can shed any light on this as PiHut does not seem to have that level of technical support in-house like wise Argon who do not respond
to emails.

I am using a Argon One M.2 case which includes a board to install a M.2 SSD in that is liked to the Pi via a USB bridge double plug.

That USB bridge is basically the same as any that would be used in any
external SSD device. I really think you're worrying about a non-issue. Concentrate on your first problem: getting the damned thing to boot!

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

Running fstrim is a required process if you are running with a SSD at least in two primary Linux based systems that have it as a boot drive otherwise failing to do so will make the SSD run out of disk space when the only fault is that it
has not run Garbage collection to clean up the unused clusters.

No, sir! This was a problem, for certain, in the early days of SSDs. But, as I've mentioned, modern SSDs perform their own garbage collection!

Only drawback to using SSD's under *nix. Windows does it automatically some how but for *nix you have to specify fstrim to run once every 24 hours for lightly used systems and 12 hourly for heavier load systems -
it might need to be more often if using them in a busy server.

Please refer to my first comment.

Now I have had a quick look at the SD card in use and it has Ubuntu Desktop 21.10 so I will continue using Bullseye and give up on it.
There is a wee list of issues with the Pi in the release notes (for
21.10) but they do not mention these noticed issues.

Honestly, I don't see why you didn't just use PiOS from the start. You can install KDE, or Gnome, or even Cinnamon from there. Not to mention that PiOS and Ubuntu are *both* Debian-based. What exactly were you trying to achieve?

I will look in on the Debian website for their release notes for v11 and see what the procedure is to upgrade the distro to use KDE or failing
that Gnome, however that does not mean they will work with a Pi in a reasonable manner - suck it and see, I guess.

"sudo apt install kde-desktop"? Or maybe "sudo apt install gnome-desktop"?
I'm not certain that this would work, because the necessary packages may not
be on the official Pi repos. But, it's not hard to add ppa's...

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

On Mon, 28 Feb 2022 16:08:55 +1200,
nospam.Vincent.Coen@f1.n250.z2.fidonet.org (Vincent Coen) declaimed the following:

My Pi is using the 64 bit operational properties which is why I specified X64

To most of the readership, X## is an implicit reference to Intel (old iAPX nomenclature)/AMD processors.

https://docs.elementscompiler.com/Platforms/Cocoa/CpuArchitectures/
"""
x86_64 is the architecture of Intel's 64-bit CPUs, sometimes also simply referred to as x64. It is the architecture for all Intel Macs shipped
between 2005 and 2021.

arm64 is the architecture used by newer Macs built on Apple Silicon,
shipped in late 2020 and beyond.
"""

Generalized 64 bit would be a simple "64-bit". ARM specific would be, as
shown above, "arm64".

https://docs.microsoft.com/en-us/answers/questions/10614/what-is-the-difference-between-x64-and-arm64.html
https://www.quora.com/What-is-arm64-vs-x64

and this is NOT exclusive to Intel, Amd, Zilog, IBM etc.

So far the first three links from Google show the X-notation IS specific to Intel/AMD, and a different notation is used for ARM chips.
There are easily five more links making the same distinction (and one discussing the difference between ARM64 and AARCH64 -- mostly coming down
to which compiler back-end was used <G>).



--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Hello Shaun!

Monday February 28 2022 12:17, you wrote to me:

When I get a chance or have to shut the system down I will
install the SD card on the offchance the boot sequence will see
the card and load from it. Failing that I will disconnect the USB
link and try it - perhaps try that method first :)

I am confused. I was under the impression that your Pi was locking up *after* the boot process. Meaning, it has already started loading from
your USB device, and locked up while trying to load Ubuntu...

No, it locked up (no clock updating) after I loaded Terminal but looking yesterday it is just terminal that does nothing after loading - no keyed input,
cannot select anything from the menu bar etc.

I did a system update from the gui and after a minute where it shows the progress bar at around 2cm's worth it just - well shows no progress even after an hour with just occasional hit on the access light which is very hard to see - must be the smallest led available anywhere in the world :)
It really is a pin prick size which you can see at night with the room light off - just. Well it is made to a price - a low one :)


Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

No, it locked up (no clock updating) after I loaded Terminal but looking yesterday it is just terminal that does nothing after loading - no keyed input,
cannot select anything from the menu bar etc.

I did a system update from the gui and after a minute where it shows the progress bar at around 2cm's worth it just - well shows no progress even after an hour with just occasional hit on the access light which is very hard to see - must be the smallest led available anywhere in the world :) It really is a pin prick size which you can see at night with the room light off - just. Well it is made to a price - a low one :)

Hahaha! I feel you, there! (^_^)

But, you might need to blame your Argon enclosure for that. The bog-standard Pi4 enclosure doesn't interfere with the LEDs.

As others have mentioned, you should try to SSH (or VNC) into your Pi, and
make sure it's actually stalled, rather than just not responding to desktop.

To be clear, I've never tried to install Ubuntu on a Pi. I know a bit about Ubuntu, and a bit about the Pi, but I've never tried to combine the two.

I'm very interested in this, because I want to buy the Argon enclosure for my own Pi4. I am certain that your problem has nothing to do with Argon, though.
I think your problem is with Ubuntu, or at least with Ubuntu on a Pi.

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

nospam.Shaun.Buzza@f110.n229.z1.fidonet.org (Shaun Buzza) writes:

One thing I have noticed with the M.2 SSD is that when running
sudo fstrim -av it exits with the implied not finding a SSD so I have to
guess that the WD M.2 SSD is not being treated as a SSD and that is a
worry if there is no garbage collection taking place.

To be clear, any modern SSD performs its own garbage collection. You shouldn't have to use fstrim.

It’s more complicated than that. A physical page can be marked garbage
when the corresponding logical page is overwritten. But a logical page
that a filesystem stops using without overwriting (e.g. when deleting a
file) still appears to be in use to the controller, at until such as
time as the filesystem uses it for something else. fstrim or the discard
option supply the missing information.

Whether it’s worthwhile probably depends on access patterns.

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Mon, 28 Feb 2022 23:07:26 +0000, Richard Kettlewell wrote:

nospam.Shaun.Buzza@f110.n229.z1.fidonet.org (Shaun Buzza) writes:

One thing I have noticed with the M.2 SSD is that when running sudo
fstrim -av it exits with the implied not finding a SSD so I have to
guess that the WD M.2 SSD is not being treated as a SSD and that is a
worry if there is no garbage collection taking place.

To be clear, any modern SSD performs its own garbage collection. You
shouldn't have to use fstrim.

It’s more complicated than that. A physical page can be marked garbage
when the corresponding logical page is overwritten. But a logical page
that a filesystem stops using without overwriting (e.g. when deleting a
file) still appears to be in use to the controller, at until such as
time as the filesystem uses it for something else. fstrim or the discard option supply the missing information.

Whether it’s worthwhile probably depends on access patterns.

logwatch reports are a big help here.

I have an old Lenovo R61i that was fitted with a 128 GB Sandisk SSD when
its original 120GB HDD died.

These days it mostly just runs protein folding software. Apart from that, there's a weekly rsync backup followed by a Fedora update, so this
workload is making what I'd call low use of the SSD. The weekly smartd
report shows that the SSD has been active 1-2 hours per week, confirming
low usage.

Yet the weekly fstrim run usually reports its added a little over 1GB of storage space to the free blocks list. To me that shows that the weekly
fstrim run is worthwhile, but running it more frequently is probably not
worth the effort of retiming the cron job to run it more frequently.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

It’s more complicated than that. A physical page can be marked garbage when the corresponding logical page is overwritten. But a logical page that a filesystem stops using without overwriting (e.g. when deleting a file) still appears to be in use to the controller, at until such as
time as the filesystem uses it for something else. fstrim or the discard option supply the missing information.

You're correct, sir. It is definitely more complicated than my simplified explanation. Hence why I simplified it.

But you make a good point! I normally add 'discard' on any SSD in my fstab,
on a PC. So much so, that I didn't even think about that. I need to check my own Pi to see if I'm using that on its SSD...

Vincent, if you didn't know: /etc/fstab is where (Debian) Linux stores its
info about storage space. Literally, 'File System TABlature'. This applies to Ubuntu, and PiOS too. There's a whole bunch of stuff you should know before attempting to edit /etc/fstab though. One can easily brick a system with a
typo in that file.

However, none of this information will help get Ubuntu to work with a Pi...Richard...

(o_O)

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

Hello Shaun!

Monday February 28 2022 19:28, you wrote to Richard Kettlewell:

But you make a good point! I normally add 'discard' on any SSD in my
fstab, on a PC. So much so, that I didn't even think about that. I
need to check my own Pi to see if I'm using that on its SSD...

Vincent, if you didn't know: /etc/fstab is where (Debian) Linux stores
its info about storage space. Literally, 'File System TABlature'. This applies to Ubuntu, and PiOS too. There's a whole bunch of stuff you
should know before attempting to edit /etc/fstab though. One can
easily brick a system with a typo in that file.

However, none of this information will help get Ubuntu to work with a Pi...Richard...

Can you provide the o/p from a cat /etc/fstab where you are using the discard sub command.

Thanks,


That said I have not found a reason why running sudo fstrim -av does not pick up that a SSD is present.

I have been using SSD's for some years and after trying Crucial branded versions that cause serious problems switched (having had advise from Linux users) to Samsung 850/950/960 series over the years.
These unlike Crucial use a fair better device controller that processes garbage
collections within the controller without requiring the system being idle for long periods. A totally better class of SSD.

That is not to say I have not had snags with them but always not running fstrim
often enough when there has been a lot of files being stored on them during the
day. Remember it is not just the initial storing of files but also any files that are updated where the current clusters are replaced with new one's and that of course includes coping data from one location to another. I was about to including moving them but technically that should not affect anything as
the file details are not changed only the location holding the file record although that does change one cluster.

I do know (but not why) that if I download a large number of files to a HDD mounted as /mnt/disk1 where the SSD is at / that for some reason the system stores the data on a SSD before moving it to the HDD.

That one has got me beat as to the reason why.
Needless to say running fstrim twice a day resolves the problem providing I keep below 1 Tb of loaded files at any one time.

These are loaded via a large USB stick directly on the box.

Again nothing here explains why running fstrim on the Pi does not result in the
expected display from the program unless it is just NOT finding the SSD so the question arises as to what is different with a SSD as a M.2 2280 mount ?

I should point out that I have been in IT since 1963 with M/F's, mini's, etc., and in micros since 1974/5 and building micro based systems since 1976 and with
Linux since 1997 (*nix systems the late 70's) or so since giving up on OS/2 when IBM did, having replaced it with Linux for running my server platforms that also run a BBS among other services 24/7.

My wife's and the various laptop devices around the house, I stick to Windows 10 and 11 but there again if they fail it is not difficult to fix one way or another, but I do not use in un-secure environments even when taking one on holiday / vacation etc to act as a back up system for my photography using large cameras althoug I might, just might check on my house system using a hotels wi-fi services having switched the laptop to very high security if not already so set up.

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Vincent Coen <nospam.Vincent.Coen@f1.n250.z2.fidonet.org> wrote:

Again nothing here explains why running fstrim on the Pi does not result in the expected display from the program

https://lemariva.com/blog/2020/08/raspberry-pi-4-ssd-booting-enabled-trim

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Can you provide the o/p from a cat /etc/fstab where you are using the discard sub command.

Thanks,

I'll send you the fstab from my laptop in netmail. It's running Linux Mint, another Debian-based OS. Give me a bit to get around to that...

That said I have not found a reason why running sudo fstrim -av does not pick up that a SSD is present.

I have been using SSD's for some years and after trying Crucial branded versions that cause serious problems switched (having had advise from Linux users) to Samsung 850/950/960 series over the years.
These unlike Crucial use a fair better device controller that processes garbage
collections within the controller without requiring the system being
idle for long periods. A totally better class of SSD.

Oh, I agree with you there! Samsung SSDs in general are better performers
that most of the competition. There's a reason they can get away with
charging a premium.

I do know (but not why) that if I download a large number of files to a HDD mounted as /mnt/disk1 where the SSD is at / that for some reason the system stores the data on a SSD before moving it to the HDD.

Sounds like your OS is cacheing the data before sending it to the HDD. I'm
not sure why it would do so by default, though. Perhaps through SWAP? Are you copying more data than would fit in RAM?

These are loaded via a large USB stick directly on the box.

Again nothing here explains why running fstrim on the Pi does not result in the
expected display from the program unless it is just NOT finding the SSD
so the question arises as to what is different with a SSD as a M.2 2280 mount ?

It could be that the Pi is mistaking it for a USB stick? After all, you're
not actually using SATA or PCI-Ex to connect.

I should point out that I have been in IT since 1963 [...]

I certainly haven't been working with computers for as long as you have.
Heck, even my dad would only have been...six? eight?...in '63! (^_^)

But I've been a 'computer guy' my entire life. I put my entire academic effort into learning anything I could about them. I even owned a 'boutique' computer shop for a while. I was never much for datacenter work, though.

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

Hello A!

Tuesday March 01 2022 18:36, you wrote to me:

Vincent Coen <nospam.Vincent.Coen@f1.n250.z2.fidonet.org> wrote:

Again nothing here explains why running fstrim on the Pi does not
result in the expected display from the program

https://lemariva.com/blog/2020/08/raspberry-pi-4-ssd-booting-enabled-t
rim

The first test failed as I only have via df :

/dev/root /
/dev/sda1 /boot

Yes there are lines between these two.

I left a message about it on the website.

May be buying a Argon one M.2 case was a mistake but I could not work out what was needed with a geekworm solution case and SSD board wise.

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Hello Shaun!

Tuesday March 01 2022 15:58, you wrote to me:

Can you provide the o/p from a cat /etc/fstab where you are using
the discard sub command.

Thanks,

I'll send you the fstab from my laptop in netmail. It's running Linux
Mint, another Debian-based OS. Give me a bit to get around to that...

That said I have not found a reason why running sudo fstrim -av
does not pick up that a SSD is present.

I have been using SSD's for some years and after trying Crucial
branded versions that cause serious problems switched (having had
advise from Linux users) to Samsung 850/950/960 series over the
years. These unlike Crucial use a fair better device controller
that processes garbage collections within the controller without
requiring the system being idle for long periods. A totally
better class of SSD.

Oh, I agree with you there! Samsung SSDs in general are better
performers that most of the competition. There's a reason they can get
away with charging a premium.

I do know (but not why) that if I download a large number of
files to a HDD mounted as /mnt/disk1 where the SSD is at / that
for some reason the system stores the data on a SSD before moving
it to the HDD.

Sounds like your OS is cacheing the data before sending it to the HDD.
I'm not sure why it would do so by default, though. Perhaps through
SWAP? Are you copying more data than would fit in RAM?

These are loaded via a large USB stick directly on the box.

Again nothing here explains why running fstrim on the Pi does not
result in the expected display from the program unless it is just
NOT finding the SSD so the question arises as to what is
different with a SSD as a M.2 2280 mount ?

It could be that the Pi is mistaking it for a USB stick? After all,
you're not actually using SATA or PCI-Ex to connect.

I should point out that I have been in IT since 1963 [...]

I certainly haven't been working with computers for as long as you
have. Heck, even my dad would only have been...six? eight?...in '63!
(^_^)

But I've been a 'computer guy' my entire life. I put my entire
academic effort into learning anything I could about them. I even
owned a 'boutique' computer shop for a while. I was never much for datacenter work, though.

From around 1976 I was running a company inporting and distributing micro Books, Magazines and software running on CPM, MPM, Cromix (*nix) for Cromemco's
and some hardware. This was mostly imported from the US which I feighted over by air after a cargo consolidation each month (normally) any ways around 1978 business man starting up a shop called The Byte Shop asked me to run it for him
and I agreed after he accepted that it would buy from my company products that I sold and distributed at a 40% discount assuming prompt payments and I would get a basic salary of around 5k but be on a 20% bonus for every item sold.

Good deal as it gave me around a 40% total commission on item I imported and sold in the shop and to give you a wee hint - We were opened Monday through Saturday but were so busy I never had the time to do the paper work in full.

So I would go in Sunday morning around 08:00 or so most often or not moving the
paper work etc into the shop desk to wrok on it all.
Wee I started to people knocking on the door to be let in so in the end I just opened up once I got a coffee. Now one of the products sold was a Commodore Pet and the first one was a one piece unit with screen and keyboard and during the week would sell at a guess around 100 or more.

Once I opened on a Sunday I sold anywhere from 50 to 100+ between opening time and 13:00 when I closed the door to do the paper work which was increased with the sales - OTher products was also sold during this time frame including magazines, books games etc.

I made more money in bonuses / commission etc that the rest of the week - it was slightly embarrassing - OK, only a little but after a year or so the owner wanted me to quit and as my company was getting busy i.e, turnover well over 1M
I left. Money want towards my commercial pilots licences and aircraft hire both
singles and twins etc with lots of change.

Within one year the Byte shop opened 3 - 4 outlets but with in 3 or so they all
folded and a few more years so did my company - too much competition for the bread and butter trade. Needless to say within a month of us shutting down
the competition folder - so I might have been able to continue but it was too late by then. I have cut a long story short here .

During all this time period I was still doing mainframe and micro programming and system design etc just to keep the wolf from the door and keep in current practice - bit like flying really but made up for it when it all closed down by
doing well over 500 hours per year - well over as was doing some 500+ hours just for my private flying let alone the flight instructing and commercial work
on a wide range of a/c from singles, twin, heavies with the occasional military
flight, etc.

I wonder now, how I found the time :)

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

On 01-03-2022 12:34, Vincent Coen wrote:

Tuesday March 01 2022 18:36, you wrote to me:

https://lemariva.com/blog/2020/08/raspberry-pi-4-ssd-booting-enabled-trim

The first test failed as I only have via df :

/dev/root /
/dev/sda1 /boot

I don't know what "first test" you're talking about. Those mounting
points look normal. Maybe this more recent version is easier to follow
for you: https://www.jeffgeerling.com/blog/2020/enabling-trim-on-external-ssd-on-raspberry-pi

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Hello A!

Wednesday March 02 2022 07:32, you wrote to me:

On 01-03-2022 12:34, Vincent Coen wrote:

Tuesday March 01 2022 18:36, you wrote to me:

https://lemariva.com/blog/2020/08/raspberry-pi-4-ssd-booting-enable
d-trim

The first test failed as I only have via df :

/dev/root /
/dev/sda1 /boot

I don't know what "first test" you're talking about. Those mounting
points look normal. Maybe this more recent version is easier to follow
for you: https://www.jeffgeerling.com/blog/2020/enabling-trim-on-external-ssd-o n-raspberry-pi

Following that post and rebooting has fixed it, many thanks.
This was using a Argon one M.2 pi 4B case with a WD 240 GB SSD with a M.2 interface that is NON NVME but a M.2 Key B (Sata ?), so nowhere as fast as MVME.

I have NOT enabled a weekly auto run of fstrim and will run it as and when, as currently I only have the box running some times, but as I want to install :

gnucobol compiler
mbse Bulletin board system as a back up system running two special program/s that will mean it will be on 24/7 connected to the intenet via a firewall port forwarding link.

After that#s up and running I will do a weekly fstrim as file creation should be
fairly low allowing for system updates etc.

Thanks again for the help, that's one less problem to deal with.
Now to find out why I am getting 'can't find libraries' message when building the compiler..

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)