Dual Boot went south (no more eOS 😭)

[linuxislife]

I thought about it but didn’t even bother looking because it made so much sense to do it in that order (gives you an idea of my logic)

@dalto

mounting the Linux EFI partition and not the Windows one.

euhhhh… it was my understanding they were sharing the same one, or did messed that up too ?

[dalto]

Compare the output of lsblk -f to your /etc/fstab.

The correct partition should be: 3E8F-28DC

[linuxislife]

yes that I didn’t mess up.

[linuxislife]

@dalto

Try re-running it.

Ok, so that definitely gave me a bootable system, I’m in. (Cheeeeeeeeersss :-D) (and thanks so much as usual…)

So i’ll do the long story a little later, but there was obviously a problem with windows bootloader.

As well, when I messed up the order on recreating the initframs after I went rogue deleting the content of /efi, it created those images in /boot (which is on my encryted / partition),

$ ls /boot
initramfs-6.12.15-1-lts.img  initramfs-6.13.3-arch1-1.img  intel-ucode.img

Once back in, I renamed those, relaunched bootctl install and then (!) reinstall-kernels, and didn’t recreate those files.
So, is this /bootdirectory supposed to be there, and what about intel-ucode.img?

Regarding the boot menu… well there isn’t one anymore… obviously I f%ck*d up the windows one, but shouldn’t I have the choices with regular kernal, lts, and the fallbacks ? (and firmware and uefi shell, or smthg)

I’ll see in the wiki, but if you have an idea…

[dalto]

@linuxislife

So, is this /bootdirectory supposed to be there, and what about intel-ucode.img?

Yes, that should be there. The package installs it there.

@linuxislife

Regarding the boot menu… well there isn’t one anymore

Check in /efi/loader/loader.conf and ensure timeout isn’t set to 0.

[linuxislife]

bootctl

$ sudo !!
sudo bootctl
[sudo] Mot de passe de jmb : 
System:
      Firmware: UEFI 2.60 (American Megatrends 5.12)
 Firmware Arch: x64
   Secure Boot: disabled
               ✓ Boot loader set partition information
    Partition: /dev/disk/by-partuuid/102bf430-dbb6-4f07-9ec9-4c46b3b6f51f
       Loader: └─/EFI/BOOT/BOOTX64.EFI
Current Entry: 83b590f185f2405ca239032d249de10c-6.12.15-1-lts.conf

Random Seed:
 System Token: set
       Exists: yes

Available Boot Loaders on ESP:
          ESP: /efi (/dev/disk/by-partuuid/102bf430-dbb6-4f07-9ec9-4c46b3b6f51f)
         File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 257.3-1-arch)
               └─/EFI/BOOT/BOOTX64.EFI (systemd-boot 257.3-1-arch)

Boot Loaders Listed in EFI Variables:
        Title: UEFI OS
           ID: 0x0010
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/102bf430-dbb6-4f07-9ec9-4c46b3b6f51f
         File: └─/EFI/BOOT/BOOTX64.EFI

        Title: Linux Boot Manager
           ID: 0x0000
       Status: active, boot-order
    Partition: /dev/disk/by-partuuid/102bf430-dbb6-4f07-9ec9-4c46b3b6f51f
         File: └─/EFI/SYSTEMD/SYSTEMD-BOOTX64.EFI

Boot Loader Entries:
        $BOOT: /efi (/dev/disk/by-partuuid/102bf430-dbb6-4f07-9ec9-4c46b3b6f51f)
        token: endeavouros

Default Boot Loader Entry:
         type: Boot Loader Specification Type #1 (.conf)
        title: EndeavourOS (6.12.15-1-lts)
           id: 83b590f185f2405ca239032d249de10c-6.12.15-1-lts.conf
       source: /efi//loader/entries/83b590f185f2405ca239032d249de10c-6.12.15-1-lts.conf (on the EFI System Partition)
     sort-key: endeavouros-6.12.15-1-lts
      version: 6.12.15-1-lts
   machine-id: 83b590f185f2405ca239032d249de10c
        linux: /efi//83b590f185f2405ca239032d249de10c/6.12.15-1-lts/linux
       initrd: /efi//83b590f185f2405ca239032d249de10c/6.12.15-1-lts/initrd
      options: sysrq_always_enabled mitigations=off nvme_load=YES nowatchdog rw rootflags=subvol=/@ rd.luks.uuid=ca4c4be1-37fe-468a-9061-520dee85a95a root=/dev/mapper/luks-ca4c4be1-37fe-468a-9061-520dee85a95a systemd.machine_id=83b590f>
~

$ sudo !!
sudo cat /efi/loader/loader.conf
#timeout 3
#console-mode keep

[dalto]

Uncomment the timeout line and see if it shows the menu after that.

[linuxislife]

I didn’t even see it was commented… sorry
and yeah, of course, the previous .conf file I did erase…

[linuxislife]

so yeah, it is indeed working as expected…
…and now I remember that I did tweak couple of thing in this .conf file when I set up that system… and realize it was really dumb to just delete it instead of saving it… ahahah

[linuxislife]

So… for the record, and @jputnam, I’m going to try and “retrace” the steps that got us there and how we got out (well, in actually :p).

First of all, thanks so much for your help guys (especially @dalto, as usual, I’ve no idea how he puts up with it)

This is a very long post full of many useless words drowning out the few informative parts…
Jump to the TD;LR part at the end if you’re still in your right mind (and intend to keep it that way).

context of the installed system

System is dual booting eOS and Windows 10 (…you already know it’s gonna be a sad story), eOS was installed after W10, with the “regular” installer (was Neo version I think), btrfs, encryption, systemd-boot and dracut, like all this “default” i.e. letting the installer do its magic, I just chose the W10 efi partition (that I previously tweaked increasing its size) and installer did the rest. (Well… as far as I remember, it was some months back, was my first time installing w/ dracut systemd-boot (and kde) and not manually partitioning or anything (except the efi size part))
It is not my main machine at all, but anyway, everything was working like a charm and as expected, the dual booting part included, and any time someone has had to do anything on eOS and/or W10 with this install, it has never disappointed.

Having to boot W10 to grab a document there, I decided to run an update from it, as it had a long time since anything happened to it (and boy was it better this way…).
And… for an obscure reason (is there any other with micro$oft?) when the system restarted to allow W10 to fulfill its shady “update”, the boot loader was broken, like systemd-boot menu was nonexistent and a blue windows death screen that I didn’t bother to read (well…) appeared to my pleasure.
After manhandling the machine a couple of times, throwing it on the ground and jumping on it while vocally expressing my gratitude to Mr Gates and its team, I rebooted to (surprisingly) the exact same screen.

I then had the wonderful idea to go check in the bios if some boot order was messed up, eOS wasn’t there anymore, I tweaked the UEFI mode to UEFI+legacy (is it when it got really bad?), rebooted, same same, tweaked back, threw it harder on the wall, spilled a big full pot of boiling water on it, restarted, same same (well, except some sparks that weren’t there before maybe).

So, following another rich idea, I let myself being tricked into the “proposition” M$ offered on its nice blue screen and ended up pressing the button “REPAIR MY SYSTEM”.
In my defense, I do a lot of experimental drugs.

Well, Micro$oft didn’t disappoint, it did repair, well, not MY, but at least HIS system.

And yes, it’s really only after willing-fully helping W10 to screw this as far as it possibly could, that I decided to boot in eOS live iso to clean this mess (about time, right?).

…this is when the first post of this thread appeared, after I unsuccessfully
# bootctl install
reboot
same crap
# bootctl install
# reinstall-kernels
same same

/efi was there, it was apparently populated as expected as @dalto checked in this post.

After crying for a couple of minutes, I went and extensively followed everything I came across in the wiki systemd-boot troubleshooting, UEFI troubleshooting here and there…
Well… that lead me kind of nowhere except in the windows command-line interface messing up rebuilding the bootloader…
This windows terminal part really was a lot of pain, leading to assuming the problem was probably (but what do I know…) with the BCD file in the windows boot loader… but like ¯_(ツ)_/¯

Yeah anyway, there’s so much pain one can take, so at one point I went rogue and just deleted (I do a LOT of drugs) everything inside the /efi partition (backing up only the /EFI/Microsoft folder which is stupid, but in line with the rest of my actions).

Now, NOTHING was booting of course. In the bios uefi was showing nothing at all to select to boot from. That was quite an achievement. I should have started with that.

So, eOS live iso, messing up the order of reinstall-kernels and bootctl install, leading to funny boot menu with nothing but the bios to “boot” on, then corrected the order, and back to a bootable eOS.
That was quite a journey…

Then, cause I like pain I guess, had to grab a f$ck*n W10 iso, do so much crap from there to “rebuild” the W10 boot loader, went back to eos, re re re re re re bootctl install → reinstall-kernels.

Back to a “normal” dual-booting system, with a wonderful systemd-boot menu showing everything it should.

In the bios, next to Linux Boot Manager and Windows Boot Manager, I still have a weird entry, called UEFI OS, that was created when I messed up kernels and bootctl order the first time I “repopulated” the /efi. I’m not sure I will care about it at this point.

What a long and boring post… (again, I do do drugs) so:

TL;DR:

• somehow (most probable cause: Me+ZindoZ) the boot menu vanished, worst, the linux bios entry did
• impossible to get it back on tracks only with bootctl install and reinstall-kernels, firmware wouldn’t acknowledge linux boot manager existence.
• blowing up /efi content for good and letting bootctl reinstall systemd-boot to the ESP did what it should. Booting into Linux was possible again.
• more idiotic steps were still necessary to get W10 on track too, but clearly the one and only mandatory step that should worth mentioning is:
• NOT TO INSTALL WINDOWS AT ALL

Cheers

[ricklinux]

Wow! This is like the story of the boot from hell.
Don’t let your bootloader play with Windows anymore! This is a good way to destroy your drives. Is that what also happened after?

[linuxislife]

lol, had it happened before it sure would have save me a lot of pain

[jputnam]

So, to sum it up, don’t do drugs.

Seriously though this morning was one of those and your post was entertaining and made my day. Thanks.

[ricklinux]

EOS is my fix.

Edit: When i need an upper i just follow @linuxislife

[linuxislife]

@jputnam

So, to sum it up, don’t do drugs.

I should totally select that as the solution

[joekamprad]

only to add to the game… i had it several times that after a windows update (windows install is on its own Disk and the first one in the row of drives in the system too) it was setting windows boot entry in the nvram as default also i set it to another one.

never saw it removing stuff on other efi partitions in my case i do always have one EFI for one drive… works perefctly.

But two times i had an update early win 11 install what completely removed and recreated efi partitions also on other drives. that stopped luckily.

[linuxislife]

Yeah I dunno, did I leave the bios in UEFI+legacy mode when windows started its “repair” process and somehow, even in UEFI only, the bios kept seeing only window…??
efibootmgr wasn’t showing anything from linux even though /efi looked normal… I can only guess it has something to do with the BCD file inside /EFI/Microsoft, but the truth is, I really don’t know.

My everyday machine is an HP laptop, with, on the same drive, W10 and eOS (yes I do love pain, I said that already) for which there is this new BIOS update waiting for me to install…
…take a look at the description of what it “fixes”:

@[HP]

Fixes

• Adds Enhanced Sign-in Security support for the fingerprint reader and the IR camera on the system. - Improves Smart Cover Support. - Optimizes the EFI partition space before the BIOS is updated through the Windows Update. - Includes the following firmware: Cypress Power Delivery (PD) Firmw […]

Let me tell you that for now, I will consider my actual bios soooo much up to date !

[ricklinux]

Me … I’d be all over it! I love updating UEFI firmware (Bios). It’s a thing!