If the none persistent device names were not created by genfstab because none of -U -L -t were used or manually by yourself I can not explain it.
Thank you. I will check what genfstab does.
If some other linux installer were used I would suspect that. That does not apply though on an arch / Windows dual install.
No installer is used. It is installed "from Wiki". However, this is my personal laptop and it was my first Arch installation, so I definitely cannot guarantee that I did not do anything foolish.
]]>You are suggesting that fstab was not modified by yourself or by your actions but by someone else or some third party software?
You want me to explain who or what this third party is?
Basically yes.
Although I have no doubts that everything happened as a consequence "of my actions" in the sense that I have allowed Windows to run updates, then I have also run all the commands from my original post. Technically, I am the only one using my own laptop.
In short, what is your take on how the hardcoded paths pointing to disk partitions ended in my /etc/fstab?
]]>So what is your take on this? Why my /etc/fstab got corrupted? Does it have something to do with grub-install?
Is the corruption you are referring to the same as you mentioned previously?
.
For some reason, my /etc/fstab ended with hardcoded paths in fstab (as <file system>). I usedblkid
to get UUIDs and manually added them to /etc/fstab instead of hardcoded paths.
You are suggesting that fstab was not modified by yourself or by your actions but by someone else or some third party software?
You want me to explain who or what this third party is?
The crucial part is "Also every time a volume is reformatted a new UUID is generated and configuration files have to get manually adjusted." (here).
For some reason, my /etc/fstab ended with hardcoded paths in fstab (as <file system>). I used
blkid
to get UUIDs and manually added them to /etc/fstab instead of hardcoded paths. Now Arch Linux boots.
It may be that Windows update reformats EFI System partition and that causes the changes in block device ordering. If that's the case, I will have to update my /etc/fstab manually every time a Windows update reformats EFI System partition.
]]>- Why systemd even tries to mount /boot/efi (apparently from /dev/sda2 which is Windows recovery environment)?
Loaded: loaded (/etc/fstab; generated)
see also `man 8 systemd-fstab-generator` and Persistent block device naming.
]]>filed to listen on Load/Save RF Kill Switch Status /dev/rfkill Match
...
failed to mount /boot/efi
# Enter recovery mode
...
Then I tried to restore my GRUB following wiki. So, basically what I did is:
- booted from my USB, and then:
$ mount /dev/sda5 /mnt
$ arch-chroot /mnt
$ mkdir /efi
$ mount /dev/sda3 /efi # my EFI System partition
$ grub-install --target=x86_64-efi --efi-directory=/efi--bootloader-id=GRUB /dev/sda
$ grub-mkconfig -o /boot/grub/grub.cfg
This restored my GRUB menu and I could boot into Windows. However, booting into Arch remained broken. From broken Arch boot emergency mode I did:
$ systemctl status boot-efi.mount
boot-efi.mount --- /boot/efi
Loaded: loaded (/etc/fstab; generated)
Active: Failed (Result: exit-code) ...
Where: /boot/efi
What: /dev/sda2
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
... systemd[1]: ...
... mount[309]: /boot/efi: wrong fs type, bad option, bad superblock on /dev/sda2, missing codepage or helper program, or other error.
... systemd[1]: ...
...
So, mount cannot mount my /dev/sda2 (which is Windows recovery environment). I tried to do that manually:
$ mount /dev/sda2 /run/media/some_mount_point
And no error occurred so I unmounted it. Thus, I assume that my system have all the utilities that it needs to boot this partition.
Then, as a sanity check, I looked at how my newly generated /boot/grub/grub.cfg looks like. And it seems OK. My intel-ucode.img, initramfs-linux-lts.img are in /boot and Arch Linux entry in grub.cnf correctly points to them. But, to the best of my understanding this does not mean much because my error happens when my Linux is already about to boot and not in GRUB script.
I basically have 2 questions:
- Why systemd even tries to mount /boot/efi (apparently from /dev/sda2 which is Windows recovery environment)?
and
- What is the correct way to restore the old functionality of GRUB after Windows update?
]]>