Failing to Successfully Install Grub on ZFS. Please help

Please Note: I am aware that with this setup if I use systemd-boot it will work, please don’t tell me to do that. I am also aware that with this setup, if I make /boot a separate partition that is not zfs and copy the kernel and initramfs accross, this will work, I am trying to fix/diagnose the actual issue though. Please don’t tell me to do that either, I will fall back to it if I have too, but I am trying to avoid that.

This is similar in functionality to having a single partition install that is ZFS. Which should be possible. I have done it with other OSes. What I think is happening is that the grub install command is not getting the zfs module preloaded to allow for the install process to recognise the filesystem.

Relevant Partition Layout

  • ESP is mounted to /boot/efi, and is fat32
    I know this oldschool method is not officially supported. I am doing it to solve other issues with the way grub is implimented on NixOS. My setup does actually work when doing this and not using ZFS. This was done as I had to unpick a lot of really borked behaviour from the standard nix options around grub.
  • /boot is not a separate partition from /.
  • / is zfs

The error I am getting:

/nix/store/jw0hq5my8ymgrzx229qylrgq5g7q84fm-grub-2.12/sbin/grub-install: error: unknown filesystem.
/nix/store/b9w7m1g5kbhyrx7k04g6yzpdh9avx2z6-install-grub.pl: installation of GRUB EFI into /boot/efi failed: No such file or directory

I have confirmed the modules were compiled (but not if done successfully as I don’t know how to do that):

[root@nixos:/home/nixos]# ls /mnt/nix/store/jw0hq5my8ymgrzx229qylrgq5g7q84fm-grub-2.12/lib/grub/x86_64-efi/ | grep zfs
zfscrypt.mod
zfscrypt.module
zfsinfo.mod
zfsinfo.module
zfs.mod
zfs.module

Other testing I have done:

  • Manual install with the modules forcibly preloaded with:
nixos-enter --root '/mnt'
grub-install --modules='zfs zfsinfo' --boot-directory=/boot --efi-directory=/boot/efi --removable --target=x86_64-efi --bootloader-id=GrUB --force /dev/sda
grub-install: error: unknown filesystem.
  • grub-probe from chrooted environment
nixos-enter --root '/mnt'
grub-probe: error: unknown filesystem.

My grub configuration.
Please note, I know the bash scripts are strange as hell, I tried to edit them for readability, but the extraInstallCommands option has some massive limitations in the way executes a shell environment, and this particular eccentric scripting style is relatively bulletproof given how the borked shell environment that extraInstallCommands envokes. Sorry for the readability headache, you probably don’t need to read the horrible parts, but I have included it for thoroughness’ sake.

The reason for the scripts is because the nix options around the efi binary file are not correctly handled/are ignored, and are kind of broken in general… or poorly documented. As a nix noob who is extremely confident messing with grub, I cannot tell which actually tell if it’s a documentation issue or a nix code issue. Those options really suck if you need to do anything like encrypted /boot, hence me writing and testing the hell out of a shell script to replace a lot of the options that aren’t working as I expected given snippets of an explaination that is the documentation. It was easier to subvert these options then spelunk in the source code.

Also, the grub shell script that is embedded into the efi binary file is incorrect for this zfs install, and is still setup for a btrfs setup I use on another machine, but as I haven’t even gotten grub correctly installed, I have left this for future me to correct. Please ignore it, it’s not an oversight.

