Announcement

Collapse
No announcement yet.

how to open grub.cfg in the ESP?

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Qqmike
    replied
    Hi jlittle. Thanks for your explanation. I may have another solution for the "multiple installation" issue.

    First, yes, "the last GRUB installed" controls the booting. Frustrating. But you can always boot back into your controlling GRUB OS and issue grub-install and update-grub, which I know you know.

    Side note: I keep refind installed just for fun, for a backup, and in case I have to help someone else with it. But, if it gets an update, then it takes over BootOrder #1 (in efibootmgr listing). So, I either leave it that way or change back to my regular OS GRUB by one of two ways: (1) Use efibootmgr to change the ordering; or (2) Boot into the OS and do grub-install and update-grub.

    OK, so back to the subject:

    In my how-to, I describe 5 ways to dual boot. It is this how-to:

    UEFI Simplified, a quicker version
    https://www.kubuntuforums.net/showth...l=1#post379977

    and the 5-ways described there:

    5 methods for dual booting:
    #1, #2, #3, do nothing special:
    (1) Use rEFInd. (2) Use GRUB2-EFI. (3) Use the UEFI firmware.

    Or, try #4 or #5:

    (4) Ubuntu-based OSs: set up separate subdirectories of EFI: /boot/efi/EFI/<some_ubuntu_distribution>
    Set up the dual-boot: Both LinuxX and LinuxY are Ubuntu derivatives, using the same ESP.
    Disable Secure Boot in firmware. Install LinuxX, boot into it, then:
    Code:
    sudo grub-install --bootloader-id=<some_name_for_LinuxX> --no-uefi-secure-boot Repeat with LinuxY. Optional: adjust BootOrder and generate new boot menus.

    (5) Separate ESPs:
    GParted: set up the ESPs and the OS partitions you need, give each ESP a label you will recognize. Install each OS, in sequence, with this procedure: Turn off all ESPs (turn off their boot flags) except for the ESP you wish to be used by the OS you are about to install now. Install the OS using the Manual installation method. Repeat for each OS. Then turn on all ESPs (re-set their boot flags in GParted).
    See the Methods #4 and #5, especially #5 using separate ESP (one for each OS). Re #5, if you set that up, and then boot into any of the OSs, issue this command:
    df /boot/efi
    and it will show you the sdxn of the ESP that is mounted at /boot/efi for THAT specific OS (that you have booted into).

    Leave a comment:


  • jlittle
    replied
    Originally posted by Qqmike View Post
    ... by "multiple installs," what do you mean?
    Several distros installed at the same time.

    Say you want to give Disco Dingo a try. Alongside your normal Kubuntu, you set up a partition for it and install to that. Then, maybe you decide it's not ready yet, and delete it. Next reboot, you get

    grub >

    and a blinkiing cursor; the grub rescue prompt. When disco installed, it took control of grub, which then can't find itself, because you deleted it.

    Or, maybe you install Linux Mint on another drive. You like it, and use it for some tasks, but keep Kubuntu for your main install. On Kubuntu, you customize grub for something, maybe a nice theme, or a kernel parameter to address a hardware issue. One day you log into Mint, it updates itself, and your nice theme is gone, or your hardware stops working.

    I encountered problems like this early in my use of Kubuntu, and it never occurred to me to avoid the problems by disabling the mount of the EFI partition except in one install. There's still the problem that at the installation time the new install will take over the boot, but I know to go back to my main install and rerun grub-install there. I mentioned this point thinking someone like my old self would find out about this approach; there are others, like not using grub, or using UEFI features to control the boot.

    Leave a comment:


  • Qqmike
    replied
    Re my Post #14: Silly me. After editing /etc/fstab to read umask=0022 (instead of reading 0000), I only ran sudo mount -a. I did not re-boot. So after re-booting, the new setting umask=0022 did take effect and I can open and read but can not rename or create any folders or files. I CAN open /boot/efi/EFU/ubuntu/grub.cfg with Kate, though. Conclusion: umask=0022 does what kubicle said it would do in Post #12.

    Leave a comment:


  • Qqmike
    replied
    I tried umask=0022 in fstab (for the ESP, /boot/efi), and I can't see any difference between that and umask=0000. I.e., with umask=0022, it looks like I can do anything to the contents of /boot/efi/EFI/ubuntu: create text files, create folders, rename folders. What am I not understanding here!

    See next post.
    Last edited by Qqmike; Jan 21, 2019, 05:34 PM.

    Leave a comment:


  • Qqmike
    replied
    jlittle: Another aspect of this picture applies with multiple installs. If they all mount the EFI partition they'll fight over who maintains grub on it, which can lead to confusion, and problems booting. A simple measure to stop this is to choose which install is to maintain grub and disable the mount of the EFI partition in the others.
    I'm not sure what this all means. First, by "multiple installs," what do you mean?

    A few additional notes:
    1. If you have krusader, and wish to GUI edit files on the efi partition, you can start krusader as root and edit the files using krusader's internal editor (in root mode krusader, select file and press f4)...this will work without changing the umask.
    2. If you are going to edit the efi fstab umask, it would be safer to use umask=0022, which doesn't give straight write access...you could still open the files with normal (not root) kate since it has read access, and it should still ask for password when you try to save
    (as it doesn't have write access)...generally more secure than having them world writable.
    Thanks, kubicle, I added that to my notes on all this. Just to comment on this ...

    I hear you. Looks like editing a text file with Kate can be done without umask=0000. But then that leaves other edits to the ESP, to /boot/efi/EFI/ubuntu contents: editing an .efi executable (which I would never do, don't know how!); or creating a new folder under /boot/efi/EFI/ubuntu, perhaps a duplicate for a backup boot; or creating/registering a new UEFI boot variable; or labelling, re-naming an existing UEFI boot variable for the sake of clarity (like when dealing with mulitple boot variables all named "ubuntu" (Ubuntu-family distros)).

    I have had several occasions where I basically needed full access to the ESP to create and populate new folders (containing new UEFI boot variables) under /boot/efi/EFI/ubuntu.

    Just had this thought: One could turn on umask=0000, do all the edits requiring flexible permissions, finish editing, then revert back to umask=0022. That way, the ESP would not be open all the time.

    Leave a comment:


  • kubicle
    replied
    A few additional notes:
    1. If you have krusader, and wish to GUI edit files on the efi partition, you can start krusader as root and edit the files using krusader's internal editor (in root mode krusader, select file and press f4)...this will work without changing the umask.
    2. If you are going to edit the efi fstab umask, it would be safer to use umask=0022, which doesn't give straight write access...you could still open the files with normal (not root) kate since it has read access, and it should still ask for password when you try to save
    (as it doesn't have write access)...generally more secure than having them world writable.
    Last edited by kubicle; Jan 21, 2019, 01:43 AM.

    Leave a comment:


  • jlittle
    replied
    Another aspect of this picture applies with multiple installs. If they all mount the EFI partition they'll fight over who maintains grub on it, which can lead to confusion, and problems booting. A simple measure to stop this is to choose which install is to maintain grub and disable the mount of the EFI partition in the others.

    Leave a comment:


  • Qqmike
    replied
    So, I guess I can see the dev's thinking on locking down the ESP mount point. No problem. As long as there is a workaround for the rest of us who want it open, like the fstab umask edit. In my case, I'm the only user on this system. If I accidentally mess up my booting, so what! It can always be fixed. Absolute worst case, I can re-install Kubuntu in 10-15 minutes.

    Leave a comment:


  • Qqmike
    replied
    I'm still a bit concerned that even using Krusader as root, I was unable to open /boot/efi/EFI/ubuntu/grub.cfg with Kate.
    Well, actually, you CAN open Kate in Krusader, but not as root ... because you can't open Kate as root anywhere, anytime, anyhow. You open Kate normally, and then edit Kate, and then enter your PW upon saving changes. So, that's OK. Looks like this was jglen490's issue in his Post #2, also.

    Leave a comment:


  • Qqmike
    replied
    A little experiment ... Going back to the original /etc/fstab, which is locked down to root only:

    Code:
    # /boot/efi was on /dev/sda1 during installation
    UUID=C896-1CFF /boot/efi vfat umask=0077 0 1
    You can then open the grub configfile at a regular Konsole line, easily:
    Code:
    kate /boot/efi/EFI/ubuntu/grub.cfg
    and you can edit that file by entering your PW upon saving your changes.

    So that is one way to at least get at that file to edit, although not being able to get into /boot/efi is cumbersome. Again, the solution in Post #6 (umask=0000) fixes all these issues, though.
    Last edited by Qqmike; Jan 20, 2019, 11:23 AM.

    Leave a comment:


  • Qqmike
    replied
    Thanks, jglen490 for looking at this, also.

    Leave a comment:


  • Qqmike
    replied
    Many thanks, jlittle. Yes, your idea works, of course. I would like to inform you of the history here, because I do agree with everything you say in your post regarding the fstab.

    So, here's the discussion.

    Before I made any changes, my original /etc/fstab was this (upon installing Kubuntu):

    Code:
    # /boot/efi was on /dev/sda1 during installation
     UUID=C896-1CFF  /boot/efi       vfat    umask=0077      0       1
    After doing the edit, and making some comments, my fstab now looks like this (I added some comments, as you can see):

    Code:
    # /boot/efi was on /dev/sda1 during installation
    # This statement only gives read/write access to root:
    # UUID=C896-1CFF  /boot/efi       vfat    umask=0077      0       1
    # NOTE: Next line gives full permissions to everyone on /boot/efi:
    UUID=C896-1CFF  /boot/efi       vfat    umask=0000      0       1
    OK, so that works, and I now have full access to my ESP (through the mount point /boot/efi); and I tested this, and I can now edit Kate (which only requires your password to save any changes).

    Here's the history, another thread:

    https://www.kubuntuforums.net/showth...l=1#post418356

    and my concluding Post #21:

    https://www.kubuntuforums.net/showth...l=1#post418408

    The opinion was expressed there that /boot/efi should be locked down to users. This was not the case for 14.04; it is new in 18.04 (AFAIK).

    I'm still a bit concerned that even using Krusader as root, I was unable to open /boot/efi/EFI/ubuntu/grub.cfg with Kate. I think that's because Kate can not now be opened at all with root privileges. For example, you can't use sudo -i, and then kate, to open Kate as root--you'll get the message that you can't run Kate as root.

    But the heavy-handed solution of editing fstab with unmask=0000 solves all these issues; but it may be considered unsafe for normal, average users ... ?

    Thanks for your help here, jlittle.

    Edit:
    See Post #8 for editing with Kate at Konsole.
    Last edited by Qqmike; Jan 20, 2019, 11:22 AM.

    Leave a comment:


  • jlittle
    replied
    Originally posted by Qqmike View Post
    Code:
    -rwx------ 1 root root 1116024 Nov 23 07:03 grubx64.efi
    
    /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
    This means that the ESP partition has been mounted with umask=077, which means access only to the owner. If it's mounted via /etc/fstab, check the options for something like umask=077. If there's none, maybe add umask=000 or 022. I don't know where umask=077 would come from otherwise, because it's not the default, generally that's 022, rwxr-xr-x.

    Leave a comment:


  • Qqmike
    replied
    OK, thanks, guys. Sorry, I got pulled away here for 8+ hours, just got home after midnight now.

    Actually, let's not worry about the "why" I might want to edit /boot/efi/EFI/ubuntu/grub.cfg (there have been reasons; and yes, there is some issue with " ...the grub.cfg used is written into the grubx64.efi executable" and so on).

    I'm not happy that I can't fully access my ESP stuff, not easily, anyway. Why, being in Krusader as root, isn't it possible to open grub.cfg with Kate? And you sure can't use Dolphin as root anymore.

    jlittle:

    Code:
    mike@mike-All-Series:~$ sudo -i
    [sudo] password for mike: 
    root@mike-All-Series:~# cd /boot/efi/EFI/ubuntu
    root@mike-All-Series:/boot/efi/EFI/ubuntu# ls -l
    total 3720
    -rwx------ 1 root root     108 Nov 23 07:03 BOOTX64.CSV
    drwx------ 2 root root    4096 Jul 30 16:25 fw
    -rwx------ 1 root root   71400 Jul 30 16:25 fwupx64.efi
    -rwx------ 1 root root     126 Nov 23 07:03 grub.cfg
    -rwx------ 1 root root 1116024 Nov 23 07:03 grubx64.efi
    -rwx------ 1 root root 1269496 Nov 23 07:03 mmx64.efi
    -rwx------ 1 root root 1334816 Nov 23 07:03 shimx64.efi
    
    root@mike-All-Series:/boot/efi/EFI/ubuntu# mount | grep efi
    
    efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
    /dev/sda1 on /boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

    Leave a comment:


  • jlittle
    replied
    Firstly, editing that file might have no effect; it is ignored on my Kubuntu, both in bionic and cosmic. AFAICT the grub.cfg used is written into the grubx64.efi executable. (In bionic I can see where grub.cfg is found by running strings -n 10 grubx64.efi | grep @, but it doesn't work in cosmic.)

    Originally posted by Qqmike View Post
    /boot/efi/EFI/ubuntu/grub.cfg

    Can navigate to and see contents of /boot/efi/EFI/ubuntu.
    Can right-click on grub.cfg ... and select open with Kate ...
    But it won't open.
    I don't understand that. Kate will open the file for me. What does
    Code:
    $ cd /boot/efi/EFI/ubuntu
    $ ls -l
    $ mount | grep efi
    say?

    The EFI partition's type is vfat so the permissions on files and directories in it are determined at mount time, based on the umask of the process mounting it, unless the mount has umask, fmask or dmask options. So I suppose it could be mounted -o fmask=777 to stop you opening the file. That mount | grep command would reveal what mask is being applied.

    If you want to change the grub.cfg that is used, use grub-install. I have a btrfs subvolume called @grub, mount the btrfs top level on /mnt/top, and use
    Code:
    $ sudo grub-install --boot-directory=/mnt/top/@grub/boot --efi-directory=/boot/efi

    Leave a comment:

Users Viewing This Topic

Collapse

There are 0 users viewing this topic.

Working...
X