You need to load kernel first and root is in a btrfs partition

There were some threads similar to this but my details are slightly different from them so I can’t follow them.

I probably had a failed update attempt because my root partition was getting full. When I booted I had the infamous you need to load the kernel first error.

I have a btrfs root partition and a btrfs home partition. I booted on a live USB and when I try to run sudo manjaro-chroot -a it says

[manjaro@manjaro ~]$ su
[manjaro manjaro]# manjaro-chroot -a
grub-probe: error: cannot find a GRUB drive for /dev/sdb1.  Check your device.map.
grub-probe: error: cannot find a GRUB drive for /dev/sdb1.  Check your device.map.
==> ERROR: No Linux partitions detected!

Probably because I do not have the canonical set up. How should I proceed?

Can you share the output lsblk -f ?

1 Like

Can you boot a Manjaro USB stick and chroot into the system ?

1 Like

manjaro-chroot does not support btrfs. You need to mount the individual subvolumes manually, but the way Calamares sets up the root filesystem is different to what one would expect. Instead of using the actual root directory of the btrfs filesystem — which has subvolid=5 — it uses a designated subvolume called @, with a different subvolid — on my system, it’s subvolid=257, but it may be different on yours.

Your problem is probably that your system doesn’t mount the correct root subvolume. You need to use the subvolid= and/or subvol=@ options when mounting, and only after you’ve mounted everything can you use manjaro-chroot to further mount things like /dev, /proc, /sys and /run.

Once in the chroot, you need to rebuild your initcpios in order to let the kernel know where the root filesystem is, and grub-install to let GRUB know where to install itself.

1 Like

Most likely this, but cat /etc/fstab and lsblk should give you all info needed.
I only needed to mount root and boot to be able to chroot into my system from live env. But if I needed to f ex update my grub, I also needed to bind mount my run, no idea why and never found an explanation of why, but it works for me.
The devices will obv be different for you.

sudo mount -t btrfs -o subvol=@ /dev/sda7 /mnt
sudo mount -t vfat /dev/sda5 /mnt/boot/efi
sudo mkdir /mnt/hostrun
sudo mount --bind /run /mnt/hostrun
sudo manjaro-chroot /mnt /bin/bash

And from within chroot:

mount --bind /hostrun /run

This is the ONLY way I got completely “working” chroot.
I can chroot without the run dir, but can not do everything in the chroot env (like f ex update-grub)
I have tried MANY different ways.

I still would love an explanation of why I HAVE to --bind /run, since I have read ppl say to NEVER use --bind on those mounts, but if I don’t, I can not chroot and repair my system completely from within chroot.

2 Likes

No, you misunderstood that. :wink: What I said was to never use bind-mounts for /proc and /sys. :wink:

That said, I don’t know why /run should be mounted either, but part of /run’s functionality is to contain what used to be in /var/run, which is now a symlink to /run. I have either way always managed to manually chroot without mounting /run, so your mileage may vary. :wink:


Edit: Okay, I think I know why you should also mount /run before chrooting, i.e. it is indeed being written to, and if it’s not mounted, then those files will remain on the root filesystem but become obscured when you’re running the system from the on-disk installation. I just discovered this on my system. :wink:

But… We are drifting off-topic. This thread is about the problem @despondentcry is having. :wink:

2 Likes

Aaah, did not want to name names, but you are an honest person and have a good memory. xD

I interpreted the comment you are referencing to “never use --bind on a virtual directory”.

But thank you for clarifying! :hearts:

Edit
I would like to clarify:

  • if I do NOT mount run, the /run directory in my chroot is empty.
  • If I try to mount it “normally” without --bind directly to /mnt/run, it creates a directory inside run called “mount”.
  • If I mount run directly to /mnt/run WITH --bind, same thing (only a directory called “mount” inside /run)
  • If I mount run “normally” to /mnt/hostrun, /hostrun contains only a directory called “mount” (like if I mount it directly to /mnt/run)
  • If I mount it like I describe above, I can see all the directories normally showing in /run in /hostrun and then --bind mount that to /run within chroot.

All very strange imho and maybe @despondentcry will come back with a report how this works on his system. :smiley:

2 Likes

Thank you very much for all the effort to help me out.

