boot.mount slowing down boot process

alba4k · 2025-04-20 17:17:36

I recently reinstalled arch on my laptop to use LUKS encryption.

However, I am noticing slower boot times and the problem appears to be boot.mount, according to systemd-analyze.

systemd-analyze

Startup finished in 6.904s (firmware) + 1.248s (loader) + 1.509s (kernel) + 2.754s (initrd) + 13.436s (userspace) = 25.854s
graphical.target reached after 13.436s in userspace.

systemd-analyze critical-chain

graphical.target @13.436s
└─multi-user.target @13.436s
  └─getty.target @13.436s
    └─getty@tty1.service @13.436s
      └─systemd-user-sessions.service @13.420s +14ms
        └─network.target @13.419s
          └─NetworkManager.service @13.073s +345ms
            └─network-pre.target @13.073s
              └─firewalld.service @12.806s +265ms
                └─polkit.service @12.851s +248ms
                  └─basic.target @12.805s
                    └─systemd-pcrphase-sysinit.service @12.775s +30ms
                      └─sysinit.target @12.771s
                        └─systemd-update-utmp.service @12.749s +21ms
                          └─systemd-tmpfiles-setup.service @12.656s +91ms
                            └─local-fs.target @12.647s
                              └─boot.mount @1.179s +11.467s
                                └─systemd-fsck@dev-disk-by\x2duuid-890D\x2dA1A5.service @363ms +35ms
                                  └─dev-disk-by\x2duuid-890D\x2dA1A5.device

systemd-analyze blame

11.467s boot.mount
 2.973s dev-ttyS3.device
 2.973s sys-devices-platform-serial8250-serial8250:0-serial8250:0.3-tty-ttyS3.device
 2.972s sys-devices-platform-serial8250-serial8250:0-serial8250:0.2-tty-ttyS2.device
 2.972s dev-ttyS2.device
 2.972s sys-devices-platform-serial8250-serial8250:0-serial8250:0.0-tty-ttyS0.device
 2.972s dev-ttyS0.device
 2.969s sys-devices-platform-serial8250-serial8250:0-serial8250:0.1-tty-ttyS1.device
 2.969s dev-ttyS1.device
 2.963s sys-devices-platform-STM0125:00-tpmrm-tpmrm0.device
 2.963s dev-tpmrm0.device
 2.954s sys-module-fuse.device
 2.953s sys-module-configfs.device
 2.931s dev-disk-by\x2dpartuuid-f03a4990\x2d4e38\x2d4c6e\x2da888\x2d0ba156e41f3b.device
 2.931s sys-devices-pci0000:00-0000:00:06.0-0000:01:00.0-nvme-nvme0-nvme0n1-nvme0n1p1.device
 2.931s dev-disk-by\x2did-nvme\x2dPM9A1_NVMe_Samsung_512GB_______S6H3NX2T530900_1\x2dpart1.device
 2.931s dev-disk-by\x2dpath-pci\x2d0000:01:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartnum-1.device
 2.931s dev-disk-by\x2dpath-pci\x2d0000:01:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartuuid-f03a4990\x2d4e38\x2d4c6e\x2da888\x2d0ba156e41f3b.device
 2.931s dev-nvme0n1p1.device
 2.931s dev-disk-by\x2did-nvme\x2dPM9A1_NVMe_Samsung_512GB_______S6H3NX2T530900\x2dpart1.device
 2.931s dev-disk-by\x2dpath-pci\x2d0000:01:00.0\x2dnvme\x2d1\x2dpart-by\x2duuid-890D\x2dA1A5.device
 2.931s dev-disk-by\x2did-nvme\x2deui.36483332545309000025385800000001\x2dpart1.device
 2.931s dev-disk-by\x2ddiskseq-1\x2dpart1.device
 2.931s dev-disk-by\x2dpath-pci\x2d0000:01:00.0\x2dnvme\x2d1\x2dpart1.device
[...]

This happens even when removing it from /etc/fstab.

