Crash on Terastation Pro II

[DavidDah]

I'm not sure is this installer problem or partition manager issue, however after reformating partitions and creating software raid 10, md1 device started resyncing and then this problem occurred and terastation rebooted. I have kept existing partitions from stock firmware for /boot, just deleted everything else and created swap and another partition for / filesystem and tried to create RAID 10. I have used latest initrd.buffalo and uImage.buffalo from [(https://github.com/1000001101000/Debian_on_Buffalo/tree/master/Buster/installer_images/armel_devices)]

`[ 1 installer 2 shell 3- shell (4*log) ][ Oct 30 23:31 ] Oct 30 23:30:15 net/hw-detect.hotplug: Detected hotpluggable network interface eth0 Oct 30 23:30:15 net/hw-detect.hotplug: Detected hotpluggable network interface lo Oct 30 23:30:18 kernel: [ 720.909371] Adding 155644k swap on /dev/sda2. Priority:-1 extents:1 across:155644k FS Oct 30 23:30:18 kernel: [ 720.950322] Adding 155644k swap on /dev/sdb2. Priority:-2 extents:1 across:155644k FS Oct 30 23:30:18 kernel: [ 720.990655] Adding 155644k swap on /dev/sdc2. Priority:-3 extents:1 across:155644k FS Oct 30 23:30:18 kernel: [ 721.031660] Adding 155644k swap on /dev/sdd2. Priority:-4 extents:1 across:155644k FS Oct 30 23:30:52 partman-md: Set the sync speed for RAID devices to 1000 Oct 30 23:30:52 partman-md: Selected spare count: 0 Oct 30 23:30:52 partman-md: RAID devices count: 4 Oct 30 23:30:52 partman-md: Spare devices count: 0 Oct 30 23:30:52 partman-md: mdadm: /dev/sda3 appears to contain an ext2fs file system Oct 30 23:30:52 partman-md: size=487931904K mtime=Thu Jan 1 00:00:00 1970 Oct 30 23:30:52 partman-md: mdadm: /dev/sdb3 appears to contain an ext2fs file system Oct 30 23:30:52 partman-md: size=487931904K mtime=Thu Jan 1 00:00:00 1970 Oct 30 23:30:52 partman-md: mdadm: /dev/sdc3 appears to contain an ext2fs file system Oct 30 23:30:52 partman-md: size=487931904K mtime=Thu Jan 1 00:00:00 1970 Oct 30 23:30:52 partman-md: mdadm: /dev/sdd3 appears to contain an ext2fs file system Oct 30 23:30:52 partman-md: size=487931904K mtime=Thu Jan 1 00:00:00 1970 Oct 30 23:30:53 kernel: [ 755.716789] md/raid10:md1: not clean -- starting background reconstruction Oct 30 23:30:53 kernel: [ 755.716805] md/raid10:md1: active with 4 out of 4 devices Oct 30 23:30:53 partman-md: mdadm: array /dev/md/1 started. Oct 30 23:30:53 kernel: [ 755.787257] md1: detected capacity change from 0 to 999283490816 Oct 30 23:30:53 kernel: [ 755.791310] md: resync of RAID array md1 Oct 30 23:31:25 kernel: [ 788.212918] ------------[ cut here ]------------ Oct 30 23:31:25 kernel: [ 788.213098] WARNING: CPU: 0 PID: 7 at drivers/scsi/scsi_lib.c:1067 scsi_init_io+0x58/0x1c4 [scsi_mod] Oct 30 23:31:25 kernel: [ 788.213105] Modules linked in: raid10 dm_mod dax raid1 md_mod xfs libcrc32c vfat fat nls_base ext4 crc16 jbd2 crc32c_generic fscrypto ecb mbcache ipv6 af_packet marvell mvmdio mv643xx_eth sata_mv libata sd_mod scsi_mod leds_gpio Oct 30 23:31:25 kernel: [ 788.213239] CPU: 0 PID: 7 Comm: ksoftirqd/0 Not tainted 4.12.13 #3 Oct 30 23:31:25 kernel: [ 788.213247] Hardware name: Buffalo Terastation Pro II/Live Oct 30 23:31:25 kernel: [ 788.213291] [] (unwind_backtrace) from [] (show_stack+0x18/0x1c) Oct 30 23:31:25 kernel: [ 788.213323] [] (show_stack) from [] (warn+0xe8/0x104) Oct 30 23:31:25 kernel: [ 788.213352] [] (warn) from [] (warn_slowpath_null+0x24/0x2c) Oct 30 23:31:25 kernel: [ 788.213499] [] (warn_slowpath_null) from [] (scsi_init_io+0x58/0x1c4 [scsi_mod]) Oct 30 23:31:25 kernel: [ 788.213664] [] (scsi_init_io [scsi_mod]) from [] (sd_init_command+0x4f4/0xd90 [sd_mod]) Oct 30 23:31:25 kernel: [ 788.213821] [] (sd_init_command [sd_mod]) from [] (scsi_prep_fn+0x7c/0x104 [scsi_mod]) Oct 30 23:31:25 kernel: [ 788.213951] [] (scsi_prep_fn [scsi_mod]) from [] (blk_peek_request+0x11c/0x23c) Oct 30 23:31:25 kernel: [ 788.214081] [] (blk_peek_request) from [] (scsi_request_fn+0x28/0x6cc [scsi_mod]) Oct 30 23:31:25 kernel: [ 788.214207] [] (scsi_request_fn [scsi_mod]) from [] (blk_run_queue+0x3c/0x4c) Oct 30 23:31:25 kernel: [ 788.214235] [] (blk_run_queue) from [] (blk_run_queue+0x1c/0x24) Oct 30 23:31:25 kernel: [ 788.214356] [] (blk_run_queue) from [] (scsi_run_queue+0x274/0x278 [scsi_mod]) Oct 30 23:31:25 kernel: [ 788.214567] [] (scsi_run_queue [scsi_mod]) from [] (scsi_end_request+0x148/0x150 [scsi_mod]) Oct 30 23:31:25 kernel: [ 788.214775] [] (scsi_end_request [scsi_mod]) from [] (scsi_io_completion+0x244/0x524 [scsi_mod]) Oct 30 23:31:25 kernel: [ 788.214897] [] (scsi_io_completion [scsi_mod]) from [] (blk_done_softirq+0x98/0xa0) Oct 30 23:31:25 kernel: [ 788.214929] [] (blk_done_softirq) from [] (__do_softirq+0x1d4/0x2bc) Oct 30 23:31:25 kernel: [ 788.214961] [] (__do_softirq) from [] (run_ksoftirqd+0x2c/0x5c) Oct 30 23:31:25 kernel: [ 788.214995] [] (run_ksoftirqd) from [] (smpboot_thread_fn+0x178/0x180) Oct 30 23:31:25 kernel: [ 788.215030] [] (smpboot_thread_fn) from [] (kthread+0x124/0x13c) Oct 30 23:31:25 kernel: [ 788.215061] [] (kthread) from [] (ret_from_fork+0x14/0x24) Oct 30 23:31:25 kernel: [ 788.215073] ---[ end trace a43daefba01e5af5 ]---

`

