A big part of learning Linux is screwing up computers and starting over.
-
My crippled kernel count is around 6, how about yours?
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.
-
My crippled kernel count is around 6, how about yours?
I've never in 15 years of Linux use and tinker have ever screwed a kernel. And I compiled LFS once.
-
My crippled kernel count is around 6, how about yours?
Both, to the point it doesn't boot, and just tweaking enough bugs that it's easier to jist start over.
-
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 will fail to execute and the kernel will loop forever.
-
Both, to the point it doesn't boot, and just tweaking enough bugs that it's easier to jist start over.
Reply fail?
-
My crippled kernel count is around 6, how about yours?
as a kid, when i was learning linux it was slackware on a massive stack of floppies. and this was before plug and play mind you, there were all sorts of things DOS did one way but linux expected another way.
Well i only had the one computer. So you would get so far through a linux install (many hours, overnight was common) and run into a real issue such as how do i properly terminate the scsi chains differently than dos expected so i could get it to see the discs, or what jumpers did you have to move around to free up irq's so that ionic could see the modem.
well if the hastily printed docs i had amassed didn't cover it, no choice but to re install dos and telemate and hope for help on usenet. which always did come. then you print that and cross your fingers and hope it worked.
I don't recall exactly how long it took me to get slackware on that old family 286 but the joy when i finally had it all working.
then i learned linux had no dialup scripts yet for slip/ppp yet so i had to reinstall dos to go learn bash so i could teach the thing how to connect to my isp, since it was a little different for all of them at that time.
as an autistic kid this was my secondary special interest and i loved every second of all of this. it prepared me for a fruitful if frustrating career as a very full stack software engineer!
-
My crippled kernel count is around 6, how about yours?
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.
-
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 will 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 -
I’m not sure I’ve ever actually killed a system, I’ve booted from UEFI shell manually just to recover systems. Back when I was using arch id just chroot into the system from a flash drive and fix whatever ¯\_(ツ)_/¯
And not somehow break it more?
Impressive! -
My crippled kernel count is around 6, how about yours?
May I introduce you to my lord and saviour NixOS?
-
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.
-
The "starting over" part is what made it take so long for linux to "stick" with me.
Once it became "restore from an earlier image", it was a game changer!
Every time I install or configure anything, it's done via CLI and added to a script. Makes setup a breeze.
-
My crippled kernel count is around 6, how about yours?
Never the kernel but just about every time I touch /etc/fstab I fuck something up. I've done that a lot....
-
My crippled kernel count is around 6, how about yours?
It's even better if your only internet connection is that computer you broke.
-
I get mine set up how I want then create an HD image that I run in a VM for fucking with.
-
My crippled kernel count is around 6, how about yours?
.... So what should I try Linux again?
-
My crippled kernel count is around 6, how about yours?
Maybe 1 or 2 back when things were less stable, but any time I have used Linux in the past 7 years or so, and particularly since I started using Debian as my primary OS, I haven't had any problems outside of trying to get some windows applications to emulate correctly, and one time when I echo'd into sources.list with > instead of >>.
-
It's even better if your only internet connection is that computer you broke.
Great incentive to learn even faster
-
.... So what should I try Linux again?
You mean why? Because you're using your bare machine, you can use it as you wish. No nanny software limiting the fun or productivity
-
Great incentive to learn even faster
And enforces the value of installing documentation and source packages
