Debian in Buffalo LS-CHL-v2

[mailminhthang]

Hi I don't see LS-CHL-v2 firmware in your list of files. Is it possible to install Debian in it ? I see some guide lines in Google search but they are too old and seem to be not ok now Thanks so much

[1000001101000]

Debian hosts there own installer for this device, though you should be careful using it: http://ftp.nl.debian.org/debian/dists/buster/main/installer-armel/current/images/kirkwood/network-console/buffalo/ls-chlv2/

The problem is that the mainline device tree for this device has the polarity of that fan backwards. As a result if you use software to control the fan speed bad things could happen (turning off the fan when it should run high). As long as you don't install fan-control it should default to running at full speed (although sensors will say that it stopped).

systemd will also run into some memory issues which can be corrected by running the following as root: echo "tmpfs /run tmpfs nosuid,noexec,size=26M,nr_inodes=4096 0 0" >> /etc/fstab mount -o remount tmpfs

I actually do have an installer under the armel_devices section of Buster for this device which attempts to fix these issues but I don't believe it has been tested with this device and may not work. You could try that one first via TFTP, if it fails to boot I can do some tests on my end to try to fix it.

[mailminhthang]

Thanks for your guide I will try to do soon

[mailminhthang]

I try in my LS-CHL-V2, it installs debian in "Low memory mode" and takes so so long time (some days) to install. So I surrender now, back to buffalo nas firmware. Thanks again

[1000001101000]

That usually only happens if you don't have a swap partition. Normally the installer will detect and use the existing swap partition if there is one, otherwise you should be able to create one early in the install process.

[mailminhthang]

I already created swap partition manually before. I think the main reason is RAM of LS-CHL-v2 is too small to install

[1000001101000]

64mb devices like this one work but only with an active swap partition (1GB works, smaller might too). I've done it with even less powerful devices like the LS-GL without issue.

[mailminhthang]

How many time did you spend to install debian on this device ?

[1000001101000]

I just gave it a try and ran into the issue's you've described with the installer provided by Debian. I ended up having to drop to a shell and manually enable swap to even get the partitioner. I didn't continue from there (yet).

I also confirmed my installer image won't boot :(

I'm going to take a closer look at the issue and see if I can get my installer working for this device. If so I can add some logic to the startup to allow low-memory mode to work better for this device.

[mailminhthang]

I back to nas buffalo firmware because I think it better and more stable. If you have time you can try more, if you don't have much time you can stop and close this question. Anyway I also would like to say thank you

[1000001101000]

No problem.

I'll put a note here when I get around to fixing this issue for the ls-chlv2 and ls-xl (and probably others).

[mailminhthang]

No problem.

I'll put a note here when I get around to fixing this issue for the ls-chlv2 and ls-xl (and probably others).

That's great !

[mailminhthang]

Hi Mr.1000001101000 Is it possible to install Debian OS to usb storage in Buffalo Nas, I see every Nas has USB port ? Thanks

[1000001101000]

Not without making modifications to the boot loader.

So far I have completely avoided making any boot loader changes as part of this project due to the risk of rendering the devices unable to boot. This could be worked around with a functioning serial console but Buffalo makes it very difficult to make the serial console work on these device, requiring soldering that is beyond my skill set.

To make it work you'd need:

