Anything show up in /var/log/kern.log etc after restarting following the failed start (which would confirm whether the kernal ever booted)? Do you get BIOS beeps when the computer starts to diagnose whether it's even starting up at all, or can you connect a beeper to cause it to do so?
I know. He is eccentric and fixated on seeing Israel as the underdog.
Nobody is perfect as they say but I have been watching his stuff this afternoon and his concerns seem pretty valid regardless of what you think of him, IDC if he is a pro-Isreal boomer or whatever, The ideological capture of Linux is disturbing, I hope his Distro comes good and encourages more to start pushing back.
I'd say back that bitch up immediately. If you still can.
I'm still confused as to what the real benefit to UEFI actually was supposed to be since after implementation the complexity went way the hell up (unfucking an EFI partition mess being the prime example), since it added on a stack of features you see on machine loaders for crazy arches like POWER (since POWER7 that arch can run both BE and LE code together, you can partition the machine to simul-boot instead of dual boot----but I don't think the PC will ever see mobos that can do simulboot with hardware-based timeshare). my only guess was the firmware swapping on integrated boards you see now makes mobomakers happier
They also create some really weird glitches when they do things that aren't properly supported. For example my server has this shit:
~$ efibootmgr
** Warning ** : Boot000e is not UEFI Spec compliant (lowercase hex in name)
** Warning ** : Boot000f is not UEFI Spec compliant (lowercase hex in name)
** Warning ** : please recreate these using efibootmgr to remove this warning.
BootCurrent: 0000
Timeout: 1 seconds
BootOrder: 0000,0010,000B,000E,000F
Boot0000* debian
Boot000B* UEFI: Built-in EFI Shell
Boot000E WDC WDS100T2G0A-00JH30
Boot000F SanDisk
Boot000e_BbsIndex*
Boot000f_BbsIndex*
Boot0010* PLDS DVD-RW DH16ACSH
Boot0010_BbsIndex*i've never read any backgrounders on UEFI and what Intel was thinking, but the complexity sort of mimics a portion of what you see on mainframes and on POWER, which has real simulboot/run capability. On a mainframe you can slice the computer up into LPARs (logical partitions) and then assign shared/exclusive I/O channels on each LPAR, so in your head you can pretend it's sorta like a hardware rendition of Proxmox but you're timesharing all physical resources at this level, there's no software virtualization going on at this level. And to make that work you have to have OSes that respect the hell out of the HW hypervisor, so no RTOS is theoretically possible, but the tradeoff is you get a real "physical" barrier you can put danger code in and prod code on the same machine and the piss streams will never cross. The other tradeoff is the boot complexity is intense (that's the part that came to the PC with UEFI). So... some of this scaffolding is on the PC, but not all of it.
Having real firmware was a nice idea. I remember, at one point around 2002 or so, being annoyed that I could only have four primary partitions so couldn't run more than a few separate Windows/DOS installs on the same machine alongside my Linux install without using one of those bizarre and dangerous DOS boot managers that would completely switch around your partition table like BootMagic if you wanted to boot to more DOS partitions than normal MBR booting would allow*.
200 companies * 5+ pajeets each = thousands of Indians have shed leprosy bacilli all over the world's UEFI implementations and approximately 0.01% of their code is ever rationalized or contributed back to the original project to be critiqued and have the lesions worked out. If any code is ever contributed back, that's irrelevant, because none of the companies 'maintaining' UEFI implementations will ever rebase their own version that cost them multiple pajeetyears to add an ugly splash screen on the current version of TianoCore.
Gentoo is definitely not for everyone and I don't know or want to know about the maintainers' political proclivities, but as far as actual distro maintenance goes, they're top-notch. Sober and sensible and help keep the non-Systemd ecosystem alive through OpenRC (which also benefits other distros like Alpine) and separated components like elogind to force a bit more of the UNIX philosophy onto the less avoidable Systemd aspects.
The only thing Gentoo needs is more package maintainers. Way too much shit kept back because package maintainers can't keep up. I've written a few myself at times to keep things updated
What filesystem? Ext4's lazy init (which is usually the default) clashes hard with some nvme firmware.
what would be the preferred filesystem for NVMe drives then? ext5 isn't out yet
You can use anything with a well behaved nvme drive. If your drive is made of Chinesium then I dunno throw btrfs on it and pray I guess.
Looks like you can get the 'old' behavior back with:
mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0
BTFS/JFS, same issue is present on NTFS and XFS. Seems to be a NVME controller bug as it is showing the controller is crashing (Removing after probe failure status: -19). See this kernel bug (Unresolved since 2017). I've got a Samsung controller which is known to cause issues.
nvme_core.default_ps_max_latency_us=0
Last SSD I had that failed was a regular SATA, and that was ~10 years ago .. no errors in the logs though.