Where is /boot in the partition list of 2021.08.27?

I can’t select /boot as separate partition: there is no list eintry.
2nd problem: calamares does not accept /boot/efi which is located on my Windows disk (nvme0n1p2)
while all Linux partitions are on nvme1n1p…
This was no problem with EndeavourOS April release.

A bit short of info on which to base any comments. Is this saying you cannot select partitions in manual mode? Were you expecting a separate /boot partition that you had not pre-created yourself? What file system was being targeted? Also - a listing of the existing partitions would be of assistance…

BTW - there are few reasons today to break out the /boot partition on its own - could you let us know what your end goal with this requirement might be? Is your ‘main’ filesystem not readable at boot time with ease?

Help will probably become available, but not without some more to work with!

ok, here is my disk layout:
SDD1 (Windows) is:
nvme0n1 259:0 0 931,5G 0 disk
├─nvme0n1p1 259:1 0 529M 0 part (ntfs)
├─nvme0n1p2 259:2 0 100M 0 part /boot/efi (fat32)
├─nvme0n1p3 259:3 0 16M 0 part (Microsoft reserved partition)
└─nvme0n1p4 259:5 0 930,9G 0 part (ntfs)

SDD2 is Linux:
nvme1n1 259:4 0 931,5G 0 disk
├─nvme1n1p1 259:6 0 952,7M 0 part /boot (ext4)
├─nvme1n1p2 259:7 0 4,7G 0 part [SWAP]
├─nvme1n1p3 259:8 0 92,6G 0 part / (xfs)
└─nvme1n1p4 259:9 0 833,3G 0 part /data (xfs)
SDD2 is currently installed with ZorinOS 16, but is planned to be
replaced with EndeavourOS.
nvme1n1p1 is currently the boot partition because the root partition (/) is
formatted with xfs (not ext4!) as well as the reserved /data (also xfs) which is currently
not used.
With EndeavourOS 21.04.17 this problem does NOT exist.

Maybe I am missing something but EndeavourOS doesn’t require a separate /boot. In a UEFI system running grub, /boot is just the place where the kernels and initramfs images are stored. It isn’t a requirement that it is ext4.

Unless you are legacy booting Linux for some reason. If that is the case, make sure you legacy boot the ISO as well. I don’t really recommend this though.

Do you have esp,boot flag set on it?
Launch Gparted and check.

1 Like

I can only assume that the separate /boot partition is to enable easier access to the ‘non-standard’ filesystem prior to booting. This should not be a problem, if the installer is told about it using the manual option. In this case I would make sure that all partitions you intend are setup already by use of gparted before you start the installer.

The UEFI partition is kinda small, but should still be 'edit’ed in the installer to be given a mount point of /boot/efi. This should also leave it with the ‘boot’ flag selected.

The XFS partitions need to be given mount points too, and you choose which are to be formatted. My suspicion is that you will keep the data one as is, and format the one for / to have EndeavourOS installed on it.

This should work - but if you have difficulties, you casn make a separate partition on the second drive for UEFI, and designate THAT one as mount point /boot/efi. All else should be the same.

If any of this isn’t clear - check first! :grin:

You can use sudo parted -l your boot partition should look like the below image.

image

need to have boot and esp flags on the boot partition for Calaramries to detect it.

here is the report by sudo parted -l
Model: Samsung SSD 970 EVO Plus 1TB (nvme)
Disk /dev/nvme0n1: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 556MB 555MB ntfs Basic data partition hidden, diag
2 556MB 661MB 105MB fat32 EFI System Partition boot, esp
3 661MB 677MB 16,8MB Microsoft reserved partition msftres
4 677MB 1000GB 1000GB ntfs Basic data partition msftdata

Model: Samsung SSD 970 EVO Plus 1TB (nvme)
Disk /dev/nvme1n1: 1000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number Start End Size File system Name Flags
1 1049kB 1000MB 999MB ext4
2 1000MB 6000MB 5000MB linux-swap(v1) swap
3 6000MB 105GB 99,4GB xfs
4 105GB 1000GB 895GB xfs

