Loading / to RAM forever

[olm52]

In Archlinux fully updated system and the right ramroot configuration (I have been using it for years) now I have

Loading / to RAM

at boot forever...

This is happening after some recent updates.
I have also tried to downgrade mkinitcpio to a previous version without success.

I have zswap.enabled=0 in kernel configuration line

[pagend0s]

Hi,
do you have systemd in HOOKS ? If so, the ramroot version you are using is not adapted for it. Remove systemd from HOOKS as I do here, for example: https://github.com/pagend0s/archus-b_linux/blob/main/resources/scripts/replace_hooks.sh . If you want, you can also try the version of ramroot I modified, which uses RSYNC instead of cp: https://github.com/pagend0s/archus-b_linux/tree/main/resources/scripts/ramroot_1.1
cheers

[arcmags]

It appears ramroot is not (yet) compatible with the new systemd hook now included by default on Arch Linux. I have begun to address this in a dev branch.

[olm52]

In the meantime I have added busybox before cp command

busybox cp .....

This is working

[arcmags]

Wait, is busybox cp working with the systemd hook in mkinitcpio.conf?

Right now, the dev branch I have going is working on a fresh Arch install when using the hooks as listed in README.md.

[olm52]

In /usr/lib/initcpio/hooks/ramroot
I have changed 3 lines:

busybox cp -a /local_root/. "/zram_root$mount_path"
busybox cp -a /zram_root/etc/ramroot.z/. /zram_root
busybox cp -a "$dir_home/.ramroot.z/." "$dir_home"

Working fine in fully updated Archlinux

[arcmags]

What is the value of HOOKS in your /etc/mkinitcpio.conf?

[olm52]

HOOKS=(base udev microcode modconf kms keyboard keymap block filesystems fsck)

[arcmags]

Hmm. I don't understand. ramroot is not in your HOOKS. How is it even doing anything if it isn't added to your initramfs image?

[olm52]

Yes this is before enabling ramroot. After enabling ramroot with the old (not dev) version system is booting to RAM.
I don't remember now in what place is added ramroot. I could do a test later.
Or you could test yourself.

[arcmags]

Okay. It would be added after udev in your case, and should work fine without changing the cp lines. The cp binary is included in the initramfs image with ramroot, so I'm at a loss as to why busybox cp should be necessary. See the dev branch above.

[arcmags]

Are you still having this issue? I have released a new version of ramroot with the documentation stating it is not compatible with a systemd initramfs. I am unable to reproduce these errors on various machines or qemu.

[olm52]

I can test next week, now on holidays...