Problems with EFI and GRUB on install. (Btrfs, dual boot, no-luks)

#1

Hey guys. Been off linux for a while but went and tried to install it, I set down for arch labs, seems like a good cross between real arch and simple installation (with drivers and such).

The archlabs installer doesn’t support built-in btrfs partitioning. I might not need btrfs, but want to spice it up for the fun of it. But I found a guide (https://github.com/Baumgartl/archlabs-btrfs) which showed how to make the partitions and then mount them. The installer will then go about and install.

First, I got an error, about linux zen (which I chose) and something not found. Instead of cleaning the partitions I mounted them and installed again (which I probably shouldn’t have) and stock kernel. But what I have problem with is EFI. I tried so much, chrooting and grub install. Making a config in /boot/grub, one in /boot/efi/grub, one in /boot/efi/efi/grub. Haha, it’s totally cluttered, there’s like a hundred files in there (P.S how do I clean it?).

Thing is, I even tried Antergos and ■■■■ [haha], but Grub always messed up, even before this complicated btrfs install. Btw Windows boots totally fine, so my efi partition isn’t ffckd, just grub. And I actually installed OS on ext4 the first time, and used built in installer partitioning, it worked. Idk if it worked because of ext4, or it worked because it was the first time I installed GRUB, which was clean at the point.

Now, in the latest instance, I can boot into grub. But to the command line. Grub is totally confused as to which dir to point. I tried “set prefix” to some of the possible directories. Only one of them worked, I think /boot/efi/efi/grub, and it came to the OS list. But it had 10 “Arch Linux” posts, none of them worked. It always said there’s no linux.mod. And it doesn’t look like it’s the right directory, i.e. with my latest archlabs install.

First thing I should do is probably clean it up (EFI). Then reset the btrfs partitions, and try a clean install. Any other tips about btrfs?

Another thing: if I want to install grub to efi, even with installers, should I mount the boot partition to /mnt/boot or /mnt/boot/efi? If I mount to /boot, it will still have a /boot/EFI folder, in contrast to having a /boot/efi/EFI folder.

#2

Ok you’ve got a lot of info there :stuck_out_tongue:

First up, /boot/efi vs /boot, some bootloaders require the kernel image in the root directory of the esp (systemd-boot, syslinux) so the answer to this debate is it depends, we chose to standardize on /boot to simplify things, if you use grub either will work just fine but the installer assumes /boot.

Next, cleaning the esp, after situations like this your boot partition will likely look like a bomb went off inside, if you need to preserve a select few of the bootloaders then a bit of manual removal is the only way to go. The installer will create two directories relative to the esp EFI/BOOT and EFI/ArchLabs, windows will have something like EFI/Microsoft, other linux distros will likely have a EFI/distro_name directory as well, everything else you should probably remove to avoid issues.

Regarding btrfs, the installer doesn’t support it due to the additional setup required for it with an already small userbase and not currently stable the users that would like to use it will have to do it manually, use of terminal job control can help with this, ^Z at any time to pause execution of the installer and background it, fg to resume after you’ve done whatever. I also suggest looking into what kernels and bootloaders are currently supporting btrfs as it might not be as clean cut as you might think.

If you know enough about Arch install procedure then you can follow that to a tee, once you reach a point where you would pacstrap the system, instead on AL you can

rsync -avh /run/archiso/sfs/airootfs/ /mnt/

This will copy the base system over (similar to pacstrap /mnt), pacstrapping will also work but you will get stock arch without any AL stuff and have to add it manually (also perfectly doable)

Then continue following the guide, the advantage is you can install and setup the system however you like.

Hope that kinda answers your questions, feel free to ask if anything is unclear or you want to know more.

Cheers

#3

Thanks for your answer :slight_smile:

Alright, so I repartitioned clean partitions and tried to install Archlabs. I followed that github page on how to mount the subvolumes, I then started the installer and it let me skip right to user login settings, and then go on. The installer made its thing without a hitch or errors, and I rebooted. Same thing; Grub either is not there or will not boot. It goes straight to Windows. If I manually choose boot menu, there are two posts, GRUB and Archlabs. Neither of them boots. I actually think these are old and not the new install.

Hm, do you have any idea what I can do from here to fix Grub? Last time I tried chrooting into the installed Archlabs and trying grub-install and grub-mkconfig. And it kinda didn’t go well. Is there anything specific you can suggest?

EDIT: I chrooted and did grub-install, with a new id so I know which is which. It booted to commandline. I tried set prefix again and one worked. It showed one post: Arch Linux (not archlabs) but it didn’t boot becasue linux.mod and such files weren’t there. >.<

Maybe I should just give up and conform by installing ext4 :wink:

#4

Yea chroot in and update a few things, it’s usually fairly easy and shouldn’t give you errors if you know the drill.

setup

# find your partitions
lsblk

# mount the root part first, then boot
mount /dev/sdXX /mnt
mount /dev/sdXX /mnt/boot

# incase the host doesn't already have these
mkdir -pv /run/{udev,lvm}

# 4 dirs, 2 for host mounts, 2 for chroot mounts
mkdir -pv /mnt/{hostrun,run}/{udev,lvm}

# bind mount the host dirs
mount --bind /run/lvm /mnt/hostrun/lvm
mount --bind /run/udev /mnt/hostrun/udev

# now we can chroot in for the rest

chroot

# chroot into the mounted system
arch-chroot /mnt

# make sure efivars is mounted
mount -t efivarfs efivarfs /sys/firmware/efi/efivars

# bind mount the chroot dirs 
mount --bind /hostrun/udev /run/udev
mount --bind /hostrun/lvm /run/lvm 

# update first
pacman -Syyu

# rebuild initramfs, for other kernels this will change eg. linux-lts
mkinitcpio -p linux

# (re)install grub
grub-install --recheck --force --target=x86_64-efi --efi-directory=/boot --bootloader-id=ArchLabs

# generate new config
grub-mkconfig -o /boot/grub/grub.cfg

# unmount the chroot dirs
umount /run/udev /run/lvm

# exit the chroot
exit

cleanup

# unmount the host dirs and remove them
umount /mnt/hostrun/udev /mnt/hostrun/lvm
rm -rf /mnt/hostrun

# unmount the system
umount /mnt/boot /mnt

# reboot
reboot

All the hostrun mounting crap save grub from having timeout issues when scanning the drives for bootloaders, it can be skipped but the process will take much longer and the generated config may not contain all boot entries, needing to be re-generated once booted into the system.

#5

If possible post an ls -R /mnt/boot

#6

I’ll try your code, but first I have to reinstall archlabs.

If you go to the github page, could you see if everything is alright as he puts it? What feels a little fishy is mounting root subvolid=5 to /mnt/btrfs. And not as /mnt

When I’m in the last step in the installer and look at the details, it shows all partitions as: Root: None, Boot: None, Swap: None, etc. Bootloader: None. All is on none. If I didn’t know better, I’d say this is the reason for my problems. Well, I actually have mounted everything manually, to /mnt. But maybe it won’t do?

#7

I really don’t know enough about btrfs having never used it myself, the guide hasn’t been updated in around 10 months so there very well could be some differences.

It seems ok, the bit

  1. mount -o noatime,compress=lzo,space_cache,ssd,subvol=@ /dev/sda2 /mnt

seems to be where he’s mounting root.

Yes the show bit won’t work for the most part as it has no means of telling which is mounted where (currently). All it cares about to allow you going forward is a few key elements:

  • is there something mounted at /mnt the default location for the install
  • has a user name and password been set
  • has the basic system configuration been finished

once the above are met, it will let the install commence, however this doesn’t entirely mean there won’t be errors due to that.

#8

If your willing to fiddle around with it, most of the variables used for install are all defined at the top of the installer /usr/bin/archlabs-installer

filling in some of these values to what you need should avoid most of the issues, mainly just the bootloader and boot partition is needed in your case, the rest you can pick during install or won’t cause issues.

BOOT_PART=""      # boot partition in /dev/sdXX format
BOOTLDR=""        # bootloader, can be: grub, systemd-boot, refind-efi

In the future I’ll split the bootloader selection bit off to it’s own section so going through the partition setup isn’t needed to set it (which is the case currently).

#9

It worked! Freakin awesome. Your code solved it all! Thanks a great deal :grin:

#10

next step: Efistub? I even got that to work with btrfs. Took a day though and was a whole bunch of tinkering. I used arch proper, though.

Oh, and one question:

why did you do the cleanup part? I think that filesystem is non temporary because it is a live system?

#11

As long as the EFI system partition is mounted to /boot then the ArchWiki guide for efibootmgr can be followed:

https://wiki.archlinux.org/index.php/EFISTUB#efibootmgr

For btrfs system add rootflags=subvol=$volume to the --unicode option and replace $volume with the name given to the ArchLabs subvolume.

#12

They’re created in the previous step as a temporary place to bind the host’s /run/{lvm,udev} where they can be accessed once chrooted. Other ways of doing this, I just use this method.

Yes they are ‘temp’, we created them to just be a ‘bridge’ and since were done, they serve no purpose, perhaps you’re confusing it with the actual /run or /mnt/run?

#13

Oh yes, I was. Thank you.

#14

Interesting. I did it a bit different. I think I put the /boot into the efi partition. Then I mounted it into the file system. I gave the root partition as a separate parameter and put the system in the root subvol of the btrfs partition, the snapshots are on the same level. I do them into /.snapshots/yyyymmdd. That allows me not to use the rootflags-subvol=$volume thing. A bit unconventional as I found out, but it works for me.