{ config, lib, pkgs, ... }:
{

# Prerequisite Packages
    environment = {
        systemPackages = with pkgs; [
            efibootmgr
            grub2_efi
        ];
    };

#
    boot = {
        loader = {
            systemd-boot.enable = false; # Need to be explicitly stated for some reason I don't understand.
            efi = {
                canTouchEfiVariables = false;
                efiSysMountPoint = "/boot/efi";
            };
            timeout = 5;
            grub = let
                bootid = "GrUB";
                modules = "zfs part_gpt sleep btrfs file true echo test probe search_label search search_fs_uuid search_fs_file ls regexp cmp";
                stub = "${config.boot.loader.efi.efiSysMountPoint}/EFI/BOOT/BOOTX64.EFI";
                inherit (lib) escapeShellArg;
            in {

            # Attempts at zfs support, also see 'modules' parameter above
                zfsSupport = true;
                forceInstall = true;
                extraGrubInstallArgs = [ "--modules=zfs zfsinfo" ];
                extraConfig = ''
                    modprobe zfs
                    modprobe zfsinfo
                '';

                enable = true;
                device = "nodev";
                fsIdentifier = "uuid";
                efiSupport = true;
                efiInstallAsRemovable = true;
                enableCryptodisk = false;
                copyKernels = true;
                configurationLimit = 50;
#                gfxmodeEfi = "1920x1080x32,1920x1080x24,1024x768x32,1024x768x24,auto"; # Screen layout - uefi Needs tailoring to screen size.
                extraEntries = ''
                    menuentry "Reboot" {
                        reboot
                    }
                    menuentry "Shutdown" {
                        halt
                    }
                    menuentry "Boot to UEFI Firmware Menu" {
                        fwsetup
                    }
                '';
                extraInstallCommands = ''

# GRUB SCRIPT FILE OPERATIONS
# IF: grub_efi.cfg script file exists in the location it is embedded into the binary from
    [ -f /boot/grub/grub_efi.cfg ] || {
# ELSE: Re/Create the script file
    ${pkgs.coreutils}/bin/cat << 'EOS' > /boot/grub/grub_efi.cfg

search --label eMMC_btrfs_rootfs --set=root
set prefix=($root)/@/boot/grub
normal
EOS
    }


# EFI BINARY FILE OPERATIONS
# IF: Binary file exists, AND Binary file contains the clear text header for the binary segment of each of the modules that should be embedded within.
    [ -f /boot/efi/EFI/BOOT/BOOTX64.EFI ] && {
        [[ "$(
            ${pkgs.coreutils}/bin/cat /boot/efi/EFI/BOOT/BOOTX64.EFI | \
            ${pkgs.gnugrep}/bin/grep -Eo --binary-files=text \
                "$(
                    ${pkgs.coreutils}/bin/echo "${modules}" | \
                    ${pkgs.coreutils}/bin/tr -s ' ' | \
                    ${pkgs.gnused}/bin/sed 's/ $//' | \
                    ${pkgs.gnused}/bin/sed 's/ /|/g'\
                )" | \
            ${pkgs.gawk}/bin/awk '!seen[$0]++' | \
            ${pkgs.coreutils}/bin/sort | \
            ${pkgs.coreutils}/bin/tr '\n' ' '
        )" == "$(
            ${pkgs.coreutils}/bin/echo "${modules}" | \
            ${pkgs.coreutils}/bin/tr ' ' '\n' | \
            ${pkgs.coreutils}/bin/sort | \
            ${pkgs.coreutils}/bin/tr '\n' ' '
        )" ]] || {
# ELSE: Delete binary file prior to recreation
            ${pkgs.coreutils}/bin/rm -f /boot/efi/EFI/BOOT/BOOTX64.EFI
        }
    }

# IF: Binary file exists, AND Script file embedded in binary is correct
    [ -f /boot/efi/EFI/BOOT/BOOTX64.EFI ] && {
        [[ "$(
            ${pkgs.coreutils}/bin/cat /boot/efi/EFI/BOOT/BOOTX64.EFI | \
            ${pkgs.gnugrep}/bin/grep -Eo --binary-files=text \
                "$(
                    ${pkgs.coreutils}/bin/cat /boot/grub/grub_efi.cfg | \
                    ${pkgs.gnused}/bin/sed '/^[[:space:]]*$/d' | \
                    ${pkgs.coreutils}/bin/tr '\n' '|' | \
                    ${pkgs.gnused}/bin/sed 's/|$//' | \
                    ${pkgs.gnused}/bin/sed 's/[][\^$.?*+(){}]/\&/g'
                )" |             ${pkgs.coreutils}/bin/wc -l
        )" == "$(
            ${pkgs.coreutils}/bin/cat /boot/grub/grub_efi.cfg | \
            ${pkgs.gnused}/bin/sed '/^[[:space:]]*$/d' | \
            ${pkgs.coreutils}/bin/wc -l
        )" ]] || {
# ELSE: Delete binary file for recreation
            ${pkgs.coreutils}/bin/rm -f /boot/efi/EFI/BOOT/BOOTX64.EFI
        }
    }

# IF: binary file is missing. Create it
    [ ! -f /boot/efi/EFI/BOOT/BOOTX64.EFI ] && {
# THEN: Create it
    # Create Directory for EFI binary file in directory doesn't already exist
    ${pkgs.coreutils}/bin/mkdir --parents ${escapeShellArg (builtins.dirOf stub)}
    # Generate efi Binary and Embed Custom grub.cfg file and require Modules
    ${pkgs.grub2_efi}/bin/grub-mkimage \
        --prefix "" \
        --format 'x86_64-efi' \
        --config '/boot/grub/grub_efi.cfg' \
        --output ${escapeShellArg stub} \
        ${modules}
    }
# BOOT MENU OPERATIONS
# IF: There's a single entry in the boot menu with the correct UUID, and Filepath, AND there's single entry in the boot menu with the correct bootid
    {
        [[ "$(
            ${pkgs.efibootmgr}/bin/efibootmgr | \
            ${pkgs.gnugrep}/bin/grep "$( \
                ${pkgs.util-linux}/bin/blkid -s PARTUUID -o value $( \
                    ${pkgs.util-linux}/bin/findmnt -n -o SOURCE /boot/efi \
                ) \
            )" | \
            ${pkgs.gnugrep}/bin/grep -E 'EFI.boot.bootx64.efi' | \
            ${pkgs.gnused}/bin/sed -E 's/^Boot([0-9]{4})([[:alnum:]]*).*/\1\2/'
        )" == "$(
            ${pkgs.efibootmgr}/bin/efibootmgr | \
            ${pkgs.gnugrep}/bin/grep -E "${bootid}" | \
            ${pkgs.gnused}/bin/sed -E 's/^Boot([0-9]{4})([[:alnum:]]*).*/\1\2/'
        )" ]] && [[ "$(
            ${pkgs.efibootmgr}/bin/efibootmgr | \
            ${pkgs.gnugrep}/bin/grep -E "${bootid}" | \
            ${pkgs.coreutils}/bin/wc -l
        )" == 1 ]]
    } || {
# ELSE: Delete all entries matching only UUID and/or bootid
        ${pkgs.efibootmgr}/bin/efibootmgr | \
        ${pkgs.gnugrep}/bin/grep -E "${bootid}|$( \
            ${pkgs.util-linux}/bin/blkid -s PARTUUID -o value $( \
                ${pkgs.util-linux}/bin/findmnt -n -o SOURCE /boot/efi \
            ) \
        )" | \
        ${pkgs.gnused}/bin/sed -E 's/^Boot([0-9]{4})([[:alnum:]]*).*/\1\2/' | \
        ${pkgs.findutils}/bin/xargs -I {} \
            ${pkgs.efibootmgr}/bin/efibootmgr -q -B -b {}
    }

# Create New UEFI Boot Entry if Needed
# IF: There's a boot menu entry with the bootid
    {
        ${pkgs.efibootmgr}/bin/efibootmgr | \
        ${pkgs.gnugrep}/bin/grep -qE "${bootid}"
    } || {
# ELSE: Create entry
        ${pkgs.efibootmgr}/bin/efibootmgr -q -c -p 1 -d "$( \
            ${pkgs.util-linux}/bin/findmnt -n -o SOURCE /mnt/boot/efi | \
            ${pkgs.coreutils-full}/bin/cut -d'p' -f1\
        )" -L "${bootid}" -l EFI/boot/bootx64.efi
    }
                '';
            };
        };
    };
}