[DavidDah]

BTW I just remember from 2 day's ago when i ended up in Marvell shell that it had option to save variables on persistent storage

saveenv - save environment variables to persistent storage setenv - set environment variables

Marvell>> help

? - alias for 'help' base - print or set address offset board_info -show board information. boot - boot default, i.e., run 'bootcmd' bootd - boot default, i.e., run 'bootcmd' bootend - with micon. send bootend. bootm - boot application image from memory bootp - boot image via network using BootP/TFTP protocol bubt - Burn an image on the Boot Flash. buzzer - with micon. buzzer command. cmp - memory compare cp - memory copy cpumap - Display CPU memory mapping settings. crc32 - checksum calculation date - get/set/reset date & time diskboot- boot from IDE device echo - echo args to console erase - erase FLASH memory ext2load- load binary file from a Ext2 filesystem ext2ls- list files in a directory (default /) fan_control - with micon. fan control . fan_rpm - with micon. fan get rpm. flinfo - print FLASH memory information get_sw - without micon. get switch status. go - start application at address 'addr' hdd_power - hdd power control . help - print online help ide - IDE sub-system led - without micon. call led control routine(for debug). led_blink - with micon. led blink control setting. led_cpu_mcon - with micon. led cpu micon control setting. led_on_off - with micon. led on off control setting. loop - infinite loop on address range md - memory display micon - with micon. command(2byte hex) -data(witin 32byte hex) mm - memory modify (auto-incrementing) mtest - simple RAM test mw - memory write (fill) nm - memory modify (constant address) pci - list and access PCI Configuraton Space printenv- print environment variables protect - enable or disable FLASH write protection rarpboot- boot image via network using RARP/TFTP protocol reset - Perform RESET of the CPU resetenv - Return all environment variable to default. saveenv - save environment variables to persistent storage setenv - set environment variables shutdown - with micon. Poff . sw_power - with micon. software power control interface tftpboot- boot image via network using TFTP protocol usb_power - without micon. usb power control . version - print monitor version

