2134206969
- 帖子
- 1
- 评论
- 114
- 加入于
- 1 yr. ago
- 帖子
- 1
- 评论
- 114
- 加入于
- 1 yr. ago
That's just science as applied by engineers.
You can fix this, and this certainly isn't "basic".
I figure you didn't see your Linux option, because your EFI boot variables (boot order and boot loader locations) are stored "on the mainboard", and you didn't manage to reset those on the new board according to your current layout. Windows still boots, as it installs its bootloader in a generic location intended for removable devices, instead of properly registering itself with EFI boot variables. Because of course they do.
To fix this, I'd recommend a deep breath first, and then set BIOS to UEFI boot only, no CSM/legacy at all for now, no even as fallback. If you're lucky, you can boot into your Linux system from the BIOS boot menu right now, and skip the archiso boot and chroot shenanigans. Have a look. Otherwise boot into the archiso as you did before.
Identify your EFI system partition(s) (ESP) Run
sfdisk -l /dev/nvme0n1andsfdisk -l /dev/nvme1n1, note the "EFI System" type partitions. Ideally, there's only one atnvme1n1p3. Multiple ESPs would be trickier, but let's assume your singular ESP isnvme1n1p3. Have a look at the ESP, to understand its layout and confirm this is really what you're looking for:mkdir /esp,mount /dev/nvme1n1p3 /esp,find /esp. You should find the Windows bootloader atEFI/Boot/bootx64.efiandEFI/Microsoft/Boot/bootmgfw.efi.You might also find your grub bootloader in a subdirectory like
EFI/arch/grubx64.efi. Find all of your instances withfind /esp -iname grubx64.efi, and note the paths. If you find multiple grubx64.efi, I'd recommend to pick only the newest file, unless you know for a fact which one is supposed to be the one you want to use. Als -l <file>gives you the date of the file to check. If you don't have any grub bootloader installed, yet, that's fine, too.Create a boot entry with grub in a chrooted system If you can
arch-chrootinto your Linux system, make sure your ESP is mounted in your chroot as well, let's say at/espagain, and your/bootdirectory must be mounted, too, otherwise grub-install will fail. Thengrub-install --efi-directory=/espshould do its magic just fine. Useefibootmgrto display/edit the EFI boot variables, and check if the entries in there look correct. The ESP will be referenced by UUID, and the list will look pretty busy, but you should recognize the EFI paths, and yourarchentry should be the BootCurrent value. Make sure you've got a/boot/grub/grub.cfgin place, otherwise grub won't do you much good! Create one withgrub-mkconfig -o /boot/grub/grub.cfgfrom within your chroot, after editing/etc/default/grubif you need to add any kernel arguments for your system. Usually you do not, so fire away.If chrooting doesn't work for you, btrfs can be a little tricky, you should be able to install grub with the ESP and boot partition mounted alone in the archiso. nvme0n1p1 looks like your boot partition, so it'd go down like this:
mkdir /esp /linuxboot mount /dev/nvme1n1p3 /esp mount /dev/nvme0n1p1 /linuxboot grub-install --efi-directory=/esp --boot-directory=/linuxbootYou can
pacman -S grubifgrub-installisn't available on archiso, yet. Make sure you've got a/linuxboot/grub/grub.cfgin place here as well. Unfortunately you cannot usegrub-mkconfigeffectively without the chroot, but if you are at this point, and you're dropped into the grub rescue shell, you can try a minimal, lovingly handcrafted grub.cfg: You need to obtain the UUIDs of your ESP, boot and root partition for the menuentries, and replace the placeholders with your values. You can get those values withlsblk -oNAME,UUID /dev/nvme1n1p3 /dev/nvme0n1p1 /dev/nvme0n1p2, in this order (ESP, BOOTPART, ROOTPART UUID). I assume your root subvolume is namedroot, and your kernel is namedvmlinuz-linuxon the boot partition, with avmlinuz-linux.imginitfs. You should adapt these filenames in the grub.cfg if they are different, of course, but I think this is a pretty good guess. :)insmod part_gpt insmod part_msdos set default="0" if [ x"${feature_menuentry_id}" = xy ]; then menuentry_id_option="--id" else menuentry_id_option="" fi export menuentry_id_option function load_video { if [ x$feature_all_video_module = xy ]; then insmod all_video else insmod efi_gop insmod efi_uga insmod ieee1275_fb insmod vbe insmod vga insmod video_bochs insmod video_cirrus fi } terminal_input console terminal_output console set timeout=5 menuentry 'Arch Linux' --class arch --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple' { load_video set gfxpayload=keep insmod gzio insmod part_gpt insmod ext2 search --no-floppy --fs-uuid --set=root <BOOTPART UUID> echo 'Loading Linux linux ...' linux /vmlinuz-linux root=UUID=<ROOTPART UUID> rw rootflags=subvol=root echo 'Loading initial ramdisk ...' initrd /initramfs-linux.img } if [ "$grub_platform" = "efi" ]; then insmod bli fi if [ "$grub_platform" = "efi" ]; then menuentry 'Windows Boot Manager --class windows --class os $menuentry_id_option 'osprober-efi' { insmod part_gpt insmod fat search --no-floppy --fs-uuid --set=root <ESP UUID> chainloader /EFI/Microsoft/Boot/bootmgfw.efi } fiLet's see how this goes.
Wow.. I.. I did not expect such density of triggers in a single panel. Trolling truly is a art. The more you look, the worse it gets. I love it.
Yes. 127.0.0.0/8 is reserved IPv4 address space for Loopback. It is perfectly valid, and occasionally useful, to use other loopback addresses that are functionally identical, like 127.0.1.1 or 127.0.0.53, which carry semantic information for the initiated, like "53? Must be DNS-related, obviously!"