The "recommendations" are for user convenience. If you are going to use EFISTUB or systemd-boot it makes sense to simply have it mounted to /boot as that is the simplest way to ensure new kernel images actually land there (as that's the default path where mkinitcpio will generate images) and will be used on the next start up. If you use a method that can boot the initramfs from a linux or other partition the only reason you'd ever have to mount it is if you wanted to update that other method.
]]>or /boot/dontlookhere/efi
Holy crap you made me LOL at work.
That is good insight. Yeah, I was just quoting the Arch Wiki. I do get nervous because, since Arch Linux just works and I never need to re-install it, I worry that I might be missing a change that was implemented in the installation procedure or something, or a better way of doing things. But I guess if my computer just keeps working then it doesn't really matter.
...but I guess if I didn't like tinkering with my installation then I probably wouldn't be using Arch Linux...
]]>Apparently your method is now preferred.
Preferred by whom? And more importantly for what reason? Using /efi does seem to be "in vogue" according to some documentation, but that is mostly at the whim of the documentation author. And even if that is accurate, that it is becoming "popular" that does not mean it is better in any way. If there are any technical benefits of this mount point, I've not seen them elaborated. It is infact a bit more restrictive, but it is noted in documentation that with some popular boot managers/loaders it is now "possible" to use /efi. But the fact that some modern bootloaders allow for it should not be sufficient justification to recommend it.
I can anticipate some claims about the benefits of not having the kernel (and initramfs) on the ESP. But if that is to hold water, one would have to know why that is actually a benefit for their use case. For some particular encryption schemes this mount point may protect against specific threats ... threats that may not even be relevant to a majority of users. But even this logic would only favor not having the ESP at /boot, it would not at all argue against /boot/efi, or /boot/dontlookhere/efi, or /boot/unicorn-farts, or just not mounting it at all! It's just arbitrary.
]]>FYI there is nothing dangerous about posting an "/etc/fstab" file or UUIDs. They are only useful on the computer they are used on. If someone has access to that then you have bigger problems.
I deleted my swap partition a few years ago and I don't miss it. I never used it! Besides, if I need swap some day, it's just as easy to create a "swap file" instead of a new partition.
...oh wow, I just noticed you're using "/efi" instead of "/boot/efi" like me. Apparently your method is now preferred. Sounds like a potential Christmas break project for me.
https://wiki.archlinux.org/index.php/EF … unt_points
EDIT: I just noticed my EFI partition is actually mounted to "/boot". Yikes.
EDIT: ...which is normal according to the wiki link above, because I use "systemd-boot".
#/dev/nvme0n1p4
UUID=xxxxxxxx / ext4 rw,relatime 0 1
#/dev/nvme0n1p2
UUID=xxxxxxxx /boot ext4 rw,relatime 0 2
#/dev/nvme0n1p1
UUID=xxxxxxxx /efi vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 2
The nvme0n1p3 is a swap partition but I haven't enabled swapping.
I hope it looks pretty normal, so that I can expect that this probably won't happen again - then again now I know how to fix it, so it's no problem.
What Gaku refers to is that you are doing some unnecessarily verbose steps when arch-chroot is a thing, it really isn't that big of a deal nor an inherent issue. What is potentially a problem is that by doing an -Sy without an -u you've updated your package database into a potential partial state. This is no problem as long as your next interaction with pacman is an -Syu but can lead to undesired side effects if you were to -S a package other than linux: https://gist.github.com/vodik/5660494
]]>@V1del
Thanks it was just my typo here, since I had to type it by hand I made a mistake.
But I didn't "do" anything. I just use my system to do the usual stuff and sometimes do pacman -Syu so I have no idea why it deleted the linux and initram files, basically the /mnt/boot folder was suddenly empty except for /mnt/boot/grub which still existed just fine.Ok, I fixed it. If pacman breaks your system, do this:
Download archlinux install image and install it on a USB stick with (replace /dev/sdb1 with your USB stick device, make sure to check via 'lsblk -f' command!):sudo dd if=archlinux-2020.12.01-x86_64.iso of=/dev/sdb1 bs=1M status=progress
and boot from it.
Now mount your existing arch partitions into /mnt folder, replacce sdXY by your actual partitions again, check 'lsblk -f' eg:mount /dev/sdXY /mnt mount /dev/sdXY /mnt/boot mount -t proc proc /mnt/proc mount -t sysfs sys /mnt/sys mount -o bind /dev /mnt/dev mount -t devpts /dev/pts /mnt/dev/pts/
and finally chroot into it, with bin/bash or archlinux will fail with error that zsh doesn't exist:
chroot /mnt /bin/bash
And finally just simply install the linux package again!
pacman -Sy pacman -S linux
And it should work again (did for me).
From what video tutorial did you got that?
dd’ing the iso to a key is ok, the rest is just arch-chroot and pacman -Syu linux...except that you mounted by hand, didn’t do squat about resolv.conf, and did a partial upgrade!
Of course, you can just do pacman -S linux, no need to check for database updates...
]]>Ok, I fixed it. I googled a bit on how to do chroot and also found a video that explains why basic chroot will fail (it's cause arch misses zsh binary). So, if pacman breaks your system, do this:
Download archlinux install image and install it on a USB stick with (replace /dev/sdb with your USB stick device, make sure to check via 'lsblk -f' command!):
sudo dd if=archlinux-2020.12.01-x86_64.iso of=/dev/sdb bs=1M status=progress
and boot from it.
Now mount your existing arch partitions into /mnt folder, replacce sdXY by your actual partitions again, check 'lsblk -f' eg:
mount /dev/sdXY /mnt
mount /dev/sdXY /mnt/boot
mount -t proc proc /mnt/proc
mount -t sysfs sys /mnt/sys
mount -o bind /dev /mnt/dev
mount -t devpts /dev/pts /mnt/dev/pts/
and finally chroot into it, with bin/bash or archlinux will fail with error that zsh doesn't exist:
chroot /mnt /bin/bash
And finally just simply install the linux package again!
pacman -Sy
pacman -S linux
And it should work again (did for me).
Man what a shocker, I wish it would not do sth like this out of the blue, lol.
If it's not the typo, what usually happens here is that you didn't have /boot mounted while needing it to, or the reverse having /boot mounted while not needing to, which of these cases is true depends on how the bootloader is configured. GRUB does not technically need the /boot and it's own partition to be the same.
What did you do here? Post your /boot/grub/grub.cfg and the output of lsblk -f The general way to fix this is to mount the partitions properly as configured and reinstalling the linux package or running mkinitcpio -p linux
]]>Loading Linux linux ...
error: file `vmlinuz-linux' not found.
Loading initial ramdisk ...
error: you need to load the kernel first.
Press any key to continue...
What happend and what am I supposed to do???
EDIT:
Fixed! See https://bbs.archlinux.org/viewtopic.php … 3#p1941023 below