Newer fedora distros keep track of authentication failure attempts.
This may prevent sudo from working even though the password is correct!
In this example, I verified my user ‘ben’ is in /etc/sudoers
# grep ben /etc/sudoers
ben ALL=(ALL) ALL
Yet when I performed a simple operation the password was not accepted
# su - ben
[ben@bedora37]$
[ben@bedora37]$ sudo bash -c ls
[sudo] password for ben:
Sorry, try again.
[sudo] password for ben:
Sorry, try again.
I could verify the password I am using is correct by performing an SSH to localhost
# ssh ben@localhost
password
#
The problem in this case was that I needed to reset the failure lock
# faillock
ben:
When Type Source Valid
2023-04-15 16:33:01 TTY /dev/pts/1 V
2023-04-15 16:33:10 TTY /dev/pts/1 V
2023-04-15 16:33:20 TTY /dev/pts/1 V
root:
When Type Source Valid
I reset via
# faillock --user ben --reset
#
Now my simple ls works
# su - ben
[ben@bedora37]$
[ben@bedora37]$ sudo bash -c ls
[sudo] password for ben:
Desktop Documents Downloads logs Music Pictures Public snap Videos
[ben@bedora37]$
I came across an issue recently whereby I had a need to display all physical hard drives on a system whether it be HDD, VHD, or SSD (NVMe) drives that were above a certain size, excluding any USB or CD-ROM/DVD drives.
In the following example I needed to obtain the first drive that was larger than 50GB
#!/bin/bash
DIR=/sys/block
MINSIZE=50 #Min size of drive in GB to look for
declare drive_type
drive_type=( "nvme" "sd" "hd" "vd" )
for t in ${drive_type[@]}; do
if [ $(ls $DIR/|grep -q "^$t";echo $?) == 0 ]; then
for d in $DIR/${t}*; do
DEV=`basename "$d"`
if [[ ( -d $DIR/$DEV || -L $DIR/$DEV ) && ( $(cat $DIR/$DEV/removable) == 0 ) ]]; then
if [ -f $DIR/$DEV/size ]; then
GB=$((`cat $DIR/$DEV/size`/2**21))
if [ $GB -gt $MINSIZE ]; then
echo "Disk device $DEV has size $GB GB"
break 2
fi
fi
fi
done
fi
done
Example
$ bash drivesize.sh
Disk device nvme0n1 has size 1788 GB
Another variation is if I wanted to list all physical drives and their sizes I can modify the above to simplify:
#!/bin/bash
DIR=/sys/block
declare drive_type
drive_type=( "nvme" "sd" "hd" "vd" )
for t in ${drive_type[@]}; do
if [ $(ls $DIR/|grep -q "^$t";echo $?) == 0 ]; then
for d in $DIR/${t}*; do
DEV=`basename "$d"`
if [[ ( -d $DIR/$DEV || -L $DIR/$DEV ) && ( $(cat $DIR/$DEV/removable) == 0 ) ]]; then
if [ -f $DIR/$DEV/size ]; then
GB=$((`cat $DIR/$DEV/size`/2**21))
echo "Disk device $DEV has size $GB GB"
fi
fi
done
fi
done
Example
$ bash drivesize_all.sh
Disk device nvme0n1 has size 1788 GB
Disk device nvme10n1 has size 1788 GB
Disk device nvme11n1 has size 1788 GB
Disk device nvme12n1 has size 1788 GB
Disk device nvme13n1 has size 1788 GB
Disk device nvme14n1 has size 1788 GB
Disk device nvme15n1 has size 1788 GB
Disk device nvme16n1 has size 1788 GB
Disk device nvme17n1 has size 1788 GB
Disk device nvme18n1 has size 1788 GB
Disk device nvme19n1 has size 1788 GB
Disk device nvme1n1 has size 1788 GB
Disk device nvme20n1 has size 1788 GB
Disk device nvme21n1 has size 1788 GB
Disk device nvme22n1 has size 1788 GB
Disk device nvme23n1 has size 1788 GB
Disk device nvme2n1 has size 1788 GB
Disk device nvme3n1 has size 1788 GB
Disk device nvme4n1 has size 1788 GB
Disk device nvme5n1 has size 1788 GB
Disk device nvme6n1 has size 1788 GB
Disk device nvme7n1 has size 1788 GB
Disk device nvme8n1 has size 1788 GB
Disk device nvme9n1 has size 1788 GB
Disk device sda has size 894 GB
Disk device sdb has size 894 GB
When I would highlight text in iterm2 to copy it, upon pasting it would always add a carriage return (line-break) at the end of the line. Thus the line that I copied would not be contiguous.
This is extremely annoying when attempting to copy log file contents.
The solution was simpler and somewhat counter intuitive.
In iterm2 there is an option under Preferences –> General –> Selection
It was seen recently on a T7000 whereby an Intel S2600TP system that boots and the only thing on the screen is the following with the number 26 in the lower right corner.
Text on the screen reads as:
Board Name S2600TP
Chipset initialization complete. No errors found.
26 (lower right hand corner).
CAUSE
I filed case 00556496 with Intel and the results were as follows:
POST code 26 indicates it may hang on to the Memory Reference Phrase (MRC) phase as MRC training is a failure. In this scenario, we recommend changing other DIMMs or boards.
SOLUTION
Replace the Memory, or since if Memory is not FRU, replace the controller.