• Pi 4B problem

    From Vincent Coen@2:250/1 to All on Wed Feb 23 22:50:17 2022
    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)
  • From Dan Clough@1:123/115 to Vincent Coen on Wed Feb 23 20:37:00 2022
    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)
  • From Shaun Buzza@1:229/110 to Dan Clough on Thu Feb 24 09:53:18 2022
    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)
  • From Richard Kettlewell@3:770/3 to Shaun Buzza on Thu Feb 24 15:28:30 2022
    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)
  • From Andy Burns@3:770/3 to Shaun Buzza on Thu Feb 24 15:40:28 2022
    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)
  • From Dan Clough@1:123/115 to Shaun Buzza on Thu Feb 24 10:46:00 2022
    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)
  • From Shaun Buzza@1:229/110 to Richard Kettlewell on Thu Feb 24 12:50:00 2022
    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)
  • From Shaun Buzza@1:229/110 to Dan Clough on Thu Feb 24 13:01:24 2022
    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)
  • From Jim Jackson@3:770/3 to Shaun Buzza on Thu Feb 24 19:50:11 2022
    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)
  • From druck@3:770/3 to Vincent Coen on Thu Feb 24 20:08:13 2022
    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)
  • From NY@3:770/3 to Shaun Buzza on Thu Feb 24 21:31:33 2022
    "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)
  • From Theo@3:770/3 to Vincent Coen on Thu Feb 24 22:45:21 2022
    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)
  • From Shaun Buzza@1:229/110 to NY on Thu Feb 24 21:13:03 2022
    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)
  • From Vincent Coen@2:250/1 to Dan Clough on Fri Feb 25 02:19:26 2022
    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)
  • From Vincent Coen@2:250/1 to Shaun Buzza on Fri Feb 25 02:32:35 2022
    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)
  • From Vincent Coen@2:250/1 to druck on Fri Feb 25 02:39:45 2022
    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)
  • From Vincent Coen@2:250/1 to All on Fri Feb 25 02:42:34 2022
    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)
  • From Anssi Saari@3:770/3 to Vincent Coen on Fri Feb 25 17:11:39 2022
    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)
  • From Dennis Lee Bieber@3:770/3 to All on Fri Feb 25 11:47:42 2022
    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)
  • From Dennis Lee Bieber@3:770/3 to All on Fri Feb 25 11:58:50 2022
    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)
  • From Lew Pitcher@3:770/3 to Dennis Lee Bieber on Fri Feb 25 17:16:51 2022
    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)
  • From scott@alfter.diespammersdie.us@3:770/3 to Shaun Buzza on Fri Feb 25 18:36:52 2022
    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)
  • From Vincent Coen@2:250/1 to Anssi Saari on Fri Feb 25 20:18:21 2022
    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
  • From Theo@3:770/3 to Vincent Coen on Fri Feb 25 22:23:04 2022
    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)
  • From A. Dumas@3:770/3 to Vincent Coen on Sat Feb 26 08:27:48 2022
    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)
  • From A. Dumas@3:770/3 to A. Dumas on Sat Feb 26 08:30:37 2022
    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)
  • From Tristan Greaves@2:250/11 to A. Dumas on Sat Feb 26 10:47:46 2022
    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)
  • From Vincent Coen@2:250/1 to All on Sat Feb 26 14:45:15 2022
    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)
  • From A. Dumas@3:770/3 to Vincent Coen on Sat Feb 26 15:32:27 2022
    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)
  • From Vincent Coen@2:250/1 to A. Dumas on Sat Feb 26 18:03:32 2022
    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)
  • From Vincent Coen@2:250/1 to A. Dumas on Sat Feb 26 19:10:50 2022
    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)
  • From NY@3:770/3 to Shaun Buzza on Sat Feb 26 21:48:59 2022
    "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)
  • From NY@3:770/3 to Dennis Lee Bieber on Sat Feb 26 21:57:06 2022
    "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)
  • From NY@3:770/3 to scott@alfter.diespammersdie.us on Sat Feb 26 22:04:22 2022
    <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)
  • From TimS@3:770/3 to me@privacy.invalid on Sat Feb 26 22:16:31 2022
    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)
  • From TimS@3:770/3 to me@privacy.invalid on Sat Feb 26 22:17:48 2022
    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)
  • From Computer Nerd Kev@3:770/3 to me@privacy.invalid on Sat Feb 26 22:33:51 2022
    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)
  • From Dennis Lee Bieber@3:770/3 to All on Sat Feb 26 19:07:37 2022
    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)
  • From Theo@3:770/3 to me@privacy.invalid on Sun Feb 27 10:49:24 2022
    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)
  • From Richard Kettlewell@3:770/3 to Theo on Sun Feb 27 13:14:23 2022
    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)
  • From Martin Gregorie@3:770/3 to All on Sun Feb 27 13:35:45 2022
    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)
  • From The Natural Philosopher@3:770/3 to Vincent Coen on Sun Feb 27 13:32:35 2022
    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)
  • From The Natural Philosopher@3:770/3 to TimS on Sun Feb 27 13:22:14 2022
    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)
  • From TimS@3:770/3 to All on Sun Feb 27 13:55:06 2022
    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)
  • From The Natural Philosopher@3:770/3 to TimS on Sun Feb 27 14:09:18 2022
    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)
  • From TimS@3:770/3 to All on Sun Feb 27 13:57:02 2022
    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)
  • From Vincent Coen@2:250/1 to The Natural Philosopher on Sun Feb 27 14:39:46 2022
    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)
  • From Ahem A Rivet's Shot@3:770/3 to TimS on Sun Feb 27 14:36:49 2022
    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)
  • From druck@3:770/3 to Vincent Coen on Mon Feb 28 09:58:43 2022
    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)
  • From Ahem A Rivet's Shot@3:770/3 to druck on Mon Feb 28 10:03:51 2022
    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)
  • From Vincent Coen@2:250/1 to druck on Mon Feb 28 16:08:55 2022
    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)
  • From Shaun Buzza@1:229/110 to Theo on Mon Feb 28 12:10:10 2022
    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)
  • From Shaun Buzza@1:229/110 to Vincent Coen on Mon Feb 28 12:17:48 2022
    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)
  • From Shaun Buzza@1:229/110 to A. Dumas on Mon Feb 28 12:21:18 2022
    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)
  • From Shaun Buzza@1:229/110 to Vincent Coen on Mon Feb 28 12:29:48 2022
    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)
  • From Shaun Buzza@1:229/110 to Vincent Coen on Mon Feb 28 12:37:41 2022
    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)
  • From Dennis Lee Bieber@3:770/3 to All on Mon Feb 28 12:54:02 2022
    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)
  • From Vincent Coen@2:250/1 to Shaun Buzza on Mon Feb 28 17:55:07 2022
    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)
  • From Shaun Buzza@1:229/110 to Vincent Coen on Mon Feb 28 15:29:34 2022
    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)
  • From Richard Kettlewell@3:770/3 to Shaun Buzza on Mon Feb 28 23:07:26 2022
    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)
  • From Martin Gregorie@3:770/3 to Richard Kettlewell on Mon Feb 28 23:47:06 2022
    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)
  • From Shaun Buzza@1:229/110 to Richard Kettlewell on Mon Feb 28 19:28:12 2022
    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)
  • From Vincent Coen@2:250/1 to Shaun Buzza on Tue Mar 1 17:37:38 2022
    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)
  • From A. Dumas@3:770/3 to Vincent Coen on Tue Mar 1 18:36:12 2022
    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)
  • From Shaun Buzza@1:229/110 to Vincent Coen on Tue Mar 1 15:58:57 2022
    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)
  • From Vincent Coen@2:250/1 to A. Dumas on Tue Mar 1 23:34:32 2022
    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)
  • From Vincent Coen@2:250/1 to Shaun Buzza on Tue Mar 1 23:39:52 2022
    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)
  • From A. Dumas@3:770/3 to Vincent Coen on Wed Mar 2 07:32:32 2022
    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)
  • From Vincent Coen@2:250/1 to A. Dumas on Wed Mar 2 16:54:26 2022
    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)