On Dual Booting Installation, I had Windows 10 Pro preinstalled.
Windows Disk Management program shows EFI boot partition then Windows BitLocker encrypted partition. (Machine is UEFI bootable, Legacy mode not available. (AMD processor))
I used Windows disk management to shrink the Windows partition and left available space unformatted free space.
Used Fedora 34 Live USB and Anaconda installer. The Blivet GUI disk format discovered EFI partition, then tiny 16MB unidentified partition, then the ntfs and finally the unformatted free space. (1TB size ssd)
Setting the EFI partition from windows to /boot/efi mount point and free space to btrfs and / mount point succeeded in installation.
BUT I want to encrypt my btrfs partition. Since /boot is on btrfs, it cannot be encrypted, according to anaconda error checking.
How can I dual boot with windows AND have encrypted btrfs?
is /boot designation necessary on EFI / UEFI booting?
I have not looked, but presume MBR is NOT present at all, since Legacy mode is not available on this BIOS.
IF it matters, hardware is Lenovo L15 AMD and Ryzen 7 graphics, 1 TB ssd, 64 GB RAM
{No swap partition created, swap space details left at discretion of anaconda installer.}
I’m sure there is more than one way to do it. To keep the number of partitions to be managed to a minimum, my personal preference would be to mount the ESP partition to /boot so that the kernel and initramfs would be copied to that partition on installation/upgrade. Unfortunately, grub does not work with that layout (it wants to put a special “symlink” file under /boot, but because the ESP (and therefore /boot) has to be formatted with a FAT file system, symlinks do not work. If you are willing to switch to another bootloader (i.e. systemd-boot), it can be done. I haven’t done a dual-boot with MS Windows configuration with systemd-boot, but it looks like systemd-boot does support that:
systemd-boot will automatically check at boot time for Windows Boot Manager at the location /EFI/Microsoft/Boot/Bootmgfw.efi, UEFI shell /shellx64.efi and EFI Default Loader /EFI/BOOT/bootx64.efi, as well as specially prepared kernel files found in /EFI/Linux/. When detected, corresponding entries with titles auto-windows, auto-efi-shell and auto-efi-default, respectively, will be generated. These entries do not require manual loader configuration. However, it does not auto-detect other EFI applications (unlike rEFInd), so for booting the Linux kernel, manual configuration entries must be created.
You would need to be sure that the ESP is sufficiently large for the bootloaders and the kernels and initramfses, but other than that, it shouldn’t be too difficult to create such a layout. It would have to be done by hand though. Here is a video that I made a while back demonstrating a systemd-boot with Fedora Linux installation that might give you some ideas about how to create such a system:
P.S. I have no experience with LUKS encryption. But it appears that it simply requires passing a few extra parameters to the kernel/dracut, so I think it should work fine with systemd-boot.
P.P.S. In the video demo above, I deleted all the contents of the ESP before installing the systemd-boot boot loader. You wouldn’t want to do that if your ESP contains your MS Windows boot loader .
Hello,
I fixed it another way, I read the installation instructions and followed them… /boot was placed on its own partition formatted ext4. Now encryption of btrfs and swap is allowed, and most conveniently Windows does NOT ask for bitlocker key everytime I reentered windows after using fedora…
Placing /boot within btrfs is strongly discouraged in fedora wiki on booting procedures…
In modern UEFI scenario /boot partition does NOT need to be within the first few cylinders of the system “disk.” (BTW, with SSD’s does “cylinders” and “heads” have any actual meaning anymore??)
CHS terminology is meaningless on HDDs as well. LBA does the translation to physical location and CHS terminology is a carry over from when drives were tiny.
Oh, my AT&T PC7300 had a HUGE hard drive, 10 MEGA BYTES. I couldn’t imagine ever filling that up. So from not trying something new I left Anaconda on “Simple” partitions instead of LVM. And GRUB seems to work fine.
I am interjecting here to discuss an issue with Fedora 34 and the specific way @glb installs systemd-boot in the YouTube video. It no longer works, I have tried several times to no avail. I went as far as to use old .iso of Fedora 32/33 which do work !
Fedora 34 fails on : > SYSTEMD_RELAX_XBOOTLDR_CHECKS=1 bootctl install --boot-path=/boot --esp-path=/boot
It does not create the directory tree of /boot/$(</etc/machine-id)/$(uname -r) which then causes > kernel-install add $(uname -r) /usr/lib/modules/$(uname -r)/vmlinuz to simply fail as well leaving you with an unbootable system.
Here is an example output of the failed build:
> SYSTEMD_RELAX_XBOOTLDR_CHECKS=1 bootctl install --boot-path=/boot --esp-path=/boot
Created "/boot/EFI".
Created "/boot/EFI/systemd".
Created "/boot/EFI/BOOT".
Created "/boot/loader".
Created "/boot/loader/entries".
Created "/boot/EFI/Linux".
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/EFI/systemd/systemd-bootx64.efi".
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/EFI/BOOT/BOOTX64.EFI".
Random seed file /boot/loader/random-seed successfully written (512 bytes).
Not installing system token, since we are running in a virtualized environment.
Created EFI boot entry "Linux Boot Manager".
Here is an example of a successful build from Fedora 33:
> SYSTEMD_RELAX_XBOOTLDR_CHECKS=1 bootctl install --boot-path=/boot --esp-path=/boot
Created "/boot/EFI".
Created "/boot/EFI/systemd".
Created "/boot/EFI/BOOT".
Created "/boot/loader".
Created "/boot/loader/entries".
Created "/boot/EFI/Linux".
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/EFI/systemd/systemd-bootx64.efi".
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/EFI/BOOT/BOOTX64.EFI".
Created "/boot/155f22cce02a4c3db7d2716c88f34b52".
Random seed file /boot/loader/random-seed successfully written (512 bytes).
Not installing system token, since we are running in a virtualized environment.
Created EFI boot entry "Linux Boot Manager".
Thanks for the heads up. @hamrheadcorvette. I actually haven’t tried a fresh install recently (though I have done several upgrades without issue).
Just going by the description of the problem you provided, I think running the following command before running kernel-install should workaround the problem.
I have had no issues with mounting the efi partition at /boot/efi. Mounting it at /boot is what seems problematic since with F34 it now looks for the grub.cfg file at /boot/grub2 and that is actually a symlink to /boot/efi/EFI/fedora/grub.cfg.
By mounting the efi partition at /boot/efi the symlink located in /boot/grub2 is still in the linux ext4 file system so it works.
I watched his you tube and I see that he did not select “efi system partition” but instead selected “vfat”. That is the correct formatting but not the correct flags to make it bootable.
It drove me mad ! Install after install and I had no idea why it failed. Last night I did successfully complete it by including :
mkdir -pv /boot/$(</etc/machine-id)/$(uname -r)
so that the /boot has the nested machine-id and the child directory with the kernel nomenclature.
Here is the sample output prior to kernel-install :
> SYSTEMD_RELAX_XBOOTLDR_CHECKS=1 bootctl install --boot-path=/boot --esp-path=/boot
Created "/boot/EFI".
Created "/boot/EFI/systemd".
Created "/boot/EFI/BOOT".
Created "/boot/loader".
Created "/boot/loader/entries".
Created "/boot/EFI/Linux".
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/EFI/systemd/systemd-bootx64.efi".
Copied "/usr/lib/systemd/boot/efi/systemd-bootx64.efi" to "/boot/EFI/BOOT/BOOTX64.EFI".
Random seed file /boot/loader/random-seed successfully written (512 bytes).
Not installing system token, since we are running in a virtualized environment.
Created EFI boot entry "Linux Boot Manager".
> mkdir -pv /boot/$(</etc/machine-id)/$(uname -r)
mkdir: created directory '/boot/2b6e9131fb574e4babaf1f5d732a71fc'
mkdir: created directory '/boot/2b6e9131fb574e4babaf1f5d732a71fc/5.11.12-300.fc34.x86_64'
> tree /boot
/boot
├── 2b6e9131fb574e4babaf1f5d732a71fc
│ └── 5.11.12-300.fc34.x86_64
├── EFI
│ ├── BOOT
│ │ └── BOOTX64.EFI
│ ├── Linux
│ └── systemd
│ └── systemd-bootx64.efi
└── loader
├── entries
├── loader.conf
└── random-seed
After sucessfully installing, I decided to try with an encrypted /root & /home using the same steps you have provided. It Also Works ! The system boot very fast and everything is nice and clean after a dnf update both kernels (install and updated) are present. here is a output of that:
In his video, He’s removing grub altogether, and only using systemd-boot. The partition needs to be vfat for the EFI to recognize it. He uses sgdisk to flag /dev/sda with ef00 and /dev/sdb with 8304 .
Here is a sample of what is happening :
sudo chroot /mnt/sysroot /bin/bash --login
PS1="> "
>sgdisk -p /dev/vda
Disk /dev/vda: 251658240 sectors, 120.0 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 30FE0ACA-AC89-4134-BD42-F8C604D0BF75
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 251658206
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 2099199 1024.0 MiB 0700
2 2099200 85989375 40.0 GiB 8300
3 85989376 251656191 79.0 GiB 8300
> sgdisk -t 1:ef00 /dev/vda
The operation has completed successfully.
> sgdisk -t 2:8304 /dev/vda
The operation has completed successfully.
> partprobe
Warning: Unable to open /dev/sr0 read-write (Read-only file system). /dev/sr0 has been opened read-only.
> sgdisk -p /dev/vda
Disk /dev/vda: 251658240 sectors, 120.0 GiB
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 82231F50-32B2-42B6-809F-1433FCBA6313
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 251658206
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 2099199 1024.0 MiB EF00
2 2099200 85985279 40.0 GiB 8304
3 85985280 251656191 79.0 GiB 8300
> rm -rfv /etc/dnf/protected.d/grub*
removed '/etc/dnf/protected.d/grub2-efi-ia32.conf'
removed '/etc/dnf/protected.d/grub2-efi-x64.conf'
removed '/etc/dnf/protected.d/grub2-pc.conf'
removed '/etc/dnf/protected.d/grub2-tools-minimal.conf'
> rpm -v --nodeps --erase $(rpm -qa | grep "^grub2-\|^os-prober-\|^grubby-")
Preparing packages...
grub2-pc-1:2.06~rc1-3.fc34.x86_64
warning: file /etc/dnf/protected.d/grub2-pc.conf: remove failed: No such file or directory
grub2-efi-x64-1:2.06~rc1-3.fc34.x86_64
warning: file /etc/dnf/protected.d/grub2-efi-x64.conf: remove failed: No such file or directory
warning: /boot/grub2/grubenv saved as /boot/grub2/grubenv.rpmsave
grub2-efi-ia32-1:2.06~rc1-3.fc34.x86_64
warning: file /etc/dnf/protected.d/grub2-efi-ia32.conf: remove failed: No such file or directory
grub2-tools-extra-1:2.06~rc1-3.fc34.x86_64
grub2-tools-efi-1:2.06~rc1-3.fc34.x86_64
grubby-8.40-51.fc34.x86_64
grub2-pc-modules-1:2.06~rc1-3.fc34.noarch
grub2-efi-x64-cdboot-1:2.06~rc1-3.fc34.x86_64
grub2-efi-ia32-cdboot-1:2.06~rc1-3.fc34.x86_64
grub2-tools-1:2.06~rc1-3.fc34.x86_64
os-prober-1.77-7.fc34.x86_64
grub2-tools-minimal-1:2.06~rc1-3.fc34.x86_64
warning: file /etc/dnf/protected.d/grub2-tools-minimal.conf: remove failed: No such file or directory
grub2-common-1:2.06~rc1-3.fc34.noarch
Running in chroot, ignoring command 'daemon-reload'
Running in chroot, ignoring command 'reload-or-restart'
> echo "exclude=grub2-*,os-prober,grubby" >> /etc/dnf/dnf.conf
grub and all of it’s components are excluded then removed :
I’m glad to hear that you got it working the way you want.
Like I said earlier, I haven’t tried using this procedure on a fresh install of Fedora Linux 34, but I don’t think the /$(uname -r) part should be necessary. The kernel-install script should create that part (though pre-creating it is also probably harmless).
I’ve been using this layout personally on about a dozen machines for a few years without any issue. The main reason I use it is because I also use a ZFS root so I can rollback in case of errors (I was doing this before Fedora Linux switched to Btrfs). And I like to have the minimal number of partitions (boot and root) AND all of the features enabled on the ZFS pool/partition (grub doesn’t/cannot support that).
I do want to clarify that, although I’ve had no problems with this configuration to date, it is not a configuration that Fedora Linux officially supports. This means that things may change and things may break and you are pretty much on your own to figure out how to fix it if/when they do. The way that the kernel-install script changed so that it no longer pre-creates that machine-id directory is a perfect example of the kind of problem that you should not be surprised to see. That said, as long as you are comfortable trying to work around those kind of problems if they come up, there is nothing that says you cannot do things your own way. In fact, just the opposite is sort of the motto of Fedora Linux.
To date, I’ve had no problems upgrading from one release to the next.
Edit: I take that back. I had almost forgotten about it, but I did encounter a minor glitch going from F28 to F29. I even found my bug report about the problem:
Actually, I use dnf update --releasever=34. That does an “online” upgrade. It should only be done from runlevel 3. And you should run rpmconf -a right after updating the packages to reconcile configuration file changes. And you must reboot promptly after completing the upgrade to have a stable system.
TIP: Add the line MERGE=vimdiff to /etc/environment so that rpmconf will use vimdiff when you press the m key. Vimdiff provides a nice interactive means of merging configuration files. The current and new config files will be displayed side-by-side with differing lines highlighted. Use ]c to jump forward to the next change or [c to jump to the previous change. Use do (diff obtain) to “pull” a changed line from the new config file over to the current config file or just edit the line in the current config file to be what you want it to be.
Also, groups of lines that are identical will be “folded”. Use zo to open a fold or zc to close a fold (]z and [z jumps between folds in the same way that ]c and [c jumps between changes).
.
The system boot very fast and everything is nice and clean after a dnf update both kernels (install and updated) are present. here is a output of that:
