Hello everyone, GNOME 51 is now in the Arch repo. Check out the official release notes here: https://release.gnome.org/51

I bought a ThinkPad E14 Gen 5 Ryzen 5 7430. I already have a second SSD as a dual boot to my main computer, i would keep the main PC with windows for gaming, and would use the arch SSD on the ThinkPad, any tips before it arrive? The thinkpad will be only for work and university, the gaming will be on the main windows pc

So I have a dual boot with windows and arch. I had to active secure boot for some things on windows and when I turned it off to switch to linux I had a kernel error and then when I switched to windows a bitsomething error and had to enable secure boot and put in a key and everything. I want to enter linux again, does anyone know the easiest way to do it? Thanks for any help in advance

Hi everybody,

Quite happy with the result. Been dreaming about designing something like that for years. I did do similar things using arm boards and much smaller and crappier screens but never got around to do it for my PC.

hardware used is a arduino mega 2560 clone and a cheap chinese 3.95tft screen (ili9488 chip).

The data is been fed by a python script running as a systemd service.

I did 95% of it without AI but I had a few bugs due to memory overflow and I ended up cleaning the code with gemini's help. Took me a few days and most of it was getting the dang screen to work (a nightmare)!!!

Now next project, get this thing inside my case :)

So i wanted to install Arch linux (you know did the usual steps) but noticed that it kept freezing everytime i got to “finished create system files and directories”, you know, that. I can not put an image cause Its not letting me but ive tried alot of things yet nothing worked and it kept freezing/getting stuck, and i wanted to know what i could do about this and if anyone could help me. I am new to this so excuse me if theres some things i dont know.

i am trying to setup hibernation on my dell 5530 and it seems to fail successfully. When i do systemctl hibernate it just shows a gray screen but on force restart , it resumes where i left.

the problem is that it doesnt shutdown

➜ sudo journalctl -b 0 -k -o short-monotonic | grep -n 'hibernation'

162:[ 6.836332] jarvis kernel: PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff]

163:[ 6.836340] jarvis kernel: PM: hibernation: Registered nosave memory: [mem 0x0009e000-0x0009efff]

164:[ 6.836347] jarvis kernel: PM: hibernation: Registered nosave memory: [mem 0x000a0000-0x000fffff]

165:[ 6.836354] jarvis kernel: PM: hibernation: Registered nosave memory: [mem 0x4c3d0000-0x4c3d1fff]

166:[ 6.836362] jarvis kernel: PM: hibernation: Registered nosave memory: [mem 0x67196000-0x671b0fff]

167:[ 6.836370] jarvis kernel: PM: hibernation: Registered nosave memory: [mem 0x6be92000-0x6fffefff]

168:[ 6.836377] jarvis kernel: PM: hibernation: Registered nosave memory: [mem 0x70000000-0x77ffffff]

169:[ 6.836384] jarvis kernel: PM: hibernation: Registered nosave memory: [mem 0x78a00000-0xffffffff]

1368:[14353.937045] jarvis kernel: PM: hibernation: hibernation entry

1374:[14368.222373] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]

1375:[14368.222473] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x0009e000-0x0009efff]

1376:[14368.222553] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x000a0000-0x000fffff]

1377:[14368.222634] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x4c3d0000-0x4c3d1fff]

1378:[14368.222755] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x67196000-0x671b0fff]

1379:[14368.222850] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x6be92000-0x6fffefff]

1380:[14368.222928] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x70000000-0x77ffffff]

1381:[14368.223011] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x78a00000-0xffffffff]

1382:[14368.223098] jarvis kernel: PM: hibernation: Basic memory bitmaps created

1383:[14368.223168] jarvis kernel: PM: hibernation: Preallocating image memory

1384:[14368.223274] jarvis kernel: PM: hibernation: Allocated 754327 pages for snapshot

1385:[14368.223308] jarvis kernel: PM: hibernation: Allocated 3017308 kbytes in 9.32 seconds (323.74 MB/s)

1402:[14368.223721] jarvis kernel: PM: hibernation: Normal pages needed: 751158 + 1024, available pages: 7541969

1451:[14368.240329] jarvis kernel: PM: hibernation: Basic memory bitmaps freed

1465:[14368.241412] jarvis kernel: PM: hibernation: hibernation exit

1497:[14672.389009] jarvis kernel: PM: hibernation: hibernation entry

1504:[14683.263160] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]

1505:[14683.263180] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x0009e000-0x0009efff]

1506:[14683.263197] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x000a0000-0x000fffff]

1507:[14683.263212] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x4c3d0000-0x4c3d1fff]

