March 2024 - Arch-general - lists.archlinux.org

Fwd: [to Arch General] Consolidating our mkinitcpio hooks
by David C. Rankin 04 Mar '24

04 Mar '24

I've followed the mkinitcpio v38 thread and efforts to not break systems. This has me concerned. I have 3 Arch servers with many mdadm RAID arrays. What changes will I have to make regarding mdadm_udev to ensure my system doesn't break? Will simply updating once all the packages hit the mirrors be all that is required?: * mkinitcpio 38-1 * systemd xxxx * lvm2 xxxx * mdadm xxxx * cryptsetup xxxx Or will manual intervention be needed? -------- Forwarded Message -------- Subject: Re: Consolidating our mkinitcpio hooks Date: Sat, 2 Mar 2024 14:07:14 +0100 From: Morten Linderud <foxboron(a)archlinux.org> To: arch-dev-public(a)lists.archlinux.org Yo, mkinitcpio v38 has been released and I made a personal test setup with the changes and everything seems to work fine on my end. To make sure we are limiting breakage I propose the following news item to go along with the update. Please note I'll insert the relevant versions when the packages hit the testing repositories sometime tomorrow if there are no objections to the current plan. Draft here: https://md.archlinux.org/ixPJWhJXTj6Arlyq3wb9jA # News Item Subject: mkinitcpio hook migration and early microcode With the release of mkinitcpio v38 several hooks provided from Arch packages has moved to the mkinitcpio upstream. The moved hooks are systemd, udev, encrypt, sd-encrypt, lvm2 and mdadm_udev. To ensure we are not breaking the boot of users we have introduced temporary conflicts into the respective packages to prevent you from installing packages that are no longer compatible. The following packages needs to be installed together: * mkinitcpio 38-1 * systemd xxxx * lvm2 xxxx * mdadm xxxx * cryptsetup xxxx Please note the `mkinitcpio` flag `--microcode` has been deprecated in favour of a new `microcode` hook. This also allows you to drop the mircocode `initrd` lines from your boot configuration as they are now included in your initramfs. -- Morten Linderud PGP: 9C02FF419FECBE16 -- David C. Rankin, J.D.,P.E.

3 3

Re: Upgrade failure
by Abraham S.A.H. 04 Mar '24

04 Mar '24

> These should be an option at old.reddit.com/prefs <http://old.reddit.com/prefs> to not use new Reddit, and thus always get the old version at www. Should minimize the headaches you get with old and dusty Reddit links. Thanks, @Aaron -- Best Regards, Abraham Sent with Tutanota; https://tuta.com

1 0

Upgrade failure
by arch＠howorth.org.uk 04 Mar '24

04 Mar '24

On Mon, 4 Mar 2024 14:07:47 +0100 (CET) "Abraham S.A.H." <arash.sah(a)tuta.io> wrote: > > https://www.reddit.com/r/archlinux/comments/1b67kih/libblockdevutils_and_up… > > Can't open. First answer: pacman -S libblockdev-utils; pacman -Syu Possibly a packaging mistake. Another reply: I had the same issue yesterday. I reran the update this morning and it worked. It was either that my mirror was not up to date or a packaging issue. If you’re not in a hurry to update give it a few hours and your mirror should update. And a third reply: I had the same problem as well, what i did was uninstall libblockdev-utils using pacman -Rdd and then i just installed the new version.

1 0

boot parameter to stop hdmi
by Jude DaShiell 04 Mar '24

04 Mar '24

Is nohdmi valid to disable hdmi on an installer boot? A contact may need this but I'm not sure since I'm not familiar with his hardware. -- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940.

1 0

Trouble connecting with NetworkManager
by SET 03 Mar '24

03 Mar '24

Hi, Since yesterday's upgrade, it's not possible to establish IPV4 networking with networkmanager 1.46.0-1 and networkmanager-qt5 5.115.0-1 on ethernet and Wi- Fi. It happens with both static and dynamic address assignment. A usable IPV6 address is obtained with DHCP on Wi-Fi. An IPV6 address is assigned on ethernet, but it is not usable to be online. # LC_ALL=C LANG=C journalctl -u NetworkManager -r |less Feb 25 08:24:59 asus0.nmset.info NetworkManager[4136]: <info> [1708845899.6577] policy: set 'ETH0' (eth0) as default for IPv4 routing and DNS Feb 25 08:24:59 asus0.nmset.info NetworkManager[4136]: <info> [1708845899.6566] device (eth0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed') Feb 25 08:24:59 asus0.nmset.info NetworkManager[4136]: <info> [1708845899.6556] device (eth0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') Feb 25 08:24:59 asus0.nmset.info NetworkManager[4136]: <info> [1708845899.6551] manager: NetworkManager state is now CONNECTING Feb 25 08:24:59 asus0.nmset.info NetworkManager[4136]: <info> [1708845899.6546] device (eth0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') Feb 25 08:24:59 asus0.nmset.info NetworkManager[4136]: <info> [1708845899.6531] device (eth0): Activation: starting connection 'ETH0' (ea1d83f9-2dd7-4769-bbe9-ecd6aa48ff3b) Activating and deactivating NetworkManager-wait-online and NetworkManager- dispatcher do not help. Reverting to networkmanager-1.44.2-3 and networkmanager-qt5-5.112.0-1 is a working temporary solution. Devices: - Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15); Kernel driver in use: r8169 - Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78); Kernel driver in use: iwlwifi I'm reporting in the hope of a fix on the next upgrade. Regards.

6 9

libblockdev split plugins
by Abraham S.A.H. 02 Mar '24

02 Mar '24

Hello everyone, Probably a little late, but I noticed that `plugins of libblockdev` package has been split out to a few individual, smaller packages, as optional dependencies. Probably, most of the users already noticed that. However, when I did check, I found that all split plugin packages — `libblockdev-*` — take significant size compared to `libblockdev` package itself. `libblockdev` is less than 220 KiB. So splitting it really reduces the size of the package and helps dependency resolution, specially for `udisks2`. Nevertheless, `udisks2` already depends on 8 of those 14 split packages… And many users may need some of them explicitly as well.So at the end of the day, most of them are installed anyway! Interestingly, as far as I know, `libblockdev` is not required by any other package than `udisks2`!! So the benefit of splitting it will not go for any other package. My question is, was such dividing really beneficial? Considering that, it probably brings more work to the maintainer and doesn't do any significant change to the ending of the story? -- Best Regards, Abraham Sent with Tutanota; https://tuta.com

3 4

Bring ARM into the fold?
by Christer Solskogen 02 Mar '24

02 Mar '24

Is it time to bring Arch Linux ARM into the fold of Arch Linux? The GNU toolchain of ALARM is now very behind, and the developers are dead silent about why. There little to no response on pull requests on the github page, and while it seems like there is activity on their PKGBUILDs repo, it almost seems to me that it is some kind of automatic jobs being run. Their forum is broken and has been broken for quite some time as well. -- chs

3 2