[1000001101000]

I usually just use the debian python3-serial package, I've had a lot of bad pip experiences.

I usually run it as: ./micon_dump.py

It could be that running with python3 and having the #! don't work together.... maybe.

You have the power to change environment variables with that prompt, you can also manually modify memory, overwrite the flash and lots of other fun things.... that can brick the device. It's too bad they don't post their uboot source, I'd love to actually work on a solution to the 7mb issues rather than just work around them.

[DavidDah]

This are the values which i got from micon_dump, (I had to remove all pip3 installed packages and use apt-get to get serial to work). If I compare this with https://buffalonas.miraheze.org/wiki/Terastation_Microcontroller_Interface i see that my TS does not show 0x28 value which is marked as shutdown_ups_recover. How could I test this value with micro-evtd ?

Address	R/W	Size	Name	Notes
0x31	R/W	1 Byte	lcd_set_linkspeed	0x00 = nolink, 0x01 = 10h, 0x02 = 10f, 0x03 = 100h, 0x04 = 100f, 0x05 = 1000
0x32	R/W	1 Byte	lcd_set_dispitem
0x33	R/W	1 Byte	fan_set_speed
0x34	R	1 Byte	system_get_mode	ups_vender=apc ups_linefail=off ups_shutdown=off lcd_change=5s lcd_fanspeed=off lcd_temp=off bz_dispbutton=on
0x35	R/W	1 Byte	system_set_watchdog
0x36	R/W	1 Byte	int_get_switch_status
0x37			temp_get
0x38*	R/W	1 Byte	fan_get_speed
0x39	R	1 Byte	lcd_get_dispplane
0x3a	R/W	1 Byte	lcd_set_bright	013AFA = bz_imhere
0x3b			hdd_set_power
0x3c			mcon_get_status
0x3d			ups_test_port
0x3e	R/W	1 Byte	usb_set_power
0x3f	R	1 Byte
0x50	R/W	2 Bytes	led_set_cpu_mcon
0x51	R/W	2 Bytes	led_set_on_off
0x52	R/W	2 Bytes	led_set_blink
0x53	R/W	2 Bytes	bz_set_freq, bz_melody
0x60	R/W	4 Bytes	lcd_set_disk_capacity
0x70	R/W	6 Bytes	lcd_set_date	one-byte each for year,month,day,hour,minute,second. Auto increments every second.
0x80	R/W	16 Bytes	lcd_set_hostname	ASCII, sets top row
0x81	R/W	16 Bytes	lcd_set_ipaddress	ASCII, sets bottom row
0x82	R/W	16 Bytes	lcd_set_raidmode	ASCII, sets top row of lcd raidmode
0x83	R	16 Bytes	mcon_get_version	model/version, example "TSQVL Ver1.5"
0x84	R	16 Bytes	mcon_get_taskdump
0x90	R/W	32 Bytes	???	sets lcd_buffer0
0x91	R/W	32 Bytes	???	sets lcd_buffer1
0x92	R/W	32 Bytes	???	sets lcd_buffer2
0x93	R/W	32 Bytes	boot_device_error	sets lcd_buffer0
0x94	R/W	32 Bytes	lcd_set_raidmode32	ASCII, 16 Characters per row

[1000001101000]

For a write operation the prefix is the length of what you're writing (00 for a simple command like boot_end or the one you're trying): micro-evtd -s 0028 micro-evtd -s 0003

here's an example of a 1-byte command (plays a sound): micro-evtd -s 013020

