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?
source ~/.bash_history
Dear god
That’s the scariest horror story in 2 words I’ve seen so far
I’m genuinely having a chuckle at how shocked people are at my submission, made my day xD
I mean, it’s simple, elegant, and destructive AF given the right circumstances. Basically a chaos grenade we didn’t realize existed
And also a very understandable mistake, to boot.
New fear unlocked
“Oh My…” thought in a George Takei voice
Oh no. That fits the bill perfectly lol.
Jesus Christ. It would be a good idea to format that file to have an
exitas first line to avoid this
i never thought i had a nuke that i can launch using one command
Many many years ago I wanted to clean up my freshly installed Slackware system by removing old files.
find / -mtime +30 -exec rm -f {};
Bad idea.
Tried to convert Ubuntu to Debian by replacing the repos in sources.list and apt dist-upgrading. 💣 Teenagers…
I’m as nerdy as they come, but… I don’t think you did teenage rebellion right.
sudo rm -f /lib /usr/share/backup/blah blah.tar.gz
Note the space.
Oh man, you really owned those libs
You need to use chown if you want to own the libs
Might be recoverable if you had a live distro ready. Otherwise, o7.
Oh no, this was back in the days when we loaded our distros by way of a stack of floppy disks.
Top tip, if tired, replace the
rm -fpart of the command with something innocuous for a first run. Actually, is better to do this mistake once so that the two important lessons are learned… Backup (obviously, in your case it was backups, but the point still stands) and double check your command if it has potential for destruction 👍
First, the classical typo in a bash script:
set FOLDER=/some/folder
rm -rf ${FODLER}/
which is why I like to add a set -u at the begining of a script.
The second one is not with a Linux box but a mainframe running AIX:
If on Linux killall java kills all java processes, on AIX it just ignore the arguments and kill all processes that the user can kill. Adios the CICS region 😬 (on the test env. thankfully)
If on Linux killall java kills all java processes, on AIX it just ignore the arguments and kill all processes that the user can kill.
jfc, is ignoring arguments the intended behavior?
On a real UNIX (not only AiX) killall is part of the shutdown process - it gets called by init at that stage when you want to kill everything left before reboot/shutdown.
Linux is pretty unique in using that for something else.
I didn’t know that, good to know.
They could have send a SIGTERM by default instead of a SIGKILL. I would not have corrupt everything 😅
killall typically sends SIGTERM by default. It accepts a single argument, the signal to send - so shutdown would call it once with SIGTERM, then with SIGKILL. killall is not meant to to be called interactively - which worked fine, until people who had their first contact with UNIX like systems on Linux started getting access to traditional UNIX systems.
It used to be common to discourage new Linux users from using killall interactively for exactly that reason. Just checked, there’s even a warning about that in the killall manpage on Linux.
Yes: same command name, two different semantics:
Cross-Unix scripting is fun ☺️
Wow, the last one is quite unexpected. What a useful command
CTRL-C-ing apt because it looked stuck for more than 10 minutes. I don’t recommend doing it.
Man, gotta love
aptsometimesapt is great, but yeah, if it’s gonna fail, let it fail on its own.
Haven’t used
aptin a while, is it not atomic? What happens if you mess with it?I don’t think it is, if it doesn’t run its course on its own, you’re screwed. It’s Debian so you can recover, but, at least for me, it was painful.
I can’t even remember how I did this, but overwriting the partition table on the main production server at our small startup (back when “the server” would usually live on the premises of the startup). I remember my boss starting to hyperventilate from panic while I reconstructed it from memory / notes, and all the filesystems came back and he calmed down.
Same job, they gave me a little embedded-systems unit for me to use to build a prototype on. I hooked it up, nothing worked. I brought it back to them.
Hey, this one doesn’t work.
Huh… that’s weird, it was working before. Did you break it?
I don’t think so. Can I have one that works?
They literally told me, as they were handing me the second one: Okay, here’s another one. Don’t break it.
I figured it out literally seconds after breaking the second one… I was hooking it up to 12 volts of power when it needed 5. Second dead computer. Explaining that and that I needed a third one now was fun.
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
- msmc101 ( @msmc101@lemmy.blahaj.zone ) 19•1 year ago
First time trying Linux I went with an arch install because I Googled “best version of Linux” and went with arch. Followed a guide to the point of drive formatting and I decided to go with a setup with drive encryption. I didn’t understand what I was doing, ended up locking myself out of my hard drives and couldn’t get windows to reinstall on them. I used a MacBook for a week until I installed Ubuntu and managed to wipe and reset my drives and reinstalled. Needless to say I am going to read up a little more before I try that again.
Been there, and even without encryption: took me to reinstall a few times before I realized I can chroot again and repair 😅
Archinstall python script is your friend 😄😉 I tried install arch manually, but as I learned that not even sudo is included in the Linux essential packages, I stopped the process and went back to aromatic script install, lol, got no time for that S*** 😂
I don’t know if that counts, but on a fresh default Debian Stable system, my cat walked across the keyboard and the DE crashed.
I could still switch to another TTY and reboot via command line.
After the reboot, I was greeted by a blinking cursor and nothing else. Had to reinstall.keyboard cat strikes again
Cat killed grafic card driver?
Deleted my entire efi partition while trying to install some grub themes.
And then my backup didn’t work when I tried to restore it.
I have pretty colours now though, so it was all worth it :)
Been there, done that. But I haven’t had any problems once I switched to
systemd-boot🤷😁
I wanted to use fio to benchmark my root drive. I had seen a tutorial saying that the
file=parameter should point to the device file, so I pointed it at /dev/sda. As you might expect, the write test didn’t go so well.This was pre-linux for me but something you can still do in most distros so I think it’s a valid story.
In 1999 I was using Napster on computer running MS-DOS. I was 12 years old and an aspiring open media enthusiast/stupid script kiddie. I was using the file explorer interface in Napster and accidentally gave access to my entire C drive. I also had opened ports to share certain media and to fuck with my friends using daemon tools (back then you could do stupid stuff like control a friend’s desktop with certain versions of daemon tools). Immediately I started receiving packages called things like “sleep.tight.tiny.mite” and I knew I was fucked so I clicked in the Napster interface and clicked “delete” and deleted my entire active drive.
I panicked and installed the only operating system we had which was a random copy of Red Hat. When my dad came home I pretended like it had always had Linux on it. I do think he was more impressed than mad.
“Just pretend it’s always been Linux” is a bold move. I salute 12-year-old you o7
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.
An intern nuked their workstation by
sudo chmod -R 777 /. Turns out adding exec to everything isn’t good either.
The first time I read this, i thought “shouldn’t all that be executable anyway?”
And then I read it again and realized, minus x
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
Just straight up overwriting boot sector and superblock of my hard drive thinking it’s the USB drive.
Udev tried to warn me, saying there’s no permission, and I just typed sudo without thinking.
Then after a second I remembered USB block devices are usually writable by users, but it was too late.
USB block devices containing mountable filesystems (on Desktop systems) can generally have those filesystems mounted and files written to them by regular users; But the block device itself stays only root writeable.
So, you need root privileges either way.
(Going from memory, but also decently confident)
