[ARM Unstable Update] 2021-12-31 Python 3.10, Boost 1.78 and Protobuf 3.19.1

ARM Unstable Updates
,
21

Here’s something you can try.

See if you have a /etc/X11/xorg.conf.d/panfrost.conf file.

If you do, try changing the line that says:

    Option      "AccelMethod"    "none"     ### "glamor" to enable 3D acceleration, "none" to disable.

to

    Option      "AccelMethod"    "glamor"     ### "glamor" to enable 3D acceleration, "none" to disable.

and save the file.

If you do not have that file, try creating it, with this contents:

Section "Device"
    Identifier  "Default Device"
    Driver      "modesetting"
    Option      "AccelMethod"    "none"     ### "glamor" to enable 3D acceleration, "none" to disable.
EndSection

Section "ServerFlags"
        Option  "AutoAddGPU" "off"
        Option "Debug" "dmabuf_capable"
EndSection

Section "OutputClass"
        Identifier "Panfrost"
        MatchDriver "meson"
        Driver "modesetting"
        Option "PrimaryGPU" "true"
EndSection
22

@Strit,
Thanks. I did that earlier and switch to Gnome-Xorg session, still the same issue – NO GPU HW Acceleration with mesa 21.3.3-2 or earlier with mesa 21.3.2 both from Unstable Branch.

FYI, on Gnome-Wayland session it should default to GPU HW Acceleration. Not happening either with mesa 21.3.3-2 or mesa 21.3.2.

I am on Manjaro-Arm-Gnome Stable Branch does that make any difference. Mesa 21.2.5-1 GPU HW Acceleration is Enabled on Wayland and Xorg Session.

23

manjaro-arm-installer while installing for rpi4 (plasma + btrfs):

