You are not logged in.
looking similar to https://bbs.archlinux.org/viewtopic.php?id=311718
I just performed a system upgrade on my machine running Arch (Intel Thinkpad X11), boot hang at the "loading initial ramdisk"
When I temporarily edit the GRUB configuration to remove the "quiet" parameter, the message during the boot hang reads:
A start job is running for /cef08ad0-dxxx-xxx-xxx-xxxxxxxxxxx (4min 15s / no limit)I'll try to regenerate initramfs.
Last edited by 0xj0n (2026-01-19 12:58:25)
Offline
Post the same data from there, e.g. what your fstab/general partition layout looks like.
Offline
unable to boot, so just pasting content of fstab (read from a live img)
# Static information about the filesystems.
# See fstab(5) for details.
# <file system> <dir> <type> <options> <dump> <pass>
# /dev/nvme0n1p3
UUID=97d2ecda-5df7-4c26-b07c-16eef457e5ea / ext4 rw,relatime 0 1
# /dev/nvme0n1p1
UUID=E806-5B20 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro 0 2
# /dev/nvme0n1p2
UUID=cef08ad0-d7fa-4a16-a9d9-43a2d5d296b8 none swap defaults 0 0sorry for bothering you with this. Not sure where to look at...
Last edited by 0xj0n (2026-01-18 14:44:33)
Offline
Did you retype that or is that the actual file? If it's the actual file, you're trying to mount your swap partition to /?
Last edited by Scimmia (2026-01-18 14:26:55)
Offline
unable to boot, so typed (I know... please forgive the handmade copy-paste, it was faster to me than juggling between computers, I swear content is accurate)
looks indeed like the swap partition is being mounted to /
Didn't touch anything, just did system upgrade
Offline
Didn't touch anything, just did system upgrade
:colbertemoji:
But that won't work for sure, fix the entry ("none") and see whether your problems stop with it.
(Switching from busybox to systemd might have exposed that though I'd assume it to be the exact same fstab mount service generator)
Offline
For future reference: https://wiki.archlinux.org/title/List_o … n_services
Could very well be that systemd was ignoring that previously and it's not now or something like that. Either way, it's not valid. Does that UUID even exist?
Offline
Thank you both very much for your answers. Helps a lot.
Was able to boot after removing
resume=cef08ad0-d7fa-4a16-a9d9-43a2d5d296b8from GRUB configuration
Does that UUID even exist?
strangely, yes
$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 15 Jan 18 19:44 97d2ecda-5df7-4c26-b07c-16eef457e5ea -> ../../nvme0n1p3
lrwxrwxrwx 1 root root 15 Jan 18 19:44 cef08ad0-d7fa-4a16-a9d9-43a2d5d296b8 -> ../../nvme0n1p2
lrwxrwxrwx 1 root root 15 Jan 18 19:44 E806-5B20 -> ../../nvme0n1p1
$ fdisk -l
Device Start End Sectors Size Type
/dev/nvme0n1p1 2048 1050623 1048576 512M EFI System
/dev/nvme0n1p2 1050624 3147775 2097152 1G Linux swap
/dev/nvme0n1p3 3147776 500117503 496969728 237G Linux root (x86-64)Could very well be that systemd was ignoring that previously and it's not now
maybe yes...
But that won't work for sure, fix the entry ("none")
I'm not sure what's wrong with the entry.
UUID points to my swap partition, isn't that supposed to be ok?
from https://wiki.archlinux.org/title/Swap and https://wiki.archlinux.org/title/Fstab
I see syntax is
UUID=device_UUID none swap defaults 0 0
Offline
I'm not sure what's wrong with the entry.
I see syntax isUUID=device_UUID none swap defaults 0 0
UUID=cef08ad0-d7fa-4a16-a9d9-43a2d5d296b8 / swap defaults 0 0
Does re-adding "resume=cef08ad0-d7fa-4a16-a9d9-43a2d5d296b8" break the boot again??
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.
Offline
befrore your edit wrote:
UUID=cef08ad0-d7fa-4a16-a9d9-43a2d5d296b8 / swap defaults 0 0
Ugh... Apparently I'm too stupid to copy one line accurately by hand. I knew it was a bad idea and I did it anyway. I'm very sorry.
Version after edit is the current fstab running on my system.
I should have created a new message. I'm sorry about that. I'm a bit stressed by this.
Does re-adding "resume=cef08ad0-d7fa-4a16-a9d9-43a2d5d296b8" break the boot again??No, unfortunately this doesn't work.
sorry again for misleading you with the typo error. Fstab does look OK to me. I don't know why it doesn't work.
Offline
No, unfortunately this doesn't work.
ie. it *does* break the boot process?
If that's not a transcription error again, the correct syntax would be "resume=UUID=cef08ad0-d7fa-4a16-a9d9-43a2d5d296b8"
Offline
"resume=UUID=cef08ad0-d7fa-4a16-a9d9-43a2d5d296b8"
Oh! That's it! Thanks so much for your help and bearing with my mistakes.
Now it boots again but I'm confused about what went wrong and what solved the problem.
I should have copied the original fstab (first boot KO after upgrade), sorry again about that, lesson learned...
Basically we went from
- system upgrade
- boot stuck at
A start job is running for /cef08ad0-dxxx-xxx-xxx-xxxxxxxxxxx (4min 15s / no limit)- first boot ok by removing
resume=cef08ad0-d7fa-4a16-a9d9-43a2d5d296b8 from GRUB cmdline
- remove
resume=cef08ad0-d7fa-4a16-a9d9-43a2d5d296b8 from
/etc/default/grub- regenerate grub config with
grub-mkconfig -o /boot/grub/grub.cfg - disable swap with
systemctl mask 'dev-disk-by\x2ddiskseq-1\x2dpart2.swap'- undo the changes to grub cfg and restore unmask swap service
- in grub cfg, fix typo
s/resume=/resume=UUID= - regenerate grub config again
- boot OK
during our exchanges I didn't do manual changes to fstab swap entry.
So either "none" was here from the beginning, and boot was KO for other reason.
or there was indeed a
UUID=cef08ad0-d7fa-4a16-a9d9-43a2d5d296b8 / swap after upgrade but I don't get how it would have been changed to "none" without manual intervention.
Is that possible that fstab was regenerated somehow?
Thank you again so much for your help and patience.
Last edited by 0xj0n (2026-01-19 21:08:11)
Offline
Now it boots again but I'm confused about what went wrong and what solved the problem.
"resume=cef08ad0-d7fa-4a16-a9d9-43a2d5d296b8" has always been wrong and makes the system search for a drive at /cef08ad0-d7fa-4a16-a9d9-43a2d5d296b8 (instead of eg. /dev/sda3 or whatever)
Either switching from busybox to systemd or a systemd setup raised the "pickyness" about that, exposing the misconfiguration through a prolonged delay.
If there's ever been a bogus fstab entry it's not been related to this.
Offline
"resume=cef08ad0-d7fa-4a16-a9d9-43a2d5d296b8" has always been wrong and makes the system search for a drive at /cef08ad0-d7fa-4a16-a9d9-43a2d5d296b8 (instead of eg. /dev/sda3 or whatever)
Either switching from busybox to systemd or a systemd setup raised the "pickyness" about that
Ah yes, this explains the sudden break after upgrade... And this explains why
"resume=UUID=cef08ad0-d7fa-4a16-a9d9-43a2d5d296b8"fixed it.
Thanks again so much for your help.
Offline