Tip: don't put important things in just 1 place.

That aside!

Years ago when I first tried out Linux (I was around the age of 10), I didn't really pay much attention while installing Linux back then, so I wiped my entire data disk D:...

I was setting up fail2ban on an sftp server at work.

Guess who got admin permanently banned from that machine.

chmod'd all my home directory's files and folders recursively. First to 600, which prevented me from listing any folders, then to 700, which broke a few programs, then to 755, which broke ssh.

• apt something that ended up removing sudo. No more admin rights.
• used rsync to backup pretty much everything in / , with remove source option...
• find with -delete option miss positioned. It deleted stuff before finding matching pattern
• chown / chmod on /bin and/or /usr/bin
• Removed everything in /etc

The Arch installation tutorial I followed originally advised using LVM to have separate root and user logical volumes. However, after some time my root volume started getting full, so I figured I would take 10GB off of my home volume and add it to the root one. Simple, right?

It turns out that lvreduce --size 10G volgroup0/lv_home doesn't reduce the size by 10GB, it sets the absolute size to 10GB, and since I had way more than 10GB in that volume, it corrupted my entire system.

There was a warning message, but it seems my past years of Windows use still have me trained to reflexively ignore dire warnings, and so I did it anyway.

Since then I have learned enough to know that I really don't do anything with LVM, nor do I see much benefit to separate root/home partitions for desktop Linux use, so I reinstalled my system without LVM the next time around. This is, to date, the first and only time I have irreparably broken my Linux install.

Can't remember exactly what happened but it involved changing permissions on /bin /sbin and similar. You know for security ...

In the end I didn't have permissions to run chmod, su or sudo

Fortunately there is little that can't be fixed by booting from a live image.

Not me but a colleague of mine wrote a bash script that had something like this and ran it on a server:

FOO="/home/bar"

... Many lines later ...