(648/648) installing rpi4-post-install                                                                                    [#########################################################################] 100%
Configuration file /usr/lib/systemd/system/attach-bluetooth.service is marked executable. Please remove executable permission bits. Proceeding anyway.
Created symlink /etc/systemd/system/multi-user.target.wants/attach-bluetooth.service → /usr/lib/systemd/system/attach-bluetooth.service.
Created symlink /etc/systemd/system/multi-user.target.wants/stop-dmesg.service → /usr/lib/systemd/system/stop-dmesg.service.
Editing mkinitcpio.conf...
Editing cmdline.txt...
/usr/sbin/sed: can't read /boot/cmdline.txt: No such file or directory
/usr/sbin/sed: can't read /boot/cmdline.txt: No such file or directory
Editing config.txt...

At the end:

Correcting permissions from overlay...
  -> Adding btrfs support to system...
  -> Cleaning install for unwanted files...
==> rpi4 kde-plasma install complete
==> Writing bootloader and cleaning up after install...
  -> Set boot partition to 284cc716-01 in /etc/fstab...
  -> Set root partition to 284cc716-02 in the relevant boot script and /etc/fstab...
===> Installing default btrfs RPi cmdline.txt /boot...
===> Installing default config.txt file to /boot/...
  -> If you get an error stating 'failed to preserve ownership ... Operation not permitted', it's expected, since the boot partition is FAT32 and does not support ownership permissions...
==> Time : 36.30 minutes...

Here is references new cmdline.txt and config.txt. So whatever the SEDs were attempting to do for cmdline.txt, it was overwritten anyway. So maybe it is not an error after all.

24

Just a feedback. The mesa 21.3.3-1 from Debian Sid works on Debian Bullseye. Not sure it helps.

25

Yeah, the rpi4-post-install tries to edit files that is not created yet, so it fails. I need to fix that.

26

$ sudo mkinitcpio -P

==> Building image from preset: /etc/mkinitcpio.d/linux515.preset: 'default'
  -> -k /boot/vmlinuz-5.15-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-5.15-x86_64.img
==> Starting build: 5.15.12-1-MANJARO
  -> Running build hook: [base]
  -> Running build hook: [udev]
  -> Running build hook: [autodetect]
  -> Running build hook: [modconf]
  -> Running build hook: [block]
  -> Running build hook: [keyboard]
  -> Running build hook: [keymap]
can't open `compose', because kbdfile already opened: compose
syntax error, unexpected ERROR
  -> Running build hook: [consolefont]
==> WARNING: consolefont: no font found in configuration
  -> Running build hook: [resume]
  -> Running build hook: [filesystems]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-5.15-x86_64.img
==> Image generation successful

Looks like a something in the keymap hook.

27

Either that, or in consolefont (which is not in our defaults, so you added that?

Also, you are running an x86_64 device there. :wink: Not related to this thread.

28

Oops, sorry about the x86_64… I have too many computers.

And I can not recreate the error… please disregard this completely.

29

With today’s unstable update. I could be wrong, but I believe this is the second time I have seen this sed error:

:: Processing package changes...
(1/1) upgrading manjaro-system                                           [#########################################] 100%
warning: directory permissions differ on /etc/sudoers.d/
filesystem: 750  package: 755
sed: can't read /home/*/.local/share/konsole/Profile 1.profile: No such file or directory
:: Running post-transaction hooks...

The file does exist and is a readable text file. I suspect the sed file parameter needs a \ in front of the space:
/home/*/.local/share/konsole/Profile\ 1.profile

Edit: manjaro-system-20220111-1-any

Edit 2: I have no idea why or how the sed commands runs. Maybe it is pacman related? It is not in the manjaro-system package and it executes just before the hooks. And it did not run during the subsequent update of new packages… or at least no error message. I was looking at the x86_64 package, not the arm64 package… the sed is in the manjaro-system-update.sh file.

And what causes the manjaro-system package to update before the other packages?

30

I guess that following line in /etc/pacman.conf:

SyncFirst = manjaro-system manjaro-keyring manjaro-arm-keyring archlinux-keyring archlinuxarm-keyring

1 Like
31

Ah yes, thank you. I knew that at one time, old age. :slight_smile:

32

Good catch. Fixed in todays update!

33

When build the initramfs, maybe missing a dependency?

==> ERROR: binary dependency `libreiserfscore.so.0' not found for `/usr/bin/btrfs-convert'
34

That would be reiserfsprogs, not sure why though. I haven’t seen that error before.

According to the Arch Linux package page, it’s an optional dependency of btrfs-progs for, you guessed it, btrfs-convert. But it’s been that for 2 years. So wonder what’s changed…

35

Note: Today’s update in arm-stable

Packages (1) manjaro-system-20220112-1

Total Download Size:   0.01 MiB
Total Installed Size:  0.00 MiB
Net Upgrade Size:      0.00 MiB

:: Proceed with installation? [Y/n] y
:: Retrieving packages...
 manjaro-system-20220112-1-any                                                                                                               6.4 KiB  30.5 KiB/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 manjaro-system                                                                                                                                         [#######################################################################################################] 100%
sed: can't read /home/*/.local/share/konsole/Profile\ 1.profile: No such file or directory
:: Running post-transaction hooks...

Well, the the slash has been added but I still get a sed error.

$ ls -n /home/*/.local/share/konsole/Profile\ 1.profile
-rw-r--r-- 1 1000 1000 75 Jan  5 14:55 '/home/support/.local/share/konsole/Profile 1.profile'
36

I am attempting to make the initramfs in a chroot environment. So maybe I have something not correct… but I went ahead as installed reiserfsprogs. I am still wrestling with this… seems doing this with btrfs on a mdadm raid1 takes a bit of trial and error until I get everything correct. I’ll report back once I am successful and report back if an issue persists.

37

Hm, not sure what’s wrong anymore then. :frowning:

I wonder why it’s not expanding the * in the path.

Here’s the section that’s suppose to do it:

38

Maybe it is the quotes:

[root@altra grub]# ls -l "/home/*/.local/share/konsole/Profile\ 1.profile"            
ls: cannot access '/home/*/.local/share/konsole/Profile\ 1.profile': No such file or directory

[root@altra grub]# ls -l /home/*/.local/share/konsole/Profile\ 1.profile
-rw-r--r-- 1 support support 75 Jan  5 14:55 '/home/support/.local/share/konsole/Profile 1.profile'
39

Hm. Usually only single quotes prohibits variable expansion. Why do the double quotes here?

40

I think the " are for expansion of environment variables, maybe not wild cards in filenames? I think a different process is required for filename expansion. Variable expansion is internal to the shell but filename expansion likely requires filesystem look-ups.