Two Manjaro installations - Moving Partitions (Boot Pains)

I now have 3 OSes on my box - Manjaro KDE (Primary), Manjaro Gnome (Secondary / Reserve) and Windows.

I’ve recently moved my Gnome partition onto a different drive to free up space for the KDE partition so I can expand it.

The problem that I have is that the grub.cfg file is pointing at the old UUID for the Gnome root partition which isn’t there anymore.

I’ve fixed the fstab and edited the grub.cfg to point at the new location manually but I know that next time I generate grub it will probably revert - I assume there is something else that I need to change so that when it does so it will point at the correct UUID.

What do I need to edit?

/etc/default/grub
1 Like

what @mithrial said - you don’t edit the grub.cfg file

the very first line (the second, actually) reads:

# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub

you instead edit

/etc/default/grub

and then run
update-grub

1 Like

I know that - hence why I’m asking - my current change was just to make sure I could actually boot the second partition (which I can)

I don’t have an /etc/default/grub - I have /etc/default/grub-btrfs. I assume that’s essentially the same thing but different because I have a btrfs formatted drive?

In there I only have a config file which is fairly sparse - what would I change?

I’ve also looked at /etc/grub.d - The issue I’m having is with the second OS being picked up by the OS Prober - I think my issue is with what’s picked up by that rather than changing something in the grub files themselves, but I can’t figure out where. It finds the other partition but then it links it’s root over to the old UUID rather than the new one.

Ends up looking like this (This is not exact as I’m recreating on a different partition at the moment, but it’s the UUID’s being different that seems awry - If I understand where the OS Prober gets that UUID from in the second instance then I can probably sort it)…

menuentry 'Manjaro Linux (on /dev/nvme0n1p4)' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-656d8930-a03a-4850-a10b-696abf952cd4' {
	savedefault
	insmod part_gpt
	insmod btrfs
	search --no-floppy --fs-uuid --set=root {CORRECT_NEW_UUID_HERE}
	linux /@/boot/vmlinuz-6.1-x86_64 root=UUID={OLD_UUID_HERE} rw rootflags=subvol=@ quiet splash udev.log_priority=3
	initrd /@/boot/intel-ucode.img /@/boot/initramfs-6.1-x86_64.img
}

I’ll post up again later when I break it again on my primary OS :slight_smile:

Yes.

And that is the reason I will withdraw and will only be watching this - because I know less than nothing about BTRFS.

Cheers!

Here’s the entry to boot the secondary Manjaro that I’ve hacked t make it work…

menuentry 'Manjaro Linux [Gnome] (22.0.0)' --class manjarolinux --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-5fe8aabe-45b7-490a-a64a-bf255650c1d0' {
	insmod part_gpt
	insmod ext2
	set root='hd2,gpt2'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt2 --hint-efi=hd2,gpt2 --hint-baremetal=ahci2,gpt2  5fe8aabe-45b7-490a-a64a-bf255650c1d0
	else
	  search --no-floppy --fs-uuid --set=root 5fe8aabe-45b7-490a-a64a-bf255650c1d0
	fi
	linux /boot/vmlinuz-5.15-x86_64 root=UUID=5fe8aabe-45b7-490a-a64a-bf255650c1d0 rw quiet splash apparmor=1 security=apparmor resume=UUID=20e13c13-0198-440d-932c-da4e8560f4c3 udev.log_priority=3
	initrd /boot/intel-ucode.img /boot/initramfs-5.15-x86_64.img
}

I simply switched out the UUIDs and changed the name (So It would stand out and I’d know instantly when it had regenerated - debugging ploy!)

It was this (with notes in)

menuentry 'Manjaro Linux (22.0.0) (on /dev/sdc2)' --class manjarolinux --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-5fe8aabe-45b7-490a-a64a-bf255650c1d0' {
	insmod part_gpt
	insmod ext2
	set root='hd2,gpt2'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt2 --hint-efi=hd2,gpt2 --hint-baremetal=ahci2,gpt2  {GOOD_NEW_UUID}
	else
	  search --no-floppy --fs-uuid --set=root {GOOD_NEW_UUID}
	fi
	linux /boot/vmlinuz-5.15-x86_64 root=UUID={BAD_OLD_UUID} rw quiet splash apparmor=1 security=apparmor resume=UUID=20e13c13-0198-440d-932c-da4e8560f4c3 udev.log_priority=3
	initrd /boot/intel-ucode.img /boot/initramfs-5.15-x86_64.img
}

it is still a generated file (not this one, the one in /boot/… ) -
you don’t edit it directly … you just don’t
It’s generated.
By something else.
You edit that - to have this one change …

The mechanism is the same, BTRFS or not.

I’ll shut up now.

1 Like

I know, but I can’t figure out WHAT To change to have it reflected here. The folder you’ve pointed to just has a config file in it which looks like this.

#!/usr/bin/env bash

