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.

I’m on fedora 38

  • Jordan_U@lemmy.ml
    link
    fedilink
    arrow-up
    30
    ·
    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
      link
      fedilink
      arrow-up
      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
        link
        fedilink
        arrow-up
        2
        arrow-down
        2
        ·
        edit-2
        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
            link
            fedilink
            arrow-up
            2
            ·
            edit-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
              link
              fedilink
              arrow-up
              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).

  • villainy@lemmy.world
    link
    fedilink
    arrow-up
    25
    ·
    9 months ago

    This looks like grub2-mkconfig was run with the output mistakenly set to /etc/default/grub. Someone ran

    grub2-mkconfig -o /etc/default/grub

    Instead of

    grub2-mkconfig -o /boot/grub2/grub.cfg

  • Throwaway1234@sh.itjust.works
    link
    fedilink
    arrow-up
    13
    arrow-down
    1
    ·
    edit-2
    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.ee
      link
      fedilink
      English
      arrow-up
      12
      arrow-down
      1
      ·
      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
        link
        fedilink
        arrow-up
        4
        arrow-down
        1
        ·
        edit-2
        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
      link
      fedilink
      arrow-up
      2
      ·
      9 months ago

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

  • funkajunk@lemm.ee
    link
    fedilink
    English
    arrow-up
    9
    ·
    9 months ago

    Somehow your /etc/default/grub file contents have been replaced with that of /boot/grub/grub.cfg

  • Brunacho@scribe.disroot.org
    link
    fedilink
    English
    arrow-up
    6
    ·
    edit-2
    9 months ago

    That looks like the grub file that’s put in /boot to make the menu to boot the system.

    Are you sure you’ve never run “grub2-mkconfig -o /etc/default/grub”? Because making the grub file you may have overwritten the config file.

    By the look of things I would reinstall grub with my package manager to forcing to overrun config files. Keep in mind this would return the file to your distribution defaults.

  • catloaf@lemm.ee
    link
    fedilink
    English
    arrow-up
    6
    ·
    9 months ago

    It says that’s /etc/default/grub in the top right. You sure you didn’t create a symlink or overwrite it?

      • Pantherina@feddit.de
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        9 months ago

        Well, if you look at the file… and search the internet for “fedora edit grub entry not possible” that works.

        You use grub2-mkconfig to create this file, and what you want to change it in another file that is used to create this one.

        The thing is, what do you want to edit?

  • Spectranox@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    1
    ·
    9 months ago

    Something has definitely been buggered seven ways from sunday here. If you need it I’m willing to provide you my config which you could then paste in. I haven’t changed anything, just enabled OS prober. Take this as a last resort though.