Pi 4B problem

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

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

-=> Shaun Buzza wrote to Dan Clough <=-

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.

SB> Sorry, sir, but that is incorrect. The Pi4B's processor is indeed SB> capable of 64-bit operation. There's also a 64-bit version of SB> 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.

SB> However, I agree that there may be some incompatibility with SB> Ubuntu, as it was primarily designed for x86_64, and not SB> 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.

SB> Didn't Ubuntu make a mobile version in the past, though? I wonder SB> 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

RK> x64 means the same as x86-64. However the OP is probably just RK> misreporting and really used an arm64 install. x86-64 would simply not RK> 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

DC> DC> I would guess that it's because of "X64". Surprised it even installe DC> DC> The RPi is an ARM processor and not capable of 64 bit X64, I believe. DC> DC> SB> Sorry, sir, but that is incorrect. The Pi4B's processor is indeed DC> SB> capable of 64-bit operation. There's also a 64-bit version of DC> SB> PiOS. DC> DC> Sorry, you're incorrect. Nowhere did I say that the RPi4's processor DC> isn't capable of 64-bit operation. I said (look right up there above) DC> 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:

DC> SB> However, I agree that there may be some incompatibility with DC> SB> Ubuntu, as it was primarily designed for x86_64, and not DC> SB> armhf_64. DC> DC> Yes, and the OP stated that he installed "Ubuntu X64". Again I say that DC> it's surprising that it even installed. It probably did NOT install DC> 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.

DC> SB> Didn't Ubuntu make a mobile version in the past, though? I wonder DC> SB> if that is armhf-compatible... DC> DC> I don't know, and that is irrelevant to this thread, as he didn't say he DC> 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

NY> Is there anything in the source code of Ubuntu (or any other flavour of NY> Linux) which, when compiled, makes it run better on x86_64 than armhf_64 NY> (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.

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

NY> I would have thought that little/big endian would have been the main NY> 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.

NY> I have NY> "fond" memories many years ago of having to go through loads of C source NY> code (*), looking for any code which *assumed* that the high byte of an NY> int would always follow rather than precede the low byte in data NY> structures, and insert #ifdefs with a macro to reverse the bytes - this NY> was for source code that was designed for Intel which we also wanted to NY> 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

Hello Dan!

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

VC>> Hello All!

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

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

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

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

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

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

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

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

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

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

Vincent

Hello Shaun!

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

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

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

Hello druck!

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

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

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

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.

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

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

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 > DC> DC> I would guess that it's because of "X64". Surprised it even installe

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

---druck

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

[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]

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.

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.

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

Plenty.

Another possible thing to try is this:

*think* Ubuntu on the Pi is using GRUB like other platforms - that 'e' keystroke is when you're in GRUB)

Theo

Hello Anssi!

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

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 Tools 3.4.2.5 draklive2 3.4.2.6 PCMemTest 3.5 Base system 3.5.1 Kernel and hardware support 3.5.2 Graphic drivers 3.5.2.1 X Window System (X11) 3.5.2.2 AMD video drivers 3.5.2.3 NVIDIA drivers 3.5.2.3.1 Proprietary NVIDIA driver 3.5.2.3.2 Optimus laptops 3.5.3 Bootloaders 3.6 Desktop environments 3.6.1 Plasma 3.6.2 GNOME 3.6.3 LXDE 3.6.4 Xfce 3.6.5 LXQt 3.6.6 MATE 3.6.7 Cinnamon 3.6.8 Enlightenment 3.6.9 Light window managers 3.6.9.1 IceWM 3.7 Office apps 3.8 Internet apps 3.9 Multimedia apps 3.10 Editors 3.11 Games 3.12 Education 3.13 Software Development 3.13.1 Compilers and tools 3.13.2 Virtualization stack 3.13.2.1 VirtualBox 3.13.3 Language stacks 3.14 Server applications 3.14.1 Nginx 3.14.2 Nextcloud 4 Upgrading from Mageia 7 4.1 Preparations 4.2 Upgrading via the Internet 4.2.1 Upgrading online, using mgaonline (GUI) 4.2.2 Upgrading online, using urpmi (CLI) 4.2.3 Upgrading online, using DNF (CLI) 4.3 Using the traditional Mageia 8 DVD to Upgrade 4.3.1 Upgrading an encrypted install 5 Known issues 5.1 User action needed 5.1.1 VeraCrypt 5.2 Bugs 5.2.1 Bug reporting 6 Packages removed from the distribution 6.1 Without removal on upgrade 6.2 With removal on upgrade

--

Any of these hiding some where ?

Vincent

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.

On Thu, 24 Feb 2022 21:13:03 +1200, snipped-for-privacy@f110.n.z1.fidonet.org (Shaun Buzza) declaimed the following:

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