Page 1 of 1

[SOLVED] clr-boot-manager fails to update

Posted: Sat Feb 03, 2018 4:39 pm
by mrbongiolo
Hi, I've been using Solus for quite some time and got a weird message when trying to install it on my new desktop.

I've just installed on a new machine (mobo is a AsRock Z370 Fatality Gaming K6), afaik I booted it with UEFI and all, but when I try to set a new timeout and update `clr-boot-manager` I get the message below:

Code: Select all

    mrbongiolo@smaug ~ $ sudo CBM_DEBUG=1 clr-boot-manager update
    [INFO] cbm (src/bootman/bootman.c:L437): Current running kernel: 4.12.7-11.current
    [DEBUG] cbm (src/bootman/bootman.c:L124): UEFI boot now selected (systemd)
    [INFO] cbm (src/bootman/update.c:L75): Checking for mounted boot dir
    [FATAL] cbm (src/bootman/update.c:L85): Cannot determine boot device
    mrbongiolo@smaug ~ $ 
Any ideas of what might be happening?

I created the ESP partition and the Solus installer found it. My `/boot`:

Code: Select all

    mrbongiolo@smaug ~ $ sudo ls -R /boot/
    Password: 
    /boot/:
    mrbongiolo@smaug ~ $ 
Right now I just have Solus installed, but I'll install Windows too, I have a Dell Vostro with this setup and it's working perfectly.

I can boot normally, but it seems like I don't have access to other versions of the kernel...

System specs:

Code: Select all

$ inxi -Fz
System:    Host: smaug Kernel: 4.12.7-11.current x86_64 bits: 64 Desktop: Budgie 10.4  Distro: Solus 3
Machine:   Device: desktop Mobo: ASRock model: Z370 Gaming K6 serial: N/A UEFI: American Megatrends v: P1.30 date: 11/22/2017
CPU:       Hexa core Intel Core i5-8400 (-MCP-) cache: 9216 KB
           clock speeds: max: 4000 MHz 1: 799 MHz 2: 799 MHz 3: 799 MHz 4: 799 MHz 5: 799 MHz 6: 923 MHz
Graphics:  Card: Intel Device 3e92
           Display Server: x11 (X.Org 1.19.6 ) drivers: fbdev (unloaded: modesetting,vesa)
           Resolution: 1920x1080@0.00hz
           OpenGL: renderer: llvmpipe (LLVM 5.0, 256 bits) version: 3.3 Mesa 17.3.3
Audio:     Card Intel 200 Series PCH HD Audio driver: snd_hda_intel Sound: ALSA v: k4.12.7-11.current
Network:   Card-1: Intel Ethernet Connection (2) I219-V driver: e1000e
           IF: enp0s31f6 state: down mac: <filter>
           Card-2: Intel I211 Gigabit Network Connection driver: igb
           IF: enp4s0 state: down mac: <filter>
           Card-3: Qualcomm Atheros AR9271 802.11n driver: ath9k_htc
           IF: wlp0s20f0u3u2 state: N/A mac: N/A
Drives:    HDD Total Size: 500.1GB (4.4% used)
           ID-1: /dev/sda model: Samsung_SSD_850 size: 500.1GB
Partition: ID-1: / size: 20G used: 5.1G (28%) fs: ext4 dev: /dev/sda2
           ID-2: /home size: 77G used: 500M (1%) fs: ext4 dev: /dev/sda4
           ID-3: swap-1 size: 16.78GB used: 0.00GB (0%) fs: swap dev: /dev/sda3
Sensors:   None detected - is lm-sensors installed and configured?
Info:      Processes: 243 Uptime: 1:01 Memory: 1856.0/15788.2MB Client: Shell (bash) inxi: 2.3.38

Re: clr-boot-manager fails to update

Posted: Sat Feb 03, 2018 6:48 pm
by mrbongiolo
I think I kind of solved it, had to manually mount the ESP `/dev/sda1` to `/boot`, then run `sudo clr-boot-manager update`, rebooting I had access to 4.14. But after restart CBM kept on failing, to fix this I had to add this:
/dev/sda1 /boot vfat defaults 0 1
to `/etc/fstab`.

I'm not sure if that's the right way to do it, but it seems to be working.

Re: clr-boot-manager fails to update

Posted: Fri Feb 09, 2018 9:59 am
by sunnyflunk
mrbongiolo wrote:
Sat Feb 03, 2018 6:48 pm
I think I kind of solved it, had to manually mount the ESP `/dev/sda1` to `/boot`, then run `sudo clr-boot-manager update`, rebooting I had access to 4.14. But after restart CBM kept on failing, to fix this I had to add this:
/dev/sda1 /boot vfat defaults 0 1
to `/etc/fstab`.

I'm not sure if that's the right way to do it, but it seems to be working.
From what I've seen, your firmware is preventing variables to be written by the bootloader which is what clr-boot-manager uses to determine boot device. This works on >99% of machines but are now seeing some with this issue.

By having the ESP mounted, clr-boot-manager no longer needs to detect the booted ESP (which it fails to do), therefore you have done the best work around imo (but I only suggest doing it when having this issue)