You are not logged in.
So I had been dual-booting Arch and Windows 10 without any problem until I upgraded Windows 10 today. The boot menu is still the same as before:
Arch Linux
Windows Boot Manager
EFI Default Loader
Reboot Into Firmware InterfaceHowever, when I select the "Arch Linux" option, the following is shown on the screen:
:: running early hook [udev]
starting version 232
:: running hook [udev]
:: Triggering uevents...
:: performing fsck on '/dev/sda5'
:: mounting '/dev/sda5' on real root
mount: unknown filesystem type 'ntfs'
You are now being dropped into an emergency shell.
sh: can't access tty; job control turned off
[rootfs ]#I think Arch is trying to boot from a Windows partition for some reason, perhaps because the Windows upgrade messed up the partitions somehow. Here are the partitions seen by Windows:
Partition 1 Recovery 450 MB
Partition 2 System 100 MB <-- This is the EFI partition
Partition 3 Reserved 16 MB
Partition 4 Primary 364 GB
Partition 5 Recovery 450 MB <-- Does /dev/sda5 refer to this?
Partition 6 Unknown 100 GB <-- This is the Arch partitionAnd here are the files on the EFI partition (with some irrelevant language files hidden):
│ intel-ucode.img
│ vmlinuz-linux
│ initramfs-linux.img
│ initramfs-linux-fallback.img
│
├───loader
│ │ loader.conf
│ │
│ └───entries
│ arch.conf
│
└───EFI
├───Microsoft
│ ├───Boot
│ │ │ boot.stl
│ │ │ bootmgfw.efi
│ │ │ bootmgr.efi
│ │ │ kd_02_1137.dll
│ │ │ kd_02_14e4.dll
│ │ │ kd_02_15b3.dll
│ │ │ kd_02_1969.dll
│ │ │ kd_02_19a2.dll
│ │ │ kd_02_8086.dll
│ │ │ kd_07_1415.dll
│ │ │ kd_0C_8086.dll
│ │ │ BCD
│ │ │ bootspaces.dll
│ │ │ memtest.efi
│ │ │ updaterevokesipolicy.p7b
│ │ │ winsipolicy.p7b
│ │ │ kd_02_10df.dll
│ │ │ kd_02_10ec.dll
│ │ │ kdstub.dll
│ │ │
│ │ ├───en-US
│ │ │ bootmgfw.efi.mui
│ │ │ bootmgr.efi.mui
│ │ │ memtest.efi.mui
│ │ │
│ │ ├───Fonts
│ │ │ meiryo_boot.ttf
│ │ │ msjhn_boot.ttf
│ │ │ msjh_boot.ttf
│ │ │ msyhn_boot.ttf
│ │ │ msyh_boot.ttf
│ │ │ segmono_boot.ttf
│ │ │ segoen_slboot.ttf
│ │ │ segoe_slboot.ttf
│ │ │ wgl4_boot.ttf
│ │ │ chs_boot.ttf
│ │ │ cht_boot.ttf
│ │ │ jpn_boot.ttf
│ │ │ kor_boot.ttf
│ │ │ malgunn_boot.ttf
│ │ │ malgun_boot.ttf
│ │ │ meiryon_boot.ttf
│ │ │
│ │ └───Resources
│ │ │ bootres.dll
│ │ │
│ │ └───en-US
│ │ bootres.dll.mui
│ │
│ └───Recovery
│ BCD
│
├───Boot
│ bootx64.efi
│
└───systemd
systemd-bootx64.efiCould you please help me identify and fix the problem?
Last edited by zizheng (2017-05-07 19:34:27)
Offline
This is a common issue: have you read the wiki and searched for similar threads?
Not an Installation issue, moving to NC...
Offline
Hi Jason, yes I have done both but haven't been able to find the solution. I found many people who got booted straight into Windows without seeing the boot menu, but haven't find anyone who failed to boot into Arch even though the boot menu showed fine.
Offline
Hint: Is fastboot enabled in Windows? If so, it could be a bad thing.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
I solved the problem by changing
root=/dev/sda5to
root=dev/sda6in /EFI/loader/entries/arch.conf in the EFI partition. Thanks for the help!
Offline
You may want to look into using UUIDs instead of device nodes (/dev/sdx)
https://wiki.archlinux.org/index.php/Pe … ng#by-uuid
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
Thank you ewaller. Is there any advantage of using one of UUID / PARTUUID over the other?
Offline
Thank you ewaller. Is there any advantage of using one of UUID / PARTUUID over the other?
The UUIDs only change when the filesystem is reformatted - so even if the device nodes shuffle around, you can count on the UUID.
Offline