My crippled kernel count is around 6, how about yours?
Not any moreso than learning any other OS. I’d just argue that it’s the case if you’re averse to research, reading, listening, watching, or just generally learning from others… or if you’re delving into unknown territory
Personally, i’m a learn-by-doing type of lady, so I’ve fucked up my share of devices (I’m allergic to reading unless it’s fiction), but I have yet to mess around in the kernel (it’s on my todo list, for my LFS build which is TBD)
Nearly always it’s been during the live USB install of a dual-boot that a distro messes with the grub or installed grub to the USB disk itself. The fault lies with me because I’m almost blindly trusting the distro, but also with the distro for lacking proper yet succinct documentation during the install or configuration of partitions.
I haven’t majorly fucked up any recent systems (almost botched the steam deck once or twice but nothing that required a reinstall), but god 10 years ago I probably reset my arch dual boot like five times lmao
Both, to the point it doesn’t boot, and just tweaking enough bugs that it’s easier to jist start over.
Reply fail?
Uhm, zero? With ten years of using Linux? What did you do to fuck up the damn kernel? o_O
It can be done if you mess with the initramfs.
The kernel starts everything else by unpacking an archive containing a minimal environment to set stuff up for later. Such as loading needed kernel modules, decrypting your drive, etc. It then launches, by default, the /init program (mines a shell script).
That program is PID 1. If it dies, your kernel will panic.
After it finishes setup, it execs your actual /sbin/init. These means it dies, and that program (systemd, openrc, dinit, runit, etc) becomes PID 1. If an issue happens, both could fail to execute and the kernel will loop forever.
Thank you for explanation :) I suspected something like that - mess up with some internals, you do have a chance to bring the thing down. Which is why I always have a bootable usb around before doing anything risky
Two. The first time I had nvidia related issues with nobara, so I removed nvidia drivers for reinstallation… And couldn’t figure out how to get them back. The second time I had used mint for long enough that I felt confident enough to nuke windows partition. I used gparted and nuked the whole disk instead.
Not counting the times I tried fedora and it killed itself with the first updates and then with multimedia codecs.
i broke debian on my plex server and said fuck it and migrated to endeavor because im more familiar with arch
I tried to use dd with too much hubris once. I had to restore from backups (which ironically, I had made with dd). I’m usually overly cautious, but I was in a hurry.
I did this one a few weeks ago lmao. You think once would be enough. But I am a truly special being.
Making errors and analysing them to figure out what went wrong and why is a huge part of learning. You can only learn so much from theory, some things can be learned best by trial and error and the experience gained from it.
When I started with Linux I did choose to use Gentoo Linux because it was the most complex and complicated option, so I had the most opportunities to learn something by ducking up!
I am very happy I am doing this on a ProxMox machine. So fast to flip them up again
So, when you say crippled kernel, do you actually mean you tweaked the kernel params/build to the point that it failed to boot? Or do you just mean you messed up some package config to the point that the normal boot sequence didn’t get you to a place you knew how to recover from and need to reinstall from scratch?
I think I’m past the point where I need to do a full reinstall to recover from my mistakes. As long as I get a shell, I can usually undo whatever I did. I have btrfs+timeshift also set up, but I’ve never had to use it.
1
Another big part is learning how to set it up in a way that it’s functional and productive the first time and then STOP FUCKING WITH IT.
😂 My gosh this hits home. If only I could stop tweaking. It’s always just this one little thing. Then another and on until it’s so fucked I don’t even know where to begin. But it’s magical when she works.
I get mine set up how I want then create an HD image that I run in a VM for fucking with.
That also sounds like a good way to stop learning!
you can either have a system to learn on, or a stable system to work on.
Not quite. But sorta, yeah.
Learning to “not fuck with it” or ways to do so and rollback are valid lessons themselves.
Being able to segregate “production” and “development” environments is very valuable.
Being able to segregate “production” and “development” environments is very valuable.
This is a best practice that pretty much everyone, eventually, discovers on their own.
I used to have a side system with /home on its own partition precisely to learn different distros and setups. It makes it much easier having a partition which is retained.
These days, qemu is your friend for playing around with random Linux stuff.
May I introduce you to my lord and saviour NixOS?
Knock Knock Knock.
We (Jehovah’s Witness) would like to know if you had a minute, so we could come inside, and talk to you about OUR Lord and Savior… Linux Mint.
Sure, ok, that’s still my daily driver, it’s incredibly stable (and no, it’s not fucking outdated), but other than that it doesn’t help so much against accidentally borking your system.
So in this context, I’m recommending @sockpuppetsociety@lemm.ee NixOS.
