Post Installation Options - 1000001101000/Debian_on_Buffalo GitHub Wiki
1. If you had raid arrays defined at install time the installer should have installed mdadm, if not install it:
apt-get install mdadm
2. Use mdadm to scan for existing raid arrays (presumable the ones you set up while on stock firmware)
~# mdadm --detail --scan ARRAY /dev/md0 metadata=0.90 UUID=8de323cf:21f920b7:2776d444:be501e4f ARRAY /dev/md1 metadata=1.2 UUID=e82d03b7:a7afdb01:663e8e97:125fc7c9 ARRAY /dev/md20 metadata=1.2 UUID=116997d2:e7f48544:24542b4e:8e4c2e18
3. Edit /etc/mdadm/mdadm.conf, make sure there is a line for each array listed by the command from the previous step. 4. If you had to make changes, generate a new initramfs and reboot.
update-initramfs -u reboot
5. You should now see all the arrays listed in /sys/block
ls /sys/block
6. Presumably you'll already have used some of these arrays as your /boot,/ and swap during install and don't need to configure them further, if you have a data array/disk create a mountpoint for it similar to:
mkdir /mnt/array
7. If you are trying to setup an array created by the stock firmware it is probably formatted as xfs, install the xfs utilities to manage it.
apt-get install xfsprogs
8. Try mounting your array manually using the device name listed in /sys/block and the mount point you created.
mount /dev/md20 /mnt/array
9. Assuming this succeeded verify the filesystem of the array.
~# mount | grep /mnt/array /dev/md20 on /mnt/array type xfs (rw,relatime)
10. Unmount the array
umount /dev/md20
11. Create an entry for the array in /etc/fstab using the info gathered above
/dev/md20 /mnt/array xfs defaults 0 2
12. Verify your fstab entry works by mounting the array
mount /mnt/array
13. Generate a new initramfs that accounts for the new configuration
update-initramfs -u
note: make certain any fstab entries you add are working properly before rebooting. If the system is unable to mount all the filesystems the default behavior is to stop the boot process. If this happens you'll need to remove the fstab entry (likely by connecting the drive to another system) to make the system bootable again. You can avoid this situation entirely by adding the "nofail" option so that system continues booting with out the filesystem or even the "noauto" option which requires you to manually mount it as needed. Personally, I just make sure to test my fstab entries whenever I make a change and manually fix the fstab if I get into trouble.
This version of the debian installer will download and install the latest version of all packages except the kernel. You can upgrade it to the latest version for the distro with:
apt-get upgrade linux-image-armmp
You will have to do this in the future when you want to update to the latest kernel.
note: updating the distro's kernel should be safe but installing the "backports" kernel requires additional steps. Since you are basically installing the kernel for a newer distro you also need the DTB files from that newer kernel (ie you need to put Buster's DTBS in /etc/flash-kernel/dtbs/ before trying to upgrade to the stretch-backports kernel).
If something goes wrong with upgrading/installing a new kernel you can always connect the drive(s) to another system (or load the installer environment via TFTP, etc) and restore the uImage.buffalo.bak and initrd.buffalo.bak from the last working kernel.
If your looking to use your device as a Samba server you'll need to do a bit of setup to get it working. The following seems to be a pretty good guide: https://www.bleepingcomputer.com/forums/t/598615/a-simple-beginners-guide-to-setting-up-a-samba-share/
One helpful hint is that samba includes the testparm utility which will validate your smb.conf and display any error/warnings encountered trying to parse it.
For most devices the fans are automatically set to "high" at boot. For many devices this is fine since it gives maximum cooling and isn't too loud, but for some devices/situations it is desirable to turn them down if the temperature is low enough.
For most devices the fans are controlled via the gpio-fan driver. Their reported speed can be seen using lmsensors which is installed by the installer:
~# sensors
...
gpio_fan-isa-0000
Adapter: ISA adapter
fan1: 5000 RPM (min = 0 RPM, max = 5000 RPM)
The fancontrol package can be used to automatically adjust the fan speeds:
apt-get install fancontrol
pwmconfig
***follow the prompts to set the temperature/fan speed settings
For devices using the on-board microcontroller (mainly Terastations) the fan speed is controlled by the microcontroller. The installer sets up a "fan daemon" script on these devices that automatically adjusts the fan speed based on simple temperature thresholds. These thresholds can be adjusted by editing:
/etc/micon_fan.conf
After making changes, restart the daemon or restart the device:
systemctl restart micon_fan_daemon
I've done my best to map all the LEDs which are controlled by the system's GPIO controller in the device tree so that they can be used directly (on some models some are controlled by a separate microcontroller or directly by the sata controller). The entries for the LEDs can be found under /sys/class/leds/. They can be toggled on and off by setting their "brightness":
~# echo 1 > /sys/class/leds/led\:function\:white/brightness ~# echo 0 > /sys/class/leds/led\:function\:white/brightness
I've generally set the power led to "on" in the device trees and have left all other leds to "off". You can set the leds to use a trigger like disk activity or network activity to control it. To see a list of available triggers for the current kernel:
~# cat /sys/class/leds/led\:function\:white/trigger
To change it:
~# echo disk-activity > /sys/class/leds/led\:function\:white/trigger
This project included examples of how to set the LEDs via a python script. see: https://github.com/1000001101000/Python_buffalo_libmicon
Buttons and drive detection are mapped the same way in the device trees. One way to use them is using something called TriggerHappy.
Install TriggerHappy:
apt-get install triggerhappy
Events can be associated with buttons by running the following command and pushing buttons on the device.
thd --dump /dev/input/event*
You can then setup thd to run certain scripts when a given button is pressed. see: http://manpages.ubuntu.com/manpages/bionic/man1/thd.1.html
This project included examples of how to detect button presses via a python script. see: https://github.com/1000001101000/Python_buffalo_libmicon
For most newer devices the SoC has a built in temperature sensor whose values can be read with lmsensors:
~# sensors
armada_thermal-virtual-0
Adapter: Virtual device
temp1: +50.1°C
For the TS-XEL and other older Terastations the temperature sensor is only accessible via the on-board microcontroller. see:
https://github.com/1000001101000/Python_buffalo_libmicon
Most of these devices have a RS5C372 realtime clock module (except LS200 and TS-XEL) but currently Debian does not include support for it in their kernel. To prevent the time from defaulting to 1/1/1970 the installer installs ntp and fake-hwclock to ensure the clock defaults to the time at the last shutdown and then updates from the internet.
If you would like to use the RS5C372 you can enable it's support by compiling the appropriate kernel module (this is what I do for hardware testing). I created a script that automates the process of building and installing individual modules, it's published at:
https://github.com/1000001101000/Debian_Module_Builder
The required option is CONFIG_RTC_DRV_RS5C372=y which is included as one of the examples in the script.
from @vale-max: at boot time the module is enabled after the kernel tries to pick up the HW clock time, so system time is not updated until fake-hwclock or ntp come into play. see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855203
I circumvented this problem by adding the following udev rule as suggested in this forum post: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855203
KERNEL=="rtc0", RUN+="/sbin/hwclock --rtc=$root/$name --hctosys"
You can install Webmin on Debian if you prefer to have a user interface (UI) to perform actions on the device. Steps can be found at https://www.webmin.com/deb.html.
The default theme for Webmin is the Authentic Interface. If Webmin is slow to respond, you may need to switch to a lightweight theme, such as the Gray Framed theme or even the legacy theme. https://doxfer.webmin.com/Webmin/Change_Language_and_Theme
If you prefer to keep the Authentic Interface, you can save some system resources and completely disable any background pulling by opening browser console (F12) and executing:
settings_side_slider_background_refresh_time = 0;
theme.config.save();
You can set up automatic security updates in Webmin by following these steps: https://guides.wp-bullet.com/configure-automatic-security-updates-with-webmin/
Here's a good tutorial for automatic updates via the CLI: https://www.linode.com/docs/guides/how-to-configure-automated-security-updates-debian/