update via pamac GUI went well, however I noticed a new pacnew file was generated for mkinitcpio…
Upgrading mkinitcpio (31-2 -> 31-2.0)...
/etc/mkinitcpio.conf installed as /etc/mkinitcpio.conf.pacnew.
and since mkinitcpio it is a pretty important package, I’d like to make sure I handle merging the changes to the config file properly:
Understanding the 4 changes:
1&2. The first and second change just seems to be simple syntax changes where parenthesis have become the standard as opposed to a mix between quotes and parenthesis… “”()
3. The third change brings in the parenthesis standardization as above, but also removes the keymap parameter and relocates the keyboard parameter…
A. what impacts are there to removing the keymap parameter? Is there any reason I’d want to keep it?
B. does the order of the hooks really matter? What difference did it make moving keyboard after filesystems? If I did opt to keep keymap should I move it after filesystems too?
Having the new #MODULES_DECOMPRESS="yes" option disabled/remmed (to me) implies a default must have been used.
A. Is it safe to assume the “default” (assuming not done before the new feature was created) was “no, do not decompress modules”?
B. And if so, would revising this line to MODULES_DECOMPRESS="no" (without the rem) in essence mean to “keep things the same”?
C. What is the recommended setting?
D. How much more ram is being used and when (i.e. during boot or during command execution); and would the average user even notice or be concerned?
What to do now after the update has been applied (with the old conf) and we’ve rebooted?
I envision two scenario’s…
I could $ sudo rm /etc/mkinitcpio.conf, $ sudo mv /etc/mkinitcpio.conf.pacnew /etc/mkinitcpio.conf, then $ sudo mkinitcpio -P and reboot… but that feels lazy and doesn’t really inform me of the change or embrace the opportunity to learn something.
My gut is telling me to keep the first three changes as is (after considering the response to reinserting keymap) and updating change 4 to MODULES_DECOMPRESS="no" (assuming that would mimic the original behaviour, and that yes isn’t the new feature of choice) within the pacnew file before running the commands to $ sudo rm /etc/mkinitcpio.conf, then $ sudo mv /etc/mkinitcpio.conf.pacnew /etc/mkinitcpio.conf, then $ sudo mkinitcpio -P and reboot
No issues here - Firefox is great - but if you have a problem with a profile, firefox -P is enough. Just go ahead and purge/delete/burn that profile and the folder…
Create new… ‘thingsiplay’ user.
Select use the selected profile without asking at startup …
Start it up.
At this point, I need to open bitwarden and/or add my bitwarden extension to get the password to sync firefox… and sign in to synchronise.
I have the same issue. Numerous warnings occur when “Building image from preset”. I did confirm that I can boot using this newly created image.
( 9/21) Updating module dependencies...
depmod: WARNING: could not open modules.builtin.modinfo at /lib/modules/4.19.251-1-MANJARO: No such file or directory
(10/21) Updating linux initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux419.preset: 'default'
-> -k /boot/vmlinuz-4.19-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-4.19-x86_64.img
==> Starting build: 4.19.251-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: [filesystems]
-> Running build hook: [keyboard]
==> Generating module dependencies
install: cannot stat '/lib/modules/4.19.251-1-MANJARO/modules.builtin.modinfo': No such file or directory
depmod: WARNING: could not open modules.builtin.modinfo at /tmp/mkinitcpio.9o3whd/root/lib/modules/4.19.251-1-MANJARO: No such file or directory
==> Creating gzip-compressed initcpio image: /boot/initramfs-4.19-x86_64.img
==> WARNING: errors were encountered during the build. The image may not be complete.
==> Building image from preset: /etc/mkinitcpio.d/linux419.preset: 'fallback'
-> -k /boot/vmlinuz-4.19-x86_64 -c /etc/mkinitcpio.conf -g /boot/initramfs-4.19-x86_64-fallback.img -S autodetect
==> Starting build: 4.19.251-1-MANJARO
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [modconf]
-> Running build hook: [block]
==> WARNING: Possibly missing firmware for module: bfa
==> WARNING: Possibly missing firmware for module: qed
==> WARNING: Possibly missing firmware for module: qla1280
==> WARNING: Possibly missing firmware for module: qla2xxx
-> Running build hook: [filesystems]
-> Running build hook: [keyboard]
==> Generating module dependencies
install: cannot stat '/lib/modules/4.19.251-1-MANJARO/modules.builtin.modinfo': No such file or directory
depmod: WARNING: could not open modules.builtin.modinfo at /tmp/mkinitcpio.M02rTA/root/lib/modules/4.19.251-1-MANJARO: No such file or directory
==> Creating gzip-compressed initcpio image: /boot/initramfs-4.19-x86_64-fallback.img
==> WARNING: errors were encountered during the build. The image may not be complete.
In this upgrade, inside file mkinitcpio.conf, in HOOKS line systemd was replaced by udev, should apply the new change ?
mkinitcpio.conf : HOOKS=(base systemd autodetect modconf block filesystems keyboard fsck)
mkinitcpio.conf.pacnew : HOOKS=(base udev autodetect modconf block filesystems keyboard fsck)
I also get this error. If you go to Hamburger - Help - More troubleshooting information, then it lists there recent crashes. If you click on the crash, it’ll show some details and matched bugs on Bugzilla.
After updating and booting with Kernel 5.18.10-1, smb-mounts for my Synology NAS I did set up via systemd mounts fail.
Reverting back to Kernel 5.17.15-1 or 5.15.53-1 brings back the mounts.
As I am not a deeply technical user, I kind of struggle to figure out, what happens here … …
Also I wonder why Manjaro reverted zstd compression by default. I noticed that after fixing .pacnew mkinitcpio started to generate gzip compressed images.
Xfce: I have five systems with Manjaro xfce. I updated one, no problems. Moved on to the next one. No problems, EXCEPT, for some reason the update installed “pipewire 1:0.3.54-1”.
None of my systems have pipewire.
I removed it, I just don’t understand why that was installed on one system and not the other.
Oh well, we’ll see what happens with the remaining three systems.
I was on track and currently using my profile by deleting/renaming the prefs.js! Just woke up and will try the suggested solution (high hopes now). Thank you for this in advance.
After today’s update, I encountered a minor issue with the python-docutils package and the Spyder IDE.
Here’s the error message when I tried to start Spyder:
pkg_resources.DistributionNotFound: The 'docutils<0.19,>=0.14' distribution was not found and is required by sphinx
Reverting to python-docutils-1:0.18-1 fixes this compatibility issue
()