It’s been a hot minute since I used GRUB but if you install it for EFI, you should not pass a device. GRUB cannot install itself into a GPT-formatted disk, only into MBR disks.

It’s also been a hot minute since I used ZFS and I don’t think I ever bothered with /boot being a zpool but you need to make sure your zpool only uses features that GRUB can understand (ZFS - ArchWiki). I’d imagine not doing so could very well cause it to error out with “unknown filesystem”.

I think I also once attempted to get ESP and boot partition to be separate but it didn’t work for me for one reason or another, so it might just be broken in NixOS.

If you’re familiar with GRUB, I’d recommend you just check the NixOS code to see what actually happens. I doubt there’s anyone still around who knows and cares about it, so if you can contribute something here, that’d be much appreciated.

1 Like

I have /boot as a fat32 partition and this config works for me

  boot = {
    initrd.supportedFilesystems = [ "zfs" ];
    supportedFilesystems = [ "zfs" ];
    loader = {
      efi = {
        canTouchEfiVariables = true;
        efiSysMountPoint = "/boot";
      };
      grub = {
        enable = true;
        device = "nodev";
        efiSupport = true;
      };
    };
  };

Frankly, you are drastically overcomplicating this and doing what you want is really quite easy, even with encrypted /boot on ZFS. In fact I wrote a guide about exactly this nearly six years ago: Encrypted /boot on ZFS with NixOS

