I’m trying to update my grub boot order back to booting the first option instead of the second, so I run sudo nano /etc/default/grub, but it brings up this, which is not the file I want to edit.

  • Jordan_U@lemmy.ml
    12·
    9 months ago

    This should get you back to defaults:

    sudo cp /usr/share/grub/default/grub /etc/default/grub && sudo update-grub

    At some point you definitely did accidentally write to /etc/default/grub when you meant to write to /boot/grub/grub.cfg.

    There’s no shame in that; Grub’s configuration process is very confusing and counter-intuitive.

    Everybody who has used Linux long enough has stories of breaking their systems in sillier ways, and this didn’t even really break your system 🙂.

    • Interstellar_1@pawb.socialOP
      3·
      9 months ago

      THanks! but I’m getting the error cp: cannot stat '/usr/share/grub/default/grub': No such file or directory when running this.

      • Jordan_U@lemmy.ml
        21·
        9 months ago

        What version of Ubuntu are you using?

        What is the output of the following command?:

        dpkg -l | grep grub

        If you urgently want your grub menu to default to the first entry that can be done first, but unless that’s needed I’d prefer to get to the root of the problem(s) and get a proper fix.

          • Jordan_U@lemmy.ml
            2·
            9 months ago

            Ahh, sorry.

            For Fedora it looks like the default /etc/default/grub looks like this:

            GRUB_TIMEOUT=5 GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)" GRUB_DEFAULT=saved GRUB_DISABLE_SUBMENU=true GRUB_TERMINAL_OUTPUT="console" GRUB_CMDLINE_LINUX="rhgb quiet" GRUB_DISABLE_RECOVERY="true" GRUB_ENABLE_BLSCFG=true

            ( Taken from https://discussion.fedoraproject.org/t/how-to-regenerate-etc-default-grub/72677/9 )

            If you’re using LVM / LUKS you may need additional kernel parameters, like resume=… for suspend to disk to work properly.

            Please, before doing anything else, post the output of the following:

            cat /proc/cmdline

            And make a backup of your existing grub.cfg with:

            sudo cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg-backup-$(date --iso-8601=s)

            Also, be sure that you have a LiveUSB on hand. You don’t want to be SOL if we break something and can’t boot again without fixing it first.

            • Jordan_U@lemmy.ml
              1·
              9 months ago

              Interstellar_1@pawb.social

              Sorry again. I wrote this last comment (and this one, TBH) from my phone and “–iso=s” should have been “–iso-8601=s” . I’ve edited my comment and the command should now work (Making a backup of your grub.cfg containing the date, to the second, in the filename. I did that to hopefully avoid you running the same command again after trying some fixes and accidentally clobbering your backup).

  • Throwaway1234@sh.itjust.works
    5·
    9 months ago

    so I run sudo nano /etc/default/grub

    For improved security during file edits that require root access, it’s highly advised to use sudoedit (or sudo -e). This method is considered the standard practice to avoid the security pitfalls associated with directly invoking editors with sudo. To ensure the use of nano with sudoedit, simply set the VISUAL environment variable with export VISUAL=nano before running sudoedit . Alternatively, for a one-off command: VISUAL=nano sudoedit /path/to/file.

    Please note that while sudoedit is a safer starting point, it’s not the only method available. Alternatives such as doas, doasedit, or leveraging polkit with pkexec can offer even more controlled and secure ways to manage file editing with elevated privileges. However, it’s perfectly acceptable to stick with sudoedit, as it’s a commonly trusted tool.

    Be aware that direct usage of sudo nano or other editors is strongly discouraged. It bypasses important security mechanisms and can lead to inadvertent system-wide risks.

    EDIT: changed VISUAL=nano sudoedit to VISUAL=nano sudoedit /path/to/file.

    • catloaf@lemm.eeEnglish
      61·
      9 months ago

      On shared systems with untrusted users, you’re right. On your own system when you already have full admin rights, sudo nano is fine and doesn’t have any security implications that I’m aware of.

      • Throwaway1234@sh.itjust.works
        1·
        9 months ago

        I agree with the general sentiment. Thank you for mentioning that!

        Though, the use of sudo nano might still pose a risk if any software found on the system is either vulnerable/exploitable, not trusted, or simply exploitative. In that case, like what’s achieved through sandboxing i.e. not allow the software to go beyond their intended scope, it makes sense to put a limit on the capabilities of the software. And to that effect, the use of sudoedit still offers merit over sudo nano.

        Though, if the user doesn’t (already) rely on bubblejail, firejail, Flatpak etc for what they offer in sandboxing. And/or if said user simply doesn’t care for the principle of least privilege, then the use of sudo nano is perfectly valid.

    • Pantherina@feddit.de
      1·
      9 months ago

      Never heard of sudoedit. I want to experiment with a system where I alias sudo=pkexec, VanillaOS does that