read operations always have a prefix of 80, for example this displays the version string returned by the mcu: micro-evtd -s 8083

The return codes are a little bit complicated ( I talk about them somewhat on the wiki page). If the command you submitted does not expect a value to be returned it returns a simple return code (0=ok 0xF*=some error). If it does expect a value it will either return that value or the one-byte error code. I'm not sure how you'd know the difference between a 1-byte response that just happens to be 0xF4 and a 0xF4 error code, but that doesn't really come up much.

[DavidDah]

root@debian:~# micro-evtd -s 0028 244

Is this good or bad response :)

[1000001101000]

244 = F4 which is an error code. For a length 0 write/command 0 = success.

[DavidDah]

So this code doesn't work for enabling shutdown ups recovery in ts2pro. Any other suggestions?

[1000001101000]

It might be worth playing around with in the stock firmware and confirm how it behaves (you may have already done this). Now that you have the serial console (we can build a copy of micro-evtd that will run in stock fw if needed) you might be able see more of what goes on when you trigger the functions in question. Then take another look at the stock init scripts surrounding ups and shutdown to see what is sent to /proc and the microcontroller (as much as possible). Some combination of that and looking closer at the stock kernel source should give us an idea what to try.

If you can confirm it's possible to make this model power on immediately after being plugged in under the stock firmware we can work on trying to replicate that. I'm reasonably certain the microcontroller is what powers on the rest of the board, it's just a matter of figuring out how it makes that decision.

[DavidDah]

I'm more than willing to try to find out how exactly it works, I will revert TS to stock firmware and we can get our hands dirty, If you like i can setup remote access for You to TS so you can poke around aswell :) BTW would it be possible to sniff traffic going to /dev/TTYS0 or TTYS1 so that we can see exactly what does stock firmware sends as parameter to enable this functionality and maybe some others aswell? My understanding is that userspace app (web gui) executes /usr/local/sbin/apcupsd which changes parametars in /proc/buffalo and that parameter get's passed to microcontroler, please correct me If I'm wrong with this assumption.

[1000001101000]

I think some of the relevant scripts, particularly startup/shutdown can be found somewhere under /etc/init.d or /etc/rc.d/.

It might be possible to find a place to attach logic probes to intercept the signals to the microcontroller but on most boards that's not easy. There are potentially other ways to snoop on the device but they are also complicated. Like we could try compiling a custom stock kernel that prints out info when those /proc drivers are used or other such tricks.

[DavidDah]

I just found another TS which hardware should be the same as tspov2, this model is terastation live HS-DHTGL/R5, this should be also ARM platform but i'm not sure are the boards the same. If they are I would like to use this one for test with stock firmware.

[1000001101000]

I've always assumed they were the same hardware but never confirmed. I'd appreciate it if you could confirm that the ts2pro debian stuff works on it as part of your testing.

I suspect it has slightly different stock firmware but probably close enough for the testing you want to do.

[DavidDah]

As far as I remember marketing materials from the time when they were released buffalo reps were claiming that it is the same hardware but just for 2 different markets (home and bussines). TS PRO Live didn't had support for Active directory in stock firmware.

[DavidDah]

I just replaced 2 hdd since they failed and i will have stock firmware running very soon.

[1000001101000]

They've done that for a bunch of models. My TS-XL is the "iscsi" variant for example.

[DavidDah]

It's the same Orion board like TS PRO v2?

[DavidDah]

BTW I found this link about HS DHTGL, it's on Japanese and it containts boot.log txt from Marvell bootloader, funny thing that in that boot log there is line Marvell Development Board (LSP Version 1.7.8_NAS)-- BUFFALO_BOARD_TS_HTGL_R5 https://mizupc8.bio.mie-u.ac.jp/pukiwiki/index.php?plugin=attach&refer=LinkStation%2FTeraStation%2F%E7%8E%84%E7%AE%B1%2FARM%2FHS-DHTGL%2FOriginalSoftware&openfile=boot.txt https://mizupc8.bio.mie-u.ac.jp/pukiwiki/index.php?LinkStation/TeraStation/%E7%8E%84%E7%AE%B1/ARM/HS-DHTGL#o611d44d

[1000001101000]

That site has a lot of good stuff for these older devices. For the even older devices most of the info is on a bunch of old japanese sites like that, many no longer online. It makes for an interesting challenge.