I just tested it and it’s still entirely accurate (including grub cryptodisk only working with LUKS1, not LUKS2), except that your zpool create command needs -o compatibility=grub2 (EDIT: Oh and also the extraInitrd method must be replaced with boot.initrd.secrets). All the custom scripting and manually running grub commands is all completely unnecessary and not how nixos does things.

But yes, I agree with @Artturin that this is much worse than just having /boot be your ESP.

2 Likes

Okay, first thing. Thank you!!! the issue was I wasn’t using the option -o compatibility=grub2 in the zpool creation. Thanks to you I have solved the issue.

So there are couple things I have found that aren’t the case in what you have said based off of my testing. Also, grub does actually support luks 2 but only if the keyslot is using the PBKDF2 key derivation algorithm. There is a project in the AUR for patching a module that gives grub support for the argon2id key derivation algorithm and an associated port of this patch to nix somewhere on reddit as well. The issue is that the module that gets compiled does not perform the operations in a multithreaded way. This means the decryption process with this algorithm can take up to 10 minutes when done in grub vs something like 30 second for equivilent settings in the initrd. You can mitigate some of the hell that is that experience by doing kexec for reboots and skip straight to the initrd second decryption system drive. There are further performance gains you can make by having the second decryption use a different slot or (if you want to not weakend the accessible keyslot from an at rest state for speed) a different header file stored in the initrd with a weaker slot that is nice and fast. But first boots will still take 10 minutes or so. This trick does work okay on nix from my testing, but is a little tricky to impliment.

One issue is that the option boot.loader.grub.extraGrubInstallArgs is only respected for second stage of the grub boot process. The so called normal mode, that only occures after the root and prefix variable are set and the efi binary executes the normal module for the change root operation. Thus entering into what people know as the grub splash screen. It is however not respected in the generation of the efi binary file that your firmware is pointed at when you allow nixos to control this operation. This means that if you need modules or script files in that binary to do pre normal mode operations, such as decrypting a rootfs in which /boot directory (where the files for normal mode are stored) then you’re shit out of luck unless you do crazy things like I have.

The same is true for the boot.loader.grub.extraConfig option. Meaning you cannot embedd the grub shell scripts in the binary file either, unless you write manual scripts for handling it like I have. These issues are compounded by the fact that using the option boot.loader.grub.efiSupport to make sure the efi grub module files are included; and the option boot.loader.efi.efiSysMountPoint set to /boot results in nixos creating efi binary file (that cannot boot depending on your goals) and associated entry that is superfluous to the one that I manually create (that is correctly formatted), even when the option boot.loader.efi.canTouchEfiVariables is set to false. But also… not always. It’s actually a little inconsistent from my testing… I think it’s hard to replicate the issue, and like I said… I don’t really know nix all that well. But if you set the option to something other then /boot this never happens. So fine… I won’t mount the ESP to /boot I wasn’t going to anyway as doing so is an issue for avoiding having an unencrypted kernel and initrd file.

The reason for this crazy setup is that if you’re using keyfiles and header files in an external location and want to have the kernel and initrd files actually within the encryption you need this ability. This is important as these files can be binwalked and deconstructed for their cryptographic material. Doing this kind of this mitigates that risk. It’s actually a relatively standard setup with grub on other distros and not exactly outside of the norm for what you can do with grub. Not to mention all of the other nice scripting features and tools grub has. Which is why I both do this and want to use grub anyway. Because grub is actually pretty cool. This setup however has the encryption stuff stripped out, as I am writing it for a underpowered system that won’t have sensitive material on it. But I am trying to write it in a way I can shim in the encryption as a separate module if I wish to.

My scripts that you see above could be simplifed a fair bit. But the reason they are complex is mostly to handle low write endurance flash media for the storage location of the efi binary such to make it safe to run these scripts on things like SDcards and USB flash drives without wearing them out more and more on every rebuild. Those scripts are mostly checks to see if anything needs to be done rather then repeating them when no action is required. Regardless they do need refactoring, and there was one error in what is posted above I found that was causing a lot of issues. I rewrote them because I originally only wrote them to handle the decryption process, and this rewrite was a recent change I hadn’t sat down and perfected yet. But the ZFS stuff was throwing me for a loop as I am also trying to factor things such that I can shim in the ZFS support with or without encryption as yet another module.