I don’t know if I should follow @Aragorn or @bedna. My output for lsblk

NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0         7:0    0 146.1M  1 loop /run/miso/sfs/livefs
loop1         7:1    0   1.1G  1 loop /run/miso/sfs/mhwdfs
loop2         7:2    0   1.5G  1 loop /run/miso/sfs/desktopfs
loop3         7:3    0 653.7M  1 loop /run/miso/sfs/rootfs
sda           8:0    0 931.5G  0 disk 
└─sda1        8:1    0 931.5G  0 part 
sdb           8:16   1  57.8G  0 disk /run/miso/bootmnt
├─sdb1        8:17   1   3.5G  0 part 
└─sdb2        8:18   1     4M  0 part 
nvme0n1     259:0    0 238.5G  0 disk 
├─nvme0n1p1 259:1    0   512M  0 part 
├─nvme0n1p2 259:2    0     5G  0 part 
├─nvme0n1p3 259:3    0  65.9G  0 part 
└─nvme0n1p4 259:4    0 167.1G  0 part

While my /etc/fstab is weirdly short

#
# /etc/fstab: static file system information
#
# <file system>        <dir>         <type>    <options>          <dump> <pass>
/dev/mapper/root-image /             auto      defaults           0      0

I tried what @bedna suggested and I think it work. My rational was that I tried to mount the partitions where I have my root and boot in that auxiliary directory.

I’m now unsure on how to try to rebuild the initcpios and do the grub-install ?

We are both saying the same thing me and Aragon, he just didn’t put the actual commands.
He uses the id and I use the @, but the outcome would be the same.
If you also want to mount /dev, /proc & /sys check your fstab how they are mounted.
The reason I didn’t include them was because when I had issues with grub, I did not have to mount them, only /run, / and /boot/efi.

Within your chroot: (commands ran as root)

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
grub-mkconfig -o /boot/grub/grub.cfg
2 Likes

I believe nvme0n1p1 is for the mount-point /boot/efi.

But there is a lack of information:

Is nvme0n1p2 for swap?
Is nvme0n1p3 for root system?
Is nvme0n1p4 for home?

You need to mount these partitions correctly, then use manjaro-chroot.

2 Likes

Why would he need swap and home to install grub?
I certainly did not.

1 Like

Thank you @bedna

I ran your mount commands with the correct partitions and I didn’t get any output so I assume it worked

I ran your last command and obtained

[manjaro /]# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
Installing for x86_64-efi platform.
Installation finished. No error reported.
[manjaro /]# grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
grub-probe: error: cannot find a GRUB drive for /dev/sdb1.  Check your device.map.
grub-probe: error: cannot find a GRUB drive for /dev/sdb1.  Check your device.map.
Adding boot menu entry for UEFI Firmware Settings ...
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
done

I tried to reboot but now the grub doesn’t have any kernel to choose from so I assume something went wrong. Maybe with the grub-probe: error: cannot find a GRUB drive for /dev/sdb1. Check your device.map. grub-probe: error: cannot find a GRUB drive for /dev/sdb1. Check your device.map.

Any thoughts?

I just realized, fstab shows your live fstab, you need to check the fstab on your root, but nvn, we can prob figure this out anyway. Sorry about that.

That is not your boot, that is the boot for the live iso, I think!! Or a win boot since it detects a memtest there.

Isn’t nvme0n1p1 your boot?
That is what you have to mount before using chroot.

Edit
I understand your confusion, I HAD sd** in my mount, because I dont have my boot on an nvme, I have mine on an old ssd, hence the sd**
Im not sure if nvme0n1p4 or nvme0n1p3 is your root, one of them is probably your home, you have to figure that out on the first row command, I will use nvme0n1p3 in this example. You want to mount the root, not your home.
The mkdir command is obv not needed if you have chroot:ed and made that directory before, but it wont break if you try to create an existing directory, so I leave it in.
So in your case:

sudo mount -t btrfs -o subvol=@ /dev/nvme0n1p3 /mnt
sudo mount -t vfat /dev/nvme0n1p1 /mnt/boot/efi
sudo mkdir /mnt/hostrun
sudo mount --bind /run /mnt/hostrun
sudo manjaro-chroot /mnt /bin/bash
mount --bind /hostrun /run

Then try to reinstall grub.

