Gparted Uefi

0 views
Skip to first unread message

John

unread,
Aug 3, 2024, 6:11:01 PM8/3/24
to predelinve

GParted live is based on Debian live with GParted installed. Therefore there are 2 kinds of boot parameters:

  1. Boot parameters from Debian live-boot and live-config. You can refer to the manual of live-boot and manual of live-config.
  2. Boot parameters specially for GParted. All of them are named as "gl__*", they are: gl-debug, gl_numlk, gl_capslk, gl_batch.
    • gl-debug is for you to enter command line prompt before any GParted-related action is run. This is easier for you to debug.
    • gl_numlk, gl_capslk.
      To turn on or off the numberlock or capslock of keyboard. You can use "on" or "off", e.g. gl_numlk=on to turn on numberlock when booting.
    • gl_batch
      To enable batch mode, put it, then GParted live won't ask about X configuration during booting.
      e.g. gl_batch
    • no-gparted-start
      To turn off the GParted start automatically. By default the GParted program will be launched when GParted live boots. If "no-gparted-start" is assigned in the boot parameters, it won't be launched automatically. (This parameter works for GParted live >= 1.3.1-3).
Therefore if you want to assign the language and keyboard layout as German one, and let the system to automatically detect the X-window configuration, you can put the boot parameters as:
locales=de_DE.UTF-8 keyboard-layouts=de gl_batch

I want to be able to move and resize partitions on my systems, so I wanted to make a live GParted USB, thing is, it doesn't support Secure Boot, Ubuntu is overkill and takes long to boot (and depending on the version, doesn't always have gparted installed), is there a compact live Linux that would be able to boot on Secure Boot?
Could I just sign the GParted Live bootloader and the kernel with my MOK? Could I do so with several MOKs to work with my multiple computers? Or must I create an MOK that I will enroll on all of my machines?
Disabling secure boot is an option on all my machines, but it's a hassle to get back on since some of them delete the MOKs when disabled.

I want to increase the size of the EFI System Partition to 750MiB so.i can install Arch Linux alongside Windows 10 because EFI System Partition Windows gave me which is only 100MiB is too small. Arch Linux recommends you mount the ESP at /boot instead of /boot/efi and 100MiB is too small for /boot. I don't want to touch the Recovery Partition.

