1 line
5.3 KiB
Plaintext
1 line
5.3 KiB
Plaintext
<!-- SC_OFF --><div class="md"><p><strong>EDIT: I am putting this at the top because it essentially invalidates the rest of this post. Rejoice all ye fellow weirdos who use framebuffer for I have a solution. I realized there was, in fact, a singular difference between the loader.conf in my new install and the old. Timeout was commented in the new one because I just wanted to see if it booted and not wait. When I commented it on my old one too, it directly booted when selecting the ssd from UEFI/Firmware, in full resolution. I believe this means systems-boot overrides the default resolution to avoid the lag issues caused in Grub menus at high res, and the kernel inherits it from the efifb driver. Realistically, this should be fixed, but I’m not sure whether the bug is located in systemd-boot, efifb, or some other part of the kernel. If I figure it out after finals I’ll try to get it fixed and up-streamed.</strong></p> <p>So I very recently got a Corsair MP600 (for some reason my seq reads/writes are the same speed as random but that's an issue for another time) and I cloned my Arch install to it.</p> <p>Now, it has been a point of no small annoyance that my framebuffer looks like censored garbage since I often break configs and need to fix them from there, but I do ML work and need to use Nvidia drivers. Astoundingly, though my framebuffer TTY looks exactly like it does when nouveau is installed, yet the driver is blacklisted, and not loaded in my kernel. I confirmed this with the following on the new install:</p> <pre><code>$ lspci -k | grep -EA3 'VGA|3D|Display' 0b:00.0 VGA compatible controller: NVIDIA Corporation TU102 [GeForce RTX 2080 Ti] (rev a1) Subsystem: ASUSTeK Computer Inc. Device 8687 Kernel driver in use: nvidia Kernel modules: nouveau, nvidia_drm, nvidia $ lsmod | grep nvidia nvidia_uvm 2564096 0 nvidia_drm 73728 0 nvidia_modeset 1155072 1 nvidia_drm nvidia 36966400 2 nvidia_uvm,nvidia_modeset $ lsmod | grep nouveau (empty) $ sudo dmesg | grep fb [ 0.721977] pci 0000:0b:00.0: reg 0x10: [mem 0xfb000000-0xfbffffff] [ 0.722035] pci 0000:0b:00.0: BAR 1: assigned to efifb [ 0.722657] pci 0000:00:03.1: bridge window [mem 0xfb000000-0xfc0fffff] [ 0.744568] pci 0000:00:03.1: bridge window [mem 0xfb000000-0xfc0fffff] [ 0.744607] pci_bus 0000:0b: resource 1 [mem 0xfb000000-0xfc0fffff] [ 0.767193] ahci 0000:09:00.0: flags: 64bit ncq sntf ilck pm led clo only pmp fbs pio slum part [ 0.767546] ahci 0000:0a:00.0: flags: 64bit ncq sntf ilck pm led clo only pmp fbs pio slum part [ 0.768302] efifb: probing for efifb [ 0.768313] efifb: showing boot graphics [ 0.773402] efifb: framebuffer at 0x7fe0000000, using 23040k, total 23040k [ 0.773403] efifb: mode is 2560x1440x32, linelength=16384, pages=1 [ 0.773404] efifb: scrolling: redraw [ 0.773405] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 [ 0.773427] fbcon: Deferring console take-over [ 0.773428] fb0: EFI VGA frame buffer device [ 1.480177] fbcon: Taking over console </code></pre> <p>The other ssd has the exact same drivers, exact same boot parameters, exact same everything. In fact, the only things that are not 100% identical are the things generated during boot time, as the guide I (mostly) followed here: <a href="https://www.rdeeson.com/weblog/157/moving-arch-linux-to-a-new-ssd-with-rsync">https://www.rdeeson.com/weblog/157/moving-arch-linux-to-a-new-ssd-with-rsync</a></p> <p>excluded only /dev/* /proc/* /sys/* /tmp/* /var/tmp/* /run/* /mnt/* /media/* and lost+found</p> <p>There was one key difference though, and that was what occurred when using sgdisk:</p> <pre><code>sgdisk /dev/sdb -R /dev/nvme0n1 sgdisk -G /dev/nvme0n1 </code></pre> <p>After running this, when chrooting to the new disk and attempting to install systemd-boot after pacstrap-ing the OS and firmware, I got an error essentially stating "block device &amp;amp;amp;lt;my nvme boot partition&amp;amp;amp;gt; is of the wrong type for extended bootloader" which made no sense, as the flags on it were boot and esp. Alas, I deleted the flags from that table and redid it setting them to ef00 (which was true on the original too) and then bootctl install worked.</p> <p>I believe that whatever caused this extra step to be necessary may also be the source of my issue, since it is efifb setting the resolution.</p> <p>I have spent the last 5 hours trying to hunt down some other difference to no avail. I even pacman -S'd base, linux, and linux-firmware just to see on the old ssd but no changes. I've run mkinitcpio a ton of times on both systems and just can't figure it out.</p> <p>I am aware grup can interface with vga drivers to provide a higher resolution, but using this in the past caused massive lag at higher resolutions. I also prefer systemd-boot, and considering my tensorflow code is running on gpu in my new install with no issues, I really want to figure out how tf to reproduce this if anyone has any ideas.</p> <p><strong>EDIT2: If you read down to here you wasted your time. Read the edit at the top.</strong></p> </div><!-- SC_ON -->   submitted by   <a href="https://www.reddit.com/user/ManiAmara"> /u/ManiAmara </a> <br/> <span><a href="https://www.reddit.com/r/archlinux/comments/r7qt2n/how_are_my_nvidia_proprietary_drivers_supporting/">[link]</a></span>   <span><a href="https://www.reddit.com/r/archlinux/comments/r7qt2n/how_are_my_nvidia_proprietary_drivers_supporting/">[comments]</a></span> |