Since I’m using custom mkinitcpio presets to generate UKIs, I deleted the default preset file inside /etc/mkinitcpio.d/ that came during system installation. Unfortunately, when pacman updates the kernel, the default preset file comes back, and the associated initramfs images get recreated automatically on top of my UKIs. The minor consequence is the waste of space on my boot partition, the major one is the inability to boot my system again if I forget to delete the undesired images before shutdown. I haven’t found how is triggered the creation of the preset file. The linux kernel package file does not include it. However there is a skeleton preset at /usr/share/mkinitcpio/hook.preset but I have no idea if it is really used during kernel update and how to prevent the generation of a new one.

I have been running both pacman -Syu and -Syuu with the following packages: > glibc make icu qt6-base linux-firmware pcaman-contrib > archlinux-contrib gcc-libs sh python wireplumber pipewire lha > base-devel fwupd linux-firmware-qlogic linux-firmware-bnx2x > linux-firmware-liquidio linux-firmware-mellanox linux-firmware-nfp The subsequent log gives no errors, only warnings. One is related to consolefonts in the mkinitcpio file. I've just been removing that element from the file and it doesn't seem to result in further problems. Another set of warnings relates to the AUR packages mentioned here https://wiki.archlinux.org/title/Mkinitcpio#Possibly_missing_firmware_for_module_XXXX . I've been installing them after the first -Syu and then re-runnign -Syu afterwards to check if they need any packages. However, every time I install upd72020x-fw, it always comes empty. I have no idea why or what effect this has. The last set of warnings mention permissions being different on the system than the package apparently wants. I've tried pre-empting these by manually changing the permissions using chmod to the numbers stated, but that just makes other packages warn about differing permissions. I've tried running -Syu without the extra packages, which leads to the same result. I've been saying yes to all of the "replace (package) with extra_main/(package)5" requests. If I do need to say no to them every time, is there a way to do so without having to type n for each? The system works fine if I don't use -Syu, but that limits what I can do with it severely. Processors: 4 x AMD Ryzen 3 2300X Quad-Core Processor Memory: 7.7 GiB Graphic Processor: AMD Radeon RX 570

after passing files to mkinitcpio via FILES or BINARIES in mkinitcpio.conf, where exactly do they end up? let's say I added FILES=(/usr/lib/firmware/edid/abc.bin) for example, with the above line:

# mkinitcpio -p linux
...
==> Creating zstd-compressed initcpio image: '/boot/initramfs-linux.img'
==> Initcpio image generation successful
# cpio -t < /boot/initramfs-linux.img
early_cpio
kernel/
kernel/x86/
kernel/x86/microcode/
kernel/x86/microcode/AuthenticAMD.bin
# ???

how can I make sure the generate init file do contain the file? And how can I be certain of the path to pass to kernel parameters?

I have been using **Arch Linux** for a while and studying about the **initramfs**. I thought of looking into the contents of the file to get a clear idea of it. I googled for various ways to peek through the file but I was not able to. Initially, I checked the file type of initramfs using the below command and got the following output: file /boot/initramfs-linux.img /boot/initramfs-linux.img: Zstandard compressed data (v0.8+), Dictionary IS: None I found that the file was **Zstandard compressed** and used the **zstd** tool to fetch the content of the file as follows: zstd -d /boot/initramfs-linux.img -o SOME_FILE_NAME That yielded gibberish result. I gave a file name as it's argument since it complained when I gave a directory. I thought that the initramfs file contains the initial root file system (set of files and directories). I am **naive** to Arch Linux and it's internals. Kindly help me through this. Thanks.

I'm setting up suspend-to-disk and resume in an 2021.12.x Arch Linux install. My question is about safely (without data-loss) unlocking partitions when resuming. Here is my configuration. The bootloader is grub 2.06, and I'm using a busybox-based initramfs. The relevant partitions are below. I'm not using LVM.

# partition	 encrypted	 mountpoint		decrypted volume name
- ---------  ---------   ----------     ---------------------
...
3 root		     luks2	 /				cryptroot
4 swap		     luks2	 [SWAP]			cryptswap
...

In /etc/mkinitcpio.conf I've configured these hooks.

HOOKS=(base udev ... openswap openroot ... resume ... filesystems fsck)

