mectx02

joined 1 year ago
[–] mectx02 7 points 3 months ago

+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!

[–] mectx02 8 points 1 year ago

It’s not necessarily required. All landings are visual maneuvers anyway; lights just help you see in non-ideal weather conditions

[–] mectx02 2 points 1 year ago

Oh man. This nightmare again…

[–] mectx02 1 points 1 year ago (1 children)

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.

[–] mectx02 1 points 1 year ago (3 children)

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:

  1. Boot into Archlinux and have it install its GRUB. (Yes, an extra grub installation with grub-install is necessary since the EFI needs to point to the Archlinux install.)
  2. Generate a GRUB configuration file within Archlinux. (os-prober should work just fine on Archlinux since I've seen their version generating much more workable configurations for other operating systems.)
  3. Copy over the theming from Ubuntu's GRUB into Archlinux's GRUB config. (This is mostly just for style points - you can theme GRUB however you like).

Hopefully that works a little better.

[–] mectx02 1 points 1 year ago (5 children)

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.

[–] mectx02 2 points 1 year ago (7 children)

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.

[–] mectx02 1 points 1 year ago (9 children)

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.

[–] mectx02 3 points 1 year ago (12 children)

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).

33
I can believe (self.memes)
 

[–] mectx02 1 points 1 year ago

That could be one reason.

Or if you need to shoehorn in something that the official ISO doesn’t provide, like an obscure driver, that’s totally possible.

I’ve made a pretty basic ISO before that had a GUI and a couple of other things for installation just to try out the process, which thankfully isn’t too difficult to piece together. But I would imagine that it allows for flexibility for the user to install as they please more than anything.

[–] mectx02 2 points 1 year ago (1 children)

The baseline (minimal iso packages list) is under another directory in configs, but it’s in the same repository.

Relevant link for easier finding.

[–] mectx02 1 points 1 year ago (3 children)

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,

  • Navigate to a folder where you want the local repository
  • Execute repo-add [repository name] [list of packages to add, separated by space]
  • Add local repository to setup 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.

view more: next ›