There’s a weird disconnect with this stuff. The folks who originally worked on this generation did a lot of great work, even got support added to the mainline linux kernel. For some reason when work was done to get all the orion5x/kirkwood linkstations supported in Debian the Terastation II/III weren’t included. Up till Stretch the ts2pro only really needed a flash-kernel entry.... too bad I only got involved as Buster was released.

[DavidDah]

It was really nice that buffalo added support to mainline linux kernel, but question is why didn't they do the last step to ts2pro. However problem with u-boot is still intriguing, do you know did buffalo released source for u-boot for some other models? Would it be possible to use config from some other model and maybe modify it slightly to work on tspro2?

[1000001101000]

I don't think Buffalo was involved in adding the mainline support, I think once Marvell added support for the Orion5x/Kirkwood SoCs folks ported a bunch of early devices and submitted that code to mainline as well.

Later device tree support was added for most kirkwood and orion5x SoCs which led to the effort to get them added too. The SoC for the Terastation II/III never got device tree support which is probably why they weren't included in that effort. It's just too bad they weren't since it wouldn't have been that hard at the time since the kernel code was already there.

I believe if you look on Buffalo's OSS site there is source for u-boot for the kirkwood linkstation devices. I don't think there were any others out there but I could be wrong. I know some of the later devices have code out there but it's just the mainline u-boot without any of buffalo's patches.

It's possible you'd be able to modify a u-boot from a similar device to work for this one, though that gets complicated fast. You'd also need a plan for re-flashing the bootloader without booting the device. (JTAG or chip programmer etc).

fixing the 7mb issue might be as simple as changing the initrd load address which would be easier. You just need to be careful in your testing since you need the device to still boot for you to activate the serial console.

[DavidDah]

I finally managed to get TS Live online, bad news is that it doesn't have option for ups_recovery in stock firmware, good news however is that it has /proc/buffalo/ups entries, iv tried simple things like which didn't work. root@HS-DHTGL217:~# echo on >/proc/buffalo/ups/ups_recover root@HS-DHTGL217:~# cat /proc/buffalo/ups/ups_recover
off

However I'm planning to try to flash tsprov2 firmware on it so we will know for sure is it the same board. Regarding JTAG, i have my soldering equipment here so i can solder port on the board. How can I send you remote access info so that you can poke around this device?

[1000001101000]

I’d recommend confirming you can dump the flash via jtag before you try flashing anything.

...that reminds me I got a cheap jtag device I haven’t tried yet.

If you want to try the other firmware on it you can usually run through the install on the device whose firmware you want, then swap the drive to the other device. At least that’s worked with the variants i’ve tried it with, I think it doesnt on some newer models.

Even then you can probably just tweak the uboot environment with out reflashing anything.

[DavidDah]

Im still stuck with trying to find out how this board works exactly in regard to ups_shutdown_recover, I have spent few day's researching what is going on with stock firmware, First time which struck me is that version of miconapl which is shipped with buffalo factory firmware 1.35-39 does not have ups_shutdown_recovery command

root@TS-HTGL217:/mnt/array1/share# strings /usr/local/sbin/miconapl |grep ups
serialmode_ups ups_linefail_off ups_linefail_on ups_vender_apc ups_vender_omron ups_shutdown_off ups_shutdown_on ups_test_port ups_linefail ups_test_apc_sd=%s ups_test_apc_lf=%s ups_test_omron_sd=%s ups_test_omron_lf=%s ups_vender=%s ups_linefail=%s ups_shutdown=%s

However entry for ups_shutdown_recover exist in /prob/buffalo/ups

I have notice that some people have used miconapl to activate ups_shutdown_recovery so naturally i downloaded firmware from LS-WSGL and tried to enable ups_shutdown_recovery which does not work on TS-HDTGL

http://bontakun.cocolog-nifty.com/blog/linkstation/index.html

root@TS-HTGL217:/mnt/array1/share# strings miconapl |grep ups ups_vender=%s ups_linefail=%s ups_shutdown=%s ups_test_apc_sd=%s ups_test_apc_lf=%s ups_test_omron_sd=%s ups_test_omron_lf=%s ups_linefail ups_shutdown shutdown_ups_recover serialmode_ups ups_linefail_off ups_linefail_on ups_vender_apc ups_vender_omron ups_shutdown_off ups_shutdown_on ups_test_port