boot flags are set for the EFI partition
and I repeat: this is not an issue with the April release of EndeavourOS

I know but EndeavourOS also doesn’t require swap or a separate home partition.
Why not mash up all in a huge root partition?
I’m an old school Linuxer (and SGI Admin before) and I have valid reasons for my layout.
I do not want to be forced by the OS or the developers.

With grub, having /boot inside the root makes recovery a lot easier. If you restore, / without also restoring /boot your kernel modules will be out of alignment with your kernels.

Me too. I have used most of the mainstream *nix OSes that have existed. sunos, solaris, hp-ux, aix, irix, digital unix, sco, etc, etc. That being said, I don’t know how that is relevant to the conversation :wink:

You aren’t, you can always use manual partitioning and set it up however you want.

EDIT: You realize you can type in the mountpoint box, correct?

EDIT 2: If you are using manual partitioning, calamares doesn’t need to detect your ESP, you tell it where it is.

3 Likes

@EDIT2:
I did that but calamares (2021.08.27) doesn’t accept it as a valid EFI partition.
calamares (2021.04.17) doesn’t have this problem.
conclusion: I will install EndeavourOS 2021.04.17 and ignore the 08.27 release
I consider this behaviour as a bug of the new calamares 2021.08.27

I you trying to say it won’t accept the efi partition that Windows already has? You have to select that from the proper drive and then edit but keep what is there and don’t format it. This is standard if you use manual partitioning and your partitions already exist on the disc. You go through the manual partitiong stage and use edit and select and set the flags and i just keep and don’t format on the efi for Windows. Should be no problem.

here are 2 Screenshots that show the problem:
#1 editing the EFI partition (keeping the data) and then clicking ok

Screenshot_2021-09-01_20-51-20

#2 the error messaging after clicking “next” in Calamares

Screenshot_2021-09-01_20-52-38

Did you try giving that boot partition around 550 MB of space instead of 100 MB?

2 Likes

no I did not grow this partition for several reasons:
#1 ist was created by the Win10 installer therefore I will keep my hands off it.
#2 the partition is accepted by release EOS4.17, I see no reason to change this.
#3 no other distro has problems with this efi partition (Ubuntu, Mint, Zorin, Fedora …)

Regardless of its ‘acceptance’ by other setups, it is too small really. I can understand not growing it (especially reason #1) - but is there anything stopping you from creating a separate EFI on the other drive for all non-MS use? You know, about 500 in size - and trouble-free :grin:

I have no idea what changed between releases - but perhaps the size checking is improved in some way - or more than 1 kernel being chosen may have tipped it over the top (did you opt for the LTS in addition, perhaps?).

Well - your machine, your choice of course…

1 Like

Yes but if you install it it’s still going to work as far as I remember as long as you have edited it in the install and set the flags in the manual section. I see this only as a a warning message. I may try it on my system later. I usually don’t use the efi partition from windows normally. I’m not concerned about using another little bit of space.

1 Like

Grub doesn’t keep the kernels in the ESP so it shouldn’t matter how many kernels you have.

I’ve found a solution:
I reused my former /boot partition (900MB) as new ESP partition. Now the problem was I could not boot Win10 from Grub.
I added GRUB_DISABLE_OS_PROBER=false to /etc/default/grub and ran sudo update-grub
At the next reboot the windows entry was available in the grub menu.
/boot is now just a directory inside /
btw: I think the name of the variable is somehow confusing (-1 * -1 = 1)
GRUB_ENABLE_OS_PROBER=true:false would be less obfuscating.

I vaguely remember that I ran into this issue when I was testing Manjaro in a VM. The cause was the use of a /boot partition around 150 MB or less. Then I increased it to 550 MB which corrected the issue.

Seems it’s the size. And they say size doesn’t matter. :wink: :rofl:

1 Like