I basically read logs for a living, read the boot sequence at least once in your life. It’s very cool to be able toi see the bootstrapping order and understanding all the basic things that have to be initialized just for the most basic of OS things to happen.
The boot sequence is what I was picturing originally, but I didn’t know how to word that cleanly for the meme, lol.
I think that the point being made here is that it’s not a great idea to hold an actually running soldering iron by the hot bit?
If so, I think that OP’s image is supposed to have some sort of thermal insulation stuff around the hot bit, that clear stuff.
Anti-fingerprinting or something, idk I don’t use secure browsers
Yeah, just reminded me of this.
LEARN
I’m trying! There’s a lot.
Excellent, remember that after 64 times booting the system there will be a mandatory test on 16 random boot up messages.
Fail, and the system refuses to start.
Few Linux users have ever successfully beaten it…
…mostly because they have never had to reboot their system 64 times before getting a new machine.
…mostly because they have never had to reboot their system 64 times before getting a new machine.
You really didn’t have to call me out like that.
I’ve had my system for ~4 years now, and I think I’ve rebooted it a grand total of maybe 10 times. Pretty much never voluntarily. Usually due to a power outage or needing to shut down for a hardware upgrade.
People reboot their systems?
You can reboot your system?
If you don’t want it, you can hide it — most distros have some way to just show a splash screen that hides it. I always unhide it, as I can see hints of things going wrong.
The messages are from a wide variety of kernel subsystems (and, later in the boot process, daemons) and most people aren’t going to be familiar with everything. I could tell you what a lot of lines mean, but there are always new ones showing up as new software is written.
They’re more-likely to be useful if something breaks and then you go examine a specific, suspicious-looking message and learn what it means. You probably won’t be constantly trying to stay up on all kernel subsystems.
as I can see hints of things going wrong.
Yes!
Even if you don’t understand every line, if the system hangs or just takes an unusually long time to boot, you’ll be able to see what it’s getting stuck on. And even if you don’t understand that, you can
googleDDG the message and find out what it’s doing, maybe figure out what’s taking so long, what’s wrong, and how to fix it.And even if you don’t care, if you have an old machine booting from a HDD, the process at least isn’t so boring.
^This comment is talking about the deluge of log messages you may or may not see (depending on the distro) while booting the system.
Just thought I’d add that, since the meme doesn’t actually mention booting. Not sure, where you got that from. 😅
In fact, the image in the meme shows an Ubuntu system installing updates using
apt.
I thought the same when I first booted Linux, but after reading it day by day, you’ll understand more and if it is too fast you can always Edit: woups!
Sudo dmesgNote that on current, systemd-based systems, one probably wants
sudo journalctl -kbto show kernel messages for the current boot.dmesgreads from the in-memory kernel ring buffer. That can be desirable in some cases, but as the name suggests, the “ring buffer” is a “ring” — it has a finite amount of space and eventually, the old stuff gets overwritten by the new stuff. The idea is that a userspace logging daemon, like journald (or syslogd on most older systems) has time to pull the data from the ring buffer out to (potentially much larger) log files on disk.journalctl will also post-process the output to do things like convert the time-from-boot to a wall clock time, which is generally more useful for correlating with other things.
dmesg
😮🙏🏻woups
Why are people so resistant to reading? fortunately, most things output an explanation of what went wrong, and often you can google that message…
Just skim to the part that tells you to type “yes, do as I say!”
The way these tools are designed, typically unless something goes wrong you need to understand basically none of it. And if something goes wrong, the resulting error messages normally at least give you something to search for in order to understand more
the resulting error messages normally at least give you something to search for
And:
#include <errno.h> #include <stdio.h> int main (void) { errno=ENOANO; perror(""); return 0; }Yields:
$ ./a.out No anode $