I'm not using the built-in encrypt hook. It can only unlock one device (typically only the root device which is specified in the cryptdevice kernel parameter), but I need to unlock the encrypted swap device, too. So instead of the encrypt hook I use two custom hooks: openswap and openroot. The openswap hook, in essence, runs: cryptsetup luksOpen cryptswap which prompts for a password. The openroot hook does the same for the root partition device: cryptsetup luksOpen cryptroot. Next, the built-in resume hook writes the swap device's major and minor numbers to /sys/power/resume .

printf "$devmajor:$devminor" >/sys/power/resume

There are two scenarios at this point. ### Scenario 1: If starting up after full shutdown When starting the computer after a full shutdown, there is no hibernation image in the unlocked swap partition. There is nothing to resume from, so a regular boot occurs. The root partition has been unlocked by this point (by the openroot hook), so booting can proceed correctly. No question of safety in this scenario. ### Scenario 2: If starting up after suspend-to-disk Earlier, when I would have initiated a suspend-to-disk, the root partition would have been in an unlocked and mounted state, and the hibernation image would have captured this state as is. Now, after kernel uses this hibernation image to resume, the system will continue to use this (already) unlocked/mounted root partition device. **This is where my question arises:** I know it is bad to *mount* a device in between suspend and resume. For example, kernel.org says : "If you touch anything on disk between suspend and resume… …kiss your data goodbye." My configuration doesn't do this. Is it similarly bad to cryptsetup luksOpen a device in between suspend and resume? Does cryptsetup luksOpen constitute touching (kernel.org terminology above) the disk? Recall that the initramfs openroot hook runs cryptsetup luksOpen cryptroot between suspend and resume. If so, how does one handle this?

