Help adding a working boot menu option to a second luks partition

Swiftd · 29 March 2022 23:28

╰─λ sudo garuda-inxi
[sudo] password for dan:         
System:
Kernel: 5.16.16-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 11.2.0
parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
root=UUID=c42114f3-adea-4625-8ec7-1d9ef08c00d5 rw rootflags=subvol=@
quiet quiet splash rd.udev.log_priority=3 vt.global_cursor_default=0
loglevel=3
Console: pty pts/1 wm: kwin_x11 DM: SDDM Distro: Garuda Linux
base: Arch Linux
Machine:
Type: Desktop Mobo: ASUSTeK model: PRIME X399-A v: Rev 1.xx
serial: <filter> UEFI: American Megatrends v: 1203 date: 10/09/2019
Battery:
Device-1: hidpp_battery_0 model: Logitech Wireless Mouse MX Master 3
serial: <filter> charge: 100% (should be ignored) rechargeable: yes
status: discharging
CPU:
Info: model: AMD Ryzen Threadripper 2920X socket: SP3r2 bits: 64
type: MT MCP MCM arch: Zen+ family: 0x17 (23) model-id: 8 stepping: 2
microcode: 0x800820D
Topology: cpus: 1x cores: 6 tpc: 4 threads: 24 dies: 2 smt: enabled
cache: L1: 1.1 MiB desc: d-12x32 KiB; i-12x64 KiB L2: 6 MiB
desc: 12x512 KiB L3: 32 MiB desc: 4x8 MiB
Speed (MHz): avg: 3500 min/max: 2200/3500 boost: enabled
base/boost: 3500/4300 scaling: driver: acpi-cpufreq governor: performance
volts: 1.1 V ext-clock: 100 MHz cores: 1: 3500 2: 3500 3: 3500 4: 3500
5: 3500 6: 3500 7: 3500 8: 3500 9: 3500 10: 3500 11: 3500 12: 3500
13: 3500 14: 3500 15: 3500 16: 3500 17: 3500 18: 3500 19: 3500 20: 3500
21: 3500 22: 3500 23: 3500 24: 3500 bogomips: 167665
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Vulnerabilities:
Type: itlb_multihit status: Not affected
Type: l1tf status: Not affected
Type: mds status: Not affected
Type: meltdown status: Not affected
Type: spec_store_bypass
mitigation: Speculative Store Bypass disabled via prctl
Type: spectre_v1
mitigation: usercopy/swapgs barriers and __user pointer sanitization
Type: spectre_v2
mitigation: Retpolines, IBPB: conditional, STIBP: disabled, RSB filling
Type: srbds status: Not affected
Type: tsx_async_abort status: Not affected
Graphics:
Device-1: NVIDIA TU104 [GeForce RTX 2070 SUPER] vendor: Gigabyte
driver: nouveau v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 16 link-max:
gen: 3 speed: 8 GT/s ports: active: HDMI-A-1 empty: DP-1,DP-2,DP-3
bus-ID: 42:00.0 chip-ID: 10de:1e84 class-ID: 0300
Display: server: X.Org v: 1.21.1.3 compositor: kwin_x11 driver: X:
loaded: modesetting,nouveau alternate: fbdev,nv,vesa gpu: nouveau
display-ID: :0 screens: 1
Screen-1: 0 s-res: 2560x1440 s-dpi: 96 s-size: 677x381mm (26.65x15.00")
s-diag: 777mm (30.58")
Monitor-1: HDMI-A-1 mapped: HDMI-1 model: Samsung C27H71x
serial: <filter> built: 2017 res: 2560x1440 hz: 60 dpi: 109 gamma: 1.2
size: 597x336mm (23.5x13.23") diag: 685mm (27") ratio: 16:9 modes:
max: 2560x1440 min: 720x400
OpenGL: renderer: NV164 v: 4.3 Mesa 21.3.7 direct render: Yes
Audio:
Device-1: AMD Family 17h HD Audio vendor: ASUSTeK driver: snd_hda_intel
v: kernel pcie: gen: 3 speed: 8 GT/s lanes: 16 bus-ID: 0b:00.3
chip-ID: 1022:1457 class-ID: 0403
Device-2: NVIDIA TU104 HD Audio vendor: Gigabyte driver: snd_hda_intel
v: kernel pcie: gen: 1 speed: 2.5 GT/s lanes: 16 link-max: gen: 3
speed: 8 GT/s bus-ID: 42:00.1 chip-ID: 10de:10f8 class-ID: 0403
Sound Server-1: ALSA v: k5.16.16-zen1-1-zen running: yes
Sound Server-2: PulseAudio v: 15.0 running: no
Sound Server-3: PipeWire v: 0.3.48 running: yes
Network:
Device-1: Intel I211 Gigabit Network vendor: ASUSTeK driver: igb v: kernel
pcie: gen: 1 speed: 2.5 GT/s lanes: 1 port: 1000 bus-ID: 05:00.0
chip-ID: 8086:1539 class-ID: 0200
IF: enp5s0 state: down mac: <filter>
Device-2: Broadcom vendor: ASUSTeK driver: brcmfmac v: kernel pcie:
gen: 2 speed: 5 GT/s lanes: 1 port: N/A bus-ID: 06:00.0 chip-ID: 14e4:43c3
class-ID: 0280
IF: wlp6s0 state: up mac: <filter>
Drives:
Local Storage: total: 3.64 TiB used: 862.35 GiB (23.1%)
ID-1: /dev/nvme0n1 maj-min: 259:1 vendor: PNY model: CS3030 1000GB SSD
size: 931.51 GiB block-size: physical: 512 B logical: 512 B
speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter> rev: CS303224
temp: 28.9 C scheme: GPT
SMART: yes health: PASSED on: 1y 195d 2h cycles: 1,202
read-units: 20,574,202 [10.5 TB] written-units: 43,775,950 [22.4 TB]
ID-2: /dev/nvme1n1 maj-min: 259:0 vendor: PNY model: CS3030 1000GB SSD
size: 931.51 GiB block-size: physical: 512 B logical: 512 B
speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter> rev: CS303224
temp: 28.9 C scheme: GPT
SMART: yes health: PASSED on: 1y 194d 17h cycles: 1,202
read-units: 23,037,379 [11.7 TB] written-units: 23,048,000 [11.8 TB]
ID-3: /dev/sda maj-min: 8:0 vendor: Samsung model: SSD 860 EVO 2TB
family: based SSDs size: 1.82 TiB block-size: physical: 512 B
logical: 512 B sata: 3.2 speed: 6.0 Gb/s type: SSD serial: <filter>
rev: 3B6Q temp: 25 C scheme: GPT
SMART: yes state: enabled health: PASSED on: 1y 187d 6h cycles: 1137
written: 203.24 GiB
Partition:
ID-1: / raw-size: 398.17 GiB size: 398.17 GiB (100.00%)
used: 20.61 GiB (5.2%) fs: btrfs block-size: 4096 B dev: /dev/sda1
maj-min: 8:1
ID-2: /boot/efi raw-size: 100 MiB size: 96 MiB (96.00%)
used: 78 MiB (81.3%) fs: vfat block-size: 512 B dev: /dev/nvme0n1p2
maj-min: 259:4
ID-3: /home raw-size: 398.17 GiB size: 398.17 GiB (100.00%)
used: 20.61 GiB (5.2%) fs: btrfs block-size: 4096 B dev: /dev/sda1
maj-min: 8:1
ID-4: /var/log raw-size: 398.17 GiB size: 398.17 GiB (100.00%)
used: 20.61 GiB (5.2%) fs: btrfs block-size: 4096 B dev: /dev/sda1
maj-min: 8:1
ID-5: /var/tmp raw-size: 398.17 GiB size: 398.17 GiB (100.00%)
used: 20.61 GiB (5.2%) fs: btrfs block-size: 4096 B dev: /dev/sda1
maj-min: 8:1
Swap:
Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
ID-1: swap-1 type: zram size: 31.26 GiB used: 2.5 MiB (0.0%)
priority: 100 dev: /dev/zram0
Sensors:
System Temperatures: cpu: 46.5 C mobo: N/A gpu: nouveau temp: 32.0 C
Fan Speeds (RPM): N/A gpu: nouveau fan: 871
Info:
Processes: 502 Uptime: 1h 14m wakeups: 5 Memory: 31.26 GiB
used: 4.74 GiB (15.1%) Init: systemd v: 250 tool: systemctl Compilers:
gcc: 11.2.0 Packages: pacman: 1944 lib: 552 Shell: garuda-inxi (sudo)
default: Bash v: 5.1.16 running-in: konsole inxi: 3.3.14
Garuda (2.5.6-2):
System install date:     2022-03-23
Last full system update: 2022-03-26
Is partially upgraded:   No
Relevant software:       NetworkManager
Windows dual boot:       Yes
Snapshots:               Snapper
Failed units:            bluetooth-autoconnect.service

I have an open question on Unix.SE but I'm not sure if it is some specific of the garuda setup that I am missing : grub - Adding a working boot option to get to my pacstrap/chroot install on a luks partition - Unix & Linux Stack Exchange

To be clear there is nothing wrong with my Garuda install - that's all good - Thank you for the distro!! I am simply hoping that knowledge of the Garuda implementation will help solve my issue.

From the link:

I know there are are a lot of questions like this but the examples I have found differ enough to confuse me, I'm hoping someone can help clarify this for me.

To briefly explain my setup. I have a windows 10 install and then on a different disk I have a garuda linux install. Both work fine but were set up for me by a the respective gui installers. I have now installed arch linux to separate partition (luks encrypted) from my garuda install (pacstrap) and would like to be able to boot into it. I can chroot into the install and have done bind mount for /dev /proc and /sys so I can see all devices and have successfully run an update and installed some bins.

disk/partition setup is as follows:

Windows disk and EFI:

Device             Start        End    Sectors   Size Type
/dev/nvme0n1p1      2048    1085439    1083392   529M Windows recovery environment
/dev/nvme0n1p2   1085440    1290239     204800   100M EFI System
/dev/nvme0n1p3   1290240    1323007      32768    16M Microsoft reserved
/dev/nvme0n1p4   1323008  519925759  518602752 247.3G Microsoft basic data
/dev/nvme0n1p5 519925760 1953523711 1433597952 683.6G Microsoft basic data

and then for linux:

/dev/sda1        2048  835028991  835026944 398.2G Linux filesystem (garuda)
/dev/sda2   835028992 1859028991 1024000000 488.3G Linux filesystem (arch -no boot)

sda1 & sda2 are both on btrfs partitions with luks encryption. However, I am not entirely clear how the garuda one was set up (gui installer). I am currently logged into garuda and have both drives unencrypted however I only see the dev/mapper for the device Im not booted into (dev/sda2) and that is the only one that show up with a luks map in lsblk:

✦  ╰─λ lsblk -o name,uuid,type
NAME                                          UUID                                 TYPE
sda                                                                                disk
├─sda1                                        c42114f3-adea-4625-8ec7-1d9ef08c00d5 part
├─sda2                                        35308676-366b-495a-afd3-9c65701ec867 part
│ └─luks-35308676-366b-495a-afd3-9c65701ec867 fb72ec72-1352-4e5c-849d-a44c69ba4b16 crypt

The unencrypted device is mounted to /run/media/dan/nix_e1 with the arch install visible.

/boot (garuda ) I have grub dir, kernels and the efi partition mounted to /efi :

✦  ╰─λ ls /boot 
drwxr-xr-x   - root  1 Jan  1970  efi
drwxr-xr-x   - root 29 Mar 02:28  grub
drwxr-xr-x   - root  8 Mar 05:09  memtest86+
.rw-r--r-- 51k root 11 Mar 19:21  amd-ucode.img
.rw------- 68M root 26 Mar 16:27  initramfs-linux-zen-fallback.img
.rw------- 43M root 26 Mar 16:27  initramfs-linux-zen.img
.rw-r--r-- 11M root 23 Mar 16:37  vmlinuz-linux-zen

/etc/fstab (garuda):

UUID=c42114f3-adea-4625-8ec7-1d9ef08c00d5 /              btrfs   subvol=/@,defaults,noatime,autodefrag,compress=zstd,discard=async,ssd 0 0
UUID=c42114f3-adea-4625-8ec7-1d9ef08c00d5 /home          btrfs   subvol=/@home,defaults,noatime,autodefrag,compress=zstd,discard=async,ssd 0 0
UUID=c42114f3-adea-4625-8ec7-1d9ef08c00d5 /root          btrfs   subvol=/@root,defaults,noatime,autodefrag,compress=zstd,discard=async,ssd 0 0
UUID=c42114f3-adea-4625-8ec7-1d9ef08c00d5 /srv           btrfs   subvol=/@srv,defaults,noatime,autodefrag,compress=zstd,discard=async,ssd 0 0
UUID=c42114f3-adea-4625-8ec7-1d9ef08c00d5 /var/cache     btrfs   subvol=/@cache,defaults,noatime,autodefrag,compress=zstd,discard=async,ssd 0 0
UUID=c42114f3-adea-4625-8ec7-1d9ef08c00d5 /var/log       btrfs   subvol=/@log,defaults,noatime,autodefrag,compress=zstd,discard=async,ssd 0 0
UUID=c42114f3-adea-4625-8ec7-1d9ef08c00d5 /var/tmp       btrfs   subvol=/@tmp,defaults,noatime,autodefrag,compress=zstd,discard=async,ssd 0 0
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
UUID=C61E-FDE5  /boot/efi       vfat    defaults      0       1

I haven't mounted anything to /boot on the arch install yet, so it just has copies of the same kernels as garuda (also arch based) and I have created the efi directory ready for the mount. I have setup the fstab (though Im not entirely sure if I have used the correct uuid - will it see it with the crypt uuid or the part uuid?)

/etc/fstab (arch):

# <file system> <dir> <type> <options> <dump> <pass>
# /dev/mapper/luks-35308676-366b-495a-afd3-9c65701ec867 LABEL=nix_e1
UUID=fb72ec72-1352-4e5c-849d-a44c69ba4b16 /           btrfs      rw,nosuid,nodev,relatime,ssd,space_cache=v2,subvolid=5,subvol=/ 0 0
UUID=fb72ec72-1352-4e5c-849d-a44c69ba4b16 /home          btrfs   subvol=/@home,defaults,noatime,autodefrag,compress=zstd,discard=async,ssd 0 0
UUID=fb72ec72-1352-4e5c-849d-a44c69ba4b16 /root          btrfs   subvol=/@root,defaults,noatime,autodefrag,compress=zstd,discard=async,ssd 0 0
UUID=fb72ec72-1352-4e5c-849d-a44c69ba4b16 /srv           btrfs   subvol=/@srv,defaults,noatime,autodefrag,compress=zstd,discard=async,ssd 0 0
UUID=fb72ec72-1352-4e5c-849d-a44c69ba4b16 /root          btrfs   subvol=/@root,defaults,noatime,autodefrag,compress=zstd,discard=async,ssd 0 0
UUID=fb72ec72-1352-4e5c-849d-a44c69ba4b16 /var/cache     btrfs   subvol=/@cache,defaults,noatime,autodefrag,compress=zstd,discard=async,ssd 0 0
UUID=fb72ec72-1352-4e5c-849d-a44c69ba4b16 /var/log       btrfs   subvol=/@log,defaults,noatime,autodefrag,compress=zstd,discard=async,ssd 0 0
UUID=fb72ec72-1352-4e5c-849d-a44c69ba4b16 /var/tmp       btrfs   subvol=/@tmp,defaults,noatime,autodefrag,compress=zstd,discard=async,ssd 0 0

# /dev/zram0
/dev/zram0            none        swap        defaults,pri=100  0 0

Now this is the point where I get a little lost:

From reading I understand I need an initcpio hook, now I am guessing this is already in place for my garuda install. I can see grub-btrfs-overlayfs has been added to the hooks and it seems to have the crypt hook is part of the install... I'm assuming I dont need to do this on the arch partition as well unless I want to update grub from there too (saw some advice not to update grub from two installs).

I think next I need to run sudo mkinitcpio -p linux-zen (not sure if I have missed some configuration step). However I have added this device to /etc/crypttab and now it gets auto-mounted and unlocked when I enter the password once (which is the same for both partitions) - so at login to garuda both drives are unlocked... I think this suggests it is set up correctly.

Now some seem to suggest that a grub update should pick up the install at this point but it doesn't add a menu entry on update

So I have added a menu entry manually to grub:

/etc/grub.d/40_custom:

menuentry "Arch" {
    search --set=root --fs-uuid 35308676-366b-495a-afd3-9c65701ec867  linux-zen /boot/linux-zen root=UUID=35308676-366b-495a-afd3-9c65701ec867 rw  quiet
}

Now I get an entry in my grub boot menu but on booting it says device 35308676-366b-495a-afd3-9c65701ec867 cannot be found, I have also tried with the uuid fb72ec72-1352-4e5c-849d-a44c69ba4b16 and got the same error.

I would appreciate if somebody could confirm what I have done so far is correct and point me in the right direction to get this working.

Thank you in advance.

petsam · 30 March 2022 01:08

Then inspect Garuda grub.cfg entries, UUIDs etc, and hopefully you"ll understand .

for the /efi partition IIRC. Do what Archwiki/grub suggests in this case.

This is a confusing and wrong statement, if taken without explanations.
With MSDOS/Legacy/MBR, you can have only one boot loader for each drive. With more than 1 drive, you may select which drive to boot from BIOS quick boot menu.
With UEFI, it’s the same, though you choose from UEFI menu, which usually includes OSes with EFI bootloader installed, while some times they only offer drives, or less.
In your case (UEFI), installing (not updating) grub on UEFI, does not matter. But grub resets the default entry each time it installs. You can change this (even immediately after installation) with efibootmgr.

IIRC, you need to also do this for the Arch system. Unless I haven’t understood your description.

I guess so, as well. Something is wrong.
Is your posted grub entry exactly as above? If yes, then it’s not bootable.

It looks like two lines in one. Is it a forum bug, or your typo?
And…

linux-zen /boot/linux-zen

linux-zen is not a grub command (this code is ran from grub, not linux).
The correct command is linux and goes in the start of a new line. It loads the kernel.

The kernel file name is not linux-zen either…

linux /boot/vmlinuz-linux-zen root=UUID=35308676-366b-495a-afd3-9c65701ec867 rw  quiet

Also, you have to add initramfs (and ucode image(s), if needed). Example:

initrd  /boot/intel-ucode.img /boot/initramfs-linux-zen.img

Good job! Keep reading the docs!

Swiftd · 5 April 2022 13:11

Hey sorry for the slow reply... got myself into some mischief.

Thank you for the tips. I started working through them and kept reading as you suggested. It turns out I missed a few steps and need to go back to the btrfs setup to get what I want. And I will be working through this again from the start. However on my journey I have run into (or created) another issue...

If you have a moment I would really like to pick your brains on two points (one related to my original question):

I broke my garuda install - the current state is a little odd. So grub is suddenly reporting a missing locale file /boot/grub/locale/C.mo, I found a few similar but seemingly unrelated issues and hacked around it by copying my correct locale file and renaming it C.mo - but I think this is indicative of a larger issue. Either way I can get passed the grub menu. The main issue is that when I get to the plymouth screen I used to be able to enter my luks password. Now upon hitting any key on the plymouth screen I get a black screen and no further response. The machine will respond to Ctrl+alt+delete and upon pressing will briefly display the plymouth screen before rebooting... any thoughts on where I should start?
I have installed garuda again (from the same iso) to a different partition. I did this because I hoped it would be useful in fixing my broken setup (availability of arch-chroot, etc) but also to play spot the difference with the setup. Unfortunately it seems to have set itself up quite differently the second time around even though the only difference on install was the choice of partition. Some interesting differences:

The original installs fstab used a UUID to reference its drives and there was no dev/mapper for the system drive (see above fstab), the new one references via /dev/mapper:

cat /etc/fstab
File: /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
UUID=C61E-FDE5                            /boot/efi      vfat    umask=0077 0 2
/dev/mapper/luks-d9169193-7d17-4b00-9c72-91e09336125b /              btrfs   subvol=/@,defaults,noatime,autode
frag,compress=zstd,discard=async,ssd 0 0
/dev/mapper/luks-d9169193-7d17-4b00-9c72-91e09336125b /home          btrfs   subvol=/@home,defaults,noatime,au
todefrag,compress=zstd,discard=async,ssd 0 0
/dev/mapper/luks-d9169193-7d17-4b00-9c72-91e09336125b /root          btrfs   subvol=/@root,defaults,noatime,au
todefrag,compress=zstd,discard=async,ssd 0 0
/dev/mapper/luks-d9169193-7d17-4b00-9c72-91e09336125b /srv           btrfs   subvol=/@srv,defaults,noatime,aut
odefrag,compress=zstd,discard=async,ssd 0 0
/dev/mapper/luks-d9169193-7d17-4b00-9c72-91e09336125b /var/cache     btrfs   subvol=/@cache,defaults,noatime,a
utodefrag,compress=zstd,discard=async,ssd 0 0
/dev/mapper/luks-d9169193-7d17-4b00-9c72-91e09336125b /var/log       btrfs   subvol=/@log,defaults,noatime,aut
odefrag,compress=zstd,discard=async,ssd 0 0
/dev/mapper/luks-d9169193-7d17-4b00-9c72-91e09336125b /var/tmp       btrfs   subvol=/@tmp,defaults,noatime,aut
odefrag,compress=zstd,discard=async,ssd 0 0
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

The other key difference I've noted is that the prompt to enter the luks password on the new install is happening before the grub menu rather than during the plymouth boot screen (it also seems slower decrypting the drive). Now to be honest the new install is not as nice as the original in the way it functions but I can now follow what is happening - I can see how the drive is being decrypted now whereas I couldn't before

Any thoughts on the above, why does the installer seem to have set things up differently this time around?

petsam · 5 April 2022 18:26

This means you did not do this properly the first time.

Great idea!

I wouldn’t want to spoil this wonderful experience of Learning By Mistakes. You have all the required tools: Archwiki and a pair of installations (one failed and one good). Now the only thing that is missing is reading and comparing.
You are going to become an expert!!
Don’t forget to give back some part of your gained experience :
We all did that

Swiftd · 6 April 2022 10:47

This means you did not do this properly the first time.

I beg to differ… there are plenty of points in this process that I will own mistakes but this isn’t one of them. The first setup was much cleaner (prior to breaking), there was no problem with how it originally installed… the only complications came after I started poking things… and both were setup the same in the garuda gui installer using the same iso.

As I see it there are two possibilities… either there is some difference in the way Garuda installs to the first partition of a disk compared to the way it installs to a second partition (or when it detects an existing garuda/linux install).

Or… I have told it second time round to encrypt the boot partition, which would explain why it is prompting for a password pre-grub now. … ignore me… I’ll go check that.

system · 20 April 2022 10:47

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.