• Ensure the uboot on the device supports usb (many older ones likely don't)
• Configure uboot to power the usb ports at start (this is difficult on some boards)
• change the uboot variables to boot from usb

In the past I have run the OS on USB temporarily on these devices by doing the following:

• install rootfs, boot partition and swap on RAID1 arrays
• create equivalent partitions on USB device and add to the RAID1 array
• remove all the other disks from the arrays

This can be useful for running read/write tests on your OS drives. But you need to get the boot/roofs/swap back on the hard disk before rebooting.

[mailminhthang]

I have LS-CHL-v2 and LS410d and I hope can test usb-OS in LS410d but your explain seem to be quite complex to do Thanks

[1000001101000]

I ended up figuring out the issues related to the debian installer and devices with 64mb of ram like the lschlv2. I've now got a separate "lowmem" version of the installer published which activates swap before starting the ssh server to prevent early crashes. Thee install process ends up taking many hours to complete. I don't see many options for speeding things up, but the devices seem to run fine once the install completes.

In case you feel like trying again with this device, it's now supported.

[mailminhthang]

Ok, I will try to test again Thanks

[mailminhthang]

Install hangs at "disk partition" after few steps

login as: installer installer@192.168.1.140's password: /var/run/utmp: No such file or directory [ (0start) ][ Jan 01 0:04 ] [ 0- start (2shell) ][ Jan 01 0:04 ] [ 0 start 2- shell (3shell) ][ Jan 01 0:04 ] [ 0 start 2 shell 3- shell (4log) ][ Jan 01 0:04 ] [ 0 start (1shell) 2 shell 3 shell 4- log ][ Jan 01 0:04 ] [ 2 shell 3 shell (4log) ][ May 23 7:23 ] Low memory mode

[ 2 shell 3- shell (4*log) ][ May 23 7:27 ] May 23 07:23:46 kernel: [ 347.960042] 9290 total pagecache pages May 23 07:23:46 kernel: [ 347.960049] 0 pages in swap cache May 23 07:23:46 kernel: [ 347.960057] Swap cache stats: add 0, delete 0, find 0/0 May 23 07:23:46 kernel: [ 347.960062] Free swap = 0kB May 23 07:23:46 kernel: [ 347.960067] Total swap = 0kB May 23 07:23:46 kernel: [ 347.960072] 16384 pages RAM May 23 07:23:46 kernel: [ 347.960077] 0 pages HighMem/MovableOnly May 23 07:23:46 kernel: [ 347.960082] 1600 pages reserved May 23 07:23:46 kernel: [ 347.960087] Tasks state (memory values in pages): May 23 07:23:46 kernel: [ 347.960093] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name May 23 07:23:46 kernel: [ 347.960114] [ 49] 0 49 1551 591 14336 0 -1000 systemd-udevd May 23 07:23:46 kernel: [ 347.960129] [ 99] 0 99 535 349 8192 0 0 syslogd May 23 07:23:46 kernel: [ 347.960144] [ 101] 0 101 535 362 10240 0 0 klogd May 23 07:23:46 kernel: [ 347.960160] [ 1585] 0 1585 1914 1003 14336 0 0 haveged May 23 07:23:46 kernel: [ 347.960175] [ 1594] 0 1594 535 365 10240 0 0 debian-installe May 23 07:23:46 kernel: [ 347.960190] [ 1601] 0 1601 704 442 10240 0 0 screen May 23 07:23:46 kernel: [ 347.960205] [ 1602] 0 1602 869 657 12288 0 0 screen May 23 07:23:46 kernel: [ 347.960220] [ 1604] 0 1604 535 370 8192 0 0 sh May 23 07:23:46 kernel: [ 347.960235] [ 1605] 0 1605 535 361 10240 0 0 sh May 23 07:23:46 kernel: [ 347.960250] [ 1606] 0 1606 535 283 10240 0 0 tail May 23 07:23:46 kernel: [ 347.960265] [ 1607] 0 1607 1603 833 14336 0 0 debconf May 23 07:23:46 kernel: [ 347.960280] [ 1613] 0 1613 536 369 10240 0 0 main-menu May 23 07:23:46 kernel: [ 347.960295] [ 3487] 0 3487 476 341 8192 0 0 udpkg May 23 07:23:46 kernel: [ 347.960310] [ 3488] 0 3488 535 377 8192 0 0 network-console May 23 07:23:46 kernel: [ 347.960325] [ 3501] 0 3501 1354 714 12288 0 -1000 sshd May 23 07:23:46 kernel: [ 347.960340] [ 3517] 0 3517 1354 1005 12288 0 0 sshd May 23 07:23:46 kernel: [ 347.960355] [ 3520] 0 3520 535 359 8192 0 0 debian-installe May 23 07:23:46 kernel: [ 347.960370] [ 3526] 0 3526 743 504 10240 0 0 screen May 23 07:23:46 kernel: [ 347.960385] [ 3527] 0 3527 1010 768 14336 0 0 screen May 23 07:23:46 kernel: [ 347.960400] [ 3529] 0 3529 535 325 8192 0 0 sh May 23 07:23:46 kernel: [ 347.960414] [ 3530] 0 3530 535 337 10240 0 0 sh May 23 07:23:46 kernel: [ 347.960430] [ 3531] 0 3531 535 310 8192 0 0 tail May 23 07:23:46 kernel: [ 347.960445] [ 3532] 0 3532 1745 1024 12288 0 0 debconf May 23 07:23:46 kernel: [ 347.960460] [ 4689] 0 4689 476 356 8192 0 0 udpkg May 23 07:23:46 kernel: [ 347.960475] [ 4690] 0 4690 535 334 8192 0 0 disk-detect May 23 07:23:46 kernel: [ 347.960490] [ 4701] 0 4701 535 385 10240 0 0 hw-detect May 23 07:23:46 kernel: [ 347.960505] [ 4704] 0 4704 800 657 12288 0 0 depmod May 23 07:23:46 kernel: [ 347.960515] Out of memory: Kill process 3532 (debconf) score 69 or sacrifice child May 23 07:23:46 kernel: [ 347.960553] Killed process 3532 (debconf) total-vm:6980kB, anon-rss:1584kB, file-rss:2512kB, shmem-rss:0kB

[1000001101000]

it's all about swap, for these devices there must already be a swap partition when you boot. which partition is your swap partition?

[mailminhthang]

Yes, I use blank hard disk without swap partition. So after that I try with you suggest, steps are below: step 1) create 3 partitions boot, /, swap in hard disk by external tool step 2) down load your image file from https://github.com/1000001101000/Debian_on_Buffalo/tree/master/Buster/installer_images/armel_devices/lowmem step 3) tftp, transfers 2 files to nas lschl-v2 step 4) nas get new IP via DHCP step 5) sshd is up and I can ssh from my PC, LED is from blue to red. I try many times, sometime this step takes 5, 10 min., sometime it takes 45 min. (during this time, LED is blue, and I can't ssh to nas). It's so stranger step 6) ssh from PC to nas with installer/install and start to install step 7) "Partition disks": if I select "no format, keep data" for partitions, install is halted, if I select "format", it can continue step 8) "Install the base system": it's nightmare, it takes some hours to get from 0% to 93% of task and it stays several hours at 93%, nothing to change. And I can't wait more.

