[LS-WXL] Bullseye installer not booting (no SSH), Buster installer working

[kubax]

Hi,

hopefully you are able to shed some light on to this problem...

I recently installed Debian Bullseye on a Netgear ReadyNAS DUOv2 to run OpenMediaVault and having it support smbv2/3 instead of only smbv1.

Now i thought, what about the Buffalo NAS. I had a look around and sumbled over your repo.

I did follow the Guide to prepare of Option 1 and everything seems working fine. Sadly after rebooting with acp_commander.jar the device took realy long to reboot, it eventually gets a ip address and is pingable, but i can't ssh into the device.

I used the onboard serial port, in the hopes that it would be accessible after the (seems to be) sucessfull boot of the kernel, but i can't get any output from the serial console, so no way of debug this problem.

I also did try to boot another u-boot image with kwboot, but the image is never transfered, so it might be that the serial port is disabled in hardware.

Any hints what i could try to get debian onto the LS-WXL (LS-WX2.0TL/R1-EU)

The Kernel i used is the uImage.buffalo.lswxl image from bullseye.

[kubax]

Nevermind.

First of all, i did use the image for the lswSxl by accident. But that didn't solve anything.

BUT, i found on the Discord that the Bullseye installer is borked for the LS-WXL and the deboostrap installer seems to work (in progress of testing right now).

So i will change the topic to Bullseye not booting on LS-WXL as this seems to be a problem.

(Buster installer boots normaly)

[1000001101000]

Good to hear from you!

If the connection to the serial port is working you should get output from the bootloader at the very least. If it’s booting far enough to get an IP address there should be kernel output too. Buffalo tends to disconnect those and hide the gap underneath chips/etc, so it’s not surprising it wouldn’t work.

it might be worth scanning with acp_commader again to make sure it didn’t boot back into the stock firmware again somehow. That’s one explanation for network but no ssh.

after the installer acquires an IP it downloads all the components needed to start the ssh-console from a debian mirror. If the device was unable to reach the internet or the debian mirror that might explain what you are seeing.

[1000001101000]

I’m fairly sure the LS-WXL is one of the devices I tested with for the revamped Bullseye installer.

Getting an IP but not starting ssh is an odd failure mode since getting an ip is actually pretty far into the installer startup. The main thing that happens between getting an IP and starting ssh is connecting to the debian mirror and downloading the ssh packages.

If I get some time in the near future I can try the installer on mine. It’s possible something broke in the latest Debian installer image that just hadn’t been reported yet. It’s rare but it wouldn’t be the first time.

In the meantime, you could try the “debootstrap” method which side-steps the installer entirely:

https://github.com/1000001101000/Debian_on_Buffalo/wiki/Alternate-install-method-via-debootstrap-script

[kubax]

EDIT: debootstrap method worked perfectly fine. Although the pv command is wrong (at least in the latest version [i'm on arch], but to my understanding it is completely messed up. also, latest dd supports "status=progress" to show a progress.

i'm writing the image to the disk now, i'll edit if that works (but given that the buster installer boots, i have no doubts it will).

I would give more details about the failing boot, but i can't seem to get the serial to work.

i found a 4 pin unpopulated header, wich is likely serial (verified GND and +3,3V) but i do not get any output on screen with 115200 B when i connect TX, RX and GND. doesn't matter wich way around the TX and RX are.

I attached a picture of the back of the board. Green = GND, Free = 3,3V the other ones are either TX or RX. At least that is what i'm thinking.

[1000001101000]

Buffalo tends to disconnect the traces leading to the serial header. The gap is often hidden under something.

[1000001101000]

I fixed the pv reference on the wiki… that was weird

[1000001101000]

I was able to reproduce the issue on a different model device with a working serial console, it's definitely failing to get to the debian mirror. I'll take a look and try to figure out what's going on.

[1000001101000]

I've pushed an update to the build script and generated new installer images that should correct the issue.

let me know when you get a chance to try it out.

[kubax]

Sorry, did test it a few hours ago, but forgot to report back.

The new image is working as expected! I allready had a working install, so i did not realy test the complete installer, just so far that i could move my working uImage and initramfs back and reboot.

Thanks for your fast help!!