mardi 15 décembre 2020

New M2.2280 SSD

Installed a 2nd 512GB SSD in the laptop.  Easy peasy.  After a week or so, rebooted in single user mode and unmounted it, then cleanup of the underlying old "/home" directory, then restarted again (thus reclaimed a few dozen GB from the first SSD).

lundi 30 novembre 2020

Databases "hot" backup : PostgreSQL

I hadn't installed Postgres in a while and apparently my current software stack doesn't require it.  So I first had to install from the repos:

sudo apt-get install postgresql

I loaded some sample data using a tutorial available from https://www.postgresqltutorial.com/load-postgresql-sample-database.  However I had to fix the "CREATE DATABASE" statement in this file, apparently the codepage 1252 is specified (Windows) and my Linux Mint PostgreSQL didn't like it.  So :

  • CREATE DATABASE dvdrental WITH TEMPLATE = template0 ENCODING = 'UTF8' LC_COLLATE = 'English_United States.1252' LC_CTYPE = 'English_United States.1252';
was replaced by:
  • CREATE DATABASE dvdrental WITH TEMPLATE = template0 ENCODING = 'UTF8';

The pg_dumpall command is supposedly able to backup everything.  Trying manually first:

  • sudo -u postgres pg_dumpall -f /var/tmp/postgres.backup.`date +%Y%m%d_%H%M%S`.psql
That worked fine, so added it in postgres's crontab:
$ sudo mkdir /var/backups/postgres
$ sudo chown postgres:postgres /var/backups/postgres
$ sudo crontab -lu postgres
# m h  dom mon dow   command
50 16 * * *  pg_dumpall -f /var/backups/postgres/postgres.backup.`date +%Y%m%d_%H%M%S`.psql
Well now that doesn't work anymore, for some reason the datestamp part of the command doesn't work quite right under cron.  So I wrote a short script to do it:
$ more dailybackup.sh
#! /bin/sh

pg_dumpall -f /var/backups/postgres/postgres.backup.`date +%Y%m%d_%H%M%S`.psql

That's OK now.

$ sudo crontab -lu postgres
# m h  dom mon dow   command
10 17 * * * /home/luc/Projects/dvdrentals/dailybackup.sh
$ ls -l /var/backups/postgres
total 96
-rw-rw-r-- 1 postgres postgres 45710 nov.  30 17:06 postgres.backup.20201130_170614.psql
-rw-rw-r-- 1 postgres postgres 45710 nov.  30 17:10 postgres.backup.20201130_171001.psql

 

lundi 23 novembre 2020

/var was still too small...

 

So : 

mkdir  /var/backups/urbackup/tmp

chown urbackup:urbackup  /var/backups/urbackup/tmp

Then in  /etc/default/urbackupsrv :

 DAEMON_TMPDIR="/var/backups/urbackup/tmp"


Current disks installed in backup server

sda

  • small 150GB Hitachi system disk
  • includes root, swap and /var partitions
  • Linux should be able to boot from just this disk
luc@kid2:~$ sudo fdisk -l /dev/sda
Disk /dev/sda: 149,5 GiB, 160041885696 bytes, 312581808 sectors
Disk model: Hitachi HDP72501
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x676b6100

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda1  *           63  25173854  25173792   12G 27 Hidden NTFS WinRE
/dev/sda2        25174016 193069055 167895040 80,1G 83 Linux
/dev/sda3       193071104 201860166   8789063  4,2G 82 Linux swap / Solaris
/dev/sda4       233072640 312581807  79509168 37,9G 83 Linux 

sdb

  • smallish 300GB Seagate system disk
  • used by a /home partition
  • any data remaining on this partition should probably migrate to the laptop (or external)
luc@kid2:~$ sudo fdisk -l /dev/sdb
Disk /dev/sdb: 298,9 GiB, 320072933376 bytes, 625142448 sectors
Disk model: ST320DM000-1BC14
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0008daeb

Device     Boot Start       End   Sectors   Size Id Type
/dev/sdb1  *     2048 625141759 625139712 298,1G 83 Linux