I currently have a boot partition and a an encrypted btrfs partition containing @ and @home subvolumes

lsblk -f

nvme0n1
├─nvme0n1p1 vfat        FAT32       890D-A1A5                             492.9M    10% /boot
└─nvme0n1p2 crypto_LUKS 2           65122208-30dd-4061-b3d3-be44937ebbf4
  └─luks    btrfs                   b79991df-414d-46ee-92d2-4ced5190283f  446.9G     6% /home
                                                                                        /

Let me know if there's anything else I could add.

Last edited by alba4k (2025-04-20 17:20:49)

cryptearth · 2025-04-20 17:40:11

as you clearly not followed it - start over here: https://wiki.archlinux.org/title/Installation_guide
we can't support whatevery really bad instructions you followed (likely some random guide, a yt video, or worst: some ai)

a few points:
- why remove /boot from fstab? - your very next topic will be "system not booting after kernell update" - caused by: /boot not mounted during update
- syslx64.efi? unless you really try to use syslinux that's a rather strange name
- btrfs in a luks container is only useful for snapshots and has a high impact on scrubbing

Last edited by cryptearth (2025-04-20 17:44:50)

alba4k · 2025-04-20 18:05:46

as you clearly not followed it

I did, what would make you think I didn't?

why remove /boot from fstab?

I did not. I did that temporarily to check whether that would fix the issue. It didn't. I know it needs to be there

syslx64.efi?

Where did you even read that. Regardless, I'm booting from a UKI

btrfs in a luks container is only useful for snapshots and has a high impact on scrubbing

unrelated

-thc · 2025-04-21 05:44:54

Have you taken a look at the journal? If you want us to ta look too:

sudo journalctl -b -1 | curl -F 'file=@-' 0x0.st

alba4k · 2025-04-21 11:58:38

Here you go: https://0x0.st/8O7S.txt

Couldn't find anything directly related to boot.mount, though

qu@rk · 2025-04-21 12:32:14

At 13:07:14 mounting /boot starts, then there's

systemd[1]: Listening on Disk Image Download Service Socket.

and it takes about 11 seconds until

systemd[1]: Mounted /boot.

Maybe some VM stuff?

-thc · 2025-04-21 12:53:25

Well - this looks a bit odd.

One thing to note is that the dirty bit of your boot partition is set and fsck removes it. That sounds like a mishap on shutdown or reboot. That doesn't take very long - it's just odd.

The 11 second time jump in the log looks like it's cause is the boot partition mount but it's probably a coincidence.

Can you provide another log with disabled mount of the boot partition?

alba4k · 2025-04-21 17:52:52

Maybe some VM stuff?

Not on a vm. XPS 9320 (i7 1260P, secure boot)

One thing to note is that the dirty bit of your boot partition is set and fsck removes it. That sounds like a mishap on shutdown or reboot. That doesn't take very long - it's just odd.

Noticed that too. It happens consistently, even if I run fsck manually after boot

Something odd I just noticed, /dev/nvme0n1p1 is being mounted even without it being in /etc/fstab. Huh? http://0x0.st/8Vr8.txt

My first thought was "well that's probably systemd", however..

systemctl list-units --type=mount --all

  -.mount                              loaded active   mounted Root Mount
  boot.mount                           loaded inactive dead    EFI System Partition Automount
  dev-hugepages.mount                  loaded active   mounted Huge Pages File System
  dev-mqueue.mount                     loaded active   mounted POSIX Message Queue File System
  home-alba4k-Documenti-OneDrive.mount loaded active   mounted /home/alba4k/Documenti/OneDrive
  home.mount                           loaded active   mounted /home
  proc-sys-fs-binfmt_misc.mount        loaded inactive dead    Arbitrary Executable File Formats File System
  run-user-1000-doc.mount              loaded active   mounted /run/user/1000/doc
  run-user-1000-gvfs.mount             loaded active   mounted /run/user/1000/gvfs
  run-user-1000.mount                  loaded active   mounted /run/user/1000
  sys-fs-fuse-connections.mount        loaded active   mounted FUSE Control File System
  sys-kernel-config.mount              loaded active   mounted Kernel Configuration File System
  sys-kernel-debug.mount               loaded active   mounted Kernel Debug File System
  sys-kernel-tracing.mount             loaded active   mounted Kernel Trace File System
  tmp.mount                            loaded active   mounted Temporary Directory /tmp
  var-lib-machines.mount               loaded inactive dead    Virtual Machine and Container Storage (Compatibility)

