Tinkering is all fun and games, until it’s 4 am, your vision is blurry, and thinking straight becomes a non-option, or perhaps you just get overly confident, type something and press enter before considering the consequences of the command you’re about to execute… And then all you have is a kernel panic and one thought bouncing in your head: “damn, what did I expect to happen?”.
Off the top of my head I remember 2 of those. Both happened a while ago, so I don’t remember all the details, unfortunately.
For the warmup, removing PAM. I was trying to convert my artix install to a regular arch without reinstalling everything. Should be kinda simple: change repos, install systemd, uninstall dinit and it’s units, profit. Yet after doing just that I was left with some PAM errors… So, I Rdd-ed libpam instead of just using --overwrite. Needless to say, I had to search for live usb yet again.
And the one at least I find quite funny. After about a year of using arch I was considering myself a confident enough user, and it so happened that I wanted to install smth that was packaged for debian. A reasonable person would, perhaps, write a pkgbuild that would unpack the .deb and install it’s contents properly along with all the necessary dependencies. But not me, I installed dpkg. The package refused to either work or install complaining that the version of glibc was incorrect… So, I installed glibc from Debian’s repos. After a few seconds my poor PC probably spent staring in disbelief at the sheer stupidity of the meatbag behind the keyboard, I was met with a reboot, a kernel panic, and a need to find another PC to flash an archiso to a flash drive ('cause ofc I didn’t have one at the time).
Anyways, what are your stories?
Not me, but one I saw… dude used chmod to lock down permissions across the board… including root… including the chmod command.
“What do I do?”
🤔
“Re-install?”
There’s got to be other tools though that could change the file permissions on chmod, right? Though I suppose you’d need permission to use them and/or download them.
You can dump the permissions from the working system and restore them. Quite useful when working with archives that don’t support those attributes or when you run random stuff from the web 😁
You could boot on an USB, mount the filesystem and change the permissions. But if the dude changed a whole lot of permissions, reinstalling might be the smart thing to do…
Changed it all to 000. ಠ_ಠ
@jordanlund @fl42v I *think* this one could be recoverable if they had a terminal still active by using the dynamic loader to call chmod — or by booting from a liveCD and chmodding from there.
That’d likely get you to a ‘working’ state quickly, but it’d take forever to get back to a ‘sane’ state with correct permissions on everything.
When Ubuntu 16.04 had just been released, I tried upgrading my 14.04, the whole system broke and I had to install another os (Manjaro won).
That day I learned Ubuntu too can be a bit stupid.
Linux Mint: removed all taskbars from the desktop. I was hoping it would just allow me to reset them to the default. But in reality, it breaks the GUI and it’s very hard to reset from the GUI. Suddenly my keystrokes weren’t being detected and I couldn’t open up applications with any sort of regularity. After a lot of dicking around, I got the terminal working so I could reset Cinnamon.
It’s not the worst way I’ve broken a machine. But it was one of the most annoying.
One thing I learnt a while back is that if you break your GUI you can always use Ctrl+Alt+F<1-9> to go to different terminals to try to solve it. Worst case scenario I would do something like mv .config .config.bkp and sudo systemctl restart that should hopefully get you back to default settings on the UI.
Source: been there, done that. Not exactly your error but similar enough.
Somehow convinced a person to run sudo chmod -x /usr/bin/*
I don’t remember the exact command so it could be a bit different but it did the job. It was a fun evening.
Daaem, I guess the poor dude at the receiving end did not consider it particularly fun. Well, at least they had sbin working, so probably possible to recover without a live cd. Huh, guess who’s now spinning up a VM to check it out 🤣
Checked it out: on arch that results in inability to run tty on reboot, then you’re dropped into initramfs’s rescue shell where you can simply +x new_root’s /usr/bin/* and be back up and running
Before installing Arch on a USB flash drive, I disabled ext4 journaling in order to reduce disk reads and writes, being fully aware of the implications (file corruption after unexpected power loss). I was confident that I would never have to pull the plug or the drive without issuing a normal shutdown first. Unfortunately, there was one possibility I hadn’t considered: sometimes, there’s that one service preventing your PC from turning off, and at that stage there’s no way to kill it (besides waiting for systemd to time out, but I was impatient).
So I pulled the plug. The system booted fine, but was missing some binaries. Unfortunately, I couldn’t use pacman to restore them because some of the files it relied on were also destroyed.
This was not the last time I went through this. Luckily I’ve learned my lesson by now
