You are not logged in.
If you re-installed the system then your username might have had it's numeric UID changed (it's the 3rd field in /etc/passwd). That would mean that everything in it's home dir would be owned by the old UID, not it's new UID. The sudo chown -R user:user /home/user command would have fixed it. And destroyed most of the evidence.
I've hit this problem before when switching distributions.
If your problem is that the system runs slowly then start by trying to fix that *without* disabling FDE.
A few questions to start with:
What sort of system is it? (Desktop or Laptop, make model, etc?)
What CPU has it got?
How much memory has it?
What is it's display? (Could you add a GPU if it hasn't got one?)
What is running on it? (OS, desktop env, etc?)
Is it using swap space very often? (If yes then adding memory might speed it up a lot.)
Try running top and vmstat to see if they say anything interesting.
Hopefully answering that lot will point you towards a fix.
Try searching everywhere outside /home that your user account could write to. (Ignore symlinks though, only permissions on what they point to matter.) Personal data could leak into any of them.
At least check /tmp/ and /var/tmp/ (you would probably need to make them separate encrypted partitions).
I assume both screens will be powered on before the boot. But how are they connected (are there two motherboard sockets or is one on a GPU)? And what sort of PC is it?
There *should* be a BIOS option to say which screen to use. But that probably only applies to the BIOS output.
You could try booting the system with one screen powered off and see what happens. Then try the other. (It probably won't help but costs nothing to experiment.)
One day i had complaints from every https site i tried to visit. The reason was:the hardware decided that current time is january 2002.
That sounds like the battery for the real time clock is going flat. And might cause it to forget changes you made to the BIOS settings (or just randomly change settings). Replacing the battery would be a good start, then check all the BIOS settings.
The first thing I'd try is to repeat round 1, cp sums.txt sums_1.txt, repeat round 2 and diff sums_1.txt sums.txt to see if they differ.
It will cause problems for scripts that call which. Unless stderr is sent somewhere harmless such as /dev/null it will either put out the message to the terminal (annoying, but probably the script will still work) or get mixed up with the output the script will try to parse (and probably make the script fail).
https://wiki.debian.org/NewInBookworm says:
Shell script writers are advised to use command -v instead.
But I won't be holding my breath waiting for *every* script calling which to be updated.
which is actually a shell script, so if this proves too annoying you could just update it on your system to comment out the message. And try to remember this if you write a script for someone else that uses which.
Don't blindly assume everyone on the left is virtuous. That would place you in grave danger if you encounter a psychopathic murderer who claims to be on the left to give people a false sense of security. And a con artist doing the same thing could give you a painful lesson.
In any case trying to fit all political views onto one dimension is far to simplistic. The extreme left and extreme right are almost identical in what they actually do, the centre are much further from them than they are from each other. Remember that Nazi is short for National Socialist.
Try running a port scan (eg nmap) from another system on the same network. That should tell you what ports are open.
If you don't have a port scanner sudo traceroute -T -p 80 realupnow.com would test access to port 80, Then you could repeat for other ports, eg 443 (https) and 22 (sshd). That should tell what ports are blocked.
Edit: we cross posted.
You may need to allow *inbound* access to port 80 (and port 443 if you want to use https). Knowing what point of view inbound and outbound refer to can be confusing.
Having a quick look from outside:
$ host www.realupnow.com
www.realupnow.com has address 66.172.90.106
$ ping www.realupnow.com
PING www.realupnow.com (66.172.90.106) 56(84) bytes of data.
64 bytes from 66.172.90.106: icmp_seq=1 ttl=47 time=110 ms
64 bytes from 66.172.90.106: icmp_seq=2 ttl=47 time=109 ms
$ sudo traceroute -T www.realupnow.com
traceroute to www.realupnow.com (66.172.90.106), 30 hops max, 60 byte packets
<snip>
13 168.182.127.17 (168.182.127.17) 114.734 ms 118.489 ms 116.881 ms
14 168.182.127.1 (168.182.127.1) 110.179 ms 110.515 ms 113.517 ms
15 168.182.127.98 (168.182.127.98) 118.143 ms 116.080 ms 117.728 ms
16 66.172.90.106 (66.172.90.106) 115.229 ms 109.814 ms 111.151 ms
17 66.172.90.106 (66.172.90.106) 3117.564 ms !H 3111.648 ms !H 3109.469 ms !H
But I can't tell what 66.172.90.106 is. Could that be your router's external IP address? Or the server's external IP address?
NB. traceroute -T uses a SYN packet as it's probe, to port 80 by default.
To get kernel driver info you need to use lspci -knn (pipe it into less to keep screen output searchable). See the man page for lspci.
Searching for recently changed files in /etc and your home directory might tell you what did it. It's more likely to be in /etc but might be in some subdirectory. Try the find command (read it's man page first if it's new to you).
The latest issue of Linux Magazine (called Linux Pro in some countries) has an article on Lynis, a tool to help harden Linux systems. I've not had time to read the article, but it's probably worth looking at (just put Lynis into your favourite serach engine and you should find it).
HTH
root@devuan1:/home/david1# modprobe e1000e bash: modprobe: command not found root@devuan1:/home/david1#
That makes me suspect you switched to root with su so didn't get your PATH updated. Try su - and see if modprobe works then.
If it still doesn't post output from:
echo $PATH
whereis modprobe
Please post output from:
uname -a
lspci -v -s nn (replace nn with the address of the nic).
Also check in /var/log/messages and /var/log/syslog for messages relating to the nic.
And are you sure the device the nic is connected to is OK? And the cable connecting it? With troubleshooting the most annoying problem is when the component you never thought to check is the faulty one.
Can you set ublock to *pretend* to allow ads, but not actually show them on your screen? It's an option I would like to have if I need to use a site that blocks access to people who are using ad blockers. The idea is that ads get downloaded but not shown, so the advertisers can't tell they are paying for nothing.
Can you temporarily connect it to your network with an ethernet cable? That would help if you need to load firmware for the wifi card onto the laptop. Or just copy any error messages into your favourite search engine.
On one system I resorted to ctrl-alt-F3 and logging on as root, ready to restart the desktop if it hung (I think the system has hardware problems that cause the desktop to lock up intermittently). So if the desktop suddenly hangs I just press ctrl-alt-F3 and restart it, even if it's ignoring the keyboard. And if that fails I can reboot the system as a last resort.
The man su was new to me.
One of the first things to know with any UNIX variant such as Linux is that man pages are the first place to go when you have problems. Whenever you see a recommendation to use a command you are not familiar with you should always start by reading the man page for it to see what it will do. Man itself has a man page (enter man man to see it).
Also try:
echo $PATH
su
echo $PATH
exit # or press control-d
su -
echo $PATH
Trying things out is a good way to learn how Linux works under the hood.
man su would also be worth reading. The man pages are always worth checking if you are having probelms with a command.
And try comparing output from echo $PATH after su and su - (also output from env and set, preferably piped into less).
I've just fixed a bug in the above script (I had a do missing) and tested it after replacing "starfish -d duration" with "sleep 5". So it might work now.
Try the following (WARNING - untested code- WARNING):
#!/bin/bash
FLAG=0
until [[ $FLAG = "1" ]]
do
DIR=$(date +%N)
mkdir $DIR
if (($?>0)) ;then exit;fi
cd $DIR
if (($?>0)) ;then exit;fi
starfish -d duration
# Tidy up anything if you want here
cd ..
if (($?>0)) ;then exit;fi
rmdir $DIR # Optional
if (($?>0)) ;then exit;fi
done
date +%N returns the current time in nanoseconds, so will very rarely repeat.
But I don't have starfish, so I can't test this. Use at your own risk.
The first thing I'd try is to boot a live DVD/USB, mount the SSD and scp everything I want to save to another system (plugging in an ethernet cable if necessary). Then mount the nVME drive and save anything I wanted or what might show what went wrong.
Then I would check the data looks OK on the destination system. After that I'd be happy to start trying to repair the broken system.
One option would be that something is outdated elsewhere in the "certificate chain" on the failing systems.
I.e., the "leaf level" certificate of www.devuan.org is fine, but in your environment some "parent" certificate in the certificate chain it stands on is outdated.
E.g., check your ca-certificates package.
That's probably why some of my systems got an error. I temporarily powered up a recently updated system (it's shut down to save power now) and it worked OK:
wget 'https://www.devuan.org/get-devuan'
--2022-11-06 12:07:55-- https://www.devuan.org/get-devuan
Resolving www.devuan.org (www.devuan.org)... 54.36.142.179, 2001:41d0:8:732b::3624:8eb3
Connecting to www.devuan.org (www.devuan.org)|54.36.142.179|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 25326 (25K) [text/html]
Saving to: ‘get-devuan’
get-devuan 100%[============================================================================>] 24.73K --.-KB/s in 0.006s
2022-11-06 12:07:56 (4.17 MB/s) - ‘get-devuan’ saved [25326/25326]
So the www.devuan.org certificate is probably OK.
I just hope being back-level doesn't start causing real problems on this system since I can't upgrade it without probably losing support for the rather old GPU.
I'm still getting them. On two different systems (one Devuan ascii, one openSUSE Leap 42.3).
I also tried echo -n | openssl s_client -connect www.devuan.org:443 -servername www.devuan.org | openssl x509 > wwwdevuanorg.cert, that gets different screen output:
On devuan:
$ echo -n | openssl s_client -connect www.devuan.org:443 -servername www.devuan.org \
> | openssl x509 > wwwdevuanorg.cert
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = www.devuan.org
verify return:1
DONE
On openSUSE:
echo -n | openssl s_client -connect www.devuan.org:443 -servername www.devuan.org | openssl x509 > wwwdevuanorg.cert
depth=3 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
DONE
chris@vega:~/primo/progs> ll wwwdevuanorg.cert*
-rw-r--r-- 1 chris users 2025 Nov 4 16:57 wwwdevuanorg.cert
Though the certificates downloaded were identical on both systems.
I doubt it's cached, the openSUSE box isn't used for web browsing so has probably never downloaded the certificate before I first tried yesterday.
But on a web server I can log on to via ssh (I do some of the admin on it) wget is happy:
$ wget 'https://www.devuan.org/get-devuan'
--2022-11-04 17:04:43-- https://www.devuan.org/get-devuan
Resolving www.devuan.org (www.devuan.org)... 54.36.142.179, 2001:41d0:8:732b::3624:8eb3
Connecting to www.devuan.org (www.devuan.org)|54.36.142.179|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 25326 (25K) [text/html]
Saving to: ‘get-devuan’
get-devuan 100%[============================================================================>] 24.73K --.-KB/s in 0.005s
2022-11-04 17:04:44 (4.50 MB/s) - ‘get-devuan’ saved [25326/25326]
And:
$ echo -n | openssl s_client -connect www.devuan.org:443 -servername www.devuan.org | openssl x509 > wwwdevuanorg.cert
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = www.devuan.org
verify return:1
DONE
And the cert appears to be the same too.
I'm now wondering if my ISP is caching something. Have you any ideas?