this post was submitted on 28 Oct 2025
529 points (98.4% liked)

Linux Memes

1005 readers
1 users here now

A community for posting memes relating to linux!

Also check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP



founded 2 years ago
MODERATORS
 
top 50 comments
sorted by: hot top controversial new old
[–] henfredemars@infosec.pub 50 points 3 weeks ago (2 children)

Bootloader’s gone boss. Now what?

[–] iloveDigit@piefed.social 66 points 3 weeks ago (2 children)
[–] b_tr3e@feddit.org 25 points 3 weeks ago

Reboot from live image if you really need to.

[–] rem26_art@fedia.io 7 points 3 weeks ago (3 children)

every linux installation that was ever made was really about trying to break the uptime world record

load more comments (3 replies)
load more comments (1 replies)
[–] Winged_Hussar@lemmy.world 37 points 3 weeks ago (2 children)

Me learning Linux:

I have no idea what the difference between systemd-boot and grub.

Also, I'm not going to check which one is being used, I'll just remove the one I don't like

Linux:

Get after it chief

Why did I have both installed? No idea. Did I have to make and use a recovery USB? Absolutely.

[–] InnerScientist@lemmy.world 35 points 3 weeks ago (3 children)

Linux user seeing a 50% chance to uninstall their bootloader:

Let's go gambling!

[–] ILikeBoobies@lemmy.ca 13 points 3 weeks ago

It’s bloat if you don’t stop running

[–] Sabata11792@ani.social 4 points 3 weeks ago

That one time I did not know what Wayland was...

load more comments (1 replies)
[–] JPAKx4@piefed.blahaj.zone 14 points 3 weeks ago (2 children)

In Linux, you are in charge. If you say jump, Linux asks "how high." If you ask Linux to bomb a daycare it'll say "run with sudo or root." If you ask Linux to sudo bomb a daycare it'll say "should I leave no witnesses?"

This is why I have a dev PC that I have no problem blowing the OS up on. Any files that i want to keep i store in other locations.

[–] caseyweederman@lemmy.ca 4 points 3 weeks ago

This incident has been reported.

[–] InnerScientist@lemmy.world 33 points 3 weeks ago* (last edited 3 weeks ago) (4 children)

I once redid the whole bootloader remotely.

I had a remote server that wasn't luks encrypted because I didn't do that some 3 years ago when setting it up.

So naturally I did the sane thing and kexec a live environment with ssh and a wireguard client, did an in-place encryption of the software raid disks, set up remote unlocking with VPN and rebooted.

And I still can't believe that it actually reconnected after that.

load more comments (4 replies)
[–] I2jgwh0hYtxrCZQ@lemmy.sdf.org 27 points 3 weeks ago (1 children)

Your system will break

So it is actually my system not Microsoft’s?

[–] iloveDigit@piefed.social 8 points 3 weeks ago

According to the windows logo face guy, I suppose

[–] rocky1138@sh.itjust.works 16 points 3 weeks ago

I'm a million years old but I have something relevant! An amazing tale shamelessly copied from Unix Horror Stories, which you simply must read if you end up liking this story, copied below:

Have you ever left your terminal logged in, only to find when you came back to it that a (supposed) friend had typed "rm -rf ~/*" and was hovering over the keyboard with threats along the lines of "lend me a fiver 'til Thursday, or I hit return"? Undoubtedly the person in question would not have had the nerve to inflict such a trauma upon you, and was doing it in jest. So you've probably never experienced the worst of such disasters....

It was a quiet Wednesday afternoon. Wednesday, 1st October, 15:15 BST, to be precise, when Peter, an office-mate of mine, leaned away from his terminal and said to me, "Mario, I'm having a little trouble sending mail." Knowing that msg was capable of confusing even the most capable of people, I sauntered over to his terminal to see what was wrong. A strange error message of the form (I forget the exact details) "cannot access /foo/bar for userid 147" had been issued by msg. My first thought was "Who's userid 147?; the sender of the message, the destination, or what?" So I leant over to another terminal, already logged in, and typed grep 147 /etc/passwd only to receive the response /etc/passwd: No such file or directory.

Instantly, I guessed that something was amiss. This was confirmed when in response to ls /etc I got ls: not found.

I suggested to Peter that it would be a good idea not to try anything for a while, and went off to find our system manager.

When I arrived at his office, his door was ajar, and within ten seconds I realised what the problem was. James, our manager, was sat down, head in hands, hands between knees, as one whose world has just come to an end. Our newly-appointed system programmer, Neil, was beside him, gazing listlessly at the screen of his terminal. And at the top of the screen I spied the following lines:

  # cd
  # rm -rf *

Oh, shit, I thought. That would just about explain it.

I can't remember what happened in the succeeding minutes; my memory is just a blur. I do remember trying ls (again), ps, who and maybe a few other commands beside, all to no avail. The next thing I remember was being at my terminal again (a multi-window graphics terminal), and typing

   cd /
   echo *

I owe a debt of thanks to David Korn for making echo a built-in of his shell; needless to say, /bin, together with /bin/echo, had been deleted. What transpired in the next few minutes was that /dev, /etc and /lib had also gone in their entirety; fortunately Neil had interrupted rm while it was somewhere down below /news, and /tmp, /usr and /users were all untouched.

Meanwhile James had made for our tape cupboard and had retrieved what claimed to be a dump tape of the root filesystem, taken four weeks earlier. The pressing question was, "How do we recover the contents of the tape?". Not only had we lost /etc/restore, but all of the device entries for the tape deck had vanished. And where does mknod live? You guessed it, /etc. How about recovery across Ethernet of any of this from another VAX? Well, /bin/tar had gone, and thoughtfully the Berkeley people had put rcp in /bin in the 4.3 distribution. What's more, none of the Ether stuff wanted to know without /etc/hosts at least. We found a version of cpio in /usr/local, but that was unlikely to do us any good without a tape deck.

Alternatively, we could get the boot tape out and rebuild the root filesystem, but neither James nor Neil had done that before, and we weren't sure that the first thing to happen would be that the whole disk would be re-formatted, losing all our user files. (We take dumps of the user files every Thursday; by Murphy's Law this had to happen on a Wednesday). Another solution might be to borrow a disk from another VAX, boot off that, and tidy up later, but that would have entailed calling the DEC engineer out, at the very least. We had a number of users in the final throes of writing up PhD theses and the loss of a maybe a weeks' work (not to mention the machine down time) was unthinkable.

So, what to do? The next idea was to write a program to make a device descriptor for the tape deck, but we all know where cc, as and ld live. Or maybe make skeletal entries for /etc/passwd, /etc/hosts and so on, so that /usr/bin/ftp would work. By sheer luck, I had a gnuemacs still running in one of my windows, which we could use to create passwd, etc., but the first step was to create a directory to put them in. Of course /bin/mkdir had gone, and so had /bin/mv, so we couldn't rename /tmp to /etc. However, this looked like a reasonable line of attack.

By now we had been joined by Alasdair, our resident UNIX guru, and as luck would have it, someone who knows VAX assembler. So our plan became this: write a program in assembler which would either rename /tmp to /etc, or make /etc, assemble it on another VAX, uuencode it, type in the uuencoded file using my gnu, uudecode it (some bright spark had thought to put uudecode in /usr/bin), run it, and hey presto, it would all be plain sailing from there. By yet another miracle of good fortune, the terminal from which the damage had been done was still su'd to root (su is in /bin, remember?), so at least we stood a chance of all this working.

Off we set on our merry way, and within only an hour we had managed to concoct the dozen or so lines of assembler to create /etc. The stripped binary was only 76 bytes long, so we converted it to hex (slightly more readable than the output of uuencode), and typed it in using my editor. If any of you ever have the same problem, here's the hex for future reference:

   070100002c000000000000000000000000000000000000000000000000000000
   0000dd8fff010000dd8f27000000fb02ef07000000fb01ef070000000000bc8f
   8800040000bc012f65746300

I had a handy program around (doesn't everybody?) for converting ASCII hex to binary, and the output of /usr/bin/sum tallied with our original binary. But hang on---how do you set execute permission without /bin/chmod? A few seconds thought (which as usual, lasted a couple of minutes) suggested that we write the binary on top of an already existing binary, owned by me...problem solved.

So along we trotted to the terminal with the root login, carefully remembered to set the umask to 0 (so that I could create files in it using my gnu), and ran the binary. So now we had a /etc, writable by all. From there it was but a few easy steps to creating passwd, hosts, services, protocols, (etc), and then ftp was willing to play ball. Then we recovered the contents of /bin across the ether (it's amazing how much you come to miss ls after just a few, short hours), and selected files from /etc. The key file was /etc/rrestore, with which we recovered /dev from the dump tape, and the rest is history.

Now, you're asking yourself (as I am), what's the moral of this story? Well, for one thing, you must always remember the immortal words, DON'T PANIC. Our initial reaction was to reboot the machine and try everything as single user, but it's unlikely it would have come up without /etc/init and /bin/sh. Rational thought saved us from this one.

The next thing to remember is that UNIX tools really can be put to unusual purposes. Even without my gnuemacs, we could have survived by using, say, /usr/bin/grep as a substitute for /bin/cat.

And the final thing is, it's amazing how much of the system you can delete without it falling apart completely. Apart from the fact that nobody could login (/bin/login?), and most of the useful commands had gone, everything else seemed normal. Of course, some things can't stand life without say /etc/termcap, or /dev/kmem, or /etc/utmp, but by and large it all hangs together.

I shall leave you with this question: if you were placed in the same situation, and had the presence of mind that always comes with hindsight, could you have got out of it in a simpler or easier way? Answers on a postage stamp to:

Mario Wolczko

[–] Treczoks@lemmy.world 15 points 3 weeks ago

The device I designed at work can be formatted and reinstalled without interrupting its work.

You can absolutely fuck your system up doing crazy shit with Linux, but it all reads like 'I was exploring the uncharted cave, and did some dumb shit when i found a bear. So anyway, I found myself five hundred feet down impaled on a three different stalactites with one broken limb and two more completely crushed by a boulder, the cave starting to flood, and a justifiably angry bear waiting for me the way i came in. Didnt get back out like 6 am thanks the monsoon+sharknado. I had my trusty knife and my hair was long enough i could braid it into a serviceable rope, so I got out, but remember I hadnt sharpened it in a while and one of my arms was broken, plus I ran into a concentration camp on my way here so obviously I had to liberate that¹, and thats why i seem kind of tired today, thinking of skipping lunch in favor of a nap.'

Windows: "hello, 911? I slept with my pillow an inch to the left and I can't move now and my cpap machine is still working so I can breathe, thank God, but at least one possibly both lungs are punctured. Please send help. Oh god so much blood. I hope you're close."

¹with one functioning limb a now very dull knife and a few meters of hair-rope

[–] Hadriscus@jlai.lu 13 points 3 weeks ago (10 children)

I so wish this were representative. I have been trying to install nvidia drivers on debian and doing so bricked my entire workstation lol. If you know anything about this don't hesitate to chime in btw

[–] Zink@programming.dev 7 points 3 weeks ago

Mint has a driver manager application that makes installing nvidia drivers point-and-click simple.

Come to think of it, the three PCs I use on a regular basis all have nvidia GPUs (970, 1080, discrete quadro in a dell laptop) and all are running Mint. No problems, even playing games.

I even use that one script to unlock the number of simultaneous NVENC sessions after I update the driver.

[–] Ziglin@lemmy.world 6 points 3 weeks ago (1 children)

No clue how to fix it. I had a similar issue and it fixed itself when I switched to endeavouros with i3.

[–] Hadriscus@jlai.lu 3 points 3 weeks ago (3 children)

Ok, thank you for the feedback still. You were able to install a different OS and boot into it normally?

load more comments (3 replies)
[–] adminofoz@lemmy.cafe 5 points 3 weeks ago (6 children)

You should know nvidia is the worst and it is definitely an nvidia problem. Nothing else (even DNS) is, such a pain on linux. Nvidia routinely ships broken software on their stable branch even for their top of the line consumer cards.

I have two 4k monitors and run many flavors of Linux as daily drivers. Plus I have a 4090. It's not a super common setup but for a company as huge as nvidia they should be testing dual monitor setups and it is clear they do not. I have stopped updating my nvidia drivers after the 3rd time I lost basic functionality after a driver update.

load more comments (6 replies)
[–] iloveDigit@piefed.social 3 points 3 weeks ago (4 children)

Good news is it's much harder to accidentally wipe/fragment all your files than it is to break your system

If anything is lost right now, you might be able to get it back just by booting from a live USB to explore your file system

load more comments (4 replies)
[–] Skullgrid@lemmy.world 3 points 3 weeks ago* (last edited 3 weeks ago) (1 children)

I ran dpkg --get-selections to get all my installed packages and here's the installed Nvidia stuff. Try to install what's missing.

If you can't even get to command line, try to backup your data to an external source by using a live USB, and replace your debian with Pika OS, which has all the Nvidia stuff out the gate.

nvidia-alternative                              
nvidia-driver                                   
nvidia-driver-bin                               
nvidia-driver-libs:amd64                        
nvidia-driver-libs:i386                         
nvidia-egl-common                               
nvidia-egl-icd:amd64                            
nvidia-egl-icd:i386                             
nvidia-installer-cleanup                        
nvidia-kernel-common                            
nvidia-kernel-dkms                              
nvidia-kernel-support                           
nvidia-legacy-check                             
nvidia-modprobe                                 
nvidia-persistenced                             
nvidia-settings                                 
nvidia-smi                                      
nvidia-support                                  
nvidia-suspend-common                           
nvidia-vdpau-driver:amd64                       
nvidia-vulkan-common                            
nvidia-vulkan-icd:amd64                         
nvidia-vulkan-icd:i386                          

EDIT : from apt list --installed

libnvidia-allocator1/stable,now 550.163.01-2 amd64 [installed,automatic]
libnvidia-allocator1/stable,now 550.163.01-2 i386 [installed,automatic]
libnvidia-cfg1/stable,now 550.163.01-2 amd64 [installed,automatic]
libnvidia-egl-gbm1/stable,now 1.1.2.1-1 amd64 [installed,automatic]
libnvidia-egl-gbm1/stable,now 1.1.2.1-1 i386 [installed,automatic]
libnvidia-egl-wayland1/stable,stable,now 1:1.1.18-1 amd64 [installed,automatic]
libnvidia-egl-wayland1/stable,stable,now 1:1.1.18-1 i386 [installed,automatic]
libnvidia-eglcore/stable,now 550.163.01-2 amd64 [installed,automatic]
libnvidia-eglcore/stable,now 550.163.01-2 i386 [installed,automatic]
libnvidia-encode1/stable,now 550.163.01-2 amd64 [installed,automatic]
libnvidia-encode1/stable,now 550.163.01-2 i386 [installed,automatic]
libnvidia-glcore/stable,now 550.163.01-2 amd64 [installed,automatic]
libnvidia-glcore/stable,now 550.163.01-2 i386 [installed,automatic]
libnvidia-glvkspirv/stable,now 550.163.01-2 amd64 [installed,automatic]
libnvidia-glvkspirv/stable,now 550.163.01-2 i386 [installed,automatic]
libnvidia-gpucomp/stable,now 550.163.01-2 amd64 [installed,automatic]
libnvidia-gpucomp/stable,now 550.163.01-2 i386 [installed,automatic]
libnvidia-ml1/stable,now 550.163.01-2 amd64 [installed,automatic]
libnvidia-pkcs11-openssl3/stable,now 550.163.01-2 amd64 [installed,automatic]
libnvidia-ptxjitcompiler1/stable,now 550.163.01-2 amd64 [installed,automatic]
libnvidia-ptxjitcompiler1/stable,now 550.163.01-2 i386 [installed,automatic]
libnvidia-rtcore/stable,now 550.163.01-2 amd64 [installed,automatic]
[–] Hadriscus@jlai.lu 3 points 3 weeks ago* (last edited 3 weeks ago) (5 children)

Thanks a bunch for the advice but I can't start my system. That's regardless of the distro I try and install (I already overwrote Trixie with Bazzite... and now with Nobara). I followed this tutorial :https://fostips.com/install-nvidia-driver-in-debian-13/?amp=1

I explain the situation over here in more detail if by any chance this rings a bell with you :

https://forums.debian.net/viewtopic.php?t=164124

Cheers, appreciate the advice

[–] Skullgrid@lemmy.world 5 points 3 weeks ago (2 children)

you done fucked up the secure boot settings I think. I am in no way qualified to help you.

I don't even understand how you can install a different OS. Work off a live USB if you even can.

As far as I understand this is the bit you fucked up. btw, the images in the debian forum post just show "filename1.jpg" as text and don't display. post on !/c/linux4noobs@programming.dev

Step 2: Enroll MOK key for Secure Boot

Debian updates its kernel (minor versions) regularly for security updates and fixes. Without re-building kernel modules every time, DKMS is used, which however needs be signed for secure boot using a machine owner key (MOK).

1. First, run the command below to check if Debian was installed with UEFI boot by running the command below in terminal:

ls /sys/firmware/efi

The command tells to list the /sys/firmware/efi directory content. If it says “No such file or directory”, then you have Debian installed as legacy boot.

2. Next, run command to check if secure boot enabled:

sudo mokutil --sb-state

If both UEFI and secure boot enabled (as the screenshot below shows you), then you need to run commands below one by one to create and enroll MOK key.

3. First, run the command below to manually generate a mok key.

sudo dkms generate_mok

Run sudo apt install dkms if the dkms command not found, and set a password for the key.

4. Next, run command to import the key:

sudo mokutil --import /var/lib/dkms/mok.pub

5. Finally, reboot your computer. At next boot, it should pop-up a screen (see the screenshot below), asking to perform MOK menagement.

There, just choose to Enroll MOK -> continue -> confirm -> enter password (you set when creating the key) -> reboot.

After enabled non-free repository and enrolled MOK key, you may then run the commands below to install NVIDIA driver.

First, install the kernel headers for DKMS:

sudo apt install linux-headers-$(dpkg --print-architecture)
[–] Hadriscus@jlai.lu 4 points 3 weeks ago

Thank you that's already a lead !

I did follow the instructions to the letter so not sure what I should have done differently

I am going to ask on the community you linked. Thanks again

[–] Hadriscus@jlai.lu 3 points 3 weeks ago* (last edited 3 weeks ago)

I just cross-posted my cry for help over there. Thanks again for the redirection. https://programming.dev/post/39832602

load more comments (4 replies)
[–] JPAKx4@piefed.blahaj.zone 2 points 3 weeks ago* (last edited 3 weeks ago) (5 children)

Sounds representative, it didn't even try to stop you!

Everyone else is saying secure boot should be correct. I was unable to load my nvidia driver until disabling secure boot, but I luckily had integrated graphics. What I think happened is you switched to to nvidia drivers that required proper secure boot before it would load. The drivers that are loaded before that don't require secure boot to be setup so that's why you had an output.

This is just an nvidia thing unfortunately.

load more comments (5 replies)
load more comments (4 replies)
[–] atopi@piefed.blahaj.zone 5 points 3 weeks ago (1 children)

But uninstalling edge would actually break your computer

[–] filcuk@lemmy.zip 4 points 3 weeks ago

Yes and no. Webview is a separate component. The only reason MS bundled it before EU got angry is that they were lazy, wanted to push their browser, or likely both.

load more comments
view more: next ›