Legend: LOAD   → Reflects whether the unit definition was properly loaded.
        ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
        SUB    → The low-level unit activation state, values depend on unit type.

Just in case:

systemctl cat boot.mount

# /run/systemd/generator.late/boot.mount
# Automatically generated by systemd-gpt-auto-generator

[Unit]
Description=EFI System Partition Automount
Documentation=man:systemd-gpt-auto-generator(8)
Requires=systemd-fsck@dev-disk-by\x2ddiskseq-1\x2dpart1.service
After=systemd-fsck@dev-disk-by\x2ddiskseq-1\x2dpart1.service
After=blockdev@dev-disk-by\x2ddiskseq-1\x2dpart1.target

[Mount]
What=/dev/disk/by-diskseq/1-part1
Where=/boot
Type=vfat
Options=umask=0077,rw,nodev,nosuid,noexec,nosymfollow

It looks like systemd isn't automatically mounting /boot, however it's still there in crytical-chain and the boot partition is, indeed, mounted

alba4k · 2025-04-21 18:17:59

apr 21 19:43:34 dell-xps systemd[1]: boot.automount: Got automount request for /boot, triggered by 596 (bootctl)
apr 21 19:43:34 dell-xps systemd[1]: Created slice Slice /system/systemd-fsck.
apr 21 19:43:34 dell-xps systemd[1]: Starting File System Check on /dev/disk/by-diskseq/1-part1...
apr 21 19:43:34 dell-xps systemd[1]: Finished File System Check on /dev/disk/by-diskseq/1-part1.
apr 21 19:43:34 dell-xps systemd[1]: Mounting EFI System Partition Automount...
apr 21 19:43:34 dell-xps systemd[1]: Finished Create System Files and Directories.
apr 21 19:43:34 dell-xps systemd[1]: Starting Rebuild Dynamic Linker Cache...
apr 21 19:43:34 dell-xps systemd[1]: First Boot Wizard was skipped because of an unmet condition check (ConditionFirstBoot=yes).
apr 21 19:43:34 dell-xps systemd[1]: First Boot Complete was skipped because of an unmet condition check (ConditionFirstBoot=yes).
apr 21 19:43:34 dell-xps systemd[1]: Starting Rebuild Journal Catalog...
apr 21 19:43:34 dell-xps systemd[1]: Save Transient machine-id to Disk was skipped because of an unmet condition check (ConditionPathIsMountPoint=/etc/machine-id).
apr 21 19:43:34 dell-xps systemd[1]: Starting Record System Boot/Shutdown in UTMP...
apr 21 19:43:34 dell-xps systemd[1]: Finished Record System Boot/Shutdown in UTMP.
apr 21 19:43:34 dell-xps systemd[1]: Finished Rebuild Journal Catalog.
apr 21 19:43:34 dell-xps systemd[1]: Finished Rebuild Dynamic Linker Cache.
apr 21 19:43:34 dell-xps systemd[1]: Starting Update is Completed...
apr 21 19:43:34 dell-xps systemd[1]: Finished Update is Completed.
apr 21 19:43:39 dell-xps systemd[1]: systemd-rfkill.service: Deactivated successfully.
apr 21 19:43:45 dell-xps kernel: PTP clock support registered
apr 21 19:43:45 dell-xps systemd[1]: Mounted EFI System Partition Automount.

Found this, but why would bootctl be mounting it? I'm not using systemd-boot

