I had some disk space left, so I tried to expand it, but there was a `linux-swap’ partition in between, so I booted from live Mint ISO, deleted the swap, expanded, and then created new swap partition. All via GParted. After I tried to reboot, Fedor just wouldn’t boot, spinning endlessly.
After this I rebooted into Mint again and there’s what I tried:
sudo mkdir -p /mnt/fedora
sudo mount /dev/nvme0n1p8 /mnt/fedora
sudo mkdir -p /mnt/fedora/boot
sudo mount /dev/nvme0n1p7 /mnt/fedora/boot
sudo mkdir -p /mnt/fedora/boot/efi
sudo mount /dev/nvme0n1p1 /mnt/fedora/boot/efi
sudo mount --bind /dev /mnt/fedora/dev
# failed to mount --bind to dev
sudo mkdir -p /mnt/fedora/dev
sudo mount --bind /dev /mnt/fedora/dev
sudo mkdir -p /mnt/fedora/proc
sudo mount --bind /proc /mnt/fedora/proc
sudo mkdir -p /mnt/fedora/sys
sudo mount --bind /sys /mnt/fedora/sys
sudo chroot /mnt/fedora
# failed, /bin/bash not found or something
From here I don’t really know what to do. In lsblk I see nvme0n1p1 vfat, nvme0n1p2 vfat (UEFI and HP tools), nvme0n1p3 as my new swap, nvme0n1p7 ext4 (boot I assume), and nvme0n1p8 btrfs (Fedora).
When you get the spinner, you should be able to press the Esc key to see what process is trying to run and failing.
I would suggest adding rd.break to your kernel parameter list. That should cause the system to drop you into a rescue shell when something fails (or takes too long to succeed). From there, you could use commands like journalctl --since=-5min or systemctl --failed to find out what is failing and you might even be able to correct the problem from that shell.
Yeah, it is looking for one of the two partitions/filesystems you changed. I’m not sure which is failing. I think it is probably the Btrfs filesystem that it is failing to find. Try changing the root=UUID=... kernel parameter to root=/dev/nvme0n1p8. If that works, you’ll need to re-run the grub command to update the UUID in your boot configuration.
Edit: Also, you’ll probably need to run sudo btrfs fi resize max / after you get your system working again to get the filesystem to expand to fill/use the extra space you’ve allocated to the partition that it is on.
You could match the uuid from the message with the output of lsblk -f. My guess is it is the swap partition definition and the resome= option on the kernel command line that is the problem. When deleting the swap partition and create a new one, it will have a new uuid which must be adjusted in /etc/fstab and in /etc/default/grub.
On a second glance, I see that your system did find a filesystem labeled “fedora”, so I’m sure Villy is right. Unfortunately, I think the fstab that is causing the problem is probably embedded in your initramfs, so you will likely need to use that rd.break parameter to get to a rescue shell in the initramfs stage and then use vi /etc/fstab to fix the problem. Then systemctl daemon-reload to reload the configuration and exit to resume the boot sequence.
I’m not familiar with the resume= option. None of my systems use that. Maybe you could just delete that parameter (if your system has it) and it would boot.
Edit: To correct your initramfs after you get your system booted, you would need to correct /etc/fstab and run sudo dracut -f (or install a new kernel).
Edit2: An alternative way to fix the problem might be to manually set the new swap partition’s UUID to the same value the old swap partition had. That would be doable from an external environment such as your Mint ISO and then you wouldn’t need to regenerate your initramfs.
/etc/fstab is not included in the initramfs. I’ve stricken those comments since they were incorrect.
Back before the zram swap space became default, the install script would create the resume= option to point to where the hibernate data is stored. This would not work anyway when secure boot was enabled and therefore kernel-lockdown is also enabled. See man 7 kernel_lockdown for information about lockdown.
systemd has some generator programs and one of them finds the swap partition and arranges for the swap partition to be enabled. It is /usr/lib/systemd/system-generators/systemd-gpt-auto-generator which does this. For further information run man systemd-gpt-auto-generator.
It was generated by anaconda (the install procedure) if it decides to create this entry. I don’t know if it still can do that. So if you have a system that was originally installed as for example Fedora 20 you may see this the resume- entry.
If you look at your first post at the gparted image, you can see the swap being enabled. See the key icon next to the partition name. You don’t need a swap entry.
Do consider /etc/default/grub to be the master version of the command line, and the grub configuration would be updated from there. The grubby command is the preferred way to do this, but someone else could provide the details.
I’m not the best person to ask about Grub configuration. If Villy (or someone else) doesn’t have the time to explain it, you’ll probably have to search online or in the man pages. The man pages (e.g. man grubby) would be a better source of information as they are less likely to contain outdated info.