I think your new files is not better than the old. So if you already successfully install on LSCHL-V2, could you please share me image file of your disk (same as ghost file of your hdd) ? Thanks so much

[1000001101000]

yeah, I think the process ends up taking like 20 hours. I'm thinking it's best to start it and let it run over night.

I'm not looking to get in the habit of providing disk partitions, though I wonder if one that's already available from Raspbian/etc might make a decent alternative. That was how I first got an LS400 on Stretch after various deboostrap guides I followed wouldn't work.

[1000001101000]

This looks promising: https://github.com/TheSin-/rpi-img-builder

[mailminhthang]

I'm not very clear with your point. It stucks during install, not 20h only. So I think clone image is temporary solution. Tks

[1000001101000]

I put together a script that can be used to generate a full disk image instead of going through the typical installer process. It's a much easier method for these low memory devices and may have some advantages for others as well.

It requires being run from a PC running linux (Debian or similar). To install the prereqs:

apt-get install qemu-user-static debootstrap qemu-system-arm
git clone --depth 1 https://github.com/1000001101000/Debian_on_Buffalo
cd Debian_on_Buffalo/Tools/debootstrap

you can then customize the variables at the top of generate_disk_image.sh to adjust the desired partition sizes as well as choosing the target device, Debian version, root password, etc. The default is already configured for the lschlv2.

then run the script to build the image (it takes a while depending on the speed of your PC but only took ~15min on my chromebook): ./generate_disk_image.sh

When it's done you'll have a disk image you can write to hard drive which will then be ready to place in your device and boot: dd if=debian_buster_armel.img of=/dev/sdx bs=1M

Give it a try and let me know what you think.

[bcoff12]

I will give this a try.