Also, the timings here look a bit weird, why are some events that happened at 19:43:45 listed before others that happened at 19:43:34?

apr 21 19:43:34 dell-xps kernel: intel_vsc intel_vsc: silicon stepping version is 0:2
apr 21 19:43:45 dell-xps kernel: input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/input/input8
apr 21 19:43:45 dell-xps kernel: mousedev: PS/2 mouse device common for all mice
apr 21 19:43:45 dell-xps kernel: Bluetooth: hci0: Waiting for firmware download to complete
apr 21 19:43:45 dell-xps kernel: Bluetooth: hci0: Firmware loaded in 1647450 usecs
apr 21 19:43:45 dell-xps kernel: Bluetooth: hci0: Waiting for device to boot
apr 21 19:43:45 dell-xps kernel: Bluetooth: hci0: Device booted in 16316 usecs
apr 21 19:43:45 dell-xps kernel: Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-0040-0041.ddc
apr 21 19:43:45 dell-xps kernel: Bluetooth: hci0: Applying Intel DDC parameters completed
apr 21 19:43:45 dell-xps kernel: Bluetooth: hci0: Firmware timestamp 2024.48 buildtype 1 build 81864
apr 21 19:43:45 dell-xps kernel: Bluetooth: hci0: Firmware SHA1: 0xc115e35a
apr 21 19:43:45 dell-xps kernel: Bluetooth: hci0: Fseq status: Success (0x00)
apr 21 19:43:45 dell-xps kernel: Bluetooth: hci0: Fseq executed: 00.00.02.41
apr 21 19:43:45 dell-xps kernel: Bluetooth: hci0: Fseq BT Top: 00.00.02.41
apr 21 19:43:45 dell-xps kernel: pci 0000:00:05.0: deferred probe pending: intel-ipu6: IPU6 bridge init failed
apr 21 19:43:34 dell-xps systemd[1]: Mounting /home...
apr 21 19:43:34 dell-xps systemd[1]: Mounting Temporary Directory /tmp...
apr 21 19:43:34 dell-xps systemd[1]: Virtual Machine and Container Storage (Compatibility) was skipped because of an unmet condition check (ConditionPathExists=/var/lib/machines.raw).
apr 21 19:43:34 dell-xps systemd[1]: Listening on Disk Image Download Service Socket.
apr 21 19:43:34 dell-xps systemd[1]: Mounted Temporary Directory /tmp.
apr 21 19:43:34 dell-xps systemd[1]: Mounted /home.
apr 21 19:43:45 dell-xps systemd-fsck[601]: fsck.fat 4.2 (2021-01-31)
apr 21 19:43:45 dell-xps systemd-fsck[601]: /dev/nvme0n1p1: 14 files, 14342/140520 clusters
apr 21 19:43:34 dell-xps systemd[1]: Reached target Local File Systems.
apr 21 19:43:34 dell-xps systemd[1]: Listening on Boot Entries Service Socket.
apr 21 19:43:34 dell-xps systemd[1]: Listening on System Extension Image Management.
apr 21 19:43:34 dell-xps systemd[1]: Set Up Additional Binary Formats was skipped because no trigger condition checks were met.
apr 21 19:43:34 dell-xps systemd[1]: Starting Update Boot Loader Random Seed...
apr 21 19:43:34 dell-xps systemd[1]: Starting Create System Files and Directories...
apr 21 19:43:34 dell-xps systemd[1]: boot.automount: Got automount request for /boot, triggered by 596 (bootctl)
apr 21 19:43:34 dell-xps systemd[1]: Created slice Slice /system/systemd-fsck.
apr 21 19:43:34 dell-xps systemd[1]: Starting File System Check on /dev/disk/by-diskseq/1-part1...
apr 21 19:43:34 dell-xps systemd[1]: Finished File System Check on /dev/disk/by-diskseq/1-part1.
apr 21 19:43:34 dell-xps systemd[1]: Mounting EFI System Partition Automount...
apr 21 19:43:34 dell-xps systemd[1]: Finished Create System Files and Directories.
apr 21 19:43:34 dell-xps systemd[1]: Starting Rebuild Dynamic Linker Cache...
apr 21 19:43:34 dell-xps systemd[1]: First Boot Wizard was skipped because of an unmet condition check (ConditionFirstBoot=yes).
apr 21 19:43:34 dell-xps systemd[1]: First Boot Complete was skipped because of an unmet condition check (ConditionFirstBoot=yes).
apr 21 19:43:34 dell-xps systemd[1]: Starting Rebuild Journal Catalog...
apr 21 19:43:34 dell-xps systemd[1]: Save Transient machine-id to Disk was skipped because of an unmet condition check (ConditionPathIsMountPoint=/etc/machine-id).
apr 21 19:43:34 dell-xps systemd[1]: Starting Record System Boot/Shutdown in UTMP...
apr 21 19:43:34 dell-xps systemd[1]: Finished Record System Boot/Shutdown in UTMP.
apr 21 19:43:34 dell-xps systemd[1]: Finished Rebuild Journal Catalog.
apr 21 19:43:34 dell-xps systemd[1]: Finished Rebuild Dynamic Linker Cache.
apr 21 19:43:34 dell-xps systemd[1]: Starting Update is Completed...
apr 21 19:43:34 dell-xps systemd[1]: Finished Update is Completed.
apr 21 19:43:39 dell-xps systemd[1]: systemd-rfkill.service: Deactivated successfully.
apr 21 19:43:45 dell-xps kernel: PTP clock support registered