GRUB_BTRFS_VERSION=4.12

# Disable grub-btrfs.
# Default: "false"
#GRUB_BTRFS_DISABLE="true"

# Name appearing in the Grub menu.
# Default: "Use distribution information from /etc/os-release."
#GRUB_BTRFS_SUBMENUNAME="Arch Linux snapshots"

# Custom title.
# Shows/Hides "date" "snapshot" "type" "description" in the Grub menu, custom order available.
# Default: ("date" "snapshot" "type" "description")
#GRUB_BTRFS_TITLE_FORMAT=("date" "snapshot" "type" "description")

# Limit the number of snapshots populated in the GRUB menu.
# Default: "50"
#GRUB_BTRFS_LIMIT="50"

# Sort the found subvolumes by "ogeneration" or "generation" or "path" or "rootid".
# # See Sorting section to https://btrfs.wiki.kernel.org/index.php/Manpage/btrfs-subvolume#SUBCOMMAND
# "-rootid" means list snapshot by new ones first.
# Default: "-rootid"
#GRUB_BTRFS_SUBVOLUME_SORT="+ogen,-gen,path,rootid"

# Show snapshots found during run "grub-mkconfig"
# Default: "true"
#GRUB_BTRFS_SHOW_SNAPSHOTS_FOUND="false"

# Show Total of snapshots found during run "grub-mkconfig"
# Default: "true"
#GRUB_BTRFS_SHOW_TOTAL_SNAPSHOTS_FOUND="true"

# By default, "grub-btrfs" automatically detects most existing kernels.
# If you have one or more custom kernels, you can add them here.
# Default: ("")
#GRUB_BTRFS_NKERNEL=("kernel-custom" "vmlinux-custom")

# By default, "grub-btrfs" automatically detects most existing initramfs.
# If you have one or more custom initramfs, you can add them here.
# Default: ("")
#GRUB_BTRFS_NINIT=("initramfs-custom.img" "initrd-custom.img" "otherinit-custom.gz")

# By default, "grub-btrfs" automatically detects most existing microcodes.
# If you have one or more custom microcodes, you can add them here.
# Default: ("")
#GRUB_BTRFS_CUSTOM_MICROCODE=("custom-ucode.img" "custom-uc.img "custom_ucode.cpio")

# Comma seperated mount options to be used when booting a snapshot.
# They can be defined here as well as in the "/" line inside the respective snapshots'
# "/etc/fstab" files.  Mount options found in both places are combined, and this variable
# takes priority over `fstab` entries.
# NB: Do NOT include "subvol=..." or "subvolid=..." here.
# Default: ""
#GRUB_BTRFS_ROOTFLAGS="space_cache,commit=10,norecovery"

# Ignore specific path during run "grub-mkconfig".
# Only exact paths are ignored.
# e.g : if `specific path` = @, only `@` snapshot will be ignored.
# Default: ("@")
GRUB_BTRFS_IGNORE_SPECIFIC_PATH=("@")

# Ignore prefix path during run "grub-mkconfig".
# Any path starting with the specified string will be ignored.
# e.g : if `prefix path` = @, all snapshots beginning with "@/..." will be ignored.
# Default: ("var/lib/docker" "@var/lib/docker" "@/var/lib/docker")
GRUB_BTRFS_IGNORE_PREFIX_PATH=("var/lib/docker" "@var/lib/docker" "@/var/lib/docker")

# Ignore specific type/tag of snapshot during run "grub-mkconfig".
# For snapper:
# Type = single, pre, post.
# For Timeshift:
# Tag = boot, ondemand, hourly, daily, weekly, monthly.
# Default: ("")
#GRUB_BTRFS_IGNORE_SNAPSHOT_TYPE=("")

# Ignore specific description of snapshot during run "grub-mkconfig".
# e.g: timeline
# Default: ("")
#GRUB_BTRFS_IGNORE_SNAPSHOT_DESCRIPTION=("")

# By default "grub-btrfs" automatically detects your boot partition,
# either located at the system root or on a separate partition or in a subvolume,
# Change to "true" if your boot partition isn't detected as separate.
# Default: "false"
#GRUB_BTRFS_OVERRIDE_BOOT_PARTITION_DETECTION="true"

# Location of the folder containing the "grub.cfg" file.
# Use by grub-btrfs to save the file "grub-btrfs.cfg".
# Might be grub2 on some systems.
# For example, on Fedora with EFI : "/boot/efi/EFI/fedora"
# Default: "/boot/grub"
#GRUB_BTRFS_GRUB_DIRNAME="/boot/grub2"

# Location of kernels/initramfs/microcode.
# Use by "grub-btrfs" to detect the boot partition and the location of kernels/initrafms/microcodes.
# Default: "/boot"
#GRUB_BTRFS_BOOT_DIRNAME="/boot"

