Can linux boot extended partition
A subreddit for the Arch Linux user community for support and useful news. Locked in protest at the 3rd party apps situation. Please do NOT send join requests or message the mods to join, they will be ignored and archived.
Does anyone have info about systemd-boot 242 using —esp-path and —boot-path? The [wiki] ( https://wiki.archlinux.org/index.php/Systemd-boot ) says the installation section is currently out to date and I cannot find a good guide that uses these options to make a system XBOOTLDR compatible.
After more closely reading this page
There is a different partition type that is needed for XBOOTLDR to work!
In cfdisk there is a type called «Linux Extended boot» which will have a Guid of «bc13c2ff-59e6-4262-a352-b275fd6f7172»
This partition is what should be used in —boot-path=
I’m confused as to what it should be formatted to. According to this it can be anything but the [previously mentioned page] ( https://systemd.io/BOOT_LOADER_SPECIFICATION/ ) says:
For systems where the firmware is able to read file systems directly, $BOOT must be a file system readable by the firmware. For other systems and generic installation and live media, $BOOT must be a VFAT (16 or 32) file system. Applications accessing $BOOT should hence not assume that fancier file system features such as symlinks, hardlinks, access control or case sensitivity are supported.
So formatting to fat32 seems to be the safest bet
This method seems to achieve my goal of having the linux kernel somewhere else in case of windows updates because all that is put onto /efi is the systemd.efi which can be easily recovered with a live disk (not the most ideal but better then having to reinstall linux all together)
So the Systemd-boot page should have something along the lines of:
**Using XBOOTLDR:** create a separate partition of atleast 250Mib labeled «Linux extended boot» (guid of bc13c2ff-59e6-4262-a352-b275fd6f7172) now referred to as $BOOT Format boot to fat32 mkfs.vfat -F 32 $BOOT mount the ESP to /mnt/efi and the $BOOT to /mnt/boot install with pacstrap per usual in chroot use the command: (not sure it is needed as bootctl looks for this by default but good to specify) bootctl —esp-path=/efi —boot-path=/boot install edit /efi/loader/loader.conf to say: «default arch timeout 3» edit /boot/loader/entries/arch.conf to: «title Arch_Linux_extendedboot linux /vmlinuz-linux initrd /initramfs-linux.img initrd /initramfs-linux-fallback.img options root=/dev/sdX» reboot and enjoy
Obviously a rough draft of what should be in the wiki but the fundementals of what to do are there.
I am looking into doing a new Arch Linux install.
Since I am a glutton for making things overly complicated I want mount my ESP to something other then /boot (/efi) and use systemd-boot
While also dual booting Windows 10
My goal really is to try and separate linux from windows so in the event of a windows update, windows will not wipe out my linux ESP info, While also using systemd-boot (I most likely would need to switch to grub or refind to make this possible but I’m still giving it a shot)
From my understanding systemd-boot can only read the partition it is installed on
So if /boot is not used you need to move your linux kernel from /boot to where ever systemd-boot is installed (/efi)
While looking at the wiki for [systemd-boot] ( https://wiki.archlinux.org/index.php/Systemd-boot ) I notice that it says the installation process is out of date.
It refers that since systemd 242 there are new —esp-path and —boot-path options This is supposed to make bootctl compatible with XBOOTLDR
So in a VM I have 5 partitions
sda1-4 — [Standard Windows Partitions] ( https://wiki.archlinux.org/index.php/Dual_boot_with_Windows#UEFI_systems )
sda5 — linux file system formated to ext4 (/)
I mount /dev/sda5 to /mnt then mkdir /mnt/efi (I also mkdir /mnt/boot not sure how necessary this is) and mount /dev/sda2 /mnt/efi
pacstrap /mnt base linux linux-firmware fstab genfstab /mnt > /mnt/etc/fstab
So now comes the confusion:
In the wiki it seems like I would just adjust my bootctl command to something like:
bootctl —esp-path=/efi —boot-path=/boot install
but when I do this I get an error:
«directory «/boot» is not the root of the file system»
bootctl —esp-path=/efi —boot-path=/ install
Looking at the man page for bootctl it states:
path to the extended boot loader partition as defined in the boot loader specification if not specified,
/boot/ is checked. it is recommended to mount the extended boot loader partition to /boot/, if possible
So I am not quite sure why I get this error if it defaults to /boot anyways
If I get rid of the the —boot-path option it installs systemd boot to /efi fine
So now I would go though and make the entries required for systemd-boot
/efi/loaders/loader.conf is edited to add:
and /efi/loaders/entries/arch.conf is created with the contents being:
title Arch_Linux linux /vmlinuz-linux initrd /initramfs-linux.img initrd /initramfs-linux-fallback.img options root=/dev/sda6
these entries seem wrong because it assumes /boot is the esp and the kernel is kept in the root of said /boot
Doing an ls of /efi gives me 3 folders
A large string of numbers and chars (not quite sure what this is, its empty), EFI (which contains the efis for windows, a systemd and linux folder) and the previously mentioned loader folder
so my loaders entry should look more like:
title Arch_Linux linux /EFI/Linux/vmlinuz-linux initrd /EFI/Linux/initramfs-linux.img initrd /EFI/Linux/initramfs-linux-fallback.img options root=/dev/sda6
I should then just need to copy data from /boot to this /efi/EFI/Linux directory
I will need to either make a pacman hook to copy these or do a bind mount to keep the kernel up to date But this method seems to make a bootable Linux system with the ablity to select windows as well
So my Questions are:
- Following this method am I XBOOTLDR compatible?
- Am I doing anything «wrong» by doing the process listed?
- Is the processes listed more or less what should go into the systemd-boot wiki page? if not does anyone have a write up of using systemd-boot with XBOOTLDR compatibility?
- Why does —boot-path=/boot give me an error?
- My goal really is to try and separate linux from windows so in the event of a windows update, windows will not wipe out my linux ESP info. This seems impossible with systemd-boot. So is there really any point to mounting esp to /efi instead of /boot (excluding updates will automatically update the ESP’s kernels)
Reading the technical details on this page
Seems to answer 1 as no but is not really written in a way with windows in mind
Closer reading of this may be needed on my part
Что такое extended partition? И как мне вернуть место?
День добрый. Поставил дебиан, и не пойму что у меня с /home происходит.
Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 28186623 28184576 13.5G 83 Linux /dev/sda2 28188670 234440703 206252034 98.4G 5 Extended /dev/sda5 28188672 234440703 206252032 98.4G 83 Linux
/home всего 10 гигов, когда как должно быть 100. Никто не знает что происходит и как /home сделать 100 гигов вместо 10?
Extended раздел — это раздел для других разделов, так как из-за ограничений mbr может быть только 4 primary partitions.
mount | grep /home df -h /home parted -l
Extended Это виртуальный костыль для обхода ограничения в четыре раздела досовой разметки. Те на самом деле у тебя:
/dev/sda1 * 2048 28186623 28184576 13.5G 83 Linux /dev/sda5 28188672 234440703 206252032 98.4G 83 Linux
user@debian:~$ mount | grep /home /dev/sda5 on /home type ext4 (rw,relatime,data=ordered) user@debian:~$ df -h /home Filesystem Size Used Avail Use% Mounted on /dev/sda5 97G 2.5G 90G 3% /home user@debian:~$ sudo parted -l Model: ATA KINGSTON SHFS37A (scsi) Disk /dev/sda: 120GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 14.4GB 14.4GB primary ext4 boot 2 14.4GB 120GB 106GB extended 5 14.4GB 120GB 106GB logical ext4
У меня файловый менеджер сказал что у меня 10 гигов моих кончается. Это он проглючил получается?
Filesystem Size Used Avail Use% Mounted on
/dev/sda5 97G 2.5G 90G 3% /home
Порядок, хомяк на 97 гигов.
Вы это в каком месте прочитали?
creating extended partition
this is my current hard disk status(Running linux Mint LIVE CD) i have-
- Ubuntu 12.04 on 206 GB partition at dev/sda1.
- dev/sda2 system reserved.
- Windows 7 on 90GB partition at dev/sda3
- and linux swap in extended partition.
what i want to do— I want to install Linux mint KDE on my system for that i want to create a new partition of 30GB(by shrinking the free space available at dev/sda1), i can’t create that because i can create only 4 Primary partitions which are already there. so do i have to delete the Swap partition? and if i did how to force Mint KDE and Ubuntu 12.04 to use/share same swap space in new logical partition?
2 Answers 2
There are a number of possible solutions, but the one I recommend is as follows:
- Back up all your important data. Partition moving and resizing operations are inherently dangerous, so things occasionally go wrong when performing steps like the following. Having a backup ensures you won’t lose irreplaceable data.
- Boot a Linux emergency disc, such as Parted Magic or the Ubuntu installer in its «try before installing» mode.
- Launch GParted.
- Using GParted, shrink /dev/sda1.
- Using GParted, delete both swap (/dev/sda5) and the extended partition that holds it (presumably /dev/sda4).
- Optionally, using GParted, expand /dev/sda3 into the space freed by the previous step. Alternatively, you can just leave blank space there.
- Create a new extended partition in the blank space left by step #4.
- Create a new swap partition inside the extended partition.
- Create new partition(s) for Linux Mint inside the extended partition. Alternatively, you could leave this to the Mint installer.
The result will be a legal, if somewhat odd, partition table. One drawback is that this procedure leaves your Windows installation the same size as or bigger than it is now. If you wanted to use some of the Windows space for Mint, you’d need to shrink and move the partition, which is the riskiest type of partitioning operation. It’s also likely to leave Windows unbootable until repaired. Overall, it’s best to avoid this if possible — and given your stated goals, it seems to be possible to avoid it.
In theory, both Ubuntu and Windows should remain bootable after this procedure; however, it’s conceivable that one or both OSes might be rendered unbootable. If so, you’ll need to repair bootability with an emergency system. The details of how to do this depend on the details of the problem, so I won’t address those details here; I just want you to be aware that there’s a small but real risk of this happening, and that the problem can be overcome if you encounter it.