pop-os / beta

Pop!_OS Beta
356 stars 19 forks source link

After unexpected update to kernel 5.15, no boot to that kernel (5.13 OK) #273

Closed juanejot closed 2 years ago

juanejot commented 2 years ago

How did you upgrade to 21.10? (Fresh install / Upgrade)

Upgraded from 21.04

Related Application and/or Package Version (run apt policy $PACKAGE NAME):

Unexpected upgrade to kernel 5.15.0-76051500, then BusyBox 1.30.1 & initramfs (what works with 5.13 is 0.140ubuntu6, dunno if 5.15 uses same)

Issue/Bug Description: Upon a regular cycle of sudo apt update && sudo apt full-upgrade, the 5.15 kernel was unexpectedly installed. Upon attempt to boot, it dropped me to BusyBox (uh oh, initramfs updates went wrong). Sure enough, the PARTUUID it was trying to use as root was not one that was on my system, once successfully booted to 5.13 & ls -al /dev/disk/by-uuid checked. EDIT: It did match the PARTUUID called up by cat /proc/cmdline while booted to 5.13-7620-generic, so that's likely a red herring; ie. root is not being found, but not exactly for that reason?

Steps to reproduce (if you know): As above

Expected behavior: Boot to 5.15, or at least that result when I type in uname -r

Other Notes: I am running Pop!_OS 21.10 Beta on a MacBookPro5,3 using version 0.3.1 of the OpenCore Legacy Patcher (based off of OpenCore 0.7.3). See update for notes on this. [UPDATE 11/20: This is likely unrelated, as comments closer to the bottom will point out the likely cause & potential solution.]

Meanwhile, everything works as expected* (so far) under 5.15 kernel, on separate 9700K/RX580 desktop machine with OpenCore 0.7.5 & Pop!_OS 21.10 beta installed on its own drive, separate from other OSes.

