Cannot boot Windows 10 from second hard drive

No, systemd-boot can handle windows. Just make sure windows efi file is also in that same $esp.
ps: I'm just 2 hours behind you. Yes, it's late.

I followed link and used your workaround (changing refind_linux.conf), but had to specify full path to .img files (string part after 'rw' was there already):

"Boot with standard options"  "root=UUID=96814df6-dca5-48b2-9d39-bebee780d05e initrd=/boot/intel-ucode.img initrd=/boot/initramfs-4.14-x86_64.img rw quiet resume=UUID=36a871a3-76db-44b0-b036-e683bb010700"

instead of yours

"Boot with standard options"  "root=UUID=c69d25c9-73a6-4a1e-a586-805d060cc822 initrd=\intel-ucode.img initrd=\initramfs-4.14-x86_64.img rw"

latter caused error in rEFInd after starting vmlinuz-4.14-x86_64:

Failed to open file: intel-ucode.img
Trying to load files to higher address
Failed to open file: intel-ucode.img

Also before changing refind_linux.conf i tried merging kernel with intel-ucode like you did on the link, but it had no effect at all, probably i missed the point here and did something pointless.

Anyway, dmesg | grep microcode output now:

[    0.000000] microcode: microcode updated early to revision 0x84, date = 2018-01-21
[    0.578294] microcode: sig=0x806ea, pf=0x80, revision=0x84
[    0.578638] microcode: Microcode Update Driver: v2.2.

Now i wonder, if in future kernel version will be changed, will current boot option stop working and i will have to redo all above or will it just boot with old kernel?

P. S. Noticed that hibernation doesn't work (there is just black screen after rEFInd screen), is it relative to "resume" entry in refind_linux.conf? Should i add "initrd ..." after "resume ..."?


This means the merging works. Intel-ucode is in effect early. Note there is no output at merging command. Neither is there any error message.

Yes, at each kernel change, you will need to do the merge command. You can put in a bash alias to help you as follows..

alias intman='sudo cp /boot/vmlinuz-4.17-x86_64 /boot/vmlinuz-intman\
&& sudo cat /boot/intel-ucode.img /boot/initramfs-4.17-x86_64.img > ~/initramfs-intman.img\
&& sudo cp ~/initramfs-intman.img /boot/'

where I use vmlinuz-intman and initramfs-intman.img ; you can use your own naming convention but use vmlinuz-xxxxxx and initramfs-xxxxxx.img in that format.

Re: resume :
Put resume=UUID=xxxxxxxxxxxxx in the options line, not the linux line and yes in the manual entry of refind_linux.conf (not refind.conf in higher directory).
Here's my manual entry (but I did not put in resume for mine, I don't use hibernation)