I do intend to try and impove those nix options in the future once I know more nix. They are really shitily documented and don’t do what you would expect based on my experience working with complex grub systems. Especially if you actually like to play at the low level grub stuff like I can easily do on any other distro.

I know this is complex but I hope you can understand why I am trying to do things the way I am. Also, again. THANKYOU!!! that oversight for the zpool creation compatibility option was the major issue I was facing <3 I appreciate the clip over the back of the head.

… Did you miss the part where my blog post does indeed use grub to decrypt your FS? That’s what enableCryptodisk = true; does, and that’s why I set efiSysMountPoint = "/boot/efi";. Like I said, you are drastically overcomplicating this. The nixos options described in the blog post work fine.

In fact, on legacy BIOS systems, this is already how the GUI installer for NixOS works. It only creates an encrypted file system and installs grub as a BIOS bootloader to decrypt the file system and start the kernel from there. My blog post just does that with EFI and ZFS.

… okay then. I don’t know what to tell you my dude.

I spent nearly a fortnight trying to get that option to effect the binary with no luck the first time around. I read the crap out of the wiki and a heap of guides. I binwalked that binary I don’t know how many times. I was unable to see the modules that should have been there, and I was unable to get it to successfully boot in the layout I wanted.

Also, I am new nixos. I am learning, but the documentation really sucks. Lets look at the description of that option. “Enable support for encrypted partitions. GRUB should automatically unlock the correct encrypted partition and look for filesystems.”. This could mean two things. Either the decryption is done using modules embedded into the efi binary file in which case, how is it able to detect the cryptographic parameters you used and match modules correctly especially since nixos doesn’t seem to do that all that well at later stages of the boot process for the hardware-configuration.nix… Or the expectation is that /boot in clear text and the modules will be accessible in normal mode, which seems to be what happens based off my memory and notes.

The only real way I can figure out what is actually meant such vaguely worded nix options is through trial and error doing blackbox testing, or to read the source code. I struggled with the source code because it is a mind bender for newbies like me. So I created a method that is actually bulletproof in my testing at least every test I could think of. A method based off the work of other people running into similar issues. Not something I can say about the nix options regarding grub… and mostly a grub specific issue too.

The documentation sucks elsewhere. But the behaviour is consistent with other options. But less so for the grub options. For example of what I am talking about, try compiling the zfs grub module using the nix options from a clean install. It fails half the time. I have tried it on VMs, I have tried it on bare metal (other physical hosts). Regardless that option is janky as hell and throws endless errors, only working when you rerun the install again and again. The nix code, kills the compile job early, and doesn’t follow the source files paths on first run as they are called before they exist. I think… like I said, I don’t know enough to know and to read the output of the trace, and the associated source code to figure that stuff out. It would be easy if it was any other distro, but nixos has a monolithic thing to learn in the way, that being the language… which is not at all easy to learn as it takes a lot of unlearning to pickup. But all I know is if I install enough times it eventually successfully works. Fine whatever, I just rerun things until they work then walk away from the problem.

And what happens when I put my hand up for help figure out what the hell is going on. Trying to ask for help confirming or navigating these issues usually results in people telling me to use systemd-boot or telling me about how wrong I am doing something irrelevant to the question actually asked. Like you just did with a different zfs issue with grub.

For what it’s worth, that’s actually really simple script. I have written entire programs in shell script. That script is simple, and very stable. What makes it look complex is the adaptations need so it works the nix context, and so that it works in the boot.loader.grub.extraInstallCommands option. If you want another example of how poorly implimented grub is in nixos, try scripting in that option. Figure out it’s limits. Because… it’s more limited than grubshell is, and doesn’t play consistently. A lot of the scripts structure is to account for that fact, and as a result a lot of the structure is to make it more readable. For more evidence that grub is very poorly implimented in nixos. Try doing things like using the tab complete on the extended grub commands in the live install enironment. It breaks on environment paths for the completion suggestions and locks up the shell session. And talking about the shell in nixos… boi, does it hate tabulators. When creating shell scripts and testing functions I am writing, it have had to change a fair bit of my process to account for nixos tantruming with script files. NixOS is not stable for a lot of linux users switching in. I don’t count this kind of crap as stable.

To be fair to you, I never followed your exact method for encryption, but I did follow other methods to universal failure in achieving my goals of getting configuration parody with other installs I am switching over to nixos. I’ll give your method a try in a VM tomorrow (it’s late for me currently and I am not going to bother tonight), and see if I get it to work and it allows me to do what I want to do.