Problem: I'm trying to set up an encrypted raid0 device with btrfs. I'm able to get beyond the first password prompt to enter the LUKS device but after that I get an error from fsck saying something like device UUID=187a468c-cab5-4a29-861e-8c5b2c7cca98 not found. I've been messing with it for about 12 hours now and I cant figure it out. I made sure to run grub-mkconfig before I reboot. Let me know if you need anymore info ``` $ blkid -o full /dev/mapper/zion: LABEL="root" UUID="187a468c-cab5-4a29-861e-8c5b2c7cca98" UUID_SUB="6cd2134e-5817-455a-a216-c41ce0495e63" BLOCK_SIZE="4096" TYPE="btrfs" /dev/sdc2: UUID="30786a7f-df33-4f36-8c80-4a4f7b4e145d" TYPE="crypto_LUKS" PARTUUID="07f3b77e-02" # /etc/crypttab zion UUID="30786a7f-df33-4f36-8c80-4a4f7b4e145d" none luks # /etc/fstab UUID=187a468c-cab5-4a29-861e-8c5b2c7cca98 / btrfs rw,relatime,space_cache,subvolid=5,subvol=/ 0 0 # /etc/mkinitcpio.conf HOOKS=(base udev keyboard autodetect modconf block mdadm_udev encrypt fsck btrfs filesystems fsck) # /etc/default/grub GRUB_DEFAULT=0 GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="Arch" GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet" GRUB_CMDLINE_LINUX="" GRUB_PRELOAD_MODULES="part_gpt part_msdos usb usb_keyboard ohci uhci ehci" GRUB_ENABLE_CRYPTODISK=y GRUB_DISABLE_OS_PROBER=y # other default values omitted # /etc/mdadm.conf ARRAY /dev/md/imsm0 metadata=imsm UUID=2c9194b5:2dc765c7:deb29150:22b74163 ARRAY /dev/md/zion_0 container=/dev/md/imsm0 member=0 UUID=533a48be:25fa4cb7:4111a783:7d68bb14 $ grub-mkconfig -o /boot/grub/grub.cfg Generating grub configuration file ... Found linux image: /boot/vmlinuz-linux-zen Found initrd image: /boot/initramfs-linux-zen.img Found fallback initrd image(s) in /boot: initramfs-linux-zen-fallback.img Found linux image: /boot/vmlinuz-linux Found initrd image: /boot/initramfs-linux.img Found fallback initrd image(s) in /boot: initramfs-linux-fallback.img Detecting snapshots ... # /boot/grub/grub.cfg # # DO NOT EDIT THIS FILE # # It is automatically generated by grub-mkconfig using templates # from /etc/grub.d and settings from /etc/default/grub # ### BEGIN /etc/grub.d/00_header ### insmod part_gpt insmod part_msdos insmod usb insmod usb_keyboard insmod ohci insmod uhci insmod ehci if [ -s $prefix/grubenv ]; then load_env fi if [ "${next_entry}" ] ; then set default="${next_entry}" set next_entry= save_env next_entry set boot_once=true else set default="0" fi if [ x"${feature_menuentry_id}" = xy ]; then menuentry_id_option="--id" else menuentry_id_option="" fi export menuentry_id_option if [ "${prev_saved_entry}" ]; then set saved_entry="${prev_saved_entry}" save_env saved_entry set prev_saved_entry= save_env prev_saved_entry set boot_once=true fi function savedefault { if [ -z "${boot_once}" ]; then saved_entry="${chosen}" save_env saved_entry fi } function load_video { if [ x$feature_all_video_module = xy ]; then insmod all_video else insmod efi_gop insmod efi_uga insmod ieee1275_fb insmod vbe insmod vga insmod video_bochs insmod video_cirrus fi } if [ x$feature_default_font_path = xy ] ; then font=unicode else insmod part_msdos insmod cryptodisk insmod luks insmod gcry_rijndael insmod gcry_rijndael insmod gcry_sha256 insmod btrfs cryptomount -u 30786a7fdf334f368c804a4f7b4e145d set root='cryptouuid/30786a7fdf334f368c804a4f7b4e145d' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint='cryptouuid/30786a7fdf334f368c804a4f7b4e145d' 187a468c-cab5-4a29-861e-8c5b2c7cca98 else search --no-floppy --fs-uuid --set=root 187a468c-cab5-4a29-861e-8c5b2c7cca98 fi font="/usr/share/grub/unicode.pf2" fi if loadfont $font ; then set gfxmode=auto load_video insmod gfxterm set locale_dir=$prefix/locale set lang=en_US insmod gettext fi terminal_input console usb_keyboard terminal_output gfxterm if [ x$feature_timeout_style = xy ] ; then set timeout_style=menu set timeout=5 # Fallback normal timeout code in case the timeout_style feature is # unavailable. else set timeout=5 fi ### END /etc/grub.d/00_header ### ### BEGIN /etc/grub.d/10_linux ### menuentry 'Arch Linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-187a468c-cab5-4a29-861e-8c5b2c7cca98' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod cryptodisk insmod luks insmod gcry_rijndael insmod gcry_rijndael insmod gcry_sha256 insmod btrfs cryptomount -u 30786a7fdf334f368c804a4f7b4e145d set root='cryptouuid/30786a7fdf334f368c804a4f7b4e145d' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint='cryptouuid/30786a7fdf334f368c804a4f7b4e145d' 187a468c-cab5-4a29-861e-8c5b2c7cca98 else search --no-floppy --fs-uuid --set=root 187a468c-cab5-4a29-861e-8c5b2c7cca98 fi echo 'Loading Linux linux-zen ...' linux /boot/vmlinuz-linux-zen root=UUID=187a468c-cab5-4a29-861e-8c5b2c7cca98 rw loglevel=3 quiet echo 'Loading initial ramdisk ...' initrd /boot/initramfs-linux-zen.img } submenu 'Advanced options for Arch Linux' $menuentry_id_option 'gnulinux-advanced-187a468c-cab5-4a29-861e-8c5b2c7cca98' { menuentry 'Arch Linux, with Linux linux-zen' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-zen-advanced-187a468c-cab5-4a29-861e-8c5b2c7cca98' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod cryptodisk insmod luks insmod gcry_rijndael insmod gcry_rijndael insmod gcry_sha256 insmod btrfs cryptomount -u 30786a7fdf334f368c804a4f7b4e145d set root='cryptouuid/30786a7fdf334f368c804a4f7b4e145d' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint='cryptouuid/30786a7fdf334f368c804a4f7b4e145d' 187a468c-cab5-4a29-861e-8c5b2c7cca98 else search --no-floppy --fs-uuid --set=root 187a468c-cab5-4a29-861e-8c5b2c7cca98 fi echo 'Loading Linux linux-zen ...' linux /boot/vmlinuz-linux-zen root=UUID=187a468c-cab5-4a29-861e-8c5b2c7cca98 rw loglevel=3 quiet echo 'Loading initial ramdisk ...' initrd /boot/initramfs-linux-zen.img } menuentry 'Arch Linux, with Linux linux-zen (fallback initramfs)' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-zen-fallback-187a468c-cab5-4a29-861e-8c5b2c7cca98' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod cryptodisk insmod luks insmod gcry_rijndael insmod gcry_rijndael insmod gcry_sha256 insmod btrfs cryptomount -u 30786a7fdf334f368c804a4f7b4e145d set root='cryptouuid/30786a7fdf334f368c804a4f7b4e145d' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint='cryptouuid/30786a7fdf334f368c804a4f7b4e145d' 187a468c-cab5-4a29-861e-8c5b2c7cca98 else search --no-floppy --fs-uuid --set=root 187a468c-cab5-4a29-861e-8c5b2c7cca98 fi echo 'Loading Linux linux-zen ...' linux /boot/vmlinuz-linux-zen root=UUID=187a468c-cab5-4a29-861e-8c5b2c7cca98 rw loglevel=3 quiet echo 'Loading initial ramdisk ...' initrd /boot/initramfs-linux-zen-fallback.img } menuentry 'Arch Linux, with Linux linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-advanced-187a468c-cab5-4a29-861e-8c5b2c7cca98' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod cryptodisk insmod luks insmod gcry_rijndael insmod gcry_rijndael insmod gcry_sha256 insmod btrfs cryptomount -u 30786a7fdf334f368c804a4f7b4e145d set root='cryptouuid/30786a7fdf334f368c804a4f7b4e145d' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint='cryptouuid/30786a7fdf334f368c804a4f7b4e145d' 187a468c-cab5-4a29-861e-8c5b2c7cca98 else search --no-floppy --fs-uuid --set=root 187a468c-cab5-4a29-861e-8c5b2c7cca98 fi echo 'Loading Linux linux ...' linux /boot/vmlinuz-linux root=UUID=187a468c-cab5-4a29-861e-8c5b2c7cca98 rw loglevel=3 quiet echo 'Loading initial ramdisk ...' initrd /boot/initramfs-linux.img } menuentry 'Arch Linux, with Linux linux (fallback initramfs)' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-linux-fallback-187a468c-cab5-4a29-861e-8c5b2c7cca98' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod cryptodisk insmod luks insmod gcry_rijndael insmod gcry_rijndael insmod gcry_sha256 insmod btrfs cryptomount -u 30786a7fdf334f368c804a4f7b4e145d set root='cryptouuid/30786a7fdf334f368c804a4f7b4e145d' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint='cryptouuid/30786a7fdf334f368c804a4f7b4e145d' 187a468c-cab5-4a29-861e-8c5b2c7cca98 else search --no-floppy --fs-uuid --set=root 187a468c-cab5-4a29-861e-8c5b2c7cca98 fi echo 'Loading Linux linux ...' linux /boot/vmlinuz-linux root=UUID=187a468c-cab5-4a29-861e-8c5b2c7cca98 rw loglevel=3 quiet echo 'Loading initial ramdisk ...' initrd /boot/initramfs-linux-fallback.img } } ### END /etc/grub.d/10_linux ### ### BEGIN /etc/grub.d/20_linux_xen ### ### END /etc/grub.d/20_linux_xen ### ### BEGIN /etc/grub.d/30_os-prober ### ### END /etc/grub.d/30_os-prober ### ### BEGIN /etc/grub.d/30_uefi-firmware ### ### END /etc/grub.d/30_uefi-firmware ### ### BEGIN /etc/grub.d/40_custom ### # This file provides an easy way to add custom menu entries. Simply type the # menu entries you want to add after this comment. Be careful not to change # the 'exec tail' line above. ### END /etc/grub.d/40_custom ### ### BEGIN /etc/grub.d/41_custom ### if [ -f ${config_directory}/custom.cfg ]; then source ${config_directory}/custom.cfg elif [ -z "${config_directory}" -a -f $prefix/custom.cfg ]; then source $prefix/custom.cfg fi ### END /etc/grub.d/41_custom ### ### BEGIN /etc/grub.d/41_snapshots-btrfs ### ### END /etc/grub.d/41_snapshots-btrfs ###