root@TS-HTGL217:/mnt/array1/share# ./miconapl -a shutdown_ups_recover -d 1

SetDeviceName Initialize:/dev/ttyS1 AdvisoryLock (1) argCmd: argc=3 argv[0]=shutdown_ups_recover argv[1]=-d argCmd: opecode:0x28, opesize:0, write:1, read:0 ComSetSomeCommand: opecode:0x28, command_name:shutdown_ups_recover SendCmd: cmd=0x00 ope=0x28 len=0 CreatePacket CalcChecksum:len=2 checksum=0x28 Output (len=3) Output write result:3 RecvPacket Input:len=4 RecvPacket:len=4 AnalyzeRecvPacket:Compare Command 0x00 vs 0x00 AnalyzeRecvPacket:Compare Opecode 0x28 vs 0x28 AnalyzeRecvPacket:Compare Packet Length 0 vs 1 CalcChecksum:len=4 checksum=0x00 State: WRITE CMD ComSendCommandInternal: SendCommand Try 1(mode:0x00) SendCmd: cmd=0x00 ope=0x28 len=0 CreatePacket CalcChecksum:len=2 checksum=0x28 Output (len=3) Output write result:3 RecvPacket Input:len=4 RecvPacket:len=4 AnalyzeRecvPacket:Compare Command 0x00 vs 0x00 AnalyzeRecvPacket:Compare Opecode 0x28 vs 0x28 AnalyzeRecvPacket:Compare Packet Length 0 vs 1 CalcChecksum:len=4 checksum=0x00 State: WRITE CMD ComSendCommandInternal: SendCommand Try 0(mode:0x00) SendCmd: cmd=0x00 ope=0x28 len=0 CreatePacket CalcChecksum:len=2 checksum=0x28 Output (len=3) Output write result:3 RecvPacket Input:len=4 RecvPacket:len=4 AnalyzeRecvPacket:Compare Command 0x00 vs 0x00 AnalyzeRecvPacket:Compare Opecode 0x28 vs 0x28 AnalyzeRecvPacket:Compare Packet Length 0 vs 1 CalcChecksum:len=4 checksum=0x00 State: WRITE CMD SendNop: cmd=0xff CreatePacket SendNop: NOP send. Output (len=32) Output write result:32 SendCmd: cmd=0x00 ope=0x28 len=0 CreatePacket CalcChecksum:len=2 checksum=0x28 Output (len=3) Output write result:3 RecvPacket Input:len=4 RecvPacket:len=4 AnalyzeRecvPacket:Compare Command 0x00 vs 0x00 AnalyzeRecvPacket:Compare Opecode 0x28 vs 0x28 AnalyzeRecvPacket:Compare Packet Length 0 vs 1 CalcChecksum:len=4 checksum=0x00 State: WRITE CMD ComSendCommandInternal: SendCommand Re-Try 1(mode:0x00) SendCmd: cmd=0x00 ope=0x28 len=0 CreatePacket CalcChecksum:len=2 checksum=0x28 Output (len=3) Output write result:3 RecvPacket Input:len=4 RecvPacket:len=4 AnalyzeRecvPacket:Compare Command 0x00 vs 0x00 AnalyzeRecvPacket:Compare Opecode 0x28 vs 0x28 AnalyzeRecvPacket:Compare Packet Length 0 vs 1 CalcChecksum:len=4 checksum=0x00 State: WRITE CMD ComSendCommandInternal: SendCommand Re-Try 0(mode:0x00) SendCmd: cmd=0x00 ope=0x28 len=0 CreatePacket CalcChecksum:len=2 checksum=0x28 Output (len=3) Output write result:3 RecvPacket Input:len=4 RecvPacket:len=4 AnalyzeRecvPacket:Compare Command 0x00 vs 0x00 AnalyzeRecvPacket:Compare Opecode 0x28 vs 0x28 AnalyzeRecvPacket:Compare Packet Length 0 vs 1 CalcChecksum:len=4 checksum=0x00 State: WRITE CMD ComSetShutdownUpsRecover GpioWrite AdvisoryLock (0)

