Cannot boot Windows 10 from second hard drive

Very nicely done. You managed to straighten this out all on your own. Most people take up a ton of forum time to fix this type of issue. Very nice to see someone who likes to get the job done themself. Kudo’s to you.

2 Likes

Thanks, i am relatively new to Linux and i think it was kinda interesting experience for me.

2 Likes

Morning, Good to hear.
Can you print out from terminal, whats

efibootmgr -v
findmnt -s
sudo parted -l
sudo blkid

Thanks.

1 Like

You should really provide the outputs gohlip requested. He is the resident expert on these issues. He will know if you have made a misstep in your configuration, and how to correct it. Please mark your thread “solved” when you’re satisfied it is working correctly.

1 Like

Sorry for my late reply. There is what you requested:

efibootmgr -v output:

BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0002,0001,2001,2002,2003
Boot0001* Windows Boot Manager  HD(1,GPT,17000707-370b-4a23-8f71-e1d110e43695,0x800,0x1f000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0002* rEFInd Boot Manager   HD(1,GPT,17000707-370b-4a23-8f71-e1d110e43695,0x800,0x1f000)/File(\EFI\refind\refind_x64.efi)
Boot2001* EFI USB Device        RC
Boot2002* EFI DVD/CDROM RC
Boot2003* EFI Network   RC

findmnt -s output:

TARGET     SOURCE                                    FSTYPE OPTIONS
/boot/efi  UUID=0604-11A2                            vfat   defaults,noatime
/home/wind UUID=FCB2D3E4B2D3A186                     ntfs   defaults,noatime
/          UUID=96814df6-dca5-48b2-9d39-bebee780d05e ext4   defaults,noatime
swap       UUID=36a871a3-76db-44b0-b036-e683bb010700 swap   defaults,noatime
/home      UUID=472122c2-a69a-46dd-a138-e3230305a1e8 ext4   defaults,noatime

sudo parted -l output:

Model: ATA WDC WD10SPZX-21Z (scsi)
Disk /dev/sda: 1000GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system     Name                  Flags
 1      1049kB  66,1MB  65,0MB  fat32                                 boot, esp
 2      66,1MB  527GB   527GB   ntfs            Basic data partition  msftdata
 3      527GB   632GB   105GB   ext4
 4      632GB   646GB   13,6GB  linux-swap(v1)
 5      646GB   992GB   346GB   ext4


Model: ATA KINGSTON RBUSNS8 (scsi)
Disk /dev/sdb: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size   File system  Name                  Flags
 1      1049kB  128GB  128GB  ntfs         Basic data partition  msftdata
 2      128GB   128GB  514MB  ntfs                               boot, hidden, esp

sudo blkid:

/dev/sda1: UUID="0604-11A2" TYPE="vfat" PARTUUID="17000707-370b-4a23-8f71-e1d110e43695"
/dev/sda2: LABEL="HDD" UUID="FCB2D3E4B2D3A186" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="6674013a-1fbb-47d7-a1fe-d6efeeb857d0"
/dev/sda3: UUID="96814df6-dca5-48b2-9d39-bebee780d05e" TYPE="ext4" PARTUUID="c09913f3-4e4a-4821-9538-8078a1127fcb"
/dev/sda4: UUID="36a871a3-76db-44b0-b036-e683bb010700" TYPE="swap" PARTUUID="8bfa6bba-bfa9-47dd-9c4c-515dc1d4bda5"
/dev/sda5: UUID="472122c2-a69a-46dd-a138-e3230305a1e8" TYPE="ext4" PARTUUID="473e8300-94fe-4535-80d8-70a9484e55db"
/dev/sdb1: UUID="E632A0A032A076E9" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="11d14c38-4991-4ebc-9d25-d4b3abb552db"
/dev/sdb2: UUID="F0CCFCE9CCFCAACC" TYPE="ntfs" PARTUUID="fd465e01-e881-4972-a73a-592e89ed07c4"

Okay, you’ve got everything in place. That’s good.
As said (elsewhere), recent installations and grub-installs have problems making efi bootentries.
And as mentioned here, if you want to have Manjaro grub when you boot up (instead of rEFInd), you can at Manjaro terminal, do

sudo grub-install
sudo cp /boot/grub/x86_64-efi/core.efi /boot/efi/EFI/boot/bootx64.efi
sudo efibootmgr -c -d /dev/sda -p 1 -L "manjaro" -l "\EFI\Manjaro\grubx64.efi

If you’re happy with rEFInd, the way you’re booting now, that’s fine.
But note if you boot Manjaro directly with rEFInd and not through its grub, intel-ucode will not be called up. You can check the differences in the 2 boots (direct and through grub) with

dmesg | grep microcode

Cheers.

[1] - without intel-ucode, you won’t get this output.
microcode updated early to revision

2 Likes

Thanks for the tip, i feel comfortable with booting through rEFind for now, with dmesg | grep microcode i got:

[    0.595873] microcode: sig=0x806ea, pf=0x80, revision=0x64
[    0.596225] microcode: Microcode Update Driver: v2.2.

Is it crucial to call intel-ucode during boot or it affects only this output?

Each of us have different ‘perspectives’ on it. Generally with the spectre and meltdown flaws, it is best to have intel-ucode booted up. I’ve seen developers calling for the removal of intel-ucode (to facilitate non-boots) and some distro’s (Antergos and previous Net-runner) do not have intel-ucode as default. But other than the above, all other distros have built in intel-ucode that boot up early.

Hope this answers (to some - tactfully). Cheers

2 Likes

Thank you for explanation, i will set up booting through grub bootloader.

1 Like

Before you begin,
There are ways to have refind boot up intel-ucode.

See this.
And I think there’s one script written by openminded that will handle that.

But both are quite convoluted.
Read them first before deciding.

1 Like

You can also fine tune you rEFInd configuration with something like initrd=/EFI/manjaro/intel-ucode.img initrd=/EFI/manjaro/initramfs-%v.img added to the refind-linux.conf in /boot/efi/EFI/manjaro directory. GRUB is great but there’s no need in it if you already boot using EFISTUB (direct kernel booting). rEFInd also looks better (IMO).
Here is my post with even more details: Secure Boot with rEFInd

Hi, openminded (hope monkeber don’t mind this segue)
Have you tried systemd-boot?

I can’t recommend it for monkeber because he has his $esp as /boot/efi
systemd-boot requires $esp as /boot.

Like rEFInd, it is using efistub.
But I personally find it simpler, direct and straightforward.
Though without the eye-candy.
You may like it.
And it boots intel-ucode (in Manjaro - with double initrd lines)

1 Like

Hi!
I tried it, but that was a special case: it was installed as a part of Solus while Manjaro’s rEFInd was still the default option, and I had not time to play with it much, because, you know, Solus does not support SecureBoot by default, and it creates quite a mess in EFI - 3 folders named com.solusproject, goofyboot, systemd-boot (I don’t remember exactly and it doesn’t matter anyway). When I saw all these in rEFInd listing I just decided to hide unnecessary items, so I signed goofyboot and disabled scanning the other two directories. And I still don’t want to mess with anything related to boot process just because I was tired of reboots those days :slight_smile:
I also have Windows on another drive, so pure systemd boot would not be a good decision I guess.
Just a thought: I don’t see any problems with mounting ESP to /boot. Maybe I’m wrong just because I used rEFInd to execute Solus’ systemd-boot, idk.
Okay I will look into it tomorrow, it’s a late night in my place, I can hardly type my phone’s keyboard :sleeping:
Have a good day/night guys.

In Manjaro, installing systemd-boot needs manual input.
Read this topic. It may be slightly outdated but I think generally it’s still valid.

The issues with bootctl (I prefer to call it that - most will call it systemd-boot) are valid with rEFInd too. Just that rEFInd is more versatile in picking up efi files (and boot them) when bootctl does not. Oh grub can do that too (pick and boot efi files) but need to input … stanza?

I have all grub, rEFInd, and bootctl in my system. :stuck_out_tongue_closed_eyes:
But preferences, being personal, can be subjective. Features though, are not.

Cheers.

2 Likes

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 …”?

Morning.

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.

##########################################################

2 Likes

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.