~(except, of course, for awaiting the update to Application Picker as in issue #243; the old-style one still eventually loads, but only after waiting to invoke it for at least 10 or so minutes. On the IC2Duo T9900/9400M/9600M GT system in this* issue, the Application Picker has always continued to work, as long as I can get through boot.)~

juanejot commented 2 years ago

Screenshot of message about the PARTUUID: IMG_7592 ~It occurs to me as possible that the evolving OpenLinuxBoot.efi and ext4_64.efi drivers for OpenCore Legacy Patcher may be somehow involved (see my comment on issue #222). The versions that come/work with the OpenCore 0.7.3 base of OpenCore Legacy Patcher 0.3.1 are different than the latest that come/work with OpenCore 0.7.5. But this may have nothing to do with it, as the whole bootloader setup worked fine with Pop!_OS 21.04 & 21.10 through kernel 5.13.0-7620-generic.~ UPDATE 11/20: While this bootloader configuration remains on my system, it seems more likely given the success listed way below with kernel 5.15.3, as opposed to 5.15.0 through 5.15.2, is unrelated to which bootloader I use.

juanejot commented 2 years ago

I do notice there are many fewer kernel modules for 5.15 than for 5.13, per cat /proc/modules in either 5.15's BusyBox vs entering the command in terminal in the completely booted 5.13. If there are any missing from the 5.15 group of modules that would help my system boot properly, that might point toward a solution.

[UPDATE 11/20: Apparently, BusyBox was only able to show what modules had loaded so far without a full boot, due to a SATA booting problem with kernels 5.15.0 through 5.15.2.]

Result for fully booted 5.13: rfcomm 81920 4 - Live 0x0000000000000000 cmac 16384 2 - Live 0x0000000000000000 algif_hash 16384 1 - Live 0x0000000000000000 algif_skcipher 16384 1 - Live 0x0000000000000000 af_alg 28672 6 algif_hash,algif_skcipher, Live 0x0000000000000000 bnep 28672 2 - Live 0x0000000000000000 snd_hda_codec_cirrus 20480 1 - Live 0x0000000000000000 snd_hda_codec_generic 81920 1 snd_hda_codec_cirrus, Live 0x0000000000000000 ledtrig_audio 16384 1 snd_hda_codec_generic, Live 0x0000000000000000 snd_hda_intel 53248 3 - Live 0x0000000000000000 snd_intel_dspcfg 28672 1 snd_hda_intel, Live 0x0000000000000000 snd_intel_sdw_acpi 20480 1 snd_intel_dspcfg, Live 0x0000000000000000 snd_hda_codec 147456 3 snd_hda_codec_cirrus,snd_hda_codec_generic,snd_hda_intel, Live 0x0000000000000000 snd_hda_core 94208 4 snd_hda_codec_cirrus,snd_hda_codec_generic,snd_hda_intel,snd_hda_codec, Live 0x0000000000000000 snd_hwdep 16384 1 snd_hda_codec, Live 0x0000000000000000 snd_pcm 118784 3 snd_hda_intel,snd_hda_codec,snd_hda_core, Live 0x0000000000000000 nvidia_uvm 36864 0 - Live 0x0000000000000000 (POE) wl 6455296 0 - Live 0x0000000000000000 (POE) coretemp 20480 0 - Live 0x0000000000000000 applesmc 20480 0 - Live 0x0000000000000000 joydev 28672 0 - Live 0x0000000000000000 snd_seq_midi 20480 0 - Live 0x0000000000000000 snd_seq_midi_event 16384 1 snd_seq_midi, Live 0x0000000000000000 kvm_intel 290816 0 - Live 0x0000000000000000 nls_iso8859_1 16384 1 - Live 0x0000000000000000 snd_rawmidi 36864 1 snd_seq_midi, Live 0x0000000000000000 kvm 872448 1 kvm_intel, Live 0x0000000000000000 btusb 61440 0 - Live 0x0000000000000000 uvcvideo 106496 0 - Live 0x0000000000000000 btrtl 24576 1 btusb, Live 0x0000000000000000 btbcm 16384 1 btusb, Live 0x0000000000000000 btintel 32768 1 btusb, Live 0x0000000000000000 cfg80211 892928 1 wl, Live 0x0000000000000000 snd_seq 73728 2 snd_seq_midi,snd_seq_midi_event, Live 0x0000000000000000 efi_pstore 16384 0 - Live 0x0000000000000000 bluetooth 663552 27 rfcomm,bnep,btusb,btrtl,btbcm,btintel, Live 0x0000000000000000 videobuf2_vmalloc 20480 1 uvcvideo, Live 0x0000000000000000 videobuf2_memops 20480 1 videobuf2_vmalloc, Live 0x0000000000000000 snd_seq_device 16384 3 snd_seq_midi,snd_rawmidi,snd_seq, Live 0x0000000000000000 snd_timer 40960 2 snd_pcm,snd_seq, Live 0x0000000000000000 videobuf2_v4l2 32768 1 uvcvideo, Live 0x0000000000000000 videobuf2_common 61440 4 uvcvideo,videobuf2_vmalloc,videobuf2_memops,videobuf2_v4l2, Live 0x0000000000000000 nvidia 10584064 59 nvidia_uvm, Live 0x0000000000000000 (POE) videodev 249856 3 uvcvideo,videobuf2_v4l2,videobuf2_common, Live 0x0000000000000000 ecdh_generic 16384 1 bluetooth, Live 0x0000000000000000 ecc 36864 1 ecdh_generic, Live 0x0000000000000000 bcm5974 24576 0 - Live 0x0000000000000000 snd 94208 15 snd_hda_codec_generic,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_rawmidi,snd_seq,snd_seq_device,snd_timer, Live 0x0000000000000000 input_leds 16384 0 - Live 0x0000000000000000 mc 57344 4 uvcvideo,videobuf2_v4l2,videobuf2_common,videodev, Live 0x0000000000000000 apple_mfi_fastcharge 20480 0 - Live 0x0000000000000000 soundcore 16384 1 snd, Live 0x0000000000000000 sbs 20480 0 - Live 0x0000000000000000 acpi_als 20480 1 - Live 0x0000000000000000 sbshc 16384 1 sbs, Live 0x0000000000000000 industrialio_triggered_buffer 16384 1 acpi_als, Live 0x0000000000000000 kfifo_buf 16384 1 industrialio_triggered_buffer, Live 0x0000000000000000 industrialio 81920 3 acpi_als,industrialio_triggered_buffer,kfifo_buf, Live 0x0000000000000000 apple_gmux 20480 0 - Live 0x0000000000000000 video 53248 1 apple_gmux, Live 0x0000000000000000 mac_hid 16384 0 - Live 0x0000000000000000 apple_bl 20480 1 apple_gmux, Live 0x0000000000000000 ip6t_REJECT 16384 1 - Live 0x0000000000000000 nf_reject_ipv6 20480 1 ip6t_REJECT, Live 0x0000000000000000 xt_hl 16384 22 - Live 0x0000000000000000 ip6_tables 32768 52 - Live 0x0000000000000000 ip6t_rt 20480 3 - Live 0x0000000000000000 ipt_REJECT 16384 1 - Live 0x0000000000000000 nf_reject_ipv4 16384 1 ipt_REJECT, Live 0x0000000000000000 xt_LOG 20480 10 - Live 0x0000000000000000 nf_log_syslog 20480 10 - Live 0x0000000000000000 nft_limit 16384 13 - Live 0x0000000000000000 xt_limit 16384 0 - Live 0x0000000000000000 xt_addrtype 16384 4 - Live 0x0000000000000000 xt_tcpudp 20480 18 - Live 0x0000000000000000 xt_conntrack 16384 16 - Live 0x0000000000000000 nf_conntrack 147456 1 xt_conntrack, Live 0x0000000000000000 nf_defrag_ipv6 24576 1 nf_conntrack, Live 0x0000000000000000 nf_defrag_ipv4 16384 1 nf_conntrack, Live 0x0000000000000000 nft_compat 20480 135 - Live 0x0000000000000000 nft_counter 16384 170 - Live 0x0000000000000000 sch_fq_codel 20480 3 - Live 0x0000000000000000 nf_tables 212992 389 nft_limit,nft_compat,nft_counter, Live 0x0000000000000000 nfnetlink 20480 2 nft_compat,nf_tables, Live 0x0000000000000000 msr 16384 0 - Live 0x0000000000000000 parport_pc 45056 0 - Live 0x0000000000000000 ppdev 24576 0 - Live 0x0000000000000000 lp 20480 0 - Live 0x0000000000000000 parport 65536 3 parport_pc,ppdev,lp, Live 0x0000000000000000 drm 561152 0 - Live 0x0000000000000000 ip_tables 32768 8 - Live 0x0000000000000000 x_tables 49152 12 ip6t_REJECT,xt_hl,ip6_tables,ip6t_rt,ipt_REJECT,xt_LOG,xt_limit,xt_addrtype,xt_tcpudp,xt_conntrack,nft_compat,ip_tables, Live 0x0000000000000000 autofs4 45056 2 - Live 0x0000000000000000 raid10 65536 0 - Live 0x0000000000000000 raid456 159744 0 - Live 0x0000000000000000 async_raid6_recov 24576 1 raid456, Live 0x0000000000000000 async_memcpy 20480 2 raid456,async_raid6_recov, Live 0x0000000000000000 async_pq 24576 2 raid456,async_raid6_recov, Live 0x0000000000000000 async_xor 20480 3 raid456,async_raid6_recov,async_pq, Live 0x0000000000000000 async_tx 20480 5 raid456,async_raid6_recov,async_memcpy,async_pq,async_xor, Live 0x0000000000000000 xor 24576 1 async_xor, Live 0x0000000000000000 raid6_pq 114688 3 raid456,async_raid6_recov,async_pq, Live 0x0000000000000000 libcrc32c 16384 3 nf_conntrack,nf_tables,raid456, Live 0x0000000000000000 raid1 49152 0 - Live 0x0000000000000000 raid0 24576 0 - Live 0x0000000000000000 multipath 20480 0 - Live 0x0000000000000000 linear 20480 0 - Live 0x0000000000000000 system76_io 16384 0 - Live 0x0000000000000000 (OE) wmi 32768 0 - Live 0x0000000000000000 system76_acpi 16384 0 - Live 0x0000000000000000 (OE) hid_apple 16384 0 - Live 0x0000000000000000 uas 28672 0 - Live 0x0000000000000000 usb_storage 73728 1 uas, Live 0x0000000000000000 hid_appleir 16384 0 - Live 0x0000000000000000 hid_generic 16384 0 - Live 0x0000000000000000 usbhid 61440 0 - Live 0x0000000000000000 hid 135168 4 hid_apple,hid_appleir,hid_generic,usbhid, Live 0x0000000000000000 firewire_ohci 45056 0 - Live 0x0000000000000000 firewire_core 69632 1 firewire_ohci, Live 0x0000000000000000 crc_itu_t 16384 1 firewire_core, Live 0x0000000000000000 ahci 40960 2 - Live 0x0000000000000000 forcedeth 73728 0 - Live 0x0000000000000000 libahci 36864 1 ahci, Live 0x0000000000000000 i2c_nforce2 20480 0 - Live 0x0000000000000000

Result for 5.15's BusyBox (just one screen; dunno if it would list more for a full boot): 5 15 bbmods

timatinsipid commented 2 years ago

Am also left with an unusable system with 5.15 kernel. After a few minutes I end up at the gdm logon screen, but with no accounts listed to login to. dropping to console and system still seems to be stuck on boot

juanejot commented 2 years ago

@timatinsipid, if you are able to successfully select another kernel to boot off of (by hitting spacebar during early boot and selecting "Pop_OS-oldkern.conf" in a fairly vanilla systemd-boot bootloader, by hitting spacebar and selecting the 5.13.0-7620 kernel in my OpenCore-based bootloader that precedes and seems to overrule systemd-boot), does the 5.13.0-7620 kernel get through login and to the desktop correctly for you? If you are not able to make any other boot selection during early boot except for the new 5.15 kernel that doesn't work for you, the beta developers should know that too. Thanks for your input, and hope a solution is found for your system, too!

timjordanatteck commented 2 years ago

@timatinsipid, if you are able to successfully select another kernel to boot off of (by hitting spacebar during early boot and selecting "Pop_OS-oldkern.conf" in a fairly vanilla systemd-boot bootloader, by hitting spacebar and selecting the 5.13.0-7620 kernel in my OpenCore-based bootloader that precedes and seems to overrule systemd-boot), does the 5.13.0-7620 kernel get through login and to the desktop correctly for you? If you are not able to make any other boot selection during early boot except for the new 5.15 kernel that doesn't work for you, the beta developers should know that too. Thanks for your input, and hope a solution is found for your system, too!

Yes I am able to successfully boot the old kernel and everything works again, just not the 5.15 one

juanejot commented 2 years ago

On a whim, I tried sudo apt reinstall linux-image-5.15.0-76051500-generic just in case I had gotten a corrupted copy, or efistub or initramfs-tools that had been automatically invoked as part of the upgrade had processed incorrectly. I can confirm that I got exactly the same result.

juanejot commented 2 years ago

On the off chance that the linux--5.13.0-21-generic and -hwe-20.04-edge updates of this morning (probably from Canonical, but maybe being leveraged by System76 for 21.10 beta issues?) might address this issue, I installed when offered. No effect; same behavior with the new EFI option generated (kernel panic) and with 5.15 (eventually drop to BusyBox, claiming not to find the boot kernel that's right where it expects & other kernels have found). Booting to 5.13.0-7620 still works.

juanejot commented 2 years ago

More (unfortunately fruitless) attempts at changing what I can on my end, in hopes of maybe getting kernel 5.15 to boot to a UI other than BusyBox: On the off chance that it's OpenCore Legacy Patcher 0.3.1 (based off of OpenCore 0.7.3) as a bootloader rather than systemd-boot that's standing in the way, I manually updated OC's config.plist & various driver, kernel extension & resource files & tools to their OC 0.7.5 counterparts, reasoning that my separate 9700K/RX580 rig with OC 0.7.5 & Pop!_OS 21.10 beta (admittedly running on its own drive, unlike this system on which it's on a partition of the drive shared with macOS) is running great with no trouble booting to any currently installed Linux kernel.

While the OC 0.7.5 files edited & replaced into OC Legacy Patcher 0.3.1 worked fine to boot macOS, as well as to boot Pop!_OS to kernel 5.13 again; the kernel 5.15 boot issue remains unresolved. This was whether I had sudo dpkg-reconfigured any of the 5.15 packages or not, whether I had update-initramfsed or not, indeed whether I had further edited OC's config.plist to let any OS but macOS see what exact kind of hardware it was really running on (not just hardware of an era the installed version of macOS would prefer; change verified in Linux by sudo dmidecode before, after, and upon restoration of default). For the record, this change in hardware visibility has never appreciably affected the operation of any distro of Linux I've run on either machine, but I was trying everything. The CPU & GPUs in question are never obscured from the OS; details on how available upon request, and/or from OC documentation.

None of this tinkering had any effect; at least as of right now, the kernel 5.15.0-76051500.202110312130[I meant to include the rest of the version number, but the tildes made it erroneously strikethrough part of it! 🤣] files seem not to like my old IC2D T9900/GeForce 9400M/9600M GT MacBookPro5,3. No previous kernel through 5.13.0-7620 (which I am currently running on it as I write this) has ever had a problem booting & running the machine.

The next scorched earth step might be completely removing any bootloader method to boot macOS at all from the EFI partition, hoping systemd-boot will auto-invoke with OC out of its way, to boot to any of the installed Linux kernels. Hmm… I'll think on that, but meanwhile I'll try to keep my system intact as 21.10 works its way through the beta process. Please let me know if that's a diagnostic step you'd like me to take.

Thanks!

juanejot commented 2 years ago

Upon today's update to plymouth-theme-pop-basic 2.0.1, system76-power 1.1.19, initramfs-tools 0.140ubuntu6, hicolor-icon-theme 0.17-2, gnome-menus 3.36.0-1ubuntu1, pop-cosmic 0.1.0, libglib2.0-0 2.68.4-1ubuntu1, dbus 1.12-20-2ubuntu2, mailcap 3.69ubuntu1 & deskop-file-utils 0.26-1ubuntu (whew!),

the automatically-invoked update-initramfs did not create an "EFI" selection that only led to a text-only kernel panic, but the inability to boot to kernel 5.15 persists (5.13 continues to boot just fine).

juanejot commented 2 years ago

Today's (11/15) update to kernel 5.15.2(etc) did not improve matters, in fact (as expected) bumping 5.13.0-7620 from its "oldkern.conf" spot; luckily having ext4_x64.efi running meant I could still select it & am successfully booted to it right now. ~I haven't yet tried to sudo apt autoremove, but it wouldn't remove a running kernel, would it?~ (Running sudo apt autoremove while booted to 5.13.0-7620 reveals nothing to remove; phew!)

See attached photo for result of cat /proc/modules in BusyBox, noting result (at bottom) of uname -r. 5670F682-EF4A-43BE-92F4-38AC38D3A0BF

Luckily, every update including kernel 5.15.2(etc), Pop!_Shop, etc. seem to continue to work great on my 9700K/RX580 rig. Just not the newest kernel this little old IC2D T9900/GeForce 9600M GT/9400 M lappy… Hopefully it can be made to run on my little portable rig by Pop!_OS 21.10 final.

juanejot commented 2 years ago

I happened to install qemu/kvm/virt-manager on this machine, and inside a Pop!_OS 21.10 beta VM (into which was configured the same Penryn class of CPU), kernel 5.15.2 is able to be upgraded to & booted to. Unfortunately, I don't see & therefore can't access the configuration of, an EFI partition (none shows up to either lsblk or df -h). Also, graphics apparently come from llvm 12.0.1, which is neither the nouveau native to, nor the nvidia-340 I've been able to install to the host machine. No idea what the performance is like, but that's not the point; I can't really check whether video drivers (even the native one) affect my machine (the host)'s boot to GUI.

jacobgkau commented 2 years ago

I don't see ... an EFI partition

Yes, virtual machines will typically use legacy BIOS/CSM mode.

nor the nvidia-340 I've been able to install to the host machine.

I would guess that the outdated NVIDIA driver is related to the issue, and this issue may be related to https://github.com/pop-os/beta/issues/270. Does the host boot using nouveau if that driver is not installed? (I assume the NVIDIA GPU is no longer supported by the current versions of NVIDIA's proprietary driver?)

juanejot commented 2 years ago

@jacobgkau Thanks for your reply. The machine (host) boots only far enough under nouveau to see nouveau’s characteristic purple “squiggle” artifacting (at least on my unit, YMMV) that has only happened at boot since at least 21.04 final (where it works)… but then in 21.10 beta with 5.15.x kernel, it then hangs black for a while, gets a hopeful grey screen that never actually gets to the user picker, and instead dumps to BusyBox.

juanejot commented 2 years ago

I’ve just tried to boot (not install) from both new “2” ISOs (Intel & Nvidia), which both run kernel 5.15. Intel boots fine using nouveau for graphics (Settings/About says “NV96/NVAC”) and Nvidia uses llvm-pipe (llvm 12.0.1). I booted to both of these from INSIDE the OpenCore Legacy Patcher bootpicker, not by bypassing it with “Option” key at boot time (which would have been kind of like F12/F7/F3/etc. on a non-Apple system). So kernel 5.15 works directly on the metal of my machine; it just doesn’t work as upgraded on my main boot SSD (shared with macOS). I’d dither over whether to wipe & reinstall, but the Install Pop!_OS 21.10 app doesn’t even seem to see my drive, nor does GParted. Weird; it used the bootloader on the EFI partition of that drive, but now can’t see it. Kinda like BusyBox claiming the drive it booted from to a CLI, wasn’t there. Update: this inability to see the internal SATA drive persists when booted via Option (ie. not using OpenCore Legacy Patcher as a bootloader).

juanejot commented 2 years ago

Since USB booting works but SATA (II, not III, on this generation of machine) appears not to show up for kernel 5.15, I did some looking around. Hmm: https://lkml.kernel.org/lkml/8735nv880m.wl-maz@kernel.org/T/

mdpetters commented 2 years ago

Updated 11/17 to 21.10 beta. Kernel 5.15.2 does not boot on a System 76 Meerkat, all Intel: Intel® Core™ i7-8559U CPU, Mesa Intel® Iris(R) Plus Graphics 655. The old kernel 5.13 boots fine. The boot is stuck on the System 76 splash boot screen. No on-screen error messages, no busybox (even after 30 min wait), no kernel logs of failed boot attempt (after booting into old kernel). The only indication of an error is that the launch keyboard stops cycling colors directly after engaging with the kernel. Booting without a keyboard made no difference. No idea how to further troubleshoot in order to provide more helpful feedback.

juanejot commented 2 years ago

@mdpetters I have to admit I don't know all the Meerkat generations; is your boot drive SATA or NVMe? The link from kernel.org (which I admit to not having read in depth, as much of it would be greek to me) seems to indicate trouble with at least some SATA implementations for kernel 5.15, fixes for which may be possible to backport from 5.16. If NVMe, not sure as my only other system with Pop!_OS 21.10 beta is running kernel 5.15.2 on NVMe trouble-free. But yeah, especially on their own hardware (and it would be great for the varied hardware of other Pop!_OS enthusiasts!), I hope System76 is able to find a solution. Thanks for your addition to this issue!

mdpetters commented 2 years ago

It's booting of a 2 TB NVMe Seq Read: 3500MB/s, Seq Write: 3300MB/s (2019 state of the art). So should not be SATA related.

juanejot commented 2 years ago

Right on. So perhaps a different issue than mine (but maybe still related). In any event, no less urgent. Hope System76 can offer up a solution!

jacobgkau commented 2 years ago

It's booting of a 2 TB NVMe Seq Read: 3500MB/s, Seq Write: 3300MB/s (2019 state of the art). So should not be SATA related.

Thank you for trying the beta. I'm setting up a meer4 in our lab now to see if I can recreate this.

jacobgkau commented 2 years ago

@mdpetters I'm seeing this on our lab unit as well. I've opened https://github.com/pop-os/beta/issues/307 to track the meer4 issue. Rest assured this would be blocking for the final release of 21.10. If you have any further details to add or make any discoveries about the issue, feel free to add them to that issue page!

We'll keep this issue open separately since it sounds like @juanejot's issue is something else, although that one may not be something we can prioritize as heavily since it is affecting third-party hardware, non-default bootloader, etc.

juanejot commented 2 years ago

@jacobgkau Priority to System76’s own hardware is understood. Do you think that researching backporting whatever kernel 5.16 addresses with SATA difficulties into System76’s iteration of 5.15.x will make it into a post-release update of 21.10 final? In the meantime, will any new 21.10 features/security updates remain available to the 5.13.0-7620 kernel? Thanks!

juanejot commented 2 years ago

Not absolutely sure this post means the backport to deal with SATA configuration has already been handled in kernel.org's vanilla 5.15.3 or not:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=7d96493bd58569f62fb813c33ebdb57c0e915d55

I tried compiling the kernel myself based off of the .config for 5.13.0-7620, but ran into some difficulties with .pem files for x509 not being available (I'd bet they're understandably internal in some way to System76 & its kernel efforts).

juanejot commented 2 years ago

POTENTIAL RESOLUTION: Downloading Ubuntu's generic mainline kernel 5.15.3 from https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.15.3/ (specifically, the unsinged generic image, generic modules, generic headers, and just for good measure, the "all" headers; but none of the "lowlatency" selections) and then installing them with sudo dpkg -i linux*5.15.3*.deb booted just fine, and uname -r returned "5.15.3-051503-generic".

I've noticed no unexpected behavior so far after a good half hour of boot & reboot time (for testing, not yet due to a crash or hang). There does seem to be the addition of a couple of seconds of timeout on boot, which is my understanding of precisely the kind of thing that 5.15.3 was meant to build in for root validation of SATA drives, for which 5.15.0 through 5.15.2 had somehow not been providing enough time.

Not closing this issue yet, as I assume System76 will want to apply their own tweaks to a 5.15.3 (or later) kernel, to integrate it completely with the rest of their system. But this at least looks like it gets 5.15.x back to SATA-booting functionality!

jacobgkau commented 2 years ago

@juanejot That is good news. This will hopefully by fixed by https://github.com/pop-os/linux/pull/81, which will update the kernel to 5.15.4.

juanejot commented 2 years ago

Just updated to kernel 5.15.4, booted fine (phew!) & accepted the sudo apt autoremove suggestion to get rid of 5.13.0-7620. Working well. Thanks, @jacobgkau, @jackpot51 & the rest of System76!