F5F Stay Refreshed Software Operating Systems Configuring bootloader for Pop! Os, Ubuntu, and Windows

Configuring bootloader for Pop! Os, Ubuntu, and Windows

Configuring bootloader for Pop! Os, Ubuntu, and Windows

B
Batt4
Member
55
03-16-2016, 09:09 PM
#1
Hi there, I seldom share updates here but recently faced a challenge that I haven’t managed to resolve and thought this would be a suitable spot to seek advice. Recently began using Pop! OS as my primary Linux distribution, which has turned out to be quite satisfactory. Previously, I used Ubuntu and I’m still trying to figure things out, but Pop! OS seems smoother. Here’s what I’m dealing with: I recently set up Pop! OS on my laptop. Before that, I was running a dual boot between Ubuntu and Windows 10 using Grub as the boot manager. When I first installed Pop!, it taught me that it switched to systemd as the boot manager instead of Grub. That made me uncertain about how Grub would function with Windows 10 or Ubuntu. So, when I added Pop! I guess it introduced another boot manager? Since I’m not very familiar with boot mechanics, I assumed it would still let me use Grub if I accessed the BIOS and selected it as the boot option (labeled as Ubuntu). But systemd doesn’t recognize Windows 10 or Ubuntu as bootable OSes. For convenience, I opted to include Pop! as an alternative in the Grub menu. However, after the first time I put Pop! to sleep (suspend), I couldn’t return to it via Grub. So I switched to booting Pop! directly through the BIOS. Right now, I’m sticking with systemd and would like to stick with it. I’m open to suggestions on why Grub might be preferred or if there’s a better way.

1. How can I add Windows boot options to my systemd configuration? It seems automatic setup didn’t work for me. I saw instructions about placing a file in /boot/efi/loader/entries. Do I really need to copy it from someone else? I’m not sure where that file is on my system. I have a screenshot of my partitions below. Am I on the right track?

2. What should I do for Ubuntu as well?

3. How can I ensure my computer wakes up with the OS after suspending, sleeping, or hibernating? I want to know what happens during boot while suspended.

4. I turned off secure boot to install Pop! Was it worth doing this? I’ve heard mixed opinions on whether secure boot is necessary. Would signing it myself be a good idea? My main concern is understanding the boot process.

5. Do the files in /boot/efi belong to my root partition? I thought they were there, but I’m not sure how to reach them during startup.

Thanks ahead of time!
-Espy
B
Batt4
03-16-2016, 09:09 PM #1

Hi there, I seldom share updates here but recently faced a challenge that I haven’t managed to resolve and thought this would be a suitable spot to seek advice. Recently began using Pop! OS as my primary Linux distribution, which has turned out to be quite satisfactory. Previously, I used Ubuntu and I’m still trying to figure things out, but Pop! OS seems smoother. Here’s what I’m dealing with: I recently set up Pop! OS on my laptop. Before that, I was running a dual boot between Ubuntu and Windows 10 using Grub as the boot manager. When I first installed Pop!, it taught me that it switched to systemd as the boot manager instead of Grub. That made me uncertain about how Grub would function with Windows 10 or Ubuntu. So, when I added Pop! I guess it introduced another boot manager? Since I’m not very familiar with boot mechanics, I assumed it would still let me use Grub if I accessed the BIOS and selected it as the boot option (labeled as Ubuntu). But systemd doesn’t recognize Windows 10 or Ubuntu as bootable OSes. For convenience, I opted to include Pop! as an alternative in the Grub menu. However, after the first time I put Pop! to sleep (suspend), I couldn’t return to it via Grub. So I switched to booting Pop! directly through the BIOS. Right now, I’m sticking with systemd and would like to stick with it. I’m open to suggestions on why Grub might be preferred or if there’s a better way.

1. How can I add Windows boot options to my systemd configuration? It seems automatic setup didn’t work for me. I saw instructions about placing a file in /boot/efi/loader/entries. Do I really need to copy it from someone else? I’m not sure where that file is on my system. I have a screenshot of my partitions below. Am I on the right track?

2. What should I do for Ubuntu as well?

3. How can I ensure my computer wakes up with the OS after suspending, sleeping, or hibernating? I want to know what happens during boot while suspended.

4. I turned off secure boot to install Pop! Was it worth doing this? I’ve heard mixed opinions on whether secure boot is necessary. Would signing it myself be a good idea? My main concern is understanding the boot process.

5. Do the files in /boot/efi belong to my root partition? I thought they were there, but I’m not sure how to reach them during startup.

Thanks ahead of time!
-Espy

O
162
03-18-2016, 10:00 AM
#2
Because systemd-boot requires manual setup, there’s no automatic setup like Grub offers. You have two Fat32 EFI volumes, but systemd-boot can only boot from configurations stored in the same partition. You must transfer Microsoft’s EFI files to your systemd EFI volume. Both partitions should be accessible inside your Linux installation. You’ll need to create a systemd-boot configuration file for Ubuntu on the same partition as systemd-boot and include the Linux kernel and image. These files must be kept current manually. An example UUID can be found with blkid: /boot/loader/entries/arch.conf.

If your system falls asleep, it will simply resume the previous session—no further action needed. If it hibernates, it will boot using the default entry. For systemd-boot, only one entry is allowed, whereas Grub can point to the last booted entry. Its main purpose was originally for OEM signature verification to block unauthorized software during startup. It’s mostly useful if malware tries to attach itself at boot, otherwise it offers little benefit.

During boot, BIOS loads only EFI partitions marked as bootable by Fat32. Your EFI images reside there. For systemd-boot, the config files and kernel must be on the same partition as systemd-boot, which supports only Fat32. With Grub, configuration files are typically on the root partition alongside the kernel. If you see entries in /boot/efi, your Fat32 volume is likely mounted there. You can verify this by checking fstab.

It seems Ubuntu detected an EFI partition and reused it, mixing its contents with Windows files. PopOS, however, probably didn’t verify the partition and assumed a fresh setup was needed, installing its files instead. In reality, systemd-boot is more suitable for standalone setups, while Grub provides better automation and compatibility for multiboot environments.
O
Oreos_In_Cream
03-18-2016, 10:00 AM #2

Because systemd-boot requires manual setup, there’s no automatic setup like Grub offers. You have two Fat32 EFI volumes, but systemd-boot can only boot from configurations stored in the same partition. You must transfer Microsoft’s EFI files to your systemd EFI volume. Both partitions should be accessible inside your Linux installation. You’ll need to create a systemd-boot configuration file for Ubuntu on the same partition as systemd-boot and include the Linux kernel and image. These files must be kept current manually. An example UUID can be found with blkid: /boot/loader/entries/arch.conf.

If your system falls asleep, it will simply resume the previous session—no further action needed. If it hibernates, it will boot using the default entry. For systemd-boot, only one entry is allowed, whereas Grub can point to the last booted entry. Its main purpose was originally for OEM signature verification to block unauthorized software during startup. It’s mostly useful if malware tries to attach itself at boot, otherwise it offers little benefit.

During boot, BIOS loads only EFI partitions marked as bootable by Fat32. Your EFI images reside there. For systemd-boot, the config files and kernel must be on the same partition as systemd-boot, which supports only Fat32. With Grub, configuration files are typically on the root partition alongside the kernel. If you see entries in /boot/efi, your Fat32 volume is likely mounted there. You can verify this by checking fstab.

It seems Ubuntu detected an EFI partition and reused it, mixing its contents with Windows files. PopOS, however, probably didn’t verify the partition and assumed a fresh setup was needed, installing its files instead. In reality, systemd-boot is more suitable for standalone setups, while Grub provides better automation and compatibility for multiboot environments.

S
Soccerdude2006
Junior Member
36
03-19-2016, 10:57 PM
#3
If you manage to copy those files, do you still require the Windows boot partition (named Microsoft Reserve Partition)? The same applies for Linux kernels. Would you need the second EFI partition (named EFI System Partition) as well? You’d have to search through that EFI partition and move the files there, then place them on the Pop!OS boot partition. You located the microsoft bootmgfw.efi but didn’t find the Ubuntu kernel.

Here’s a summary of your boot setup:
- BIOS opens the fat32 grub partition
- It loads the Ubuntu root partition for configuration
- You’re considering using Grub for hibernation
- Systemd with a delay can boot from the hibernated point
- gparted doesn’t show these partitions tagged that way
- Pop!OS installation needs a boot partition defined

Your plan seems to lean toward using Grub, as it’s the standard for modern systems. You might want to test both options and see which fits your needs. Thanks for your question and the helpful feedback!
S
Soccerdude2006
03-19-2016, 10:57 PM #3

If you manage to copy those files, do you still require the Windows boot partition (named Microsoft Reserve Partition)? The same applies for Linux kernels. Would you need the second EFI partition (named EFI System Partition) as well? You’d have to search through that EFI partition and move the files there, then place them on the Pop!OS boot partition. You located the microsoft bootmgfw.efi but didn’t find the Ubuntu kernel.

Here’s a summary of your boot setup:
- BIOS opens the fat32 grub partition
- It loads the Ubuntu root partition for configuration
- You’re considering using Grub for hibernation
- Systemd with a delay can boot from the hibernated point
- gparted doesn’t show these partitions tagged that way
- Pop!OS installation needs a boot partition defined

Your plan seems to lean toward using Grub, as it’s the standard for modern systems. You might want to test both options and see which fits your needs. Thanks for your question and the helpful feedback!

J
Jawsome12342
Junior Member
15
03-26-2016, 03:14 PM
#4
Windows anticipates its presence. You might adjust settings in the registry, though I’m uncertain about the process. For Ubuntu, the files should reside in your root partition at /boot. However, I can’t verify this for Arch-based systems. If you wait and access the hibernated machine, it should function properly. GParted lists them as "boot,esp" at "/dev/nvme0n1p1" and "/dev/nvme0n1p10" based on your earlier note. When attempting boot from GRUB to PopOS!, it likely searched the incorrect partition or had an incorrect filename. The drive and directory GRUB is trying to use must exist. You should be able to proceed, though PopOS! employs a custom setup for systemd-boot, making the transition to GRUB on that distro unclear. A search gives inconsistent results for PopOS!. GRUB typically needs the kernel and image in the root partition, usually /boot. The task seems straightforward if you back up your boot files from /boot, remove the EFI partition from fstab, unmount and delete it, then recreate everything on /boot, install GRUB, and regenerate the grub.cfg. PopOS! tends to behave differently than most distributions, which can add complexity.
J
Jawsome12342
03-26-2016, 03:14 PM #4

Windows anticipates its presence. You might adjust settings in the registry, though I’m uncertain about the process. For Ubuntu, the files should reside in your root partition at /boot. However, I can’t verify this for Arch-based systems. If you wait and access the hibernated machine, it should function properly. GParted lists them as "boot,esp" at "/dev/nvme0n1p1" and "/dev/nvme0n1p10" based on your earlier note. When attempting boot from GRUB to PopOS!, it likely searched the incorrect partition or had an incorrect filename. The drive and directory GRUB is trying to use must exist. You should be able to proceed, though PopOS! employs a custom setup for systemd-boot, making the transition to GRUB on that distro unclear. A search gives inconsistent results for PopOS!. GRUB typically needs the kernel and image in the root partition, usually /boot. The task seems straightforward if you back up your boot files from /boot, remove the EFI partition from fstab, unmount and delete it, then recreate everything on /boot, install GRUB, and regenerate the grub.cfg. PopOS! tends to behave differently than most distributions, which can add complexity.

M
MoZErTiK
Junior Member
2
03-26-2016, 05:15 PM
#5
Great! I'll try to help you today.
M
MoZErTiK
03-26-2016, 05:15 PM #5

Great! I'll try to help you today.

R
RuenixYT
Member
66
03-26-2016, 05:44 PM
#6
You seem to have resolved most issues with the systemd bootloader, though Windows functions perfectly. The missing files warning occurred only after copying the entire Microsoft directory, not just the bootmgfw.efi file. Ubuntu appears stable, but you still encounter errors during startup. Check if all required components are present and properly configured.
R
RuenixYT
03-26-2016, 05:44 PM #6

You seem to have resolved most issues with the systemd bootloader, though Windows functions perfectly. The missing files warning occurred only after copying the entire Microsoft directory, not just the bootmgfw.efi file. Ubuntu appears stable, but you still encounter errors during startup. Check if all required components are present and properly configured.

_
_digiboy
Member
196
03-28-2016, 03:48 AM
#7
The issue appears to be with systemd, not grub.
_
_digiboy
03-28-2016, 03:48 AM #7

The issue appears to be with systemd, not grub.

S
Santonite
Member
208
03-28-2016, 08:44 AM
#8
S
Santonite
03-28-2016, 08:44 AM #8