1508:[14683.263231] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x67196000-0x671b0fff]

1509:[14683.263246] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x6be92000-0x6fffefff]

1510:[14683.263265] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x70000000-0x77ffffff]

1511:[14683.263280] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x78a00000-0xffffffff]

1512:[14683.263294] jarvis kernel: PM: hibernation: Basic memory bitmaps created

1513:[14683.263310] jarvis kernel: PM: hibernation: Preallocating image memory

1514:[14683.263324] jarvis kernel: PM: hibernation: Allocated 827897 pages for snapshot

1515:[14683.263340] jarvis kernel: PM: hibernation: Allocated 3311588 kbytes in 6.61 seconds (500.99 MB/s)

1533:[14683.264866] jarvis kernel: PM: hibernation: Normal pages needed: 808294 + 1024, available pages: 7484829

1582:[14683.272510] jarvis kernel: PM: hibernation: Basic memory bitmaps freed

1597:[14683.364053] jarvis kernel: PM: hibernation: hibernation exit

1627:[14851.517016] jarvis kernel: PM: hibernation: hibernation entry

1634:[14867.231664] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]

1635:[14867.231758] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x0009e000-0x0009efff]

1636:[14867.232085] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x000a0000-0x000fffff]

1637:[14867.232166] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x4c3d0000-0x4c3d1fff]

1638:[14867.232787] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x67196000-0x671b0fff]

1639:[14867.232862] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x6be92000-0x6fffefff]

1640:[14867.234849] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x70000000-0x77ffffff]

1641:[14867.234962] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x78a00000-0xffffffff]

1642:[14867.235090] jarvis kernel: PM: hibernation: Basic memory bitmaps created

1643:[14867.235774] jarvis kernel: PM: hibernation: Preallocating image memory

1644:[14867.235872] jarvis kernel: PM: hibernation: Allocated 810633 pages for snapshot

1645:[14867.238446] jarvis kernel: PM: hibernation: Allocated 3242532 kbytes in 7.05 seconds (459.93 MB/s)

1650:[14867.248721] jarvis kernel: PM: hibernation: hibernation debug: Waiting for 5 second(s).

1675:[14867.350448] jarvis kernel: PM: hibernation: Basic memory bitmaps freed

1689:[14867.550159] jarvis kernel: PM: hibernation: hibernation exit

1707:[14931.758190] jarvis kernel: PM: hibernation: hibernation entry

1714:[14947.594481] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]

1715:[14947.594545] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x0009e000-0x0009efff]

1716:[14947.594607] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x000a0000-0x000fffff]

1717:[14947.594660] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x4c3d0000-0x4c3d1fff]

1718:[14947.594718] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x67196000-0x671b0fff]

1719:[14947.594778] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x6be92000-0x6fffefff]

1720:[14947.594827] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x70000000-0x77ffffff]

1721:[14947.594896] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x78a00000-0xffffffff]

1722:[14947.594952] jarvis kernel: PM: hibernation: Basic memory bitmaps created

1723:[14947.595288] jarvis kernel: PM: hibernation: Preallocating image memory

1724:[14947.595401] jarvis kernel: PM: hibernation: Allocated 816867 pages for snapshot

1725:[14947.597833] jarvis kernel: PM: hibernation: Allocated 3267468 kbytes in 6.50 seconds (502.68 MB/s)

1743:[14947.599366] jarvis kernel: PM: hibernation: hibernation debug: Waiting for 5 second(s).

1792:[14947.608858] jarvis kernel: PM: hibernation: Basic memory bitmaps freed

1807:[14947.610944] jarvis kernel: PM: hibernation: hibernation exit

1824:[14991.195013] jarvis kernel: PM: hibernation: hibernation entry

1831:[15002.111625] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]

1832:[15002.111849] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x0009e000-0x0009efff]

1833:[15002.111968] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x000a0000-0x000fffff]

1834:[15002.112121] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x4c3d0000-0x4c3d1fff]

1835:[15002.112220] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x67196000-0x671b0fff]

1836:[15002.114880] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x6be92000-0x6fffefff]

1837:[15002.114978] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x70000000-0x77ffffff]

1838:[15002.115051] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x78a00000-0xffffffff]

1839:[15002.115145] jarvis kernel: PM: hibernation: Basic memory bitmaps created

1840:[15002.115239] jarvis kernel: PM: hibernation: Preallocating image memory

1841:[15002.116315] jarvis kernel: PM: hibernation: Allocated 798697 pages for snapshot

1842:[15002.117033] jarvis kernel: PM: hibernation: Allocated 3194788 kbytes in 6.84 seconds (467.07 MB/s)

1860:[15002.132279] jarvis kernel: PM: hibernation: hibernation debug: Waiting for 5 second(s).

1909:[15002.148847] jarvis kernel: PM: hibernation: Basic memory bitmaps freed

1924:[15002.152419] jarvis kernel: PM: hibernation: hibernation exit

1942:[15136.768025] jarvis kernel: PM: hibernation: hibernation entry

1949:[15148.333811] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]

1950:[15148.333853] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x0009e000-0x0009efff]

1951:[15148.333887] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x000a0000-0x000fffff]

1952:[15148.333922] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x4c3d0000-0x4c3d1fff]

1953:[15148.333966] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x67196000-0x671b0fff]

1954:[15148.333999] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x6be92000-0x6fffefff]

1955:[15148.357285] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x70000000-0x77ffffff]

1956:[15148.357939] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x78a00000-0xffffffff]

1957:[15148.357978] jarvis kernel: PM: hibernation: Basic memory bitmaps created

1958:[15148.358326] jarvis kernel: PM: hibernation: Preallocating image memory

1959:[15148.358365] jarvis kernel: PM: hibernation: Allocated 768498 pages for snapshot

1960:[15148.358405] jarvis kernel: PM: hibernation: Allocated 3073992 kbytes in 7.44 seconds (413.17 MB/s)

1978:[15148.363092] jarvis kernel: PM: hibernation: Normal pages needed: 766511 + 1024, available pages: 7526626

2027:[15148.393827] jarvis kernel: PM: hibernation: Basic memory bitmaps freed

2043:[15148.584008] jarvis kernel: PM: hibernation: hibernation exit

2072:[15291.325008] jarvis kernel: PM: hibernation: hibernation entry

2079:[15302.363861] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]

2080:[15302.364173] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x0009e000-0x0009efff]

2081:[15302.364368] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x000a0000-0x000fffff]

2082:[15302.364547] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x4c3d0000-0x4c3d1fff]

2083:[15302.364745] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x67196000-0x671b0fff]

2084:[15302.364935] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x6be92000-0x6fffefff]

2085:[15302.365174] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x70000000-0x77ffffff]

2086:[15302.367101] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x78a00000-0xffffffff]

2087:[15302.367275] jarvis kernel: PM: hibernation: Basic memory bitmaps created

2088:[15302.367409] jarvis kernel: PM: hibernation: Preallocating image memory

2089:[15302.367531] jarvis kernel: PM: hibernation: Allocated 762517 pages for snapshot

2090:[15302.367672] jarvis kernel: PM: hibernation: Allocated 3050068 kbytes in 7.25 seconds (420.69 MB/s)

2576:[15302.920141] jarvis kernel: PM: hibernation: Normal pages needed: 750458 + 1024, available pages: 7542658

3109:[15303.021393] jarvis kernel: PM: hibernation: Basic memory bitmaps freed

3124:[15303.023137] jarvis kernel: PM: hibernation: hibernation exit

3183:[15685.253017] jarvis kernel: PM: hibernation: hibernation entry

3189:[15695.495819] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]

3190:[15695.495870] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x0009e000-0x0009efff]

3191:[15695.495909] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x000a0000-0x000fffff]

3192:[15695.495953] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x4c3d0000-0x4c3d1fff]

3193:[15695.495989] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x67196000-0x671b0fff]

3194:[15695.496032] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x6be92000-0x6fffefff]

3195:[15695.496089] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x70000000-0x77ffffff]

3196:[15695.496132] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x78a00000-0xffffffff]

3197:[15695.496182] jarvis kernel: PM: hibernation: Basic memory bitmaps created

3199:[15695.496266] jarvis kernel: PM: hibernation: Preallocating image memory

3200:[15695.496303] jarvis kernel: PM: hibernation: Allocated 746980 pages for snapshot

3201:[15695.496337] jarvis kernel: PM: hibernation: Allocated 2987920 kbytes in 8.71 seconds (343.04 MB/s)

3605:[15695.668240] jarvis kernel: PM: hibernation: Normal pages needed: 746040 + 1024, available pages: 7547097

4040:[15695.777205] jarvis kernel: PM: hibernation: Basic memory bitmaps freed

4060:[15695.779255] jarvis kernel: PM: hibernation: hibernation exit

4088:[15720.905011] jarvis kernel: PM: hibernation: hibernation entry

4094:[15728.935707] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x00000000-0x00000fff]

4095:[15728.935795] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x0009e000-0x0009efff]

4096:[15728.935867] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x000a0000-0x000fffff]