# Name/path of grub-mkconfig command, use by "grub-btrfs.service"
# Might be 'grub2-mkconfig' on some systems (Fedora ...)
# Default paths are /sbin:/bin:/usr/sbin:/usr/bin,
# if your path is missing, report it on the upstream project.
# For example, on Fedora : "/sbin/grub2-mkconfig"
# You can use only name or full path.
# Default: grub-mkconfig
#GRUB_BTRFS_MKCONFIG=/usr/bin/grub2-mkconfig

# Name of grub-script-check command, use by "grub-btrfs"
# Might be 'grub2-script-check' on some systems (Fedora ...)
# For example, on Fedora : "grub2-script-check"
# Default: grub-script-check
#GRUB_BTRFS_SCRIPT_CHECK=grub2-script-check

# Path of grub-mkconfig_lib file, use by "grub-btrfs"
# Might be '/usr/share/grub2/grub-mkconfig_lib' on some systems (Opensuse ...)
# Default: /usr/share/grub/grub-mkconfig_lib
#GRUB_BTRFS_MKCONFIG_LIB=/usr/share/grub2/grub-mkconfig_lib

# Password protection management for submenu,snapshots
# Refer to the Grub documentation https://www.gnu.org/software/grub/manual/grub/grub.html#Authentication-and-authorisation
# and this comment https://github.com/Antynea/grub-btrfs/issues/95#issuecomment-682295660
#
# Add authorized usernames separate by comma (foo,bar)
# When Grub's password protection is enabled, the superuser is authorized by default, it isn't necessary to add it
# Default: ""
#GRUB_BTRFS_PROTECTION_AUTHORIZED_USERS="foo,bar"
#
# Disable authentication support for submenu of Grub-btrfs only (--unrestricted)
# doesn't work if GRUB_BTRFS_PROTECTION_AUTHORIZED_USERS isn't empty
# Default: "false"
#GRUB_BTRFS_DISABLE_PROTECTION_SUBMENU="true"

I think this is a red herring as the entries are being picked up by the script that makes up the 30_os-prober file in /etc/grub.d - This isn’t a file you would really edit either! This was where I actually went to first in trying to get it to boot and resorted to hacking the grub.cfg to get me booted to the other partition in short term so I could clean up the primary partition.

It seems to be this part of the script that generates the entry…

menuentry '$(echo "$OS $onstr" | grub_quote)' $CLASS --class gnu-linux --class gnu --class os \$menuentry_id_option 'osprober-gnulinux-simple-$boot_device_id' {
EOF
	    save_default_entry | grub_add_tab
	    printf '%s\n' "${prepare_boot_cache}"
	    cat <<  EOF
	linux ${LKERNEL} ${LPARAMS}
EOF
            if [ -n "${LINITRD}" ] ; then
          cat << EOF
	initrd ${LINITRD}
EOF
            fi
        cat << EOF
}
EOF

More specifically, this bit: linux ${LKERNEL} ${LPARAMS} but where this comes from is the point at which I get a little lost.

Figured it out. This is autogenerated and is now correct, from what I can see…

menuentry 'Manjaro Linux (22.0.0) (on /dev/sdc2)' --class manjarolinux --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-5fe8aabe-45b7-490a-a64a-bf255650c1d0' {
	insmod part_gpt
	insmod ext2
	set root='hd2,gpt2'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd2,gpt2 --hint-efi=hd2,gpt2 --hint-baremetal=ahci2,gpt2  5fe8aabe-45b7-490a-a64a-bf255650c1d0
	else
	  search --no-floppy --fs-uuid --set=root 5fe8aabe-45b7-490a-a64a-bf255650c1d0
	fi
	linux /boot/vmlinuz-5.15-x86_64 root=UUID=5fe8aabe-45b7-490a-a64a-bf255650c1d0 rw quiet splash apparmor=1 security=apparmor resume=UUID=20e13c13-0198-440d-932c-da4e8560f4c3 udev.log_priority=3
	initrd /boot/intel-ucode.img /boot/initramfs-5.15-x86_64.img
}

It looks like the grub instance on the “other” partition is the source of information - You need to update that so that you can boot it from the partition which actually has the boot menu - a bit like a boot chain, which sort of makes sense.

The steps to rectify were…

  1. Manually edit /boot/grub/grub.cfg to fix the bad UUID mapping to point at the new UUID following the partition move in the main partition (pretty sure you have to do this in this case).
  2. Restart the PC and select the partition that you’ve moved in the grub menu - It should boot now (but not for long).
  3. When it’s started up run sudo update-grub - This updates the grub definition for the moved partition - I wasn’t using this as my system boot menu, but I THINK the OS Prober uses this to determine where it is (which is a bit weird, but hey).
  4. Restart the PC and select the partition that contains the main grub menu definition.
  5. Run sudo update-grub
  6. Inspect /boot/grub/grub.cfg - It should now contain the correct UUIDs throughout!
  7. Nearly forgot! - Check you can boot everything

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