I've recently installed Arch Linux to a virtual disk, under a custom configuration for root on ZFS. This was in using some scripting I've put together for managing a multiboot configuration, with separate boot and root pools, each to be used both for Arch and FreeBSD. Presently, the ZFS pool configuration was created with FreeBSD under a VM. The Arch Linux installation was then created from another VM, where Arch was installed on an Ext4 partition. With Arch installed on the boot/root ZFS configuration and after some configuration for Grub, the Arch installation on ZFS now boots successfully. Presently, the virtual disk with the ZFS pools on it is running under a separate virtual machine. Arch Linux is the only OS installed on that machine's virtual disk, at this time. It boots successfully now, with a corresponding Grub2 configuration. However, I'm noticing a loop during shutdown.

[ 1561.324253] systemd-shutdown[1] : Sending SIGKILL to remaining processes...
[ 1561.336930] systemd-shutdown[1] : Unmounting file systems.
[ 1561.341650] : Remounting '/var' read-only in with options 'noxattr,noacl'.
[ 1561.783555] : Unmounting '/var'.
[ 1561.790194] : Remounting '/usr' read-only in with options 'noxattr,noacl'.
[ 1561.796853] : Remounting '/' read-only in with options 'noxattr,noacl'.
[ 1561.803420] systemd-shutdown[1] : All filesystems unmounted.
[ 1561.809423] systemd-shutdown[1] : Deactivating swaps.
[ 1561.813672] systemd-shutdown[1] : All swaps deactivated.
[ 1561.818688] systemd-shutdown[1] : Detaching loop devices.
[ 1561.824354] systemd-shutdown[1] : All loop devices detached.
[ 1561.829085] systemd-shutdown[1] : Stopping MD devices.
[ 1561.833346] systemd-shutdown[1] : All MD devices stopped.
[ 1561.837982] systemd-shutdown[1] : Detaching DM devices.
[ 1561.842299] systemd-shutdown[1] : All DM devices detached.
[ 1561.847501] systemd-shutdown[1] : All filesystems, swaps, loop devices, MD devices and DM devices detached.
[ 1561.856852] systemd-shutdown[1] : Successfully changed into root pivot.
[ 1561.863478] systemd-shutdown[1] : Returning to initrd...
[ 1562.306958] shutdown[1] : Syncing filesystems and block devices.
[ 1562.311377] shutdown[1] : Sending SIGTERM to remaining processes...
[ 1562.316903] shutdown[1] : Sending SIGKILL to remaining processes...
[ 1562.329374] shutdown[1] : Unmounting file systems.
[ 1562.334319] sd-remou: Remounting '/' read-only in with options 'noxattr,noacl'.
[ 1562.346902] sd-umoun: Unmounting '/oldroot/sys/kernel/config'.
[ 1562.354595] sd-umoun: Unmounting '/oldroot/sys/fs/fuse/connections'.
[ 1562.361525] sd-umoun: Unmounting '/oldroot/sys/kernel/tracing'.
[ 1562.368232] sd-umoun: Unmounting '/oldroot/sys/kernel/debug'.
[ 1562.373715] sd-umoun: Unmounting '/oldroot/dev/mqueue'.
[ 1562.380105] sd-umoun: Unmounting '/oldroot/dev/hugepages'.
[ 1562.386843] sd-umoun: Unmounting '/oldroot/sys/fs/bpf'.
[ 1562.391984] sd-umoun: Unmounting '/oldroot/sys/fs/pstore'.
[ 1562.397417] sd-umoun: Unmounting '/oldroot/sys/fs/cgroup'.
[ 1562.404234] audit: type=1334 audit(1635363440.667:81): prog-id=8 op=UNLOAD
[ 1562.410100] sd-umoun: Unmounting '/oldroot/dev/pts'.
[ 1562.414579] audit: type=1334 audit(1635363440.667:82): prog-id=6 op=UNLOAD
[ 1562.420101] sd-umoun: Unmounting '/oldroot/dev/shm'.
[ 1562.426852] sd-umoun: Unmounting '/oldroot/sys/kernel/security'.
[ 1562.432165] sd-umoun: Unmounting '/oldroot/usr'.
[ 1562.443869] sd-remou: Remounting '/oldroot/run' read-only in with options 'noxattr,noacl'.
[ 1562.456905] sd-umoun: Unmounting '/oldroot/run'.
[ 1562.461323] sd-umoun: Unmounting '/oldroot'.
[ 1562.466800] sd-umoun: Failed to unmount /oldroot: Device or resource busy
[ 1562.473458] sd-umoun: Unmounting '/oldroot/dev'.
[ 1562.478395] sd-umoun: Unmounting '/oldroot/sys'.
[ 1562.483288] sd-umoun: Unmounting '/oldroot/proc'.
[ 1562.488082] sd-umoun: Unmounting '/oldroot'.
[ 1562.493279] shutdown[1] : All filesystems unmounted.
[ 1562.498851] shutdown[1] : Deactivating swaps.
[ 1562.502456] shutdown[1] : All swaps deactivated.
[ 1562.506839] shutdown[1] : Detaching loop devices.
[ 1562.511505] shutdown[1] : All loop devices detached.
[ 1562.515404] shutdown[1] : Stopping MD devices.
[ 1562.520083] shutdown[1] : All MD devices stopped.
[ 1562.523666] shutdown[1] : Detaching DM devices.
[ 1562.527617] shutdown[1] : All DM devices detached.
[ 1562.531822] shutdown[1] : All filesystems, swaps, loop devices, MD devices and DM devices detached.
[ 1562.540145] shutdown[1] : Successfully changed into root pivot.
[ 1562.544940] shutdown[1] : Returning to initrd...

