Table of Contents
- Root Cause: Removed the Swap Partition
- Panic Started
- Fixing Elementary OS
- EndeavourOS Forum
- Things I Tried
- The Solution: Boot Parameters
I recently dual-booted my system with 2 Linux operating systems: EndeavourOS and elementary OS and I made a video about it here: https://youtu.be/KEup9DYAJYc After a few weeks, I hit a problem where my installation of EndeavourOS wasn’t able to boot anymore. It got stuck at this part where it said “A start job is running for /dev/disk/by-uuid/<my partition’s UUID here>” as you can see in the featured image above, and it did so for an eternity each time (a.k.a. “until I rebooted”)… There’s already a solution by the awesome people at the EndeavourOS Forum here: https://forum.endeavouros.com/t/stuck-on-a-start-job-is-running-for-dev-disk-by-uuid-while-booting-please-help/43048?page=2 but this blog post goes deeper into my journey into this: the how’s and why’s.
Root Cause: Removed the Swap Partition
I did 2 things which I thought probably led to this: deleting the swap partition and resizing the partition where EndeavourOS was. About removing the swap partition, look, I’m using a small 120 GB SSD. I wanted to try both EndeavourOS and elementary OS so I installed both on it in a dual-boot setup. I used the systemd-boot (dracut) bootloader for EndeavourOS and GRUB for elementary OS. If you’re not familiar with these, EndeavourOS (EnOS) is based on Arch Linux and Elementary is based on Ubuntu. But I think you already know that since you’re here. My initial partition setup was (in logical order):
- 1 GB for the boot partition
- 45 GB for EndeavourOS
- 45 GB for elementary OS
- 32 GB for the swap partition (since I have 32 GB of RAM – this was supposedly particularly for hibernation)
When I saw that I only had 2 GB of free space left, I decided to remove the swap partition. I have 32 GB of RAM so I thought, “I don’t think I’ll do anything which would require more than 20 GB of RAM in Linux anyway…” So I installed GParted, deleted the swap partition, enlarged elementary OS then moved it to the end, and finally resized EndeavourOS so it took up the remaining free space. All went well – until I rebooted.
Panic Started
During the first reboot, I left the computer to do something else, and came back to it kind of shocked to see that there was a line that said, “A start job is running for /dev/disk/by-uuid/<my partition’s UUID here>” which was already running for more than 5 minutes as indicated by that boot sequence. I waited for 2 more minutes and then tried to reboot with CTRL+ALT+DEL and was glad that it still responded to reboot because it reacted with something like “rebooting now” when I did it.
I waited for it to boot again, still nothing, so I rebooted to elementary OS. I waited for around less than 2 minutes before I wanted to give up. I was about to CTRL+ALT+DEL again when it suddenly loaded the desktop environment. Mind you, both operating systems took less than 20 seconds to boot in my setup – including the POST and BIOS screens. I rebooted to try and see if it would take the same time to boot since I know that it may have tried to fix sectors and partition issues while booting. It did. I rebooted a third and fourth time, but it was the same. So I started looking for “why”.
Fixing Elementary OS
My hunt for the fix led me to conclude that it was only because of the removal of the swap partition and then not “notifying” the operating systems about it. Fixing Elementary was a cinch since I just had to look for and remove the references to the missing partition in the “GRUB-y” entries in /etc/fstab and /etc/crypttab. Reboot, and… Voila! It was already booting again faster than I could freshen up my face in the bathroom and come back after the frustrating endeavor (pun is kind of intended).
EndeavourOS Forum
As for Endeavour… It just didn’t boot no matter how long I waited. And so I went back to Elementary, created a live USB, and booted from it. I tried searching for solutions before doing the same thing I did in Elementary because I thought, you know, systemd-boot and GRUB, different bootloaders. I am very glad that the EnOS forum exists, but I don’t know why, on my connection, it takes more than 5-8 minutes to initially load anything from the site. I’m not exaggerating. This made matters really, really frustrating. Opening multiple tabs will let them sit there loading, then when one loads, all the others also load at the same time.
I was already about to give up after 3 hours of searching but what mattered was that they loaded, so I persevered. All the answers, then, also led me to edit /etc/fstab. Nice. I was happy, and rebooted. To my surprise, it didn’t work. It still didn’t boot. Same “start job is running” message on the same partition UUID.
I went back to my /etc/fstab file to double-check but I saw that I had indeed already deleted the reference to the said UUID. I tried searching for the problematic UUID everywhere by doing “grep -r <UUID here> /” to “search all directories recursively for this UUID starting from the / directory”. It didn’t find any since, again, I had already removed all references of this UUID as far as I was aware.
Things I Tried
These are the things I tried to fix the problem; usually with a reboot involved to confirm if the solution worked:
- Mounted the drive/partition using the EndeavourOS Live USB
- chroot into the installation so I can switch the root directory from the live USB to the installation –
chroot /run/media/liveuser/endeavouros/(also tried arch-chroot) - edit /etc/fstab as super user –
sudo nano /etc/fstab - search all directories recursively for said UUID starting from the / directory –
grep -r <UUID here> /(no result) - Confirm the non-existence of said partition –
ls -l /dev/disk/by-uuid dracut-rebuild(failed: something /proc or /efi not mounted)- And possibly others I forgot
The Solution: Boot Parameters
Thanks to the guys over at the EnOS forum (Flame, pebcak, and pycrk) https://forum.endeavouros.com/t/stuck-on-a-start-job-is-running-for-dev-disk-by-uuid-while-booting-please-help/43048?page=2, after 4 more hours, I eventually found that I needed to change the boot parameters during the boot selection. I needed to look for “resume=UUID=<partition UUID>”. So, I rebooted, pressed the “e” key when I saw the EndeavourOS boot options, pressed the right arrow key until I saw that there was, indeed, that line I was looking for.
I removed it with Backspace/Delete, and pressed Enter. BAM! It booted! I tinkered with it a bit and then rebooted just to confirm that it works. Alas, it failed again. Apparently, I needed to make the change persistent. I rebooted, edited the boot options parameters again, and got into the desktop environment. According to the solution, I was supposed to do dracut-rebuild but found that they were doing it for a GRUB bootloader. I used systemd-boot so the /etc/default/grub directory didn’t exist in my system. I was getting confused.
I looked for /boot/efi like in the solution but the only thing in my /boot directory was a file named “intel-ucode.img”. So after a bit of playing around, I tried looking for it in my /efi directory but I had to be the root user to get into it so I did the “su” command to be the root user, entered my password, then navigated to it. Finally, I found mine in /efi/loader/entries and a file named “<series of numbers>-arch-1-1.conf”. I also had a file named “<series of numbers>-arch-1-1-fallback.conf”. I removed the “resume=UUID” instances in both files, rebooted 3 times just to confirm, and it worked!
I hope this article was of help to you!
Leave a Reply