Yea, that’s me. lol
It wouldn’t be just the HOOKS line but MODULES, FILES, BINARIES etc as well.
I’d say no as I do not like this meddling in config files in fhe first place.
I’d rather see a .pacnew to deal with for a manually adjusted config file than some automagic adjustment (and for non manually adjusted files the meddling isn’t even necessary as libalpm would simply overwrite those).
I understand your sentiment, but I want to make it easier for beginners with Manjaro.
Asking them to look out for log messages in install operations and then making 3-way diffs with pacnew files is not feasible.
Maybe we should provide a config flag somehow in the future to let advanced users like yourself handle config files maintenance themselves via opt-in and try to migrate beginners automatically.
Sounds good; plus the compulsory scary message warning that “There be dragons here…”
Or, is that overkill? It works (more or less) for Firefox!
Yea, a warning is fine too. I need to look into where to add this flag though. For this particular change I would go without the flag, but for future ones we hopefully have something then.
I created a MR with the change: fix: port HOOKS array to new array format (!2) · Merge requests · Packages / Core / mkinitcpio · GitLab
Maybe you can give it a go before it’s merged.
Just clone the repo and checkout the git branch.
Then execute from parent dir:
sudo chrootbuild -p mkinitcpio -b <your-manjaro-branch>`
sudo pacman -U mkinitcpio-39-5-any.pkg.tar.zst
Afterwards you can downgrade again via:
sudo pacman -S mkinitcpio
As mentioned:
So, may as well do it all at once.
Will do, but I’ll need a few minutes.
Edit:- On second thought, someone else may have better luck; I’m getting:
failed to commit transaction (conflicting files)
So, I must be doing something wrong.
Ok, added a second commit with some copy-pasta to cover the other cases.
Looks good to me:
==> Check if we should port MODULES to new array format in /etc/mkinitcpio.conf.
-> No string format found. No change.
==> Check if we should port BINARIES to new array format in /etc/mkinitcpio.conf.
-> No string format found. No change.
==> Check if we should port FILES to new array format in /etc/mkinitcpio.conf.
-> No string format found. No change.
==> Check if we should port HOOKS to new array format in /etc/mkinitcpio.conf.
-> No string format found. No change.
==> Check if we need to add "kms" to hooks in /etc/mkinitcpio.conf.
-> "kms" hook already exists. Doing nothing.
Ruby package has just been updated in Arch from 3.0.6 (which is now EOL) to 3.2.4.
I expect some things to break because of such a big bump. But honestly I’m happy it’s finally happening.
Will keep an eye out for when this hits Testing.
updates have dried up in unstable branch for some reason, are we holding-off updates (maybe new gcc)
upgraded mkinitcpio (39-4 → 39-5) said:
==> Check if we need to add "kms" to hooks in /etc/mkinitcpio.conf.
-> "kms" hook does not exist yet. Adding it to the HOOKS line.
-> Adding "kms" hook after "modconf" hook.
And then I reverted this after reboot, because my system runs faster without kms HOOK ![]()
I already forgot why this hook became a new default ![]()
Interesting. How do you measure this? And what hardware/drivers are you using?
I’d like to check/verify on my systems.
kernel mode setting.
https://wiki.archlinux.org/title/KMS
I always put it there.
Manjaro got hot and bothered about it needing to be there … because plymouth breaks boot with even more certainty if it is missing. Having kms doesnt magically make plymouth work in every case … but it cuts down the black screens by a decent percentage.
systemdd-analyze and systemd-analyze blame
graphic card: Navi 14 [Radeon RX 5500/5500M / Pro 5500M]
open drivers
That only shows boot up speed (I might add that I haven’t noticed any difference in that speed), and I haven’t seen it slow down the way my system runs.
@Yochanan i’ve been getting like really few updates (compared to arch stable) since last two days, i refreshed my mirrors to no avail. is this expected.
A post was split to a new topic: Remove Plymouth from the default install
Are those questions? If so, you may want to mark them as such. ![]()
The team is currently focusing on the next stable branch update along with new ISOs with KDE Plasma 6.
As you noticed, Arch just updated GCC. There have been a few issues with rebuilding packages like older NVIDIA kernel modules and Mesa, however it all seems to be resolved now.
Updates will resume soon