This is cause calamares is not starting. So user account creation is absent from unstable images until calamares is fixed.
Thanks for your detailed answer.
I saw a new arm testing update, nice, I hope a stable one for arm and x86, Iām worried for some issues.
Hello, I typed pacman -Qi abseil-cpp on my Raspberry Pi 4b device and found that the abseil-cpp version is 2023. I am using the Manjaro system, and pacman -Syu seems that the Manjaro system is not the latest. I want to know if the abseil-cpp package has been updated in Manjaro ARM?
Unstable branch has a newer version but seeing some weird report on it. Looks like a rebuild for some reason
Version : 20240116.2-1
Build Date : Sat 04 May 2024 01:34:19 AM CDT
Hi, I am new here and donāt know where to post.
It seems like CVE-2024-6387 - regreSSHion is already fixed for x86 but my rpi4 with arm64 kernel is not getting any security updates?
What is the status of that port, is it still supported?
you might grab from Alarm repos, or wail months later.
No you cannot. The package from ALARM cannot be installed on Manjaro ARM stable. The package will install, but sshd
will not start. It requires a newer glibc
version.
You can use the following to compile the latest xz on your device:
#update and install compile tools
sudo pacman -Syu base-devel
#clone upstream package build
git clone https://gitlab.archlinux.org/archlinux/packaging/packages/xz.git
cd xz
#skip hash checks (when downloading from github, the hash changes)
sed -i 's/^sha/#sha/' PKGBUILD
echo "sha256sums=('SKIP')">>PKGBUILD
#locally trust the pgp key from the upstream software maintainer (or, alternatively, skip the pgp check with --skippgpcheck in the makepkg command below):
gpg --receive-keys 3690C240CE51B4670D30AD1C38EE757D69184620
#compile with the following options:
#A: skip architecture check (allow compile on architectures other than x86_64)
#s: download missing dependencies
#i: install when finished
makepkg -Asi
xz
is not the issue here, the version of xz
in stable does not have the backdoor.
The issue here is a security bug in OpenSSH itself. (One that was already fixed at one point, but the bug was accidentally reintroduced, hence āregreSSHionā.)
Ah, youāre right.
Same instructions but for openssh
:
#update and install compile tools
sudo pacman -Syu base-devel --needed
#clone upstream package build
git clone https://gitlab.archlinux.org/archlinux/packaging/packages/openssh.git
cd openssh
#locally trust the pgp key from the upstream software maintainer (or, alternatively, skip the pgp check with --skippgpcheck in the makepkg command below):
gpg --receive-keys 7168B983815A5EEF59A4ADFD2A3F414E736060BA
#compile with the following options:
#A: skip architecture check (allow compile on architectures other than x86_64)
#s: download missing dependencies
#i: install when finished
makepkg -Asi
Hi,
Inixi is up to date on stable branch :-)
[n2@nls ~]$ sudo pacman -Syu
[sudo] password for n2:
:: Synchronising package databases...
core 265,7 KiB 886 KiB/s 00:00 [#######################################################] 100%
extra 9,3 MiB 17,2 MiB/s 00:01 [#######################################################] 100%
community 29,0 B 138 B/s 00:00 [#######################################################] 100%
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
Packages (1) inxi-3.3.36.1-1
Total Download Size: 0,36 MiB
Total Installed Size: 1,33 MiB
Net Upgrade Size: 0,02 MiB
:: Proceed with installation? [Y/n] y
:: Retrieving packages...
inxi-3.3.36.1-1-any 366,7 KiB 3,58 MiB/s 00:00 [#######################################################] 100%
(1/1) checking keys in keyring [#######################################################] 100%
(1/1) checking package integrity [#######################################################] 100%
(1/1) loading package files [#######################################################] 100%
(1/1) checking for file conflicts [#######################################################] 100%
(1/1) checking available disk space [#######################################################] 100%
:: Processing package changes...
(1/1) upgrading inxi [#######################################################] 100%
New optional dependencies for inxi
bluez-deprecated-tools: hciconfig: -E bluetooth data (deprecated, good report)
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...
[n2@nls ~]$ fastfetch
##### n2@nls
####### ------
##O#O## OS: Manjaro ARM aarch64
####### Host: Hardkernel ODROID-N2
########### Kernel: 6.7.9-1-MANJARO-ARM
############# Uptime: 20 days, 14 hours, 37 mins
############### Packages: 1011 (pacman)[arm-stable]
################ Shell: bash 5.2.26
################# Display (Mi TV): 1920x1080 @ 60Hz
##################### DE: KDE Plasma 5.27.10
##################### WM: KWin (X11)
################# WM Theme: plastik
Theme: Breeze (Light_nl) [QT], Breeze [GTK3/4]
Icons: oxygen [QT], oxygen [GTK2/3/4]
Font: Noto Sans (10pt) [QT], Noto Sans (10pt) [GTK2/3/4]
Cursor: Breeze_Snow (24px)
Terminal: konsole 23.8.5
CPU: Cortex-A53 + Cortex-A73 (6) @ 1,99 GHz
GPU: Mali-G52 (Panfrost)
Memory: 1,23 GiB / 3,58 GiB (34%)
Swap: 453,50 MiB / 5,37 GiB (8%)
Disk (/): 24,03 GiB / 56,79 GiB (42%) - ext4
Local IP (eth0): 192.168.0.50/24 *
Locale: en_GB.UTF-8
[n2@nls ~]$
Moderator edit: In the future, please use proper formatting: [HowTo] Post command output and file content as formatted text
Are there any plans to update the stable
branch? It has now been 6 months (to the day) that stable
was last updated (except for the callaudiod
update 6 days later and the occasional inxi
updates). That is as long as the fastest non-rolling distributions take to prepare a new release. But unlike the current Manjaro stable
, those distributions provide bugfix and security updates for the current release.
Hi,
Nice to read you.
The last unstable up date are looking good for the future stable up date, I built images for the Odroid c2 && odroid c4, the devices are working, more details here
I hope to test asap the Odroid n2 && Odroid m1
I did the tests on the devices listed above.
How can we update the new manjaro-keyring
alarm@rock-5b:~$ sudo pacman -Sy archlinux-keyring manjaro-keyring
[sudo] password for alarm:
:: Synchronizing package databases...
core is up to date
extra is up to date
community is up to date
warning: archlinux-keyring-20240208-1 is up to date -- reinstalling
warning: manjaro-keyring-20230719-2 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...
Packages (2) archlinux-keyring-20240208-1 manjaro-keyring-20230719-2
Total Installed Size: 1.75 MiB
Net Upgrade Size: 0.00 MiB
Since On Arm64, we are using gcc version 12.1.0 and latest .gcc version 14.01
Appears to me you are up to date with the stable branch. The latest toolchain versions will be on our unstable branch. It is more in line with the versions arch-arm has. Being that the stable branch has not been updated in 7 months and your device, I have no clue if switching to the unstable branch would be successful or not as not all devices has been tested with the program versions in the unstable branch.
The linux kernel (6.9.3) on the unstable branch is 4 months old so it may be pretty close to what you have. You could build an test image off the unstable branch and see if it boots.
How can I switch to an unstable branch?
Hi,
Switching branch
Or
||
Build an unstable image, the devices I own on unstable are running well
Hi, thanks for the info and the link ā I just noticed the link now.
So far, Iāve done it like this without any issues:
sudo pacman-mirrors -aS unstable && sudo pacman-mirrors --fasttrack && sudo pacman -Syu
or back to stable:
sudo pacman-mirrors -aS stable && sudo pacman-mirrors --fasttrack && sudo pacman -Syu
Sometimes, there are multiple ways to reach the goal. Are there any concerns with this commands, or doesnāt it matter?