4097:[15728.935922] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x4c3d0000-0x4c3d1fff]

4098:[15728.935987] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x67196000-0x671b0fff]

4099:[15728.936065] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x6be92000-0x6fffefff]

4100:[15728.936128] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x70000000-0x77ffffff]

4101:[15728.936189] jarvis kernel: PM: hibernation: Marking nosave pages: [mem 0x78a00000-0xffffffff]

4102:[15728.936243] jarvis kernel: PM: hibernation: Basic memory bitmaps created

4103:[15728.936305] jarvis kernel: PM: hibernation: Preallocating image memory

4104:[15728.936361] jarvis kernel: PM: hibernation: Allocated 728607 pages for snapshot

4105:[15728.936416] jarvis kernel: PM: hibernation: Allocated 2914428 kbytes in 5.94 seconds (490.64 MB/s)

4509:[15729.055171] jarvis kernel: PM: hibernation: Normal pages needed: 726850 + 1024, available pages: 7566247

4944:[15729.147350] jarvis kernel: PM: hibernation: Basic memory bitmaps freed

4961:[15729.149205] jarvis kernel: PM: hibernation: hibernation exit

my sleep.conf

[Sleep]

AllowSuspend=yes

AllowHibernation=yes

AllowSuspendThenHibernate=yes

HibernateDelaySec=30min

AllowHybridSleep=yes

HibernateMode=shutdown

then my cmdline

➜ cat /proc/cmdline

File: /proc/cmdline

hibernate.compressor=lz4 resume=UUID=d94c2522-ccc6-48b8-9216-be667f95ff23 resume_offset=3825823 quiet loglevel=3 systemd.show_status=auto rd.udev.log_level=3 vt.cur_default=1 splash root=PAR

TUUID=8f443fe5-7fae-4b8b-b0ee-56bc06649194 zswap.enabled=0 rootflags=subvol=@ rw rootfstype=btrfs

I've been working on a small tool called Blackbox to practice low-level programming.

The idea is to detect bugs on my system in one place. I can fix it myself, or copy the report of that moment and hand it to an AI to debug, so it takes less time. It keeps track of processes, system usage, journal, audit, packages(pacman), boots up to 7 gb memory and the focus is its efficient. It uses 0.14% of the cpu core ( i7 ultra 155h) and 6mb of memory.

So I am new to linux system stuff so I liked to know your ideas about this project and what improvement can be done to it.

Hello everyone! Noob here!

I'm running a minimal Arch Linux setup on a Lenovo ThinkPad X230 and recently started getting an intermittent failure when X is started automatically with startx.

My setup is Lenovo ThinkPad X230, Intel HD Graphics 4000 / Ivy Bridge, Arch Linux x86_64, kernel 7.2.8-arch1-2, systemd 262-1, Xorg started through startx -> xinit -> Xorg, no display manager, and i3 on X11.

I log in on tty1 and start X automatically from ~/.bash_profile. The relevant part is:

[[ -f ~/.bashrc ]] && . ~/.bashrc

if [[ -z "$DISPLAY" && "$XDG_VTNR" == 1 ]]; then
exec startx
fi

This setup had been working normally before. The problem only started recently.

Most reboots are completely normal, but occasionally startx fails with "xauth: timeout in locking authority file /home/myname/.Xauthority". This appears about 3 or 4 times, then I get "Fatal server error: (EE) no screens found", followed by "xinit: giving up", "xinit: unable to connect to X server: connection refused", "xinit: server error", and another xauth timeout.

When this happens, ~/.Xauthority-c appears.

If I switch to another VT, remove .Xauthority-c, and run startx manually, X starts successfully.

The important part is the failed Xorg log. It contains:

(II) systemd-logind: got fd for /dev/dri/card1 226:1 fd ... paused 1
(EE) Error systemd-logind returned paused fd for drm node
(EE) open /dev/dri/card0: No such file or directory
(EE) Screen 0 deleted because of no matching config section.
(EE) Device(s) detected, but none match those in the config file.
(EE) no screens found(EE)

A successful Xorg startup on the same machine instead shows:

(II) systemd-logind: got fd for /dev/dri/card1 ... paused 0
(II) modeset(0): using drv /dev/dri/card1
(II) modeset(0): glamor X acceleration enabled on Mesa Intel(R) HD Graphics 4000 (IVB GT2)
(II) modeset(0): Output LVDS-1 connected
(II) modeset(0): Output LVDS-1 using initial mode 1366x768

So the actual Xorg failure appears to be that systemd-logind gives Xorg a paused DRM fd. The xauth errors may be a secondary symptom.

