RunningAroundIC Sounds like clr-boot-manager did not successfully run, possibly a full boot partition.
If you still have access to 5.14.10 and it's available in the boot menu, I would boot into that. You have two options after this, frankly I would suggest the first option.
The Easy Thing
- Revert the eopkg transaction(s) responsible for the installation of
-201 by following https://getsol.us/articles/package-management/history-and-rollback/en/ -- For example if it was transaction number 1000, you would do sudo eopkg history -t 999 to basically uninstall it.
- Wait until
201 is pushed to the stable repo.
The Hard(er) Thing
sudo clr-boot-manager update
sudo clr-boot-manager list-kernels
Return the result from the last command. If 5.14.12-201 isn't listed there, it may be indicative of a full EFI System Partition (ESP). Do the following:
- Run
lsblk to determine the partition device names. You may see sda or it might be even be nvme0n1 if it is an NVMe drive.
- Run
sudo fdisk -o Device,Size,Type -l /dev/###, replacing ### with either sda, nvme0n1, etc. You should see something like the following...
[~] sudo fdisk -o Device,Size,Type -l /dev/nvme0n1
Disk /dev/nvme0n1: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 970 EVO Plus 1TB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 1CDC09CE-51FC-456F-8E52-A5B5EDE6E12C
Device Size Type
/dev/nvme0n1p1 100M EFI System
/dev/nvme0n1p2 16M Microsoft reserved
/dev/nvme0n1p3 214.2G Microsoft basic data
/dev/nvme0n1p4 505M Windows recovery environment
/dev/nvme0n1p5 500M EFI System
/dev/nvme0n1p6 700.6G Linux filesystem
/dev/nvme0n1p7 15.6G Linux swap
Look for the EFI System. If you are dual-booting with Windows and had correctly followed our UEFI instructions, you should have a 500M EFI System partition. If you didn't, you are probably sharing it with Windows (big no no) and it's full with both Solus and Windows stuff.
In my example, my EFI System Partition is /dev/nvme0n1p5 and so I will run:
sudo mount /dev/nvme0n1p5 /boot
After this, I run sudo tree /boot, which returns
├── EFI
│ ├── Boot
│ │ └── BOOTX64.EFI
│ ├── com.solus-project
│ │ ├── initrd-com.solus-project.current.5.14.10-199
│ │ ├── initrd-com.solus-project.current.5.14.12-200
│ │ ├── initrd-com.solus-project.next.5.10.0-17
│ │ ├── kernel-com.solus-project.current.5.14.10-199
│ │ ├── kernel-com.solus-project.current.5.14.12-200
│ │ └── kernel-com.solus-project.next.5.10.0-17
│ └── systemd
│ └── systemd-bootx64.efi
└── loader
├── entries
│ ├── Solus-current-5.14.10-199.conf
│ ├── Solus-current-5.14.12-200.conf
│ └── Solus-next-5.10.0-17.conf
└── loader.conf
6 directories, 12 files
This is my desktop, not my laptop, and thus I have some extra stuff and not actually 201 (my laptop is what I tested 201 on).
In this scenario (as in, in your case, as you should be on .10), I would do the following:
- Remove 5.14.12* by doing:
sudo rm /boot/EFI/com.solus-project/*.solus-project.current.5.14.12-*
- Remove the 5.14.12* config by doing:
sudo rm /boot/loader/entries/Solus-current-5.14.12-*.conf
This would clean up space, and thus I would re-install the -201 kernels (following either the command from the task, or whatever means you did it). This is the easiest way to ensure clr-boot-manager is triggered and has the necessary files.
After this, re-run sudo clr-boot-manager list-kernels and sudo tree /boot (assuming it is still mounted) and double check that 201 is now listed. If it failed and /boot is still mounted, try doing sudo umount /bootthen try the clr-boot-manager update again.
