You are not logged in.
Pages: 1
I'm dual booting Arch Linux with Windows 10 on a laptop with UEFI.
Some windows updates result in linux becoming unbootable. It still has an entry in the boot menu, but when I select it I get the error 'vmlinuz-linux not found'.
When I boot from usb and mount my linux partitions, I find that `/boot/vmlinuz-linux` does exist, but `fsck.vfat` finds a problem with the file. After it attempts repairs, I get a new error ('vmlinuz-linux: unsupported'), but I still cannot boot linux.
My current solution to this problem is to boot from usb, `arch-chroot` into my linux partition, and `pacman -S linux` to reinstall the bootloader.
Has anyone experienced similar problems dual-booting windows 10? Is there a more permanent solution to this problem?
Offline
Is fast boot turned off? I don't think that should affect the ESP, but good to check.
Offline
Yes, I turned off Fast Startup the previous time this happened (about a month ago)
Offline
I have a working dual boot with Windows 10 and don't have this problem. However I have (besides the Windows files) only refind in the ESP, and it fetch the kernel from my usual root partition. I leave the ESP unmounted in Linux. But you should be more precise. What bootloader do you use? What fsck.vfat exactly says? How exactly have you run it?
Offline
FWIW I also dual boot on my desktop with Windows 10 using UEFI with no issues on Arch. I do need to reset the time in Windows whenever I boot into it for some reason, but since I use it only occasionally it doesn't really bother me enough to investigate why.
Offline
FWIW I also dual boot on my desktop with Windows 10 using UEFI with no issues on Arch. I do need to reset the time in Windows whenever I boot into it for some reason, but since I use it only occasionally it doesn't really bother me enough to investigate why.
That may be because Windows interpret the Bios/UEFI clock as local time and Linux as UTC. You can configure Windows to interpret it as UTC to match Linux. Open regedit, navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
and create a new DWORD key named RealTimeIsUniversal with a value of 1
Last edited by olive (2016-10-24 07:26:38)
Offline
That may be because Windows interpret the Bios/UEFI clock as local time and Linux as UTC. You can configure Windows to interpret it as UTC to match Linux. Open regedit, navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation
and create a new DWORD key named RealTimeIsUniversal with a value of 1
Thanks for the info. I'll check that out next time I'm logged into Windows.
Anyways, back to the OT.
Offline
Is there a more permanent solution to this problem?
The FAT filesystem required for the ESP is notoriously fragile so perhaps you could try mounting just /boot/efi to the ESP rather than /boot
GRUB can be used to boot a non-ESP-located kernel image or you could try https://wiki.archlinux.org/index.php/EF … unt_Points
Jin, Jîyan, Azadî
Offline
What bootloader do you use? What fsck.vfat exactly says? How exactly have you run it?
I'm using grub. From memory, fsck.vfat reports an unexpected byte in vmlinuz-linux, and it says "assuming EOF" when it goes to fix the file.
I ran fsck.vfat after booting from usb, mounting my partitions and finding that the boot partition was mounted read-only because of errors. The sequence would have been something like:
# mount /dev/sda5 /mnt
# mount /dev/sda1 /mnt/boot
# arch-chroot /mnt
# ... try to reinstall kernel using pacman, errors about /mnt/boot being a read-only filesystem ...
# fsck.vfat /dev/sda1
# pacman -S linux
The idea of storing the kernel away from the EFI partition is interesting; I will look into switching to refind.
Offline
perhaps you could try mounting just /boot/efi to the ESP rather than /boot
Thanks I'm looking into this now.
Offline
# mount /dev/sda5 /mnt # mount /dev/sda1 /mnt/boot # arch-chroot /mnt # ... try to reinstall kernel using pacman, errors about /mnt/boot being a read-only filesystem ... # fsck.vfat /dev/sda1 # pacman -S linux
The idea of storing the kernel away from the EFI partition is interesting; I will look into switching to refind.
You are running fsck on a mounted filesystem. You should never do that and expect severe file system corruption if you do it. Always unmount any filesystem before fsck them.
Offline
You are running fsck on a mounted filesystem. You should never do that and expect severe file system corruption if you do it. Always unmount any filesystem before fsck them.
Thanks, I'll keep this in mind for next time.
Offline
Pages: 1