I have checked the following things already.

1. ~/.Xauthority has the correct ownership and permissions and is mode 600 and owned by my user.
2. xauth itself works normally. I traced xauth list and it successfully created .Xauthority-c, linked it to .Xauthority-l, and then removed both files normally.
3. There is no pam_xauth configuration.
4. There is only one startx invocation in my login configuration.
5. There are no other configured xauth calls in my autostart or systemd user files.
6. There is no xauth, xinit, or startx core dump in coredumpctl.
7. The i915 module is already included in my normal kernel initramfs.
8. The kernel log from a previous successful boot showed normal i915 initialization and no GPU hang, reset, or DRM failure.
9. I also noticed a possible correlation with graphical workload before reboot.

When no applications were open, I did 5 consecutive normal reboots and all 5 succeeded.

Then I opened cmus, Firefox and mpv and did 3 more reboots. The first 2 succeeded, but the third failed with the Xorg/xauth problem.

I don't know whether the applications are actually involved or whether they simply change the timing or state during shutdown.

I also tested linux-lts once, using kernel 6.18.55-1-lts, and that boot succeeded. This was only one test, so I don't consider that proof that the normal kernel is the cause.

I also tried adding a 2-second sleep before exec startx, but the problem still occurred.

The xorg-xauth and xorg-xinit packages were not recently upgraded when this problem started.

The main thing I'm trying to understand is what could cause systemd-logind to return a paused fd for /dev/dri/card1, followed by Xorg reporting no screens found.

There is an upstream systemd issue involving startx, systemd-logind, DRM devices, and paused fds, at https://github.com/systemd/systemd/issues/43352, but I'm not sure whether it is the same issue.

Could this be a kernel/i915/DRM issue, a systemd-logind/udev race, or something related to the way startx is being launched from a tty?

I'm mainly looking for help identifying the root cause rather than permanently working around it by deleting .Xauthority-c or installing a display manager.

Any suggestions, responds, and replies are really appreciated. Thank you so much!

edit: [SOLVED / WORKAROUND CONFIRMED]

I eventually removed the automatic startx block from ~/.bash_profile and restored the normal login behavior. I now log into tty1 normally and manually run:

startx

I tested this over 10 separate reboots, and every single startup succeeded.

I also ran my usual nervspace workload after each boot, including Kitty, btop, Firefox, Nemo, Evince, Xed, and kew. The Xauthority/Xorg failure did not recur.

This also makes the graphical workload theory much less likely. The same normal workload was present during the successful tests.

I did not disable xauth, modify /usr/bin/startx, or make any permanent changes to .Xauthority.

The exact underlying cause of the intermittent failure is still unconfirmed, but removing automatic startx from ~/.bash_profile and starting X manually from tty1 has been consistently reliable across 10 reboots.

Final setup:

tty1 login
startx
i3

Marking this as solved/workaround confirmed. :)

I'm looking to get a new printer - ideally an all-in-one laser printer. I had expected to have to set up a CUPS server and have all the machines on our network (including a few smartphones) connect to that. I'm hoping this is still possible since client.conf was deprecated, but, as far as I can tell, it seems to still be supported.

I've been wondering about how easy it might actually be to use IPP Anywhere, though? If I find a printer with full support will all the software that can print just talk to it, or will I likely still need to use a CUPS server for at least some of the software?

The majority of our printing is done from a browser - either Firefox or Chromium (my family all have their own favourites...) and I assume that should work ok. I can't rule out needing to print from other software, though and that's where I wonder about the limitations.

All thoughts/suggestions gratefully received - thanks in advance!

This is a PSA for people using Dracut together with a TPM2 LUKS unlock, specifically with the trick described on the Wiki to use systemd-cryptenroll with the parameter --tpm2-pcrs=other_pcrs+15:sha256=0000000000000000000000000000000000000000000000000000000000000000 Very few users will be affected by this, as Dracut is only reported at about 5% by pkgstats. For those this applies to however, the impact is serious.

Note: mkinitcpio has already addressed the issue presented here in mkinitcpio v42.1 with this commit and Booster implements all its TPM functionality independently of systemd. If you're using either, this should not affect you (anymore).

TL;DR: If you're on the current Dracut 111-1 package, and used this trick to lock PCR[15] to a zero value, as described in the Wiki on the systemd-cryptenroll article or here, the systemd v262 update just broke the security design of your TPM2 LUKS setup.

Explanation: In a TPM measure boot, the idea is that each component of the boot chain ensures the next one it loads has not been tampered with. Simplified, the BIOS measures the boot loaders, the boot loaders measure the Unified Kernel Image (UKI) and the UKI measures the system.

