no worries! i’m not the fastest to respond myself. i do want to help though. to explain the command,

• journalctl searches the journal, a database of messages from the units on your system managed by journald
• -b0 means “this boot’s messages”, not the last boot or the one before…
• -p4' means "WARNING (4) or higher" (3, 2, 1, or 0). these priority levels are pretty old, long before my time. you can see them in man syslog`, but 0 is “alert” and 7 is “debug”

i say all that because i naively hoped a malfunction on your system would appear as a high-priority message in the journal, and i wanted to spare you the back-and-forth that this kind of troubleshooting usually entails. in this case, though, i didn’t really see anything in those logs, so i suspect the culprit has been filtered out.

i will keep trying my best to help, don’t worry, but i understand if you get fatigued and just want to move on.

there are some odd gaps in the logs where i can’t tell what’s happening. now that you know how to send logs to something like dpaste, let’s open the floodgates. i don’t mind wading through a sea of logs to find something (kind of my day job too)

to give the kernel’s account of what happened:

dmesg -H | curl -s -F "content=<-" https://dpaste.com/api/v2/

that’s everything from the start of the system to now, so it’s best if you do it soon after booting.

finally, i had you filter to WARNING (4) and above with -p4 but it didn’t show anything. how about…everything?

journalctl -b0 | curl -s -F "content=<-" https://dpaste.com/api/v2/

that will be a lot of information but it should be informative!

oh god this isn’t satire

no worries, i gave a suggestion in my comment:

journalctl -b0 -p4 | curl -s -F "content=<-" https://dpaste.com/api/v2/

that captures the output from journalctl -b0 -p4 and sends it to dpaste.com. it will print out a URL to the result. give that a try

it’s very hard to decipher. the lines are right-truncated like you just copy-pasted from the terminal (the lines end in > which is less’s sigil for “more content to the right”). you can make a pastebin from command output. to capture any command as a paste try

journalctl -b0 -p4 | curl -s -F "content=<-" https://dpaste.com/api/v2/

the part after the | comes from here:

https://dpaste.com/FZNXRMS75

you can put anything before | to capture it to dpaste. check it for sensitive information first!

from what i can see though, your nvme is behaving strangely. it may be related to power saving settings. try these settings from the Arch wiki:

https://wiki.archlinux.org/title/Solid_state_drive/NVMe#Troubleshooting

do you boot from the nvme?

you can also journalctl -b0 -p4 to show only high priority messages. that would help too

thanks, can you please give me the output of

journalctl -b0 -u systemd-modules-load

i’m curious why it’s taking 30s. maybe the other two services as well

the dmesg you posted is very truncated, just like a screenful of info. you can usually pipe command output to curl with these pastebin sites. i understand if you’re concerned about sensitive info in dmesg though

can you post journalctl -b0 and systemd-analyze blame results from after a successful boot. i have broken and fixed my own systems countless ways so maybe i’ll spot something

it’s punycode

oh! đ and þ are used for þat soubd right? but one is voiced and þe oþer isn’t i can never remember which… oh okay in Old English þey just used þ for boþ

i wanna know

i started with slackware ~2003 and moved to gentoo in 2005. it was very transparent to me as a newbie. use flags and compilation from source were way simpler to me than mysterious precompiled binaries. also ndiswrapper worked with my wireless chipset on gentoo. that helped

for my own sanity i will assume the audience of that page you linked is business customers given one of their examples is a .gov. im just residential. getting a static ip out here felt monumental in itself

it was apparently impossible for my isp. i have a very good deal on a static ip so reluctant to rock the boat

even if you get port 25 unblocked your IP won’t pass the sniff test. you must have a PTR record on the IP pointing to your domain for the large email hosts to accept mail from you. i use amazon SES to handle outbound because of this hurdle. it sucks

no, if the attacker can change files in your account, they can read every byte you type in and respond with anything, including pretending to be a normal shell. im not sure how to prevent ssh from running commands in your shell

which sudo will check $PATH directories and return the first match, true. however when you type sudo and hit enter your shell will look for aliases and shell functions before searching $PATH.

to see how your shell will execute ‘sudo’, say type sudo (zsh/bash). to skip aliases/functions/builtins say command sudo

meh nvm none of these work if your shell is compromised. you’re sending bytes to the attacker at that point. they can make you believe anything