{"title":"frankie-tales","id":"https:\/\/lovergine.com\/feeds\/tags\/debian.xml","subtitle":"Tag: debian","updated":"2026-06-07T07:00:01Z","link":[{"@attributes":{"href":"https:\/\/lovergine.com\/feeds\/tags\/debian.xml","rel":"self"}},{"@attributes":{"href":"https:\/\/lovergine.com"}}],"entry":[{"title":"A Terramaster NAS with Debian, take two.","id":"https:\/\/lovergine.com\/a-terramaster-nas-with-debian-take-two.html","author":{"name":"Francesco P. Lovergine","email":"mbox@lovergine.com"},"updated":"2026-01-19T13:00:00Z","link":{"@attributes":{"href":"https:\/\/lovergine.com\/a-terramaster-nas-with-debian-take-two.html","rel":"alternate"}},"content":"

After experimenting at home, the very first professional-grade NAS from\nTerramaster arrived at work, too, with 12 HDD bays and possibly a pair of M2s.\nNVME cards. In this case, I again installed a plain Debian distribution, but HDD\nmonitoring required some configuration adjustments to run smartd<\/code> properly.<\/p>

A decent approach to data safety is to run regularly scheduled short and long\nSMART tests on all disks to detect potential damage. Running such tests on all\ndisks at once isn't ideal, so I set up a script to create a staggered\nconfiguration and test multiple groups of disks at different times. Note that it\nis mandatory to read the devices at each reboot because their names and order\ncan change.<\/p>

Of course, the same principle (short\/long test at regular intervals along the\nweek) should be applied for a simpler configuration, as in the case of my home\nNAS with a pair of RAID1 devices.<\/p>

What follows is a simple script to create a staggered smartd.conf<\/code> at boot\ntime:<\/p>

#!\/bin\/bash\n#\n# Save this as \/usr\/local\/bin\/create-smartd-conf.sh\n#\n# Dynamically generate smartd.conf with staggered SMART test scheduling\n# at boot time based on discovered ATA devices\n\n# HERE IS A LIST OF DIRECTIVES FOR THIS CONFIGURATION FILE.\n# PLEASE SEE THE smartd.conf MAN PAGE FOR DETAILS\n#\n#   -d TYPE Set the device type: ata, scsi[+TYPE], nvme[,NSID],\n#           sat[,auto][,N][+TYPE], usbcypress[,X], usbjmicron[,p][,x][,N],\n#           usbprolific, usbsunplus, sntasmedia, sntjmicron[,NSID], sntrealtek,\n#           ... (platform specific)\n#   -T TYPE Set the tolerance to one of: normal, permissive\n#   -o VAL  Enable\/disable automatic offline tests (on\/off)\n#   -S VAL  Enable\/disable attribute autosave (on\/off)\n#   -n MODE No check if: never, sleep[,N][,q], standby[,N][,q], idle[,N][,q]\n#   -H      Monitor SMART Health Status, report if failed\n#   -s REG  Do Self-Test at time(s) given by regular expression REG\n#   -l TYPE Monitor SMART log or self-test status:\n#           error, selftest, xerror, offlinests[,ns], selfteststs[,ns]\n#   -l scterc,R,W  Set SCT Error Recovery Control\n#   -e      Change device setting: aam,[N|off], apm,[N|off], dsn,[on|off],\n#           lookahead,[on|off], security-freeze, standby,[N|off], wcache,[on|off]\n#   -f      Monitor 'Usage' Attributes, report failures\n#   -m ADD  Send email warning to address ADD\n#   -M TYPE Modify email warning behavior (see man page)\n#   -p      Report changes in 'Prefailure' Attributes\n#   -u      Report changes in 'Usage' Attributes\n#   -t      Equivalent to -p and -u Directives\n#   -r ID   Also report Raw values of Attribute ID with -p, -u or -t\n#   -R ID   Track changes in Attribute ID Raw value with -p, -u or -t\n#   -i ID   Ignore Attribute ID for -f Directive\n#   -I ID   Ignore Attribute ID for -p, -u or -t Directive\n#   -C ID[+] Monitor [increases of] Current Pending Sectors in Attribute ID\n#   -U ID[+] Monitor [increases of] Offline Uncorrectable Sectors in Attribute ID\n#   -W D,I,C Monitor Temperature D)ifference, I)nformal limit, C)ritical limit\n#   -v N,ST Modifies labeling of Attribute N (see man page)\n#   -P TYPE Drive-specific presets: use, ignore, show, showall\n#   -a      Default: -H -f -t -l error -l selftest -l selfteststs -C 197 -U 198\n#   -F TYPE Use firmware bug workaround:\n#           none, nologdir, samsung, samsung2, samsung3, xerrorlba\n#   -c i=N  Set interval between disk checks to N seconds\n#    #      Comment: text after a hash sign is ignored\n#    \\      Line continuation character\n# Attribute ID is a decimal integer 1 <= ID <= 255\n# except for -C and -U, where ID = 0 turns them off.\n\nset -euo pipefail\n\n# Test schedule configuration\nBASE_SCHEDULE="L\/..\/..\/6"  # Long test on Saturdays\nTEST_HOURS=(01 03 05 07)   # 4 time slots: 1am, 3am, 5am, 7am\n\nDEVICES_PER_GROUP=3\n\nmain() {\n    # Get array of device names (e.g., sda, sdb, sdc)\n    mapfile -t devices < <(ls -l \/dev\/disk\/by-id\/ | grep ata | awk '{print $11}' | grep sd | cut -d\/ -f3 | sort -u)\n\n    if [[ ${#devices[@]} -eq 0 ]]; then\n        exit 1\n    fi\n\n    # Start building config file\n    cat << EOF\n# smartd.conf - Auto-generated at boot\n# Generated: $(date '+%Y-%m-%d %H:%M:%S')\n#\n# Staggered SMART test scheduling to avoid concurrent disk load\n# Long tests run on Saturdays at different times per group\n#\nEOF\n\n    # Process devices into groups\n    local group=0\n    local count_in_group=0\n\n    for i in "${!devices[@]}"; do\n        local dev="${devices[$i]}"\n        local hour="${TEST_HOURS[$group]}"\n\n        # Add group header at start of each group\n        if [[ $count_in_group -eq 0 ]]; then\n            echo ""\n            echo "# Group $((group + 1)) - Tests at ${hour}:00 on Saturdays"\n        fi\n\n        # Add device entry\n        #echo "\/dev\/${dev} -a -o on -S on -s (${BASE_SCHEDULE}\/${hour}) -m root"\n        echo "\/dev\/${dev} -a -o on -S on -s (L\/..\/..\/6\/${hour}) -s (S\/..\/..\/.\/$(((hour + 12) % 24))) -m root"\n\n        # Move to next group when current group is full\n        count_in_group=$((count_in_group + 1))\n        if [[ $count_in_group -ge $DEVICES_PER_GROUP ]]; then\n            count_in_group=0\n            group=$(((group + 1) % ${#TEST_HOURS[@]}))\n        fi\n    done\n}\n\nmain "$@"<\/code><\/pre>
To run such a script at boot, add a unit file to the systemd configuration.<\/p>
sudo systemctl  edit --full \/etc\/systemd\/system\/regenerate-smartd-conf.service\nsudo systemctl enable regenerate-smartd-conf.service<\/code><\/pre>
Where the unit service is the following:<\/p>
[Unit]\nDescription=Generate smartd.conf with staggered SMART test scheduling\n# Wait for all local filesystems and udev device detection\nAfter=local-fs.target systemd-udev-settle.service\nBefore=smartd.service\nWants=systemd-udev-settle.service\nDefaultDependencies=no\n\n[Service]\nType=oneshot\n# Only generate the config file, don't touch smartd here\nExecStart=\/bin\/bash -c '\/usr\/local\/bin\/create-smartd-config.sh > \/etc\/smartd.conf'\nStandardOutput=journal\nStandardError=journal\nRemainAfterExit=yes\n\n[Install]\nWantedBy=multi-user.target<\/code><\/pre>"},{"title":"DebianGis anniversary and the power of being a community","id":"https:\/\/lovergine.com\/debiangis-anniversary-and-the-power-of-being-a-community.html","author":{"name":"Francesco P. Lovergine","email":"mbox@lovergine.com"},"updated":"2025-10-16T18:15:00Z","link":{"@attributes":{"href":"https:\/\/lovergine.com\/debiangis-anniversary-and-the-power-of-being-a-community.html","rel":"alternate"}},"content":"
A few days before today, 21 years ago, I sent\nthis message<\/a>\nto the debian-devel-announce<\/em> mailing list to solicit helpers in packaging and\nto oversee the geospatial software stack included in the main Debian archive.\nAfter so many years, still there.<\/p>
At that time, the Debian project had already been around for more than 10 years\nand even had a few releases behind, but the typical maintenance of software was\nstill a one-person show, except for a few large and complex pieces of software.\nEven the kernel was managed by a single developer, Herbert Xu. Each developer\nwas responsible for implementing updates, fixing bugs, and releasing updates.\nOften jealous of such prerogatives and their stated possession of the package\nor task. While there was already a quality assurance team and an orphaning\nprocess for abandoned packages (or inactive developers), these processes were\nnot very common and were even relatively slow and imperfect.<\/p>
Since that time, team-based maintenance has become the standard approach in the\nDebian community for properly managing the most complicated software\ncollections. That's at least to ensure proper long-term maintenance,  because\nthe average developer can provide only a limited continuity to their efforts,\nand real life is generally more complicated than the digital one. It is not\nsecondary that packaging tasks can be tedious in the long term, and it is easy\nto lose motivation. The presence of a working team can reduce the risk of\nburnout and allow each developer to step down when needed. The most effective\nteam should be small enough to coordinate more easily and avoid lagging in\nchanges and migrations, but not too small: presenting a one-person show as a\nteam work is not a great idea. But too many people in the same team is equally\nnot a great idea for the opposite reason.<\/p>
In the specific case of Debian, the system is so modular and lacks many\ninterdependencies that it favors the creation of fully independent management\ngroups for hundreds of components and ecosystems of packages. It is not casual\nthat most of the bugs and inconsistencies are concentrated where too many parts\nneed to interact appropriately with perfectly aligned programming interfaces.<\/p>
Talking about DebianGis and the geospatial software, the key motivation at the\ntime was the lack of a coordinated effort to build and collect together, with\nconsistency, a lot of different libraries and programs that were (and still\nare) specialized enough and based on hundreds of dependencies, often not within\nthe perimeter of competence of the geodata user. At that time, piling up the\nsoftware stack of a typical geospatial application was not an easy task for the\nfaint of heart, and most (all?) of the Linux distributions lacked in one way or\nanother.<\/p>
Anecdotally, I can remember about 15 years ago, the company that sold us a Suse\nEnterprise-based solution for a geospatial information system that had so many\nproblems in completing the required setup that I finally created a chroot-based\nenvironment with a Debian stable plain install to run a working PostGIS DBMS.\nThat was the time when containerized solutions were still far from being\nsupported, so the chroot environment was the most immediate solution to such a\nproblem.  A little win for a community-based distribution and its tiny\ngeospatial team, which provides a measure of the problems at the time. A giant\nstep for the whole FOSS concept.<\/p>
I'm currently much less active in packaging tasks, but still seeing the current\nteam alive and capable of releasing well-supported products more than twenty\nyears later gives me reason to be proud of such a community.<\/p>"},{"title":"Installing Debian on a USB stick for a Terramaster NAS","id":"https:\/\/lovergine.com\/installing-debian-on-a-usb-stick-for-a-terramaster-nas.html","author":{"name":"Francesco P. Lovergine","email":"mbox@lovergine.com"},"updated":"2025-10-15T18:00:00Z","link":{"@attributes":{"href":"https:\/\/lovergine.com\/installing-debian-on-a-usb-stick-for-a-terramaster-nas.html","rel":"alternate"}},"content":"
I recently bought a basic NAS for home use. The NAS is a nice Terramaster\nF2-425<\/a>, which is a very\nbasic RAID1-only NAS with a decent CPU and 2.5Gb network. Terramaster allows\nusers to either use its custom Linux-based TOS or install any other operating\nsystem supported by the x86_64-based platform. Note that this model does not\nmount any NVME unit for the OS, as for the F2-424.<\/p>
Common choices include TrueNas, Proxmox, or any other Linux-based distribution.\nMy choice has been a plain Debian stable distribution because I do not have\nspecial requirements and prefer a lightweight CLI-only solution over a\ndashboard. The F2-425 does not have NVME cards, only regular HDDs\/SSDs.\nHowever, when installing an independent OS, as in my case, you can immediately\nuse an external USB stick for the system, and dedicate HDDs to data. The unit\neven has a tiny (264MB) internal USB stick for installing TOS, but I simply\nused a decent 16GB SanDisk thumb drive. The clear advantage is the possibility\nof having the base system and data perfectly separated, and multiple copies of\nthe stick for safety.<\/p>
Of course, the installation of such a system can be done without using the\nDebian installer at all, so I'm describing here how to perform such an\ninstallation for my future reference and for other geeks. Of course, you need a\nrunning Linux system with debootstrap<\/em> installed. The process involves\npartitioning the stick in GPT mode, installing the base system and EFI, and\nconfiguring the system to finalize a bootable system with the necessary\nsoftware to connect the NAS to the network, including OpenSSH.<\/p>
Note that the 2.5 Gb Ethernet is a RealTek, so a firmware blob\n(firmware-realtek package on Trixie) is required to properly work with that.\nAlternatively, another of the USB ports could also be used to add a wireless\nconnection. The OS stick could be simply mounted on the internal port, but it\nrequires opening the chassis for that and using a tiny stick.<\/p>
At power-on, the internal TOS dongle automagically boots up, so connecting an\nHDMI display and a keyboard is required to change the setup to boot the Debian\nEFI image on the stick. On F2-425, press the <F12><\/code> key to access the AMI setup\nand change boot priorities. There are always slight differences among AMI BIOS\nsetups, so it is required to find the right key to access settings and change\nboot options.<\/p>
Let's consider \/dev\/sde as the name of the USB stick device on the host where\nit will be prepared. A GPT partition can be created via GNU parted, as follows:<\/p>
parted \/dev\/sde \t# to create EFI and root primary partition\npartprobe --summary \/dev\/sde\nsfdisk -l \/dev\/sde\nmkfs.vfat -F 32 \/dev\/sde1\nmkswap \/dev\/sde2\nmkfs.ext4 \/dev\/sde3<\/code><\/pre>
Once done, installing the base system is immediate.<\/p>
mount \/dev\/sde3 \/mnt\nmount \/dev\/sde1 \/mnt\/boot\/efi\ndebootstrap trixie \/mnt\n\nmount -o bind \/dev \/mnt\/dev\nmount -t devpts devpts \/mnt\/dev\/pts\nmount -t proc proc \/mnt\/proc\nmount -t sysfs sysfs \/sys \/mnt\/sys\nmount -t tmpfs run \/mnt\/run\n\ncp \/etc\/apt\/sources.d\/debian.sources \/mnt\/etc\/apt\/sources.d\/.\ncp \/etc\/resolv.conf \/mnt\/etc\/.\n\necho "nas" > \/mnt\/etc\/hostname\nsed -i -e 's\/localhost$\/localhost\\n127.0.0.1\\tnas\/' \/mnt\/etc\/hosts\n\nrootfs=$(blkid \/dev\/sde | grep TYPE=\\"ext4\\"|awk '{print $2}'|cut -d\\" -f2)\nvfat=$(blkid \/dev\/sde|grep TYPE=\\"vfat\\"|awk '{print $2}'|cut -d\\" -f2)\nswap=$(blkid \/dev\/sde|grep TYPE=\\"swap\\"|awk '{print $2}'|cut -d\\" -f2)\n\ncat >\/mnt\/etc\/fstab <<EOF\nUUID=$rootfs \/ ext4 noatime,errors=remount-ro 0 1\nUUID=$vfat \/boot\/efi vfat noatime,umask=0077 0 1\nUUID=$swap none swap sw 0 0\nEOF\n\nchroot \/mnt\napt update\napt upgrade -y\napt install grub-efi-amd64 linux-image-amd64 ssh \\\n        firmware-misc-nonfree \\\n        firmware-realtek xfsprogs rsync pmount \\\n        gddrescue screen util-linux-extra bash-completion \\\n \tmdadm  parted smartmontools htop ntp unattended-upgrades sudo\nuseradd -m -G sudo -s \/bin\/bash -C 'Your Name' your_username \npasswd your_username\nadduser your_username plugdev\napt install tzdata locales\ndpkg-reconfigure locales\ngrub-install --target=x86_64-efi --force-extra-removable \/dev\/sde\nupdate-initramfs -u\napt clean\nexit # leave the chroot\numount \/mnt\/run\numount \/mnt\/sys\/firmware\/efi\/efivars\numount \/mnt\/sys\numount \/mnt\/proc\numount \/mnt\/dev\/pts\numount \/mnt\/dev\n<\/code><\/pre>
Note that required HDDs can be easily installed later. I manually configured\nthe two disks with GNU parted for a GPT Linux RAID partition.  After booting\nwith the stick, a simple install of the md array support suffices.  Typically,\nthe USB stick runs as \/dev\/sdd<\/code><\/p>
sudo mdadm --create \/dev\/md0 --level=1 --raid-devices=2 \/dev\/sda1 \/dev\/sdb1\nmkfs.xfs \/dev\/md0\nmkdir \/data\ndata=$(blkid \/dev\/md0|grep TYPE=\\"xfs\\"|awk '{print $2}'|cut -d\\" -f2)\necho "UUID=$data \/data xfs defaults 1 1" >>\/etc\/fstab<\/code><\/pre>
In order to allow shutting down by pressing the power button, it is required to\nconfigure systemd-logind<\/code> as follows.<\/p>
sed -i -e 's\/^#HandlePowerKey=poweroff'\/HandlePowerKey=poweroff\/ \\\n       -e 's\/^#HandlePowerKeyLongPress=ignore\/HandlePowerKeyLongPress=ignore\/ \\\n    \/etc\/systemd\/logind.conf\n\nsystemctl restart systemd-logind.service<\/code><\/pre>
It could also be a good idea to stop the periodic auto-scan on the RAID volume\nfor big disks, which can take ages to run.<\/p>
sed -i -e 's\/^AUTOCHECK=true\/AUTOCHECK=false\/' \/etc\/default\/mdadm\nsystemctl restart mdmonitor.service<\/code><\/pre>
The network configuration depends definitively on the type of connection used\nand the home network setup. In my case, the NAS uses a static IPv4\naddress, so it can be configured through ifupdown<\/code>, and it is only necessary\nto correctly write the \/etc\/network\/interfaces<\/code> for the enp1s0<\/code> Realtek 2.5Gb\nEthernet interface. Not that it requires a non-free firmware blob to run.<\/p>
After the initial syncing, a series of software to better manage the NAS can be\ninstalled, but that is optional and can be the subject of a different post. For\nsure, for better convenience, a copy of the USB stick with the complete\nconfiguration is a good idea, to allow a fast recovery in case of failures.<\/p>"}]}