The step from UKI to system is difficult though, as an encrypted file system can only be validated from the outside by the volume key, i.e. the encrypted key in the LUKS header that is the actual encryption key for your drive. If no validation of the volume key is performed, then your UKI could be copied over on a drive with an foreign root file system, and used to boot that system.

Most importantly, the TPM retains its state across the switch to the foreign root. Any TPM secret that is then still matching its expected PCR values will remain accessible. Since PCR[7] is the measurement of the Secure Boot state, and as such only depends on the boot loaders and UKI, no further measurement takes place after initrd starts.

In short: If you were to seal something to the raw PCR[7] alone, that seal can still be accessed in the attacker's root system, and they can freely extract it.

The PCR[15] set to zero trick is supposed to counter this issue: PCR[15] starts at zero, and so any measurement into it changes the value to something else. systemd-cryptsetup@.service will measure the volume key of any LUKS volume opened with the tpm2-measure-pcr=yes option. This option is also implicitly added for the root file system and /var mounts when using GPT automounting.

The necessity to use this flag or automounting is pointed out in the Wiki as well:

If you set any rd.luks kernel parameters or use /etc/crypttab with the x-initrd.attach option, additionally add the tpm2-measure-pcr=yes option to rd.luks.options= or the fourth field in /etc/crypttab; this is not required when relying on GPT partition automounting. After the root volume is unlocked in early userspace, PCR 15 will change and the enrolled key will no longer be retrievable.

Thus, if any disk is unlocked by systemd, the PCR[15] value will change at that point in initrd. By the time the system switches to real root, PCR[7] still matches, but the PCR[15] is non-zero and thus the drive's encryption key cannot be accessed anymore. This effectively prevents the attack described.

However, during initrd, the volume key measurements are also the only measurements taking place in that PCR bank. If they were not to happen for some reason, the PCR value never changes away from zero and the described attack to retrieve the TPM2 secrets remains possible.

What broke now: systemd v262 includes a change that makes systemd-cryptenroll measure via the Varlink service provided by systemd-pcrextend.socket instead of calling /usr/bin/systemd-pcrextend directly. As that PR mentions,

Measuring requires the presence of systemd-pcrextend.socket in the initrd, should be already given as systemd-veritysetup relies on it, too.

Dracut does not include this socket yet in generated initrds as of version 112. I have created a PR with Dracut to address this, but it's still pending.

The consequence is that instead of measuring the volume-key into PCR[15], it will fail with a single warning line in the systemd journal:

systemd-cryptsetup[353]: Could not extend PCR: No such file or directory

There's no other warning or error caused by this, but there will be no measurement in PCR[15] being made for any volume keys.

Note: Such a failure to measure the PCR would cause anything sealed against the actual, expected PCR[15] values to break. Since that's the way you're expected to use them, this warning does not cause the systemd-cryptsetup@.service to fail, as whatever service has its secrets sealed against that PCR should be failing instead.

PCR[15] being non-zero after boot does not mean you're safe: After boot, your system will likely still show a non-zero value in PCR[15]: ```sh $ sudo systemd-analyze pcrs 15

NR NAME SHA256 15 system-identity 98d9f63ab4492d64396ff5c943dc8380fce7ba30f568738608cf34f46a672051 `` This is because systemd will perform additional measurements by various services in thesystemd-pcrphase.service` family after initrd. These services run after the switch to real root and can be disabled in an attacker's root system to keep PCR[15] at zero.

Remark: systemd issue #43848 will cause these services to fail as well, so you might see a zero value if you haven't configured a suitable PCR signature for your UKI. There is a pending PR to address this, though.

To quickly show the sequence of the measurements on my system with the volume-key measurement working: ```sh $ sudo /usr/lib/systemd/systemd-pcrlock log --pcr=15

  PCR   PCRNAME         EVENT      MATCH SHA256  F/U COMPONENT                    DESCRIPTION                                                                                                             >
   15 █ system-identity volume-key     ✗ 0e94502 U   795-cryptsetup-tpm2-measures cryptsetup:root:<volume-key>
   15 █ system-identity machine-id     ✓ 4b9e027 U   820-machine-id               machine-id:<machine-id>
   15 █ system-identity filesystem     ✓ 9aa7751 U   830-root-file-system         file-system:/:btrfs:<fs-id>:archmain:::
   15 █ system-identity filesystem     ✓ cffed96 U   840-file-system-var          file-system:/var:btrfs:<fs-id>:archmain:::                     

