It’s not necessarily required. All landings are visual maneuvers anyway; lights just help you see in non-ideal weather conditions
It’s not necessarily required. All landings are visual maneuvers anyway; lights just help you see in non-ideal weather conditions
If you reinstall GRUB from ArchLinux and get the Ubuntu themed one on reboot, might be wort going into your UEFI/BIOS and manually selecting which EFI file to boot from. Probably would be labeled “arch” or something similar.
Apologies for the longer delay this time, but I needed to have a play with a similar scenario since I haven’t worked with LVM.
I set up a VM with Kubuntu (just out of preference; everything else compared to Ubuntu should be the same) and Archlinux similar to your setup (sans LUKS encryption - only wanted to test one thing at a time). I started with installing Kubuntu and letting it do LVM however it wanted, then shrunk it down and installed Archlinux afterwards.
When I was using Ubuntu’s GRUB and letting it do the configuration, it could “find” the Archlinux partition, but it refused to boot it on the basis of “can’t find kernel image” error. Manhandling it produced similar results - it just refused to boot.
Using Archlinux’s GRUB, however, worked flawlessly. It even detected and booted up Kubuntu just fine.
Having a look at the GRUB configuration files, it looks like there’s a difference between the options…
Kubuntu’s GRUB config for booting Archlinux:
menuentry 'Arch Linux (on /dev/mapper/vgkubuntu-archlinux)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-linux--/dev/mapper/vgkubuntu-archlinux' {
insmod part_gpt
insmod lvm
linux /boot/vmlinuz-linux root=/dev/mapper/vgkubuntu-archlinux rw loglevel=3 quiet
initrd /boot/initramfs-linux.img
}
Archlinux’s default GRUB config:
menuentry 'Arch Linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-42a47177-8802-48bf-93d1-376419d431e5' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod lvm
insmod ext2
set root='lvmid/F8XGRm-mOlV-RmRq-sFoj-IBYw-7D8q-lNxCOg/ubT282-XqAq-DvJg-fj4H-bfpQ-1P4f-5215v9'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint='lvmid/F8XGRm-mOlV-RmRq-sFoj-IBYw-7D8q-lNxCOg/ubT282-XqAq-DvJg-fj4H-bfpQ-1P4f-5215v9' 42a47177-8802-48bf-93d1-376419d431e5
else
search --no-floppy --fs-uuid --set=root 42a47177-8802-48bf-93d1-376419d431e5
fi
echo 'Loading Linux linux ...'
linux /boot/vmlinuz-linux root=/dev/mapper/vgkubuntu-archlinux rw loglevel=3 quiet
echo 'Loading initial ramdisk ...'
initrd /boot/initramfs-linux.img
}
Notice a difference?
Granted, there’s a lot of extra fluff in there, but I noticed that it looks like GRUB has no idea where the root is for the LVM when using (K)Ubuntu’s config. Which is, frankly, just lazy - if you go the other way, Archlinux correctly recognizes the required defaults for booting the other operating system. (I suspect a bug report should be filed, but, eh.)
So, here’s an option:
grub-install
is necessary since the EFI needs to point to the Archlinux install.)os-prober
should work just fine on Archlinux since I’ve seen their version generating much more workable configurations for other operating systems.)Hopefully that works a little better.
Btw sorry if I keep sending pictures of the screen instead of screenshots just a lazy boy😅
Work smarter, not harder :)
Those file formats are fairly typical for most Linux installations, so that rules out GRUB drivers.
Your most recent screenshot shows evidence of an encrypted volume for your Arch install. I would have a read on the archlinux wiki and give that a shot first. In addition, while you’re in Ubuntu, they have update-grub
that will auto-generate GRUB’s config file for you, so that might help with a couple of problems.
Beyond that, you might have to use an alternate bootloader, as GRUB doesn’t seem to have very good support for LUKS at the moment. Alternatively, you could remove the LUKS encryption from your Arch install, but I’m not aware of how feasible that solution is since I don’t use it.
I had a closer look at your picture and I noticed that GRUB is throwing an error about an unrecognized partition type.
What file system did you choose to install Arch on? You might not have the correct file system drivers for os-prober
to see it.
If you’re having to mount drives in Ubuntu’s recovery mode, something is really f*cked up. If you can remember the default state, I would try and revert back to that first before making any changes. (Hopefully you don’t have to reinstall anything)
I’m not familiar with gnome-disks, so I can’t say anything about its own file relationships and how that works with GRUB.
From past experience, most Linux distributions will place your EFI partition (looks like it’s at /dev/nvme0n1p1
in your example) at /boot/efi
. /boot
partitions generally aren’t really needed for a home linux environment afaik, but I’m sure someone with more experience will be happy to come along and give an example of when you might need one. However, in order for Linux to boot up successfully, it does need to know where all of its internal components are (typically the kernel and an initramfs, if you have one - I think Ubuntu ships with one by default).
If you’re looking to just have the EFI partition mounted correctly, you can unmount it temporarily (as root, so exercise caution) and then make changes with the directory structure before remounting it. Your fstab
file should match up with where you want it mounted.
If you’re running under UEFI, GRUB typically installs a bootx64.efi
file in the EFI partition (typically under its own little GRUB folder), so that when your computer boots up, the BIOS/UEFI can point to that file and start GRUB, which will then look at its configuration file to find all the preconfigured bootable operating systems that it knows about. BIOS is a little bit different, but the premise is the same - a small executable is placed somewhere that the BIOS can find and execute to launch your OS’ bootloader.
All os-prober
does is look at operating systems that are already mounted and adds them to the configuration file. If a system isn’t mounted, then os-prober
(and by extension, GRUB, since the grub.cfg
file is where all the OS options are placed) won’t know about it.
Assuming that you have your fstab file for Archlinux configured correctly (where your EFI partition is mounted under a reasonable directory, such as /boot/efi
), you can boot into Ubuntu, mount your Archlinux partion under Ubuntu temporarily, and run sudo grub-mkconfig -o /boot/grub/grub.cfg
under Ubuntu to generate the necessary boot option for Archlinux.
You can install the GRUB package under Archlinux, but there’s no need to install the bootx64.efi
file (from sudo grub-install
) a second time since that file already exists. It would mostly be used for keeping your grub.cfg
up to date. The theming can probably be copied over from Ubuntu’s configuration (but I’m not sure of where it is off the top of my head).
The baseline
(minimal iso packages list) is under another directory in configs
, but it’s in the same repository.
Relevant link for easier finding.
If you look up the package on the ArchWiki repository, there’s a Gitlab page where you can find the file that is used to make the releng
ISO: relevant packages.x86_64 file. There’s a similar file in that repository for the minimum number of packages for install if you want to trim down your number of installed packages.
What you can then do is set up a local repository for the setup pacman.conf
(the one in your working project directory) and include your driver as a precompiled pacman package. This page on the ArchWiki shows how to set that up, but if you want the gist of it,
repo-add
[repository name] [list of packages to add, separated by space]pacman.conf
You can do something similar such that the drivers will be installable from the iso itself - just place your repository somewhere inside the airootfs/etc/
directory and modify etc/pacman.conf
.
+1 to this.
As someone playing jazz for 8+ years, my two cents on the glissandos/vocal slides is that they should only be marked if the slide should occur every time. Otherwise, keep them omitted.
Transcriptions are hard to make, but it looks like you’re doing a pretty good job so far!