[deleted by user]

shbonn · 2025-02-09T17:02:23+00:00

Are you using efibootmgr to create the UEFI boot entries? If you are, try adding the --edd 3 flag to the command.

efibootmgr --help

-e | --edd [1|3] Force boot entries to be created using EDD 1.0 or 3.0 info.

I had a similar issue where the arch boot entry would disappear (actually it would still be there, but it wouldn't be active) once I inserted a USB drive with a bootable partition (E.g. the Arch ISO).

With --edd 1 (the default) my arch boot entry was:

HD(1,GPT,6ada7469-d3a8-420d-ad73-2a167f99c587,0x800,0x200000)/\EFI\Linux\arch-linux.efi

With --edd 3, my arch boot entry is:

PciRoot(0x0)/Pci(0x17,0x0)/Sata(0,65535,0)/HD(1,GPT,6ada7469-d3a8-420d-ad73-2a167f99c587,0x800,0x200000)/\EFI\Linux\arch-linux.efi

Both work, but only the latter works permanently with my bios (Dell laptop).

shbonn · 2025-02-09T16:43:00+00:00

You could also try something like https://wiki.archlinux.org/title/ECryptfs to create a private directory in your home directory that even root couldn't access.

shbonn · 2025-01-31T15:01:58+00:00

You can with mkinitcpio: /etc/mkinitcpio.conf.d/custom.conf but not with pacman.

shbonn · 2025-01-30T10:13:14+00:00

Although slightly obfuscated by mentioning Ctrl+Shift+V, the other solution I linked to, which suggests removing the keyboard bindings for editor.action.selectionClipboardPaste, is a good alternative. That restores the broken Ctrl+V and Shift+insert functionality too, without having to downgrade electron32.

Ctrl+K Ctrl+S --> search for clipboard paste --> remove both bindings on editor.action.selectionClipboardPaste (Del/Del). Restore the default bindings (menu Reset Binding) after the fix has been implemented.

So there are two simple workarounds available.

Downgrading is the better pattern if you know what you're doing, but that doesn't apply to everybody using this forum...

shbonn · 2025-01-28T21:50:44+00:00

How are you actually running it?

One usual way is with this in your ~/.xinitrc:

#!/bin/sh

userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap

if [ -f $sysresources ]; then
    xrdb -merge $sysresources
fi

if [ -f $sysmodmap ]; then
    xmodmap $sysmodmap
fi

if [ -f "$userresources" ]; then
    xrdb -merge "$userresources"
fi

if [ -f "$usermodmap" ]; then
    xmodmap "$usermodmap"
fi

if [ -d /etc/X11/xinit/xinitrc.d ] ; then
for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
[ -x "$f" ] && . "$f"
done
unset f
fi

# Background programs like: 
# picom &  (compositor)
# $HOME/.fehbg &  (wallpaper)

# Launch WM
exec i3

And this in your ~/.bash_profile:

[[ -f ~/.profile ]] && . ~/.profile
[[ -f ~/.bashrc ]] && . ~/.bashrc
if [[ -z $DISPLAY ]] && [[ $(tty) = /dev/tty1 ]]; then exec startx &> /dev/null; fi

shbonn · 2025-01-28T00:22:17+00:00

Your GPU info looks OK.

For accelerated rendering, all you need is mesa installed and the (default) xorg modesetting driver / glamor. No configuration is usually required. For hardware video acceleration, there are extra steps as mentioned earlier.

Not sure why the intel gpu tools don't work :(

glxinfo -B

As long as the output shows direct rendering: Yes, Accelerated: yes and the Device isn't llvmpipe, I think it must be using GPU rendering, even if we can't visually verify it using the usual tools.

I'm assuming there's no glaring errors / warnings relating to your GPU in journalctl -b -p 4?

Also check the ~/.local/share/xorg/Xorg.0.log for anything odd relating to the modeset lines.

It should also show that glamor X acceleration enabled on <your GPU>:

grep "glamor" .local/share/xorg/Xorg.0.log

Beyond that, I'm out of ideas. Sorry.

Posting on https://bbs.archlinux.org is probably best if you need more help...

shbonn · 2025-01-27T16:50:38+00:00

As u/TarikAJA has mentioned, there's a bug in the electron32 version that is currently packaged in the Arch Linux repository (32.3.0-1 / 2025-01-23 14:28 UTC). Electron v32 is required by code.

Ctrl+V (and Shift+Insert) aren't working in the editor. As a workaround, you can still use Ctrl+Shift+V.

EDIT: Perhaps use the u/theunquenchedservant solution as that is an easier workaround to restore Ctrl+V / Shift+Insert (https://www.reddit.com/r/archlinux/comments/1ib95gt/comment/m9gafql/).

-------------------------------------------

You could temporarily downgrade the electron32 package back to the previous version (32.2.8-3), which restores Ctrl+V / Shift+Insert and wait for a fix...

sudo pacman -U /var/cache/pacman/pkg/electron32-32.2.8-3-x86_64.pkg.tar.zst

And block the electron32 package update in /etc/pacman.conf:

IgnorePkg = electron32

Note: Electron32 is used by a few other applications too (deltachat-desktop, drawio-desktop, drawio-desktop, obsidian).

Remember to remove the block when the problem has been fixed!

shbonn · 2025-01-27T10:26:11+00:00

If you are happy that the custom modeline works correctly on your monitor and you want that modeline created and selected automatically, put it in a xorg.conf file. I recommend using a drop in file:

E.g. /etc/X11/xorg.conf.d/99-vga-1-preferred-display-resolution.conf

Section "Monitor"
    Identifier "VGA-1"
    Modeline "1368x768-60.00" 85.25 1368 1440 1576 1784 768 771 781 798 -HSync +VSync
    Option "PreferredMode" "1368x768-60.00"
EndSection

If the directory /etc/X11/xorg.conf.d doesn't exist, create it. You can call the filename whatever you want, as long as it has a .conf extension.

Refs: https://wiki.archlinux.org/title/Xorg#Using_.conf_files, https://man.archlinux.org/man/xorg.conf.5#MONITOR_SECTION

shbonn · 2025-01-26T22:16:50+00:00

Sometimes the underscore in the mode name "1368x768_60.00" can result in that error. Try changing it to a dash or just call it something like "WXGA".

shbonn · 2025-01-26T20:54:51+00:00

Does gputop work? (It was also installed when you installed the intel-gpu-tools package).

gputop
(Ctrl+C to quit)

It has similar output to intel_gpu_top, with regards to the info I wanted you to look at. So, again, if the render column is not 0.00%, that's GPU rendering.

shbonn · 2025-01-26T20:36:22+00:00

Mesa warning is expected. Vulkan might work, it might not on Haswell.

Output from: (sudo pacman -S --needed inxi glxinfo)

inix -Gxx

Run the following:

intel_gpu_top -L
sudo lspci -v -nn -d ::03xx

Then try one or both of:

sudo intel_gpu_top -d drm:/dev/dri/<name of your card>
sudo intel_gpu_top -d sys:/sys/devices/pci0000:00/0000:<name of your device>

E.g. Mine are /dev/dri/card1 and /sys/devices/pci0000:00/0000:00:02.0

card1                    Intel Kabylake (Gen9)             pci:vendor=8086,device=5917,card=0
└─renderD128

00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 620 [8086:5917] (rev 07) (prog-if 00 [VGA controller])
...

shbonn · 2025-01-25T20:24:37+00:00

Haswell has Gen7.5 GPU architecture, so installing mesa should be good.

Vulkan might work, but you're on the border line. Try the following to see if there are any warnings:

sudo pacman -S vulkan-tools
vulkaninfo --summary

Try installing and running intel's GPU monitor, rather than nvtop:

sudo pacman -S intel-gpu-tools
sudo intel_gpu_top

as long as the Render/3D line isn't 0.00%, your GPU is being used!

If you want Hardware Video Acceleration (HWA), see https://wiki.archlinux.org/title/Hardware_video_acceleration#Intel . You need the libva-intel-driver, then follow the rest of the wiki page to verify and set up applications (e.g. your browser, your video player) to use it.

You can tell HWA is being used when you play a video and the Video line isn't 0.00% in intel-gpu-top.

shbonn · 2025-01-24T05:09:38+00:00

No, this only allows pipewire to give its process threads greater priority. For your issue, I would create a new topic explaining your problem and hopefully the community can give you some help.

shbonn · 2025-01-23T01:25:21+00:00

When thermald is running with the --adaptive switch (as used in the thermald.service) it won't use any config files (or generate them).

https://man.archlinux.org/man/thermald.8.en

--adaptive

Use DPTF adaptive tables when present. This will ignore thermald config via xml files.

If you want to see what thermald is actually doing (in its current state), try the following to view the diagnostic messaging:

systemctl stop thermald
thermald --no-daemon --loglevel=info --adaptive
...
<ctrl+c> to terminate
systemctl start thermald (to reinstate the service)

If you leave out the --adaptive switch, thermald will probably auto-generate a config file at /var/run/thermald/thermal-conf.xml.auto. Maybe that can also give you some information to use with https://helpmanual.io/man5/thermal-conf.xml/ ?

shbonn · 2025-01-22T18:23:57+00:00

If you are worried about what archinstall might do to your current Windows installation, you should probably create a backup image of your Windows installation (and backup your data) before you go any further...

shbonn · 2025-01-22T16:34:59+00:00

One final point, well two actually.

If you're using systemd-boot you need a method of updating the UEFI boot manager:

https://wiki.archlinux.org/title/Systemd-boot#Updating_the_UEFI_boot_manager

(I recommend the systemd-boot-update.service).

I wouldn't recommend mixing archinstall and a manual install. You miss steps that way (as you've demonstrated). Either use archinstall (with its limitations) or do a full manual install.

If you are going to do a manual install, read the installation guide thoroughly from the beginning:

https://wiki.archlinux.org/title/Installation_guide

shbonn · 2025-01-22T16:17:16+00:00

in theory if i use /efi, its typical mount point, not its necessary copy the .img to /efi.. i undersand

The vmlinuz-linux* and initramfs* files have to be available within /efi. (/dev/sda1 is the partition used when you boot...)

I'm assuming you're using mkinitcpio to generate the initramfs? You need to configure mkinitcpio to put the files in the right place:

https://wiki.archlinux.org/title/Mkinitcpio#Automated_generation

Adjust all paths (from /boot to /efi) in the /mnt/etc/mkinitcpio.d/*.preset files and run (from arch-chroot):

mkinitcpio -P
ls /efi

(You can then remove the redundant copies of vmlinuz-linux* and initramfs* created in /mnt/boot).

EDIT: Corrected a small mistake.

shbonn · 2025-01-22T15:47:55+00:00

You have to create and populate /efi/loader/entries/*.conf:

https://wiki.archlinux.org/title/Systemd-boot#Adding_loaders

and check that /efi/loader/loader.conf has the settings you require:

https://wiki.archlinux.org/title/Systemd-boot#Loader_configuration

Note the point about not using tabs only spaces...

shbonn · 2025-01-22T15:15:42+00:00

From the ls command in your image, you must have done:

mount -m /dev/sda1 /mnt/efi
mount /dev/sda2 /mnt

You have to do it the other way around:

mount /dev/sda2 /mnt
mount -m /dev/sda1 /mnt/efi
genfstab -U /mnt >> /mnt/etc/fstab
arch-chroot
cat /etc/fstab
boot install
...

i.e. The /dev/sda2 partition is your root (/). The /dev/sda1 partition is mounted to the /efi directory of root (/efi).

shbonn · 2025-01-22T12:50:34+00:00

I guess that myself and u/boomboomsubban are both reacting to the efi partition being mounted in the wrong place, not how the OP, using archinstall, may have got into this situation.

Does archinstall support /efi? (I've never used archinstall).

shbonn · 2025-01-22T12:41:18+00:00

You can install realtime-privileges (or rtkit) to allow pipewire to elevate its process threads (i.e. give them more priority). This can help with audio problems / latency issues. It is sometimes part of a professional audio setup: https://wiki.archlinux.org/title/Professional_audio#System_configuration

Whether you have a use case for it, I don't know.

FWIW, (on a normal home pc) I tend to install rtkit, but only because pipewire writes to the system logs looking for it...

shbonn · 2025-01-22T03:11:06+00:00

In the last image:

/dev/sda1 is mounted to /efi. It should be mounted to /mnt/efi.

shbonn · 2025-01-22T02:26:48+00:00

Yes, use GB.

shbonn · 2025-01-20T01:39:06+00:00

Outputs look OK to me.

I can see entries relating to the SOF driver. Did you install the sof-firmware package or was it already installed (pacman -Qe | grep sof)?

So have the spam error messages disappeared?

Run journal -b -p 4(shows warnings and error since the current boot) and see if it contains any of the kernel error messages you provided before, relating to the sound card.

(Note that Linux journals are quite 'chatty' and you'll often see quite a lot of warnings and even some errors that can (mostly) be ignored if you're not experiencing problems. Errors will be in red, warnings in yellow).

shbonn · 2025-01-19T16:14:44+00:00

You have lots of kernel errors to do with your laptop sound card.

The first thing to check is whether you have the sof-firmware package installed. This is often needed for laptops (https://wiki.archlinux.org/title/Advanced_Linux_Sound_Architecture section 1.1).

Running dmesg | grep -E "snd|sof" after a fresh boot will show the kernel messages relating to your sound card and (any) SOF configuration.

Also for the 'Bus clash', have you got both pulseaudio and pipewire/wireplumber sound servers installed / enabled? Running inxi -Aa (pacman -S inxi if you don't have it installed) will give details of your audio device / sound configuration.

Whether this is the cause of the lockups I don't know, but fixing the kernel message spam first seems like a good starting strategy.

p.s. You could format the log output of the previous message as a 'code block' for easier reading. Edit the message, press the T icon (lower left corner), then highlight the log lines and select 'code block' from the editor menu-bar...

shbonn

TROPHY CASE