sdc

  • 2TB Seagate system disk, recently installed
  • is BTRFS devid 2
  luc@kid2:~$ sudo fdisk -l /dev/sdc
Disk /dev/sdc: 1,84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: ST2000DM001-1ER1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

sdd

  • 2TB HP system disk, recently reformatted
  • is BTRFS devid1
 luc@kid2:~$ sudo fdisk -l /dev/sdd
Disk /dev/sdd: 1,84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: MB2000GDUNV
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

samedi 21 novembre 2020

Adding a second drive to BTRFS

luc@kid2:~$ sudo btrfs device add -f /dev/sdc /var/backups/urbackup/
luc@kid2:~$ sudo btrfs fi show
Label: none  uuid: 9c8025a0-5351-4807-b7ac-97ffa87ededa
        Total devices 2 FS bytes used 447.00GiB
        devid    1 size 1.82TiB used 450.02GiB path /dev/sdd
        devid    2 size 1.82TiB used 0.00B path /dev/sdc

vendredi 20 novembre 2020

Making room on /var for urbackup

Well /var/urbackup is now too small. Or rather, the / filesystem is (almost) full due to /var/log (4GB) and /var/urbackup (12GB) competing for getting a few more gigabytes from the 37GB root filesystem. It turns out I still have a Windows partition on /dev/sda2 (80GB) which isn't used anymore, never boots up, doesn't seem like it contains any valuable data... so perfect candidate for a new /var filesystem

  1. fdisk /dev/sda : change type to 83 for partition 2
  2. mkfs.ext4 /dev/sda2
  3. blkid /dev/sda2 and copy the UUID
  4. vi /etc/fstab and make a line to mount /var.  Stupid me, I had defined that line at the end of fstab, it should have been before the line for /var/backup/urbackup obviously

So after fixing this, urbackup should be able to take backups again.  But while I was there, I also opened the box and removed the failed Western Digital 2TB drive, and inserted a Seagate 2TB that I had lying around.  Looks like this is working fine now as a new /dev/sdc.  I will check it and then add it to the BTRFS later on.

 Also took note of /dev/sdd being labeled HP Enterprise 2TB.  This is the one still working fine after the WD disaster.

Re-create BTRFS lost filesystem

fdisk /dev/sdc, removed /dev/sdc1 partition so I can start over on the bare device. sdc is the Western Digital 2TB disk:
luc@kid2:~$ sudo fdisk -l /dev/sdc
Disk /dev/sdc: 1,84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD20EARX-00P
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Creating the first device on new BTRFS :
luc@kid2:~$ sudo mkfs.btrfs -f /dev/sdc
btrfs-progs v5.4.1 
See http://btrfs.wiki.kernel.org for more information.

Label:              (null)
UUID:               b12623df-e351-4d48-856b-867e38361682
Node size:          16384
Sector size:        4096
Filesystem size:    1.82TiB
Block group profiles:
  Data:             single            8.00MiB
  Metadata:         DUP               1.00GiB
  System:           DUP               8.00MiB
SSD detected:       no
Incompat features:  extref, skinny-metadata
Checksum:           crc32c
Number of devices:  1
Devices:
   ID        SIZE  PATH
    1     1.82TiB  /dev/sdc
So we have an unmounted btrfs filesystem, let's take note of the UUID and update fstab:
luc@kid2:~$ sudo btrfs fi show /dev/sdc
Label: none  uuid: b12623df-e351-4d48-856b-867e38361682
	Total devices 1 FS bytes used 128.00KiB
	devid    1 size 1.82TiB used 2.02GiB path /dev/sdc
luc@kid2:~$ sudo vi /etc/fstab     
luc@kid2:~$ sudo tail /etc/fstab 
UUID=2a51d4ad-e97f-4d6c-bde4-a44ebd1ff267 /home           ext4    defaults        0       2
# swap was on /dev/sdb3 during installation
UUID=5690db75-3d2a-4171-a789-b5179a501942 none            swap    sw              0       0
/dev/fd0        /media/floppy0  noauto    rw,user,noauto,exec,utf8 0       0