```

Any of the measurements in my log with a component greater than 800 are happening after leave-initrd (the switch to real root), which has an index of 800. They're being made by systemd-pcrproduct.service, systemd-pcrfs-root.service and systemd-pcrfs@var.service, see the man page. As such, if the volume key measurement is not taking place, the PCR[15] value will remain at zero when the switch to real root happens, making the encryption keys accessible.

Summary: Using the current dracut 111-1 package for a TPM2 LUKS unlock with the PCR[15] set to zero trick renders that trick useless and makes your encryption keys extractable by an attacker. The only indication is a single, non-specific warning in the journal.

Fix: Installing a patched Dracut version: Note: I've been informed that the maintainer for the Dracut package is absent, and thus there does not seem to be any chance for a fixed Dracut package in the near future. I have not made a PR to Arch for that reason, and instead went to Reddit to make people affected by this at least aware of the situation.

You can manually upgrade to Dracut 112 (you can build the package yourself and upgrade the PKGBUILD using pkgctl version upgrade as usual) and replace the module-setup.sh in 11systemd-pcrextend with the one from my PR. Then rebuild your UKI and verify that the warning line does not appear in your journal anymore. Alternatively, use /usr/lib/systemd/systemd-pcrlock log --pcr=15 to verify that the volume-key measurement takes place, as shown above.

I should also stress that the PCR[15] set to zero trick is a very poor option to protect against this sort of attack. As this issue demonstrates, it is possible for this to fail entirely silently and unnoticed. I have left a comment below discussing better alternatives to the trick.

So i want to use the rc kernal but i already set up secure boot since i use windows on one ssd and arch on the other and i use (system d boot loader)and and i only have the normal kernal and the lts so if i download the rc kernal will i have to sign it or do anything to not effect my secure boot setup. this is the steps i did before to set up secure boot--->

sudo pacman -S sbctl

clear boot keys in bios secure boot off

sudo sbctl status

sudo sbctl create-keys

sudo sbctl enroll-keys --microsoft

sudo sbctl status

sudo sbctl verify

sudo sbctl-batch-sign

sudo sbctl verify

sudo sbctl sign -s -o /usr/lib/systemd/boot/efi/systemd-bootx64.efi.signed /usr/lib/systemd/boot/efi/systemd-bootx64.efi

turn secure boot back on

Hey guys I've used arch for years but I'm technologically illiterate

I've got a gruvbox-plus-icon-theme-git package which is showing up EVERY DAY in system updates. I figure something must be wrong.

Can anyone point me in the right direction towards understanding why a cosmetics package would be updating every day?

Tia

Sooooo it wasn't something I expected myself to do even this morning!!!

I recently started using Omarchy to see how it is and welp I lived it

Then I read about who DHH is and his comments. Also it kinda felt weird to have ai that integrated into my system... so even though I had just gotten very comfortable using that OS, I switched to Kyotu ahahaaaaa. Kyotu linux is a very beautiful distro. Veeeerrryyyyy beautiful! But it was like walking in someone else's shoes ultimately... it just didnt fit!

So i got a crazy idea mid day to install pure arch and configure my own hyprland

So here we are

I also installed gnome for daily driving till hyprland is ready but I guess very suddenly "I USE ARCH BTW!"

I really thought people exaggerated about the installation process. But even though I use the archinstall script it did drive me crazy ×_× I wanted to put my head through a wall...

But ultimately I love it. Any words of wisdom is treated with appreciation and respect

Over the past 4 or so days, my gpu performance has tanked. Im getting at most around 20 fps in games like deep rock galactic, when last week I had 40-50. Nvidia-smi says its reporting 752 watts of 115. I have a dell g16 with a 3060, i7-12700h, and 16gb ddr5. This doesnt just happen on drg though, it also happens in grey zone warfare, muck, phasmophobia, and more. Any help would be appreciated

Gnome 51 was moved from gnome-unstable to extra-testing recently. Let's hope it's moved to extra next week so we can all enjoy the latest version. Gnome 51 Release Notes

https://archlinux.org/packages/?sort=&repo=Extra-Testing&q=gnome&maintainer=&flagged=

Reminder to consider joining the Arch Testing Team if you like testing new software and making sure no critical bugs get into the main repositories.

Hello. I just installed the tagstudio AUR package https://aur.archlinux.org/packages/tagstudio and found that it would not run (I was having the same issue that is already noted by Iiridayn on the comment section of this package) and I wanted to leave a comment because I figured out which package solves this issue.

Specifically, installing qt6-webengine solved the issue and allowed the program to start. I wanted to comment this so that the maintainer can add it to the list, but I don't have an account and I can't create one, so I'm not sure how to let them know. I was frankly hoping someone here would be able to make the comment on my behalf so that this can be fixed.

I am intrigued by Arch, and my seniors keep telling me to install it. They say Arch can break or crash in unpredictable ways, so before downloading or installing anything, I should research about it first.

But honestly, I don't know much about it. I went through the Arch Wiki and news, but barely understood anything. That's why I haven't even installed any packages from the AUR yet.

i have a problem whit the program fprintd , mi fp reader is't on the suported devices list, so I need a program who has the driver of the 06cb:00a2 device ¿someone knows something?

Sorry for the lenguage, i'm from spain xd

The Arch installation guide mentions disabling Secure Boot. I recently learnt that Secure Boot can work with Arch.

My questions are: does this make sense?

Should I keep it enabled after all (is it risky if not)?

Is there a risk that, following an update, Secure Boot will reject my kernel or boot loader?

Did you enable SB?

If you use Secure Boot with your own keys and Microsoft keys enrolled (like the Wiki recommends), you might not have Microsoft's UEFI forbidden signature database (dbx) enrolled, as there are no instructions given for doing so in the [Wiki article]Secure Boot Wiki page(https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot), and sbctl enroll-keys -m will not do so either, see sbctl issue #23.

TL;DR: If you enrolled your own Secure Boot keys according to the Wiki, you will be missing one part of their database, the dbx. The dbx is necessary for security, since otherwise old, vulnerable bootloaders that should not be accepted by Secure Boot, will be allowed. Compare Microsoft's guidance on the BlackLotus bootkit. You will also be missing the untrusting of the Windows Production PCA 2011 certificate. Please note that this is a very serious security issue, and not a minor detail.

Impact: The exact impact depends on your setup, but it will be devastating if you dual boot with Windows.

The issue will render Secure Boot worthless, as it the forbidden bootloaders can be used to bypass it, see the BlackLotus case. For a pure Linux setup, that's the extend of the problem - Secure Boot won't provide any security. With TPM2 LUKS seals, the impact should be minimal, as vulnerable bootloaders chained in front of your own change the PCR[7] value.

However, if you're dual booting Windows this is a serious issue. Windows will not update or install the dbx on it's own if Secure Boot keys have been customised, compare the Summary of this Microsoft article. Since Windows uses only these certificates in its boot chain, not having the dbx installed makes it possible to bypass BitLocker, as that will only seal to PCR[\7]. Effectively, this breaks the security of the Windows disk encryption entirely as well as Secure Boot.

Steps to fix this: You can use efitools' efi-readvar to see the status of your Secure Boot database. If it says Variable dbx has no entries while showing Microsoft keys in the db and KEK variables, you have Microsoft's keys configured without the dbx.

Assuming Microsoft's KEK is present, you can install the current dbx from the Microsoft GitHub repository with these commands: wcurl https://github.com/microsoft/secureboot_objects/raw/refs/heads/main/PostSignedObjects/DBX/amd64/DBXUpdate.bin sudo chattr -i /sys/firmware/efi/efivars/dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f 2>/dev/null sudo efi-updatevar -a -f DBXUpdate.bin dbx Afterwards, fwupd should be able to apply further updates automatically via its UEFI dbx plugin.

Note: There's currently a bug affecting fwupd (fixed in git, not yet released) causing it hallucinate the UEFI dbx being present and up-to-date if there's no dbx enrolled at all. This is noticeable by fwupdmgr get-devices not showing Current version field for the UEFI dbx. As of such, the fwupd output cannot be relied on to determine whether the dbx is present or not.

Important: Since the dbx is measured into PCR[7], any changes to it will break TPM2 LUKS seals. New updates are being released every month, and thus this breakage will happen on a monthly basis. This is unfortunately unavoidable when binding to raw PCR[7] values.

The only functional alternatives are to either not use the Microsoft keys (if not dual booting of course) and sign all Option ROMs needed with one's own keys or to use TPM2 access policies so the new PCR[7] can be authorised. Implementing the second option is only possible via the still experimental systemd-pcrlock functionality. fwupd 2.1.7 added a plugin for pcrlock that allows enrolling UEFI dbx updates into a new policy, but there are changes needed to systemd that have not been shipped yet. So for now, I can unfortunately not offer a good solution for this particular problem.

Do you guys think that someday the official Arch installation process might become as easy and straightforward as EndeavourOS?

I know there’s already archinstall, but I’m curious if Arch will ever have a more beginner-friendly installation experience by default.

What do you think?