Notes and Stuff
Set the pretty format:
git log --color --graph --pretty=format:'%Cred%h%Creset %Cgreen(%cr) %C(bold blue)<%an>%Creset -%C(yellow)%d%Creset %s' --abbrev-commit
Create an alias:
git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset %Cgreen(%cr) %C(bold blue)<%an>%Creset -%C(yellow)%d%Creset %s' --abbrev-commit"
DisplayCAL relies on Python2, which is not supported since Fedora 32.
You can download the required packages compiled for Fedora 31, that will work for versions 32/33/34:
wget https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/31/Everything/x86_64/os/Packages/p/python2-wxpython-3.0.2.0-26.fc31.x86_64.rpm https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/31/Everything/x86_64/os/Packages/p/python2-gobject-3.34.0-3.fc31.x86_64.rpm https://archives.fedoraproject.org/pub/archive/fedora/linux/releases/31/Everything/x86_64/os/Packages/p/python2-gobject-base-3.34.0-3.fc31.x86_64.rpm https://rpmfind.net/linux/fedora/linux/releases/31/Everything/x86_64/os/Packages/p/python2-gobject-3.34.0-3.fc31.x86_64.rpm https://displaycal.net/download/Fedora_31/x86_64/DisplayCAL.rpm
After updating a server, rebooting it to load the new Kernel, removing the old Kernel and rebooting again, I got the GRUB minimal BASH-like prompt (I still can’t understand why, honestly), as if GRUB wasn’t able to see any info on how it should load the Kernel and the OS.
I know I could be very distracted but deleting all the Kernels seemed a little too much so I tried to manually boot the Kernel.
First, I checked what GRUB could see:
grub> ls (hd0) (hd0,msdos1) (hd0,msdos2)
Listed the content of the disks to see what files were present and determine which one was the root filesystem:
grub> ls (hd0,1)/ lost+found/ vmlinuz-5.10.21-200... initramfs-5.10.21-200....img vmlinuz-0-rescue... initramfs-0-rescue....img
Set it as boot volume:
grub> root=(hd0,msdos1)
Loaded the Kernel image and RAM disk:
grub> linux /vmlinuz-5.10.21-200... root=/dev/sda1 grub> initrd initramfs-5.10.21-200....img
And finally booted the system:
grub> boot
Just in case, I also created a new GRUB config based on the currently running system:
grub2-mkconfig -o /boot/grub2/grub.cfg
While trying to update a CentOS server I got this error:
[root@washingmashine ~]# yum update error: rpmdb: BDB0113 Thread/process 47226/140411903506496 failed: BDB1507 Thread died in Berkeley DB library error: db5 error(-30973) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery error: cannot open Packages index using db5 - (-30973) error: cannot open Packages database in /var/lib/rpm CRITICAL:yum.main: Error: rpmdb open failed
The RPM database seemed corrupted.
First, I deleted the DB:
[root@washingmashine ~]# rm -rf /var/lib/rpm/__db*
Then I used the rpm --rebuilddb command to rebuild it.
After extending a virtual drive on VMWare, I had to add the additional disk space to the logical volume.
After adding adding the space, you need to resize the file system. On the infrastructure I was working on, I usually use resize2fs command but this time it didn’t work:
[root@washingmashine ~]# resize2fs /dev/mapper/data-archive
resize2fs 1.44.6 (5-Mar-2019)
resize2fs: Bad magic number in super-block while trying to open
/dev/mapper/data-archive
Couldn't find valid filesystem superblock.
The resize2fs program will resize ext2, ext3, or ext4 file systems; I took for granted that LVM was using a ext4 fs but I was wrong:
[root@washingmashine ~]# mount | grep data-archive
/dev/mapper/data-archive on / type xfs (rw,relatime,...
XFS fs has its own command set; in this case I had to use the xfs_growfs command:
[root@washingmashine ~]# xfs_growfs /dev/mapper/data-archive
File system resized!
ip -s neighbour flush all
By default, logrotate runs once a day, using a cron scheduler from /etc/cron.daily/
# ls /etc/cron.daily/ logrotate
/etc/logrotate.conf:$ cat /etc/logrotate.conf # see "man logrotate" for details # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # create new (empty) log files after rotating old ones create # use date as a suffix of the rotated file dateext # uncomment this if you want your log files compressed #compress # RPM packages drop log rotation information into this directory include /etc/logrotate.d # system-specific logs may be also be configured here.
I’ve been having problems with incrond for months; after trying to upgrade from version 0.5.10, incrond would not trigger after a specified event occurred in the monitored path.
After upgrading to version 0.5.12-9 (I couldn’t use 0.5.10 because of security policies), incrond has started behaving in a completely random way: sometimes it was triggered as expected but some other times (way too many), nothing was happening.
This was the entry in incrontab:
/home/elena/upload IN_CLOSE_WRITE /bin/find $@ -type f -exec /bin/chmod g+rw {} \+
Writing a script and adding it to crontab was out of question; here is where systemd came in handy, with path units.
A .path unit (systemd.path) monitors a file or directory and it calls a .service unit (systemd.service), usually with the same name, when something happens to the monitored file or directory.Continue reading