Only note of miconapl in /etc/init.d/ups are this lines d# cat ups|grep miconapl MICONAPL="/usr/local/sbin/miconapl" /usr/local/sbin/miconapl -a ups_linefail_off /usr/local/sbin/miconapl -a ups_shutdown_on

Interesting thing is how buffalo changed software for communication between TS and UPS in different versions of their firmwares. They started by using APCUPS on early models of TS and firmwares such is ts pro 2, then they added omrond which seems to be obsolete and very simple daemon for communication with UPS devices made by Japanese company Omron. However due to the limitations of APCUPSD when it comes to support of UPS from other vendors they have switched to another open source project with is NUT (Network UPS tools) which supports communication over UPS, different rules and communication over IP network. Examining conf file from TS-1200 firmware (/etc/inid.d/ups) does not show any traces of miconapl however miconapl resides in /usr/local/sbin and supports ups_shutdown_recover option.

Summary here is that I'm not any closer to solving this challenge, different UPS control software versions in different firmwares do not communicate with Marvell board, obviously that is done with miconapl binary which in version for ts pro2 do not have ups_shutdown_recovery option. However that option is obviously available in firmwares for older and never models of terastations.

On the other side stock kernel of tspro v2 (TS_HDTGL) containes entries in /proc which points that ups_shutdown_recover function should be available on that device. If You have any other idea in which direction I could go to enable that board to power on after power is restored I would appreciated it much.

[1000001101000]

Sounds like you're looking in the right places.

Could you describe in detail the behavior that the device is demonstrating under the stock firmware that it isn't currently under debian? Please include what shows on the LCD and serial console output if possible.

Here's a static-linked version of micro-evtd that might work on the stock firmware which you could use to enable the serial console for testing if needed: micro-evtd.gz

You could probably do the same with the stock miconapl tool though I've never tried that. Let me know if the version I attached doesn't work, I can try building with an older gcc if needed.

[1000001101000]

I finally got around to fixing the installer issue you reported.

I still don't actually understand why micro-evtd is failing (other than my new port detection logic must not be as good as the old logic). For now I just added logic to have it try twice with a delay in between which seems to be enough to make it succeed reliably. Eventually I'll revisit the actual micro-evtd logic to make it more robust.

The new images should now have the kernel with the patch too.

[1000001101000]

I was just doing some other work on my Terastation II and noticed that when I plugged it in that it powered on right away without pushing the power button. I don't think it used to do this and am assuming it is the result the testing we were doing. Is this something you're still looking into?

[ksuuk]

@DavidDah

I have TS-RHTGL/R5 F/W 1.35 and as it's samba does only support v1, which Apple dropped and as I have not found any suitable custom samba build with v2 support, then I have plan to install Debian instead.

I found Your guide - https://github.com/DavidDah/Debian_on_Buffalo/wiki/How-to-install-Debian-on-TeraStation-PRO-II-TS-HTGL-R5 but is this guide final and working or I need (if yes, then what?) take some guidance also from this thread?

@1000001101000

BTW, as device does have USB port, is it possible to install Debian into USB stick and boot from it and just mount the existing raid array and that's it?

[1000001101000]

Good to hear from you!

I'm embarrassed to say I don't remember all the context behind that guide being created. It should work but also seems more complicated than is needed.

I think the important point is that the buffalo firmware's rootfs partitioning is too small for debian so you need to wipe it out and replace it with a bigger version. This can be done inside the installer if needed.

That device's bootloader is hard-coded to boot from the hard drives, I don't think there's a way to make it boot from USB.

[ksuuk]

@1000001101000

I managed to install Debian to TS-RHTGL/R5, some notices:

Instructions (https://github.com/DavidDah/Debian_on_Buffalo/wiki/How-to-install-Debian-on-TeraStation-PRO-II-TS-HTGL-R5) say's that for / and /boot Raid1 is used, but images are showing that / and /boot are using Raid10. Images are false, device won't boot with Raid10.

My goal was to use max space for array, so I used smaller partitions:

/boot    300MB
/        2GB
swap     100MB

As swap is multiplied by four, so total mounted swap is 400MB:

              total        used        free      shared  buff/cache   available
Mem:          121Mi        40Mi        38Mi       8.0Mi        42Mi        67Mi
Swap:         379Mi       6.0Mi       373Mi

And after default install + some extra packages , /boot and / are still having enough free space:

Filesystem          Size  Used Avail Use% Mounted on
udev                 53M     0   53M   0% /dev
tmpfs                30M  8.9M   22M  30% /run
/dev/md1            1.8G  955M  773M  56% /
tmpfs                61M     0   61M   0% /dev/shm
tmpfs               5.0M     0  5.0M   0% /run/lock
tmpfs                61M     0   61M   0% /sys/fs/cgroup
/dev/md0            267M   27M  227M  11% /boot
tmpfs                13M     0   13M   0% /run/user/0

Tested array with ext3/ext4 (disk size 912G, available 866G) and stayed with xfs (disk size 927G, available 927G), as it's format is fast and it maximizes the available space.

Installed and set cryptsetup for array, as hardware is weak, so no speed is expected (but still enough as overnight backup device), and as it does not have built-in aes (which is crypsetup -s default, but very slow choise) support, so after testing multiple settings, I choose custom cipher (twofish-xts-plain64) and sector size (4096), cryptsetup benchmark results are:

Tests are approximate using memory only (no storage IO).
PBKDF2-sha1        28568 iterations per second for 256-bit key
PBKDF2-sha256      47976 iterations per second for 256-bit key
PBKDF2-sha512      24380 iterations per second for 256-bit key
PBKDF2-ripemd160   21501 iterations per second for 256-bit key
PBKDF2-whirlpool    6068 iterations per second for 256-bit key
argon2i       4 iterations, 10680 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      4 iterations, 10822 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
      Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b         5.9 MiB/s         6.3 MiB/s
    serpent-cbc        128b         5.1 MiB/s         7.1 MiB/s
    twofish-cbc        128b         7.5 MiB/s         7.9 MiB/s
        aes-cbc        256b         5.4 MiB/s         5.7 MiB/s
    serpent-cbc        256b         5.1 MiB/s         7.1 MiB/s
    twofish-cbc        256b         7.5 MiB/s         7.9 MiB/s
        aes-xts        256b         6.3 MiB/s         6.3 MiB/s
    serpent-xts        256b         7.5 MiB/s         7.1 MiB/s
    twofish-xts        256b         7.3 MiB/s         7.9 MiB/s
        aes-xts        512b         5.7 MiB/s         5.8 MiB/s
    serpent-xts        512b         7.5 MiB/s         7.1 MiB/s
    twofish-xts        512b         7.3 MiB/s         7.9 MiB/s

Checked and disabled unwanted services:

systemctl --type=service --state=active

systemctl kill --kill-who=all apt-daily.service
systemctl kill --kill-who=all apt-daily-upgrade.service

systemctl stop apt-daily.timer
systemctl disable apt-daily.timer
systemctl stop apt-daily.service
systemctl disable apt-daily.service

systemctl stop apt-daily-upgrade.timer
systemctl disable apt-daily-upgrade.timer
systemctl stop apt-daily-upgrade.service
systemctl disable apt-daily-upgrade.service
systemctl daemon-reload
systemctl reset-failed

rm /etc/systemd/system/timers.target.wants/apt-daily.timer
rm /etc/systemd/system/timers.target.wants/apt-daily-upgrade.timer

mv /usr/lib/apt/apt.systemd.daily /usr/lib/apt/apt.systemd.daily.DISABLED
mv /lib/systemd/system/apt-daily.service /lib/systemd/system/apt-daily.service.DISABLED
mv /lib/systemd/system/apt-daily.timer /lib/systemd/system/apt-daily.timer.DISABLED
mv /lib/systemd/system/apt-daily-upgrade.service /lib/systemd/system/apt-daily-upgrade.service.DISABLED
mv /lib/systemd/system/apt-daily-upgrade.timer /lib/systemd/system/apt-daily-upgrade.timer.DISABLED

[DavidDah]

Hello ksuuk, I took your suggestions and revisited that guide and updated it for Debian 12 (bookworm), Idea beahind that guide is to help people who are little bit less tech savy or have totally bricked TS devices to install debian on them. That's the reason why guide is so detailed. It's more work in progress than finished guide, but I hope it will help someone who wants to repair it's TS.