1 Like

Now the output was slightly different

[manjaro /]# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
Installing for x86_64-efi platform.
Installation finished. No error reported.
[manjaro /]# grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
ERROR: mkdir /var/lock/dmraid
grub-probe: error: cannot find a GRUB drive for /dev/sdb1.  Check your device.map.
grub-probe: error: cannot find a GRUB drive for /dev/sdb1.  Check your device.map.
Adding boot menu entry for UEFI Firmware Settings ...
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
done

Edit: So I guess the grub-prober not recognizing the sdb1 isn’t a problem. But is ERROR: mkdir /var/lock/dmraid problematic. I just want to make sure with you before I reboot because everytime I reboot I have to do it all over again.

That was the error I got when I didn’t mount my run correctly EXACTLY like I typed it. Did you forget the last mount within the chroot? You might have coped my commands before I edited and added the last --bind mount within chroot, I actually forgot it first. Sorry again. :flushed:
It was only grub telling me os-prober failed to work correctly adding my win11 boot option.

But it still let me boot to manjaro (but my win11 entry was gone) and then let me do the update-grub from my normal system and that fixed everything.

But does it work to reboot now?

Another solution is to just choose “select boot” (or something like that) at the bottom of your grub menu on your live iso usb, then select the manjaro one and THEN do the update grub from your normal system. (don’t think you need to reinstall grub in that case). Just run sudo update-grub from your “normal” system, not live)
That might also be an option if you dont get this to work.

Do you have win on your computer, or is sdb1 the live iso? I actually don’t remember the output, it might be the live boot it is trying to add, and then you can just ignore it.

2 Likes

If this is the case, you need to fix this problem first. As long as your file system is full, there is nothing you can do.

For a tutorial on this issue see:

  • You must boot from a live Manjaro
  • You must mount your “full” file system
  • (do not chroot)
  • You must clean up the mess!
  • After that you can redo the update with chroot

:footprints:

2 Likes

The thing is my update first failed because of the lack of size, then I uninstalled some packages and I was with still 2 GB of space left. Only after I rebooted my system failed to reboot. I guess 2 GB left are enough to make this work no?

Thank you for your endless help!

The output of the grub reinstall is like this now

[manjaro /]# grub-mkconfig -o /boot/grub/grub.cfg
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
grub-probe: error: cannot find a GRUB drive for /dev/sdb1.  Check your device.map.
grub-probe: error: cannot find a GRUB drive for /dev/sdb1.  Check your device.map.
Adding boot menu entry for UEFI Firmware Settings ...
Found memtest86+ image: /boot/memtest86+/memtest.bin
/usr/bin/grub-probe: warning: unknown device type nvme0n1.
done

There doesn’t seem anything wrong. The live usb grub identifies two efi boots but when I click both of them it doesn’t work.

Only

sudo btrfs filesystem usage 

will tell.
You need to have some unallocated space (see the wiki why) to be able to redo your update. “free” space is not enough for btrfs. :man_shrugging:
:footprints:

2 Likes

Thank you all. I’m getting progressively more confused but I will not surrender!

I used gparted to get more space for my btrfs root partition

btrfs filesystem usage /mnt 
WARNING: cannot read detailed chunk info, per-device usage will not be shown, run as root
Overall:
    Device size:		  76.28GiB
    Device allocated:		  66.10GiB
    Device unallocated:		  10.18GiB
    Device missing:		     0.00B
    Device slack:		  16.00EiB
    Used:			  63.97GiB
    Free (estimated):		  11.17GiB	(min: 11.17GiB)
    Free (statfs, df):		  11.17GiB
    Data ratio:			      1.00
    Metadata ratio:		      1.00
    Global reserve:		 138.42MiB	(used: 0.00B)
    Multiple profiles:		        no

Data,single: Size:63.57GiB, Used:62.58GiB (98.44%)

Metadata,single: Size:2.50GiB, Used:1.40GiB (55.95%)

System,single: Size:32.00MiB, Used:16.00KiB (0.05%)


I tried again the prescriptions of @bedna but I stil don’t see anything to boot in the grub.

Is there anything I could check to see if there is something wrong in my system ?

Edit I don’t know if I should do something to the root partition after giving it more space. I did what is mentioned in the wiki.