This question is among the top results on Google for "How to resize the EFI System Partition" (unsurprising, given that's the question title), however the current answers here, though containing good advice for the OP's situation and generally useful information, do not actually attempt to answer that question as stated. My previous rather terse (now deleted) attempt to answer that question was downvoted, so here's a more thorough one.

There's a good chance that you're reading this because you've tried the obvious thing (use gparted) and got the error "GNU Parted cannot resize this partition to this size. We're working on it!". You may have also tried doing it from within Windows (using Disk Management), only to discover that Windows refuses to perform any operations with the ESP at all.

If you are resizing the ESP of the disk you're booting on, ensure you have some bootable rescue media on hand that you can use to repair your system in case things go wrong. Having a backup of your data before doing any disk partitioning operations is a good idea in general.

That should be everything. I've successfully used the above procedure to resize the ESP for a Windows installation whose ESP was too small (50 MB) to allow Windows to upgrade to Fall Creators' Update (before resizing the ESP, Windows Update failed with error 0x8E5E03FB, and the Update Assistant with error 0xc1900200).

The Arch community has taken the Freedesktop.org Boot Loader Specification to heart. AFAIK, Arch and its derivatives are the only distributions to do this, and even in Arch, it's not required. The Boot Loader Specification recommends using a shared FAT partition, such as the ESP, as the location to store Linux kernels, along with a system to isolate one distribution's kernels from another on this partition and to manage boot loader configuration for the kernels.

The Boot Loader Specification is an attempt to solve some real problems with Linux distribution co-existence on multi-boot computers; however, because it's been adopted by just one major distribution, even after several years of existence, it doesn't provide any practical benefits. Furthermore, the Boot Loader Specification is tied closely to the systemd-boot boot manager, which is rather unpopular except in the Arch community. Although systemd-boot has some advantages, unless you're familiar enough with the field to understand those advantages and know that you need them, you might not want to start setting things up in odd ways (like mounting the ESP at /boot) just to enable use of systemd-boot. What's more, systemd-boot has one huge disadvantage: It can launch follow-on boot programs (including Linux kernels) only from the partition from which it was launched itself. This in turn means that, if you use systemd-boot, you're pretty much committed to storing systemd-boot, your Linux kernels, and the boot loaders for other OSes (like Windows) on one partition -- the ESP. This conforms to the Boot Loader Specification vision, but it creates its own problems.

That said, if you want to enlarge an ESP, you can do so with various tools; however, this means you'll need to shrink the following partition from its start point. This is riskier and more time-consuming than shrinking a partition from its end, so I strongly recommend backing up the following partition. Also, on a Windows computer, the partition following the ESP is likely to be a Microsoft Reserved partition, which is basically just an empty partition that Windows uses for scratch space. It normally has no filesystem, so most partitioning tools won't let you shrink it -- and Windows likes it to be a specific size (100 MiB or 128 MiB, IIRC). You may instead need to shrink the partition following the Microsoft Reserved partition, delete the Microsoft Reserved Partition, and create a new one. This is all one huge hassle and greatly increases the risks involved in installing a new OS.

Instead, you may want to create a new ESP elsewhere on the disk. After you make space for Arch Linux, you can create a new ESP and other partition(s) for Arch Linux. Depending on the boot manager you use, you can simply have separate Arch and Windows ESPs; or you can move the Windows boot loader files to the new ESP and delete or re-purpose the original ESP. Note that because systemd-boot can't launch boot loaders that reside on partitions other than its own, if the reason for mounting the ESP as /boot is that you want to use systemd-boot, you'll have to move the Windows boot loader to the new ESP if you expect to launch it from systemd-boot. Also, the last time I checked (which was with Windows 7, so this may no longer be true), the Windows installer became very confused and malfunctioned if it saw two ESPs on a disk, making the installation of Windows on such a disk impossible. Thus, if you set things up with two ESPs, you could have problems down the road. Such problems can be easily overcome by temporarily changing the partition type code of the non-Windows ESP, but you must be aware of this workaround.

In sum, although I recognize that the Arch community likes to mount the ESP at /boot and use it to store Linux kernels that are (often) launched via systemd-boot, this approach creates complications and few or no significant benefits. Overall, you're probably better off using GRUB 2 or my own rEFInd, both of which will fit on your small ESP and launch kernels stored elsewhere. My EFI Boot Loaders for Linux page describes Linux boot loader and boot manager options in more detail.

Instead, open up disk management, and shrink the windows partition (your main one) by an amount (however much you'd like to use with Arch Linux). There's always usually a set limit as to how much you can shrink by, even when it seems like there's plenty of space on the disk. This "issue" is solved elsewhere so I won't explain it here. Just remember which one is which. Eg. the big one's windows, the small space is empty etc.

Don't forget to disable fast startup in windows - this is essentially hibernating your PC instead of shutting it down, in order to achieve a "fast startup." If you instead boot into Linux, you risk losing data in the windows system.

Boot into the Linux installation environment (from a USB or whatnot) and then setup that free space you made in windows, and make it into your linux system partition. Just remembering which partition is which. Eg. don't reformat the windows partition accidentally - use your partition sizes you recorded above to double check.

openSUSE-Tumbleweed-XFCE-Live-x86_64-Current.iso
when i try to install gives me this error:
_error.png
my portions look like this:
_portion.png
how can i increase uefi portion ? can i use gparted ?

It would seem from your picture that your partitions and mount points are not ok.
The /boot/efi mount point should point to the FAT32 partiton. And do not format it if it already has Windows or other operating system stuff in it!

fat32 partition must be only mounted and not formatting it! it needs the boot flag to be enabled (esp was it before but they merge boot and esp to the same) this is used by other installed systems also to keep boot entries for them (Manjaro in your case?)

to add EndeavourOS you do not need to run gparted and you do not need to remove Manjaro or any other installed system, install will add EndeavourOS to the already existing fat32 (EFI) partition, you need only need to format the root filesystem partition nvme0n1p3 and create the mountpoint for it. the fat32 (EFI) partition needs only to be mounted on the right place so not formatted, as this would remove entries for other systems inside this partition.
For this you must choose manual partition here:

c80f0f1006
Reply all
Reply to author
Forward
0 new messages