I took the route I did because of the lack of control and the unstable and opaque (given my struggles with the nix expression language) implementation of grub on nixos and to get the control I wanted, now… and it worked!!! took a bit. But it’s actually kind of bullet proof on the encryption side of things and the handling of the binary file. Largely because of my scripting of which you can see a modified part above. I am holding onto that above script because I want to shim it as a module with the encryption stuff at a later date to unify and simplify my hacks to make nixos behave. Also, ultimately I’m alowed things differently if I want to… aren’t I? am I breaking a rule here?

I don’t get this about the nix community. Why is it so spikey in this regard. I do complex stuff, it helps me learn and feeds my passions. It makes better at my job. This is an example of that, kind of… via the kiss principle it’s actually less complex in implementation in the way it subverts nix options if you take into consideration nixos’s clunk. I actually don’t understand why is doing things a little off purity is such a target for abusive resistance from the nix community in particular. It’s not like this code nearly ever gets executed once the system is installed. I have found that no other distro community is quite so bad in this regard. I don’t know about other peoples experience but mine has been horrible with the nix community, and I find this is actually an emotionally exhausting aspect of nix. It’s death by a thousand off subject rejections of a different path. This community is kind of aggressive towards relatively specific questions when something is a little complex. I want to fix the nixos grub stuff… but I am way to ignorant to even attempt it at this stage. That’s fine. Whatever, future problem. In the meantime I have what I want working, and it’s working very well.

I asked about help with zfs support. You helped me in that regard. I am thankful for that help. I don’t want help with the encryption side of things. I didn’t ask for help with the encryption side of things. I have spoken about in justify myself to you and others to explain why there’s a big script in my code. Next time around I won’t include that kind of thing for thoroughness’ sake. I know it’s complex, I know there are likely better solutions, more pure solutions, but I understand it very well, and it’s stable. That is more than I can say about the relative nix options.

Since you have given me suggestions off topic to the question I asked about, and when I was simply trying to give you an explanation for my config, you were so insistent about me doing things the wrong way. Let me return the favour. Responses like this make me want to hide what I am doing even more, and ask for help less often. Simple in nix is not always elegant or consistently stable. Maybe keep it to the questions people are asking for help with. Be generous with your allowance of their wish to do things differently to you, when they talk about it like I have. There are good reasons behind what I have done, and I have not told you them all. Maybe if you need to comment further, teach people what’s going on in the underlying source code and elaborate on the mechanism that are poorly allude to in the documentation. Because I can’t heads or tails of it a lot of the time, and there is a really big community issue in the lack of sympathy for new comers and working with them while they trying to have fun with their configs. This approach you have employed is demoralising for those of us who genuinely do know what we are talking about and what we are doing, but don’t know how to do it in nix. Especially considering the not exhaustive list of instabilities I have stated above. If you don’t believe, test them. Grubs implimentation is not good on nixos.

I will try you method tomorrow, but I am not sure you know what I have been doing with my config well enough to so boldly state I am wrong in my methods.

Nix is a programming language, and in my experience, this community operates more like a programming community than a Linux community. And not an excuse for it, but to set this in perspective - I’ve personally seen far more smug and presumptive behaviour in other programming communities compared to here (and in terms of distros, I could name a couple rough ones too…)

But really this comes from a couple places:

  • Assuming that most questions with a “weird” premise are X-Y problems - more specifically beginners trying to create overwrought solutions to solved problems, because they misunderstood (or never encountered) a core concept
  • Programming communities tend to attract the kind of personality that immediately points out anything aberrant - which great for debugging, but not always productive in conversations.

Essentially, I would say a fair amount of it comes from a good intention to prevent extra maintenance work and confusion for the question-asker down the line, and also make it easier to provide support from the answerers’ point of view.

In your case since you’ve decided you know what you are signing up for by creating the manual script, I don’t see a massive issue with ignoring that part and focusing on the core issue. And glad you got the issue resolved. It’s easy for answerers to not see the difference between someone who has no idea what they are doing vs. someone with decent Linux experience but not nix experience - sometimes they look the same on the outside without more context, so I sympathise with the frustration of having to provide extra context to prove it’s not an X-Y issue. You’re of course welcome to ignore the tangential advice in return if you feel that it’s not relevant for you, I think that’s more sustainable than overjustifying.

1 Like