rm -rf $FOOT/*

Reminder that bash will resolve uninitiated variables to the empty string.

Luckily he halted the process after it had only nuked /boot and /bin. If it had gotten to /var and the mounted data storage within, we would have been in trouble

My buddy was in a class doing a programming test. It was a couple minutes until turn in time, so he went to zip up the source files. He had already ran the appropriate zip command previously, so he pressed up three times and then enter. It appears he had miscalculated, because the command that ran was rm *.c. There were no backups.

I just finished doing a fresh install this morning, because my wifi card wasn't working. It honestly needed to be done anyway because I was out-of date, but the wifi card finally got me to back-up all my data and do it.

Fresh install, and wifi still won't even toggle-on. Was about to look for manual install of the driver, and so on and so forth... and then I noticed my folly

Fucking keyboard has a toggle switch to turn the wifi off. Not the worst and glad I didn't pull my hair out over it, but damn... felt pretty dumb this morning

For this very reason, I have aliased rm -rf with trash-cli

dir="$(something that ultimately resolved to "")"

rm -r $dir/*

on a company server

I also once completely destroyed the data in a db that wasn't backed up for that same company while trying to restore from a dump (which was deleted as part of the script i was running).

Luckily both of these mistakes happened on staging servers so no one really cared. (prod is backed up though so if i did it there, not that i have access to prod, it also wouldn't be catastrophic)

$ grub-mkconfig -o /boot/grub/grub.conf

Thaaat... took me a stupid amount of time to fix.

I have a story that most of here might have faced. I ran dd on my external drive instead of my usb stick to create an iso. 1.8TB of data poof.

I once just uninstalled sudo and replaced it with doas. Turns out, the shutdown process needs sudo and a lot more. So I am still using my system since then, without shutting down.

No joking, I use Fedora Atomic and can not break my system... unless you mess up your dotfiles, and a lot more.

I also put a drive into my /etc/fstab once without the nofail argument.

No idea why that is not set by default, but when removing that drive my system couldnt boot and I exited to a very scary dracut shell.

Was trying to get corectrl configured and I was blindly copying text to paste into config files.

Next thing I know, I can't get my system to boot up again. 🤣

Time to reinstall. Again. 😅

Let a narcisist bipolar family member onto my home server for phaseI. For phaseII I granted too much access in sudo because I was busy. Fast forward a year or two and a downswing triggers the victim rage and he attempts to wreck my server after a minor argument -- would have, too, if I wasn't keenly aware of a conversation he had a few weeks before where he detailed "how to fuck with someone horribly" to a peer and I used that recollection to reverse the damage. It was a lucky thing, and 25 years on I have better security and backup processes.

I still regret that. #family, right?

Typed "rm -r" in "/home/myuser" instead of "/home/myuser/Documents/ThingINoLongerNeed"

Used gparted to wipe and format the device mounted at "/" instead of the external drive I meant to reformat. I've done this one TWO WHOLE TIMES in my life, three if you count wiping a device that was mounted at "/home/myuser/MyTwoTBDrive4DocsPicsMusicGamesEtc".

I once spent a month automating the production of repositories for each kernel version supported on our HPC and rested every step exhaustively in isolation.

When I was satisfied I ran it with root permissions and hosed the VMs it was running on because a recursive chmod evaluated to /.

Oops.

1. Have Nvidia card
2. Change the driver to see if I can fix a weird graphical issue I was having.
3. Rebooted computer and got stuck in boot loop because there was an error with the driver.

Wanted to customize GRUB and tried the GUI program. I wanted it to boot without delays unless a key is being held, and also add a "Shutdown" option (GRUB script halt), in case I open the laptop and didn't want it turned on. The edits looked alright in GRUB Customizer but I should not have made them both at once, because it made "Shutdown" the default option somehow, so the OS would never boot and holding none of the special keys worked. I failed to update or reinstall GRUB using a live USB and ended up having to reinstall the entire distro.

I've deleted my DE a couple of times from not reading the "The following packages will be REMOVED"-list.

Run sudo apt dist-upgrade -y right after an upgrade to the Kubuntu 24.04 beta on a semi production system.

This is right after the xz thing happened. Also while Ubuntu made the t64 migration (Replaced packages with a 32 time variable with a 64 bit one, the packages are renamed. E.g. lib2geom1.2.0 to lib2geom1.2.0t64)

Packages based on the compromised xz had been removed from the repositories, but I already had some newer ones installed which where dependent on them. Also they already wanted the packages with the t64 addition, which by now where nowhere present in the system.

So dist-upgrade did what it could to upgrade 5 packages and bring the system into a consistent state: It uninstalled half of the system including some somewhat essential packages.

I noticed one of them scrolling by and hit CTRL+C. Afterwards I had the choice of saving the data and restoring from a backup a few weeks ago, or to patch it up by hand. So I did the second and created transitional packages like an empty lib2geom1.2.0t64 which depends on lib2geom1.2.0 which was in the repositories back then. 20 of these later I could install packages to get the GUI somewhat working and now weeks later all the t64 migrations are back in the repos and the system is fully functional again :)

Lessons learned:

• Be very careful with dist-upgrade
• Manually trigger a backup before a release upgrade

In now upgrade with
sudo apt-get update && sudo apt-get upgrade -yV && read -p "Flatpak Update? (yj/n): " choice && [[ $choice = [YyJj] ]] && sudo flatpak update --noninteractive
and equivs-build ( sudo apt install equivs) came in really handy in building the transitional packages fast.

I updated my graphics card. Twice. On two different systems. Nvidia sucks. Both times resulted in reinstalling Linux entirely.

Once I omitted a semicolon after an “rm -rf”and the next command. The script was supposed to reduce downtime vs typing the commands manually, but instead it deleted the production site and the “.bak” backup of the site instantly.

Force uninstalled glibc on my Gentoo, which basically broke every shell and binary on the system. Was able to repair in place because I

1. Had already compiled busybox statically
2. Still had a copy of the stage 3 tarball on / which I could use to 'restore' glibc libraries