[mailminhthang]

I applied new image and my LSCHL is up successfully, now I'm monitoring.

[mailminhthang]

It runs smoothly. This is the best way to install in lowmem device. Thanks

[1000001101000]

Nice!

[bcoff12]

Ok, finally had a chance to do this for LS-XL.

Used the following:

set some vars.

target="/mnt/target"

target_hostname="lschlv2"

target_hostname="ls410d"

machine="Buffalo Linkstation LS-CHLv2"

machine="Buffalo Linkstation LS410D"

target_hostname="lsxl" machine="Buffalo Linkstation LS-XL" arch="armel"

arch="armhf"

target_rootpw="supersecret" target_user="ifd" target_userpw="supersecret"

distro="stretch"

distro="buster" boot_size="512" swap_size="1024" root_size="2048" use_raid="N"

Image had MD5 of 22e025c2360ed903adc847fbb62cdd1a. It didn't boot (and I don't believe it got into a reboot loop.)

Any suggestions?

Thanks again for doing this!

[1000001101000]

I don't see any obvious issue based on the parameters.

For these the MD5 won't tell us anything (they will all be unique). The output from running the script might tell us what happened if the problem occurred with the build. i should probably try to add some success/fail detection logic to parts of it at some point.

one reason for a boot loop would be the image not being completely written to the disk (like if it was disconnected early). Basically anything that would result in a valid boot partition but a corrupt rootfs would result in a boot loop. I'd suggest trying to write it to disk again and wait ~5minutes after dd returns before unplugging the drive. If that still fails try running it again and capture the output.

In the meantime I'm take your parameters and try running it to see if i run into the same issue or not.

[bcoff12]

Standby... I had a bunch of errors when I regenerated the disk img... anything in /usr/sbin wasn't found. I don't know how I didn't see this before.

[1000001101000]

For me the process completed and i was able to boot it successfully (on an ls-chlv2)

Let me know what you find error-wise. I tested the script on a second machine at one point to try to ensure I wasn't missing any pre-reqs but I haven't done it on a totally clean install. It could be there's something else we need to add to the setup instructions.

~$ ssh ifd@lschl
Warning: Permanently added 'lschl,192.168.1.203' (ECDSA) to the list of known hosts.
ifd@lschl's password: 
Linux lsxl 4.19.0-9-marvell #1 Debian 4.19.118-2 (2020-04-29) armv5tel

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
ifd@lsxl:~$ cat /proc/device-tree/   
#address-cells    aliases/          compatible        gpio_leds/        mbus@f1000000/    model             ocp@f1000000/     
#size-cells       chosen/           cpus/             interrupt-parent  memory/           name              restart_poweroff/ 
ifd@lsxl:~$ cat /proc/device-tree/model 
Buffalo Linkstation LS-XL
ifd@lsxl:~$

[bcoff12]

My basic problem was /usr/sbin missing from path. I have a booted device now. Thanks!

[1000001101000]

I have finally trained my self to always su - or sudo su - etc to avoid that very problem. It took nearly a year to get to that point though.

This does remind me I need to finish writing up the wiki page for this process and start promoting it more. It's got some real advantages over the installer route for certain scenarios like this one.

[1000001101000]

Is there anything else you want me to look at for this?

I'm looking to close out some issues.

[marklam]

FYI: The generate_disk_image.sh script can also work from the Windows Subsystem for Linux v2 (wsl2). I used a Debian install from the Microsoft Store, and installed and started genie, so that the /dev/disk/by-uuid nodes get populated. Once all the required tools are installed in the Debian environment, the script runs to completion much faster than on the linkstation itself.

If you attach the drive to the PC, there's probably a Windows app that can write the generated image file to the disk, but I booted to the UEFI settings via the "Advanced Startup Options", then started a System Rescue CD and used mount, dd etc from there.

[1000001101000]

nice!

[1000001101000]

I got another report that the script fails on Ubuntu 12.04 due to some old versions of the programs that it relies on (not too surprisingly). I'm glad to hear it worked on WSL.... I wonder if I can get that enabled at work.