menuentry "Manjaro Plasma" {
    icon     /EFI/refind/icons/os_manjaro1.png
    loader   /vmlinuz-intman
    initrd   /initramfs-intman.img
    options  "root=PARTUUID=d7ab9a0b-b52b-4b69-8d1c-bd57b9b98a2e rw"

As for the earlier part of your post, I'll let openminded handle this as I think you are referring to his link, but note I think his $esp is in /boot (not /boot/efi) [same as mine] and therefore you have to use
initrd=/boot/intel-ucode.img xxxxxxxxxxxxxxx
not initrd=/intel-ucode.img xxxxxxxxxxxxxxx

As a side note, systemd $esp has to be /boot
grub $esp best to be /boot/efi (can be /boot but will be disastrous)
and while rEFInd can be in /boot (like mine) or in /boot/efi (like yours), I recommend it to be in /boot (for many reasons to be listed here) but not disastrous either way.

So note refind can need some level of tweaking while systemd-boot is straightforward and grub is hassle-free, automatic as well as versatile and powerful. Those who know me longer can say I might be biased. They may not be wrong but I happily stand guilty as charged. :grinning:

[edit] - Here's a note I wrote elsewhere (not here); thought it might be useful to understand better.

Systemd-boot can only pick up OS's in the same $esp. So if Linux-mint $esp is not the same as KaOS and Solus, it won't be picked up. The same applies for rEFInd. But it (refind) can detect efi files in other $esp's and boot them up. But that means it will boot through their own efi files and that usually means through their grubs. Grub 2 can detect other OS's not in their own $esp and boot them.

There can be ways to boot other OS's not in the same $esp in systemd-boot. That involves copying over their vmlinuz and initrd files to systemd-boot. You have to copy as sym-links won't work on fat32 format partitions.
Another way is to copy over the core.efi files and the boot will 'chainload' to that efi file effectively going through their grub (usually).

I would advise against using Ubuntu (and derivatives) in systemd-boot as their kernel generation makes a sym-link (vmlinuz) to root directory. As said, sym-links won't work. Also if using same name vmlinuz and intrd files, like arch and kaos, (both using vmlinuz-linux and initramfs-linux.img) or like Ubuntu and Linux Mint, have them in the same $esp (/boot), systemd-boot would be perilous (same as in rEFInd). But grub 2 will present no such problem for any multitude of OS's.



Thank you a lot for explaining it all for me! I will try to understand all of these booting options tommorrow, because it is 5:15 in my area and i haven't slept yet. :upside_down_face:
Maybe i will be comfortable to not use hibernation too, but "playing" with boot seems interesting so far.

1 Like

Good morning.

Look at my own refind_linux.conf:

"Boot with optimized options" "rw quiet bootsplash.bootfile=bootsplash-themes/manjaro-mi/bootsplash add_efi_memmap cryptdevice=UUID=539765e7-4e25-44e4-b03a-7feecae7fd54:cryptlvm:allow-discards root=/dev/mapper/ManjaroVolGroup-root rootfstype=ext4 resume=/dev/mapper/ManjaroVolGroup-swap initrd=/EFI/manjaro/intel-ucode.img initrd=/EFI/manjaro/initramfs-%v.img"
"Boot with fallback initrd" "rw quiet bootsplash.bootfile=bootsplash-themes/manjaro-mi/bootsplash add_efi_memmap cryptdevice=UUID=539765e7-4e25-44e4-b03a-7feecae7fd54:cryptlvm:allow-discards root=/dev/mapper/ManjaroVolGroup-root rootfstype=ext4 resume=/dev/mapper/ManjaroVolGroup-swap initrd=/EFI/manjaro/initramfs-%v-fallback.img"

Here you can see lots of options but what you need is initrd=/EFI/manjaro/intel-ucode.img initrd=/EFI/manjaro/initramfs-%v.img. As I said, these strings are something special for my setup, i.e. there's a path to intel-ucode.img & initrd image which are located on my EFI parition that is mounted to /boot/efi. refind_linux.conf is also right there, in "manjaro" folder. That's because of LVM on LUKS partition scheme I have, and refind cannot access it of course.
But for you things should be much easier. You don't have to copy both intel-ucode and initramfs images, vmlinuz and refind_linux.conf to manjaro folder on ESP. What you need is make correct adjustments to existing refind_linux.conf in your /boot directory.

So, to sum this up, I suggest simply edit your string to look like initrd=/boot/intel-ucode.img initrd=/boot/initramfs-%v.img. Fallback entry would be initrd=/boot/initramfs-%v-fallback.img accordinggly.

As I see you have already done similar job, but I had to explain in detail anyway. Also, one more thing: using %v in refind_linux.conf substitutes kernel version, which is smth like 4.14-x86_64 in Manjaro, and using this kind of indication makes your config flexible because you write it once, and Linux will always boot, any version.

1 Like

Oh, this is what I always try to avoid. Never liked the idea to let Windows and Linux boot files co-exist on the same partition, even if it's EFI. Linux distros tend to amend some files in Windows folder during installation process, and Windows was spotted to do the same. And as soon as there are 2 physical drives in my system - this goal is easily achieved by detaching another drives before installation.
As for using /boot for ESP, well that's not my case. I mean I didn't even need to do that at all.

Yes, I agree. I too have windows in separate $esp. I'm clarifying that systemd-boot can handle windows if they are on the same $esp, as they would other linux boots if they are on the same $esp, otherwise they (linux OS's) would not be in the systemd-boot menu if they were not. And correct, that's a not a good point about systemd-boot. However, this applies to rEFInd too , just that the mechanism allows it to detect efi files in other $esp's and that's how rEFInd boots other OS's not in the same $esp. And that's precisely another (there are many others) good point about grub. And there's no need to detach any drive for any installation (in grub).

Whatever, I think we both agree on this particular matter.