I've only encountered this with the Arch Linux installation on ZFS. Using the same systemd, mkinitcpio, linux, and zfs-linux versions under another VM installation, with Arch on an Ext4 partition there, there's no such loop occurring during shutdown in that machine. May it be due to the root on ZFS configuration? I'm at a loss for trying to figure out how to debug this loop any further. To my best guess, this may be related to some scripting for systemd-shutdown on mkinticpio, such that was introduced in 2013 (Bächler2013 ). What appears to be the main code in the mkinitcpio-generate-shutdown-ramfs service, introduced around that time - an excerpt of /usr/lib/systemd/system/mkinitcpio-generate-shutdown-ramfs.service

[Service]
Type=oneshot
# /tmp could be umounted at this point
# use /run as temporary directory
Environment=TMPDIR=/run
ExecStart=/usr/bin/mkinitcpio -A sd-shutdown -k none -c /dev/null -d /run/initramfs

Furthermore, the contents of the file /usr/lib/initcpio/install/sd-shutdown

#!/bin/bash

build() {
    add_binary /usr/lib/systemd/systemd-shutdown /shutdown

    if type -P kexec >/dev/null; then
        add_binary kexec
    fi
}

help() {
    cat <

I'm not certain if that's actually making it into the shutdown process, on the VM - the system might not meet the stated preconditions for that much. I've tried masking the mkinitcpio-generate-shutdown-ramfs service under systemd, then running mkinitcpio -P again, rebooting ... and it still goes into that loop during system shutdown. The system is still usable under the VM installation - at least, up to the point of that event in the shutdown, when the machine begins to loop indefinitely. Ideally I'd like to be able to work this knot out of the configuration, before installing anything beside Arch or putting this onto a machine's internal hard disk. I'm not certain what may be resulting in the message, Failed to unmount /oldroot: Device or resource busy. It may be something related to the root on ZFS installation? But that's just a guess, really. To my own perspective, the systemd-shutdown process - is it running under initrd, from what the console output says? I believe it seems nontrivial to debug, at this point. I'm certain I could continue towards using Arch for keeping the Grub configuration up to date, after installing FreeBSD beside Arch, in the ZFS pool configuration under the VM's virtual disk. If it's possible to fix this issue with the shutdown loop under Arch, however, I'd like to be able to maintain the Arch installation as a working desktop system - in the VM installation, or finally on the PC's hard disk. While I'm at a loss for trying to figure out how to debug this loop any further, for that loop during shutdown, maybe there's a patch that I just haven't found yet? **Update** I've found source code for systemd-shutdown, at the version in use on Arch Linux. I think it looks like some fairly straightforward code. There may not be a lot there about the 'oldroot' mount point, or how it could become unmountable under systemd-shutdown. It doesn't appear to be due to logging. I've set Storage=volatile in /etc/systemd/journald.conf and created a oneshot systemd service that runs /usr/bin/journalctl --flush after boot. The /var/ filesystem gets successfully umounted now, and I don't believe I'm loosing all of the log data across reboots. The loop is still occurring during the shutdown, however, along with the message Failed to unmount /oldroot... from systemd-shutdown. Is there something hanging it up by side effect?