I'm also thinking of creating a docker container to do it at some point. I'd previously assumed that qemu under docker was a bad idea but found it worked fine on a linux host at least.

If I set that up would be able to test it under windows?

[marklam]

I don't have docker installed currently, but I could give it a go. Just let me know when it's available.

[rems28]

Hello, I have a LS-XHL (I think it's pretty the same as LS-CHLv2). It works well on Debian Buster. I tried an update to bullseye and the HDD make some start/stop loops all the time during boot. I stop electrically to avoid damages on the disk. If somebody have some advices ?

[1000001101000]

Good to hear from you!

Different devices seem to handle Bullseye differently which is slowing down progress on adding support.....that and just lack of time on my part.

I've run into some issues making the installer work for the armel devices under Bullseye, We did an experiment the other day doing a dist-upgrade on an LS-QVL which worked but seemed to result in stability issues.

I'm guessing the specific issue you ran into is that the initrd generated with Bullseye's 5.10 kernel was too big for that device's bootloader causing the failure. If that's the issue it should be possible to fix by changing the initramfs config to use XZ rather than GZIP. I'm in the process of making that the default moving forward.

I have successfully installed Bullseye on my LS-GL and LS-QVL using this method: https://github.com/1000001101000/Debian_on_Buffalo/wiki/Alternate-install-method-via-debootstrap-script

Both are stable, depending on how testing of other devices turns out this may be the only method I support for armel devices going forward.

[rems28]

Hum, OK, I will try it. Is there a difference between XZ and Zstd at your eyes ? The stable kernel seems to support it. Or can we made a custom initrd to fit more closely the device instead of a generic one ? [Edit] Ok, I'd take a look at your debootstrap script and it seems that you do it for the initrd

[1000001101000]

XZ provides better compression ratios at the cost of using much more CPU to compress and more memory to decompress. This is very noticeable on these devices and causes generating an initrd to take like 3 minutes rather than 30 seconds. It also means you need to be careful with your XZ settings or you could generate a file that takes up too much RAM for your device to unpack. When you have a device that will crash if your initrd is bigger than 7MB it's worth it to reduce the size from 7.1MB->5MB but it's still a hassle. Fortunately it's not something that has to be done very often, and the amount it increases boot time isn't as noticeable.

A custom initrd is something I think about from time to time. The tools provided by debian are nice since they support a wide range of configurations automatically, but at the cost of being bigger than they really need to be. Some of the recent size increases come from things that wouldn't likely apply to these devices, specifically kmod which added large ssl libraries to work with signed kernel modules. I could probably throw something together lighter but it would mean having to tell folks what subset of features are supported etc.

[rems28]

Hi, I continued to search for that NAS to work with bullseye, but each time I start to see the light, the NAS is doing his boot-loop. The initrd created is not so big I think and boot well. The boot loop is starting after the first boot (Which I think it's the initrd, that one boot well like on buster). Your scripts were very instructive for me but I think that Buster is the last compatible Debian on it. The last think I can try is to install buster kernel on bullseye to may have a correct boot. It's the last chance IMHO.

[1000001101000]

What size is your initrd?

[rems28]

6 MB with gzip compression

[rems28]

Works flawlessly with 4.19 kernel from buster

[1000001101000]

xz might be enough to fix that.

it seems like for some of these devices as the kernel gets bigger there’s less space for the initrd because of where it gets loaded. Combined with initrds getting bigger this is a problem. Xz might get you down to like 4mb which might work. If you try my debootstrap script it will handle all that for you.

I’ve got an idea for an alternate method but it involves patching the kernel and/or uboot. It’ll be my last resort if I can’t find a better way forward for the TS-XEL but if I end up going that route it would probably work for other devices too

[rems28]

For test, can I execute you script on the NAS directly with the destination disk on the USB port ?

[rems28]

The size of the initrd is the same on 4.19.0-18-marvell kernel from buster

[1000001101000]

The script is setup to create a disk image and uses the qemu version of debootstap. You could tweak it to go to a disk and to run natively rather than qemu.

The 5.10 kernel image is bigger which seems to make the max initrd size smaller…I assume they overlap when unpacked. Xz would make it snaller which might help.