-thc · 2025-04-22 05:35:18

alba4k wrote:

Found this, but why would bootctl be mounting it? I'm not using systemd-boot

This would explain, why excluding "boot" from fstab had no effect.

Check those:

ls -la /boot/EFI/systemd
ls -la /boot/EFI/loader
systemctl status systemd-boot-update.service
efibootmgr

alba4k · 2025-04-22 09:56:11

/boot/EFI/systemd doesn't exist, as expected
/boot/EFI/loader doesn't exist, I think you meant /boot/loader, which only contains the random-seed file (why would it, though?)

/boot
├── EFI
│   └── Linux
│       └── arch-linux.efi
├── intel-ucode.img
├── loader
│   └── random-seed
└── vmlinuz-linux

systemd-boot-update.service is disabled and there is no output, so nothing noteworty

BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000
Boot0000* Arch Linux	HD(1,GPT,f03a4990-4e38-4c6e-a888-0ba156e41f3b,0x800,0x113000)/\EFI\Linux\arch-linux.efi

alba4k · 2025-04-22 10:12:21

I might have found a "fix", will have to do some further research on why it worked

I removed /boot from fstab and masked boot.automount

After a reboot, boot.mount was gone and boot was not getting mounted (as expected). iwd.service appears to be taking up those 10 seconds now, the boot time did not change.

Disabling iwd.service (as NetworkManager starts it anyway, so it isn't really needed) fixed the boot time

Startup finished in 6.888s (firmware) + 1.268s (loader) + 1.519s (kernel) + 2.702s (initrd) + 1.770s (userspace) = 14.149s
graphical.target reached after 1.767s in userspace.

I will now try to unmask boot.automount and/or re-add /boot to fstab.

Here is a boot with a masked boot.automount, no /boot in fstab and disabled iwd.service: http://0x0.st/8VKT.txt

edit: Looks like adding back either one of those 3 things (iwd, automount or fstab entry) adds the delay back. iwd doesn't seem to be related in any way (it still takes 6 seconds to launch, as reported by systemd-analyze blame, but likely simply doesn't slow the boot when not explicitly enabled), so I'll just assume it takes some time for it to start after the system powers on. So the problem is likely still just the boot partition. Mounting it manually, even with the same args used in fstab, is fairly quick. Running fsck manually on it doesn't show anything unusual.

I could consider adding a custom systemd service that mounts the boot partition later, which of course would just be a workaround and not a clean fix, something like

# /etc/systemd/system/mount-boot-later.service
[Unit]
Description=Late mount /boot
After=multi-user.target
ConditionPathExists=/dev/disk/by-uuid/890D-A1A5

[Service]
Type=oneshot
ExecStart=/usr/bin/mount /dev/disk/by-uuid/890D-A1A5 /boot -o rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro

[Install]
WantedBy=multi-user.target

This works, but as I said, I would much prefer finding the cause of the delay in the first place. Also, in systemd-analyze-balme, I can still see how this service takes over 10 seconds to launch, just dosn't clog the boot process while starting

Last edited by alba4k (2025-04-22 10:34:32)

-thc · 2025-04-22 13:13:45

alba4k wrote:

/boot/loader, which only contains the random-seed file (why would it, though?)

The build process for UKI's seems to add "bootctl" functionality - this in turn creates the seed file.
I've seen this in my UKI boot too.

Some other things I noticed: Your startup summary contains an extra entry for "initrd" - mine (UKI/non-UKI) doesn't.
You seem to have enabled "onedriver", which starts before the network is up.

002445 · 2025-04-22 13:46:56

I am encoutering the same issue on a Dell XPS 9340. (Almost the same device as your 9320).

For some unknown reason the boot.mount is taking 10 seconds slowing down startup by 10 seconds. It didnt do this until somewhere last month I'd say. Startup used to be almost instant.

$ systemd-analyze blame
10.969s boot.mount

alba4k · 2025-04-22 18:50:50

Nice to know I'm not alone

You can also try my workaround

remove the boot partition from /etc/fstab, then create a file /etc/systemd/system/mount-boot-later.service

[Unit]
Description=Late mount /boot
After=multi-user.target
ConditionPathExists=/dev/disk/by-uuid/890D-A1A5

[Service]
Type=oneshot
ExecStart=/usr/bin/mount /dev/disk/by-uuid/890D-A1A5 /boot -o rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro

[Install]
WantedBy=multi-user.target

and then

# systemctl enable mount-boot-later.service
# systemctl mask boot.mount
# systemctl mask boot.automount

Last edited by alba4k (2025-04-22 20:50:34)

qu@rk · 2025-04-23 00:18:09

-thc wrote:

The build process for UKI's seems to add "bootctl" functionality - this in turn creates the seed file.
I've seen this in my UKI boot too.

I think I removed the seed file with "bootctl remove" or something similar. I deleted the loader folder and doesn't get created anymore.

Last edited by qu@rk (2025-04-23 00:19:06)

alba4k · 2025-04-23 18:11:39

Some other things I noticed: Your startup summary contains an extra entry for "initrd" - mine (UKI/non-UKI) doesn't.
You seem to have enabled "onedriver", which starts before the network is up.

Mh, none of those should be an issue, though

ernesto159 · 2025-04-28 08:10:36

I am also experiencing this issue, Dell XPS 9640 here (is it a Dell specific thing?).

My /boot partition is not encrypted, the rest is encrypted and I do not use secure boot.

I am currently running the linux-lts kernel, and I have been able to trace the issue back to kernel 6.12.19.
Reverting to 6.12.18 fixes the issue for me. I do not know how this translates on the stable branch.

The culprit might be somewhere there: https://lore.kernel.org/stable/20250313 … c7@gregkh/

Can you try reverting / installing kernel 6.12.18 and see if it fixes the issue for you?

002445 · 2025-05-02 10:54:55

After reinstalling Arch the boot.mount item doesn't take 10 seconds anymore, only 188ms now.

Edit: I did also disable the webcam from the BIOS, this seems to be the real "fix" and not the clean installation.

Last edited by 002445 (2025-05-05 06:31:08)

alba4k · 2025-05-03 13:02:45

I still have that issue after reinstalling, however I did not re-create any partitions, just cleared them,

tuxtax · 2025-05-04 00:43:50

ernesto159 wrote:

I am also experiencing this issue, Dell XPS 9640 here (is it a Dell specific thing?).
My /boot partition is not encrypted, the rest is encrypted and I do not use secure boot.
I am currently running the linux-lts kernel, and I have been able to trace the issue back to kernel 6.12.19.
Reverting to 6.12.18 fixes the issue for me. I do not know how this translates on the stable branch.
The culprit might be somewhere there: https://lore.kernel.org/stable/20250313 … c7@gregkh/
Can you try reverting / installing kernel 6.12.18 and see if it fixes the issue for you?

im having dell xps 9320 and the boot mount also happend to me, disable the camera fixs that

```
? 7% ❯ systemd-analyze blame
10.541s boot-efi.mount
10.541s boot-efi.mount
575ms power-profiles-daemon.service
385ms dev-nvme0n1p3.device
367ms upower.service
311ms polkit.service
304ms NetworkManager.service
191ms systemd-hostnamed.service
169ms user@1000.service
139ms systemd-tmpfiles-setup.service
137ms systemd-udev-trigger.service
101ms systemd-journal-flush.service
89ms systemd-vconsole-setup.service
68ms systemd-update-utmp.service
66ms systemd-journald.service
64ms systemd-tmpfiles-setup-dev-early.service
59ms dev-disk-by\x2duuid-3ee9f619\x2d5211\x2d495b\x2d966a\x2d59a2da6ec595.swap
56ms systemd-udevd.service
```

alba4k · 2025-05-04 09:12:11

sincerely, what the fuck, intel? I get that IPU6 on linux is a mess, but how could it possibly interfere with a partition not mounting properly.

ernesto159 · 2025-05-04 10:42:03

tuxtax wrote:

im having dell xps 9320 and the boot mount also happend to me, disable the camera fixs that

Thanks for pointing that out. It does indeed fix the issue for me too.

tuxtax · 2025-05-06 19:57:09

still exist in 6.14.5-arch1-1

Arch Linux

#1 2025-04-20 17:17:36

boot.mount slowing down boot process

#2 2025-04-20 17:40:11

Re: boot.mount slowing down boot process

#3 2025-04-20 18:05:46

Re: boot.mount slowing down boot process

#4 2025-04-21 05:44:54

Re: boot.mount slowing down boot process

#5 2025-04-21 11:58:38

Re: boot.mount slowing down boot process

#6 2025-04-21 12:32:14

Re: boot.mount slowing down boot process

#7 2025-04-21 12:53:25

Re: boot.mount slowing down boot process

#8 2025-04-21 17:52:52

Re: boot.mount slowing down boot process

#9 2025-04-21 18:17:59

Re: boot.mount slowing down boot process

#10 2025-04-22 05:35:18

Re: boot.mount slowing down boot process

#11 2025-04-22 09:56:11

Re: boot.mount slowing down boot process

#12 2025-04-22 10:12:21

Re: boot.mount slowing down boot process

#13 2025-04-22 13:13:45

Re: boot.mount slowing down boot process

#14 2025-04-22 13:46:56

Re: boot.mount slowing down boot process

#15 2025-04-22 18:50:50

Re: boot.mount slowing down boot process

#16 2025-04-23 00:18:09

Re: boot.mount slowing down boot process

#17 2025-04-23 18:11:39

Re: boot.mount slowing down boot process

#18 2025-04-28 08:10:36

Re: boot.mount slowing down boot process

#19 2025-05-02 10:54:55

Re: boot.mount slowing down boot process

#20 2025-05-03 13:02:45

Re: boot.mount slowing down boot process

#21 2025-05-04 00:43:50

Re: boot.mount slowing down boot process

#22 2025-05-04 09:12:11

Re: boot.mount slowing down boot process

#23 2025-05-04 10:42:03

Re: boot.mount slowing down boot process

#24 2025-05-06 19:57:09

Re: boot.mount slowing down boot process

Board footer