As mentioned, I have systemd-boot, rEFInd and grub and I have 4 $esp (at least 3) on each of my 3 disks. I use mainly grub (for all OS's, even for those on systemd-boot or on rEFInd or none), and use rEFInd and systemd-boots only to test and check them out so I can understand them better. I had tested them before and now is just to revisit if I was wrong or they (rEFInd or systemd-boot) had improved. Nope, neither. :yum:

As said before (elsewhere), I have no problem with anybody using anything they are happy with. This applies with the boot system (or grub-customizer :rofl: ) as well.



Sure thing.

As a side note I would like to say that rEFInd has become my main boot manager due to its ability to find and list all possible loaders I could have, including external ones, it has one config file, all its files reside on ESP, and the last but not the least - because of excellent manuals written by its creator, I mean "rodbooks". I know exactly what to do in order to make rEFInd look and behave as I wish, while every time I face some difficulties with GRUB I am like "What? Google again?" Also GRUB shipped with one distro is often unable to boot another one - os-probe makes them visible in boot menu but the boot itself fails. openSUSE's GRUB cannot boot Manjaro, Manjaro's - cannot boot Fedora or Solus, vise versa, et cetera, et cetera. And the utmost - every distro installs its GRUB rewriting nvram so every time one has to efibootmgr -c -d -p -l -L just to mess with the GRUB's config of his own liking? Nah, not for me.

1 Like

Yes, wholeheartedly agree. His websites are an excellent, reliable and detailed repository of uefi information. He too has personally helped others mainly in ubuntu sites.

On the other hand, the systemd-boot developer..... :laughing:

Cheers, take care.

1 Like

Thanks for the tip and following explanation, i edited string and wrote -%v there, all works fine.

About hibernation - i tried to add menuentry, but it still doesn't fix hibernation and prints error something like "Not found while loading vmlinuz-4.14-x86_64", i tried several naming conventions and provided full path to files bot nothing helped.
Also i encountered this section on arch wiki:
and i wonder is it possible that my hibernation problem is the same bug, since Manjaro is Arch-based distro?

Anyway, i think i will be comfortable just using Manjaro without hibernation, thanks a lot for your help.:slightly_smiling_face:

Re: hibernation.
Check if 'resume' is in HOOKS line of /etc/mkinitcpio.conf

If none, correct it and do
sudo mkinitcpio -P

Then at refind options add

Note: as stated I do not have hibernation.
openminded will be better on refind than me to help, but I guess he is sleeping now, I will soon.

Already checked, "resume" is already there:

HOOKS="base udev autodetect modconf block keyboard keymap resume filesystems fsck"

But it is no big deal in hibernation, maybe i will try to fix this in future, good night then.

in this cases , multi linux boot and grub
just update-grub will add others systems linux

Done this?

So, after appending resume to HOOKS run
sudo mkinitcpio -P
Then add the following to refind_linux.conf:
This is the UUID that you have posted in the begininng of the thread. I hope your swap partition is slightly bigger that RAM size?

Yep, after i also tried with PARTUUID.

Yes, my swap is 12.7 GiB and my RAM is 12 GiB.
I tried sudo mkinitcpio -P and put resume in refind, but it didn't work, so then i just turned hibernation off and removed it from options.:upside_down_face:

@monkeber, Try this.
Make a manual entry in /boot/efi/refind/refind.conf (not in /boot/refind_linux.conf) at the bottom of the file.

menuentry "Manjaro Plus Resume" {
    icon     /EFI/refind/icons/os_manjaro.png
    loader   /vmlinuz-xxxxxxxxxxx
    initrd   /initramfs-xxxxxxxxxxxx.img
    options  "root=PARTUUID=c09913f3-4e4a-4821-9538-8078a1127fcb resume=UUID=36a871a3-76db-44b0-b036-e683bb010700 rw"

Fill in the kernel and initramfs files appropriately.
Let us know if hibernation now works when booting up that manual entry.

ps: I assume mkinitcpio.conf HOOKS has that 'resume' and 'mkinitcpio -P' is done.

[edit] - Oops, I forgot - your $esp is /boot/efi; mine is /boot.
So to above it should be /boot/vmlinuz-xxxx and /boot/initramfs-xxxxx.img
Not /vmlinuz-xxxxxxxxxx and /initramfs-xxxxxxx.img

1 Like

So, i added to HOOKS resume where it was and ran sudo mkinitcpio -P, then edited refind.conf:

menuentry "Manjaro Plus Resume" {
    icon     /EFI/refind/icons/os_linux.png
    loader   /boot/vmlinuz-4.14-x86_64
    initrd   /boot/initramfs-4.14-x86_64.img
    options  "root=PARTUUID=c09913f3-4e4a-4821-9538-8078a1127fcb resume=UUID=36a871a3-76db-44b0-b036-e683bb010700 rw"

But hibernation still doesn't work. After i select this entry in rEFInd menu i get this error:

Invalid loader file!
Error: Not Found while loading vmlinuz-4.14-x86_64

However vmlinuz-4.14-x86_64 is in /boot/.
Also my refind.conf is in /boot/efi/EFI/refind/, not in /boot/efi/refind/, is it relevant?

Forum kindly sponsored by