# urbackup data
UUID=b12623df-e351-4d48-856b-867e38361682 /var/backups/urbackup	btrfs defaults 0 3
#UUID=4881245e-bed5-4526-b9ff-3b5ba39b283d /var/backups/urbackup	btrfs defaults 0 3

luc@kid2:~$ sudo mount /var/backups/urbackup/
luc@kid2:~$ 
No error message. However the mount didn't happen. Apparently the system still "remembers" of a zombie BTRFS partition that used to be mounted there, from /dev/sdd. I could mount the new one (/dev/sdc) manually on another mount point (/mnt) but not on /var/backups/urbackup where I need it.

I ended up using fdisk to wipe out the BTRFS label (?) on /dev/sdd by creating then removing /dev/sdd1. After that I rebooted and the system happily mounted /dev/sdc thanks to my previous update in /etc/fstab. However there was another slight problem with permissions, the mount is only accessible by root after this point. It still needed some chown/chmod commands:

luc@kid2:/var/backups/urbackup$ sudo -u urbackup ls
luc@kid2:/var/backups/urbackup$ sudo -u urbackup touch a
touch: cannot touch 'a': Permission denied
luc@kid2:/var/backups/urbackup$ sudo chown root:urbackup .
luc@kid2:/var/backups/urbackup$ cd ..
luc@kid2:/var/backups$ sudo chmod g+w urbackup/
The Urbackup server immediately started backing up two clients. Unfortunately on one of them the external USB drive wasn't mounted so that failed. I restarted afterwards, and asked for a full backup. But that failed soon enough also, this time the new BTRFS file system had been remounted ro (readonly). Clearly something really wrong is going on with that disk drive (/dev/sdc):
luc@kid2:/var/log$ sudo fdisk /dev/sdc

Welcome to fdisk (util-linux 2.34).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

fdisk: cannot open /dev/sdc: Input/output error
So I started back doing the same BTRFS re-creation on /dev/sdd this time. That worked fine but of course I now have only half the capacity to take backups. It should be just enough though for the moment, the server displays statistics going up to 1701GB at the moment.

jeudi 22 octobre 2020

urbackup failures

File backups are failing now when the external drive isn't mounted. On the laptop it doesn't get mounted automatically (unless I access it via the file manager). On the desktop I usually never connect it anymore, so it's also never mounted. So at least on the desktop I removed the backup directory for it:
sudo urbackupclientctl remove-backupdir -d /media/luc/Sea

mardi 20 octobre 2020

SAMBA talking Linux to Linux

Well it kinda works... as long as you don't have french accents in your filenames :=<

Conclusion: reverted back to autofs and NFS in order to move files from WS1 to the laptop. Too much of a headache otherwise.

Linux Mint "personal" PATH. Also, chords!

From the default .profile created in my Linux Mint home directory:
# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi
So these are the preferred locations under Mint? Just moved my ~/System/bin folder under ~/.local/bin and that worked fine.

Also, chordii is available from the repo so no problem to reinstall it.

mardi 13 octobre 2020

Darktable 3.0.1 : move to external HDD and backup thereof

On WS1, moved 2020 RAW files to /media/luc/Sea/RAW/2020. Went fine (after moving the connection to a USB2 socket -- USB1.1 was sooo slooow). Then tried to backup WS1 including the external HDD. That didn't work after changing the urbackup server group configuration, even after restart of both server and client software (no reboot). So used urbackupclientctl add-backupdir on the client, to add the directory. That seems to do the trick.

lundi 12 octobre 2020

Darktable metadata import problem

 Looks like it has to be done a certain way in order to work as I want:

  • The "apply metadata on import" has to be unchecked (otherwise metadata gets set from the values in the various fields underneath)
  • The checkmark "to be imported" has to be checked in order for Darktable to read these fields from the imported file (and/or .XMP sidecar, if present)

dimanche 11 octobre 2020

Darktable 3.2.1

 On the Medion I installed 3.2.1 (WS1 still has 3.0.1).  Works fine.

  • I don't have my full set of hierarchical tags yet.  I guess that will be created as I import more photos with existing tags in them.
  • Took me a while to find how to configure Rapid Photo Downloader output directory structure.  I had missed the cog next to the directory name, where this can be defined
  • Same for the metadata export. Looks like it's now optional in Darktable 3.2.1 and needs to be activated.  Turns out there's also a cog wheel next to "Export" button, where this is defined.
  • Pay attention to import dialog : the metadata can be assigned there, field by field (looks like it could overwrite stuff).
  • A first attempt at importing 3.0.1 RAW files (with XMP) resulted in photos without metadata.  Reverted that.

samedi 10 octobre 2020

Linux Mint

Linux Mint installed fine on the E15302.  Not sure any GPU is being used at full potential but for the rest everything seems to work fine again.

Note to self: when "burning" an image to an USB stick, don't let it go into a partition : use the device name as output for cp or dd.  The UEFI stuff didn't accept any partitioning on the USB stick and refused to boot from it.

I received the USB/Ethernet hub : works fine.  Also received the 4TB external drive, works fine (on WS1 for now).  I have to test Darktable on the Medion then devise a migration strategy (!).

vendredi 9 octobre 2020

Medion E15302, my new laptop

Yes I have this Dell E6220 still working fine.  However due to the recent promotion at ALDI I am now also the owner of this Medion laptop for 599€.  AMD Ryzen 5 3500U, 16GB of DDR4 RAM, Full HD IPS 15.6" screen, SSD (512 GB), 16 GB, aluminium top plate.

Some serious drawbacks though:

  • Only 1 USB-C and 1 USB2 ports
  • No Ethernet port (Wifi only for the networking interface)
  • HDMI output (yes) but none other (VGA, DisplayPort, ...)
  • Hangs during Ubuntu install - so far - maybe due to the proprietary GPU.

For the ports issue I bought a combo USB3 x 3 ports + Gigabit Ethernet x 1 port, connected to the USB-C port.  So far so good.  I also ordered a USB3 external HDD (Seagate Backup Plus 4TB) including a small USB hub x 2 ports.  I might want to migrate to Bluetooth mice and keyboard in the future.  The main issue is still the Linux install.  Maybe I will try some other distro (Manjaro, Mint, Arch, ...)

Booting into UEFI works with holding F2 during power-on.


jeudi 8 octobre 2020

Umidigi A3X, my new smartphone

 Since two weeks I have received my new phone.  The previous one wasn't really broken but the side buttons (power and volume) had become flimsy and had their own life without me pushing any of them.  So it was slowly beginning to get me mad using the phone.

I looked at what was available and my requirements included RAM (> 2GB), a recent "clean" Android release, a fingerprint sensor, a good camera, a nice screen, storage expansion via microSD...

I settled on the Umidigi A3X, with 3GB RAM and all my other requirements above plus some.  Man I was happy I did.  The phone is pretty nice and works very well since I have it (two weeks of almost constant daily use).  However the battery will not last an entire day if you use it really constantly -- but what i mean is I am using it very frequently for relatively short periods of time all over the day (phone calls, e-Mail, SMS, chats, RSS feeds mainly).

I also use it for GPS functions (when hiking or mountain biking).  I use navigation apps (OSMAND) and also as GPS tracker.  I find the GPS very accurate and reliable compared to my previous phone.

I am a hobbyist photographer, so having a perfect smartphone camera wasn't really a requirement for me (I have enough good cameras already) but my phone had to have some decent camera so I can take a picture when I'm out and the camera is in the bag or at home.  Well simply said, this is the best smartphone camera that I have owned since I use smartphones (and I started in 2010).

Build quality and ergonomics seem fine to me.  The size is perfect (a tad smaller than my previous phone) and fits nicely in my shirt pocket or other small places.

So far I'm pretty happy with this purchase and I would certainly recommend it.