[GoFlex Home] Cannot login via SSH with latest Debian rootfs (v6.5.7)

Hello

I'm installing the latest Debian rootfs (Debian-6.5.7-kirkwood-tld-1-rootfs-bodhi.tar.bz2) on my GoFlex Home, and everything seems to boot successfully from USB. Here are the steps I’ve completed so far:

1. Partitioned and formatted the USB drive as ext3, labeled it as "rootfs".
2. Extracted the rootfs archive to the USB root using:

sudo tar -xjf Debian-6.5.7-kirkwood-tld-1-rootfs-bodhi.tar.bz2 -C /mnt/usb

3. Mounted dev, proc, sys and chrooted into /mnt/usb to set the root password and enable SSH login:

- Set a new root password using `passwd`
- Edited `/etc/ssh/sshd_config`:
```

     PermitRootLogin yes
     PasswordAuthentication yes

```
4. Unmounted everything and rebooted the GoFlex Home.

On reboot:

- I see the GoFlex Home gets an IP address from the router.
- The LED turns green.
- Port 22 is open (checked via nmap).
- I can ping the device.
- But SSH always gives:
`Permission denied, please try again.`

I also tried connecting using:

ssh -oKexAlgorithms=+diffie-hellman-group14-sha1 \
    -oHostKeyAlgorithms=+ssh-rsa \
    root@<IP>

Still no success.

Is there anything I'm missing or doing wrong?
Do I need to install the latest U-Boot in order to use this rootfs properly?
(Unfortunately, I don't have a USB-to-TTL serial cable at the moment.)

Any suggestions would be greatly appreciated.

To bodhi, thanks so much for your great work!

Koinin,

> I'm installing the latest Debian rootfs
> (Debian-6.5.7-kirkwood-tld-1-rootfs-bodhi.tar.bz2)
> on my GoFlex Home, and everything seems to boot
> successfully from USB

> sudo tar -xjf
> Debian-6.5.7-kirkwood-tld-1-rootfs-bodhi.tar.bz2
> -C /mnt/usb

You must be root, sudo won't work.

https://forum.doozan.com/read.php?2,12096

Quote

Note: all steps below must be done while logging in as root user (not sudo). If you are not the root user then don't continue, because the rootfs will not work.

> [/code]
>
> 3. Mounted dev, proc, sys and chrooted into
> /mnt/usb to set the root password and enable SSH
> login:
>
> - Set a new root password using `passwd`
> - Edited `/etc/ssh/sshd_config`:
> ```
>

>      PermitRootLogin yes
>      PasswordAuthentication yes

> ```

There is no need to do anything to the rootfs like that.


> Is there anything I'm missing or doing wrong?
> Do I need to install the latest U-Boot in order to
> use this rootfs properly?

Yes. If the u-boot on your box is stock u-boot then you'll need serial console. And follow this instruction:

https://forum.doozan.com/read.php?2,102054,105374#msg-105374


=======

Without serial console, you can install the 2017.07 u-boot for this box inside stock OS. But it would be a bit risky, and then if things don't go well, you'll need to set up serial console to recover.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi bodhi,

I'm using a GoFlex Home with U-Boot 2017.07 installed following your instructions, and I've successfully booted into Debian from a USB drive. However, I’m facing an issue when I connect a SATA hard drive:

Sometimes the USB shows up as /dev/sda1 → boots successfully

Other times the USB becomes /dev/sdb1 → boot fails because the kernel can't find the rootfs

I have already tried using UUID in bootargs, but it did not work — Debian still failed to mount the rootfs from the USB.
I'm also not planning to use LABEL.

Currently, my bootcmd is:

usb start
ext2load usb 0:1 0x800000 /boot/uImage
ext2load usb 0:1 0x1100000 /boot/uInitrd
ext2load usb 0:1 0x1c00000 /boot/dts/kirkwood-goflexhome.dtb
bootm 0x800000 0x1100000 0x1c00000

And my bootargs is:

console=ttyS0,115200 root=/dev/sda1 rootdelay=10

I'm considering modifying bootcmd to try both /dev/sda1 and /dev/sdb1 for rootfs using U-Boot scripting like this:

setenv try_boot 'echo Trying root=/dev/sda1; setenv bootargs console=ttyS0,115200 root=/dev/sda1 rootdelay=10; run load_and_boot || echo Trying root=/dev/sdb1; setenv bootargs console=ttyS0,115200 root=/dev/sdb1 rootdelay=10; run load_and_boot'

setenv load_and_boot 'ext2load usb 0:1 0x800000 /boot/uImage && ext2load usb 0:1 0x1100000 /boot/uInitrd && ext2load usb 0:1 0x1c00000 /boot/dts/kirkwood-goflexhome.dtb && bootm 0x800000 0x1100000 0x1c00000'

setenv bootcmd 'usb start; run try_boot'

Do you think this is a reliable solution? Or is there a better way to handle this situation in U-Boot?

Thank you very much for your hard work supporting these legacy devices!

Koinin,

> I'm using a GoFlex Home with U-Boot 2017.07
> installed following your instructions, and I've
> successfully booted into Debian from a USB drive.

Cool!

> Other times the USB becomes
> /dev/sdb1 → boot fails
> because the kernel can't find the rootfs
>
> I have already tried using
> UUID in
> bootargs, but it did not
> work — Debian still failed to mount the rootfs
> from the USB.

Yes, it is expected. The order of enumeration for drives is unpredictable.

> I'm also not planning to use
> LABEL.

Why not? you're already booting with uInitrd. Using the LABEL guarantee that it will boot correctly.

> I'm considering modifying
> bootcmd to try both
> /dev/sda1 and
> /dev/sdb1 for rootfs using
> U-Boot scripting like this:
>
>

> setenv try_boot 'echo Trying root=/dev/sda1;
> setenv bootargs console=ttyS0,115200
> root=/dev/sda1 rootdelay=10; run load_and_boot ||
> echo Trying root=/dev/sdb1; setenv bootargs
> console=ttyS0,115200 root=/dev/sdb1 rootdelay=10;
> run load_and_boot'
> 
> setenv load_and_boot 'ext2load usb 0:1 0x800000
> /boot/uImage && ext2load usb 0:1 0x1100000
> /boot/uInitrd && ext2load usb 0:1 0x1c00000
> /boot/dts/kirkwood-goflexhome.dtb && bootm
> 0x800000 0x1100000 0x1c00000'
> 
> setenv bootcmd 'usb start; run try_boot'
>

>
> Do you think this is a reliable solution? Or is
> there a better way to handle this situation in
> U-Boot?

No, not a reliable solution. It actually will not work.

Please explain why you are not using root=LABEL=rootfs?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 06/04/2025 10:16PM by bodhi.

bodhi,

The reason I initially avoided this method was because I assumed it would behave similarly to root=UUID=..., which I had already tried without success. So I was looking for an alternative approach.

Now that I see root=LABEL=rootfs works reliably, I’ll stick with it. Thanks again for your continued support!

> Now that I see
> root=LABEL=rootfs works
> reliably, I’ll stick with it.

Cool!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi,

I’m currently trying to set up netconsole to receive logs in case the system fails to boot.

Here's what I’ve confirmed so far:

• Netconsole is compiled as a module in config-6.5.7-kirkwood-tld-1:
  

    CONFIG_NETCONSOLE=m  CONFIG_NETCONSOLE_DYNAMIC=y  CONFIG_NETPOLL=y  

• The netconsole module loads fine once Debian is up and running. I tested this with:
  

    echo "=== TEST NETCONSOLE ===" > /dev/kmsg

  and the message is received successfully on my remote PC.
• However, as expected, if the system fails to boot (e.g. issues in initramfs or mounting root), I do not get any kernel logs via netconsole — since the module hasn’t been loaded yet.

My goal:
I want to receive early kernel logs over netconsole — as early as possible — ideally starting right after U-Boot, even before the rootfs is mounted.

My question:
Is there any known workaround to achieve early netconsole output without rebuilding the kernel or rootfs?

I understand the standard way would be to:

• Rebuild the kernel with CONFIG_NETCONSOLE=y (built-in)
• Pass netconsole= parameters via U-Boot bootargs
• Possibly use initramfs hooks if needed

But I’m trying to avoid kernel compilation for now. So:

• Is it possible to patch an existing kernel image (uImage) to enable built-in netconsole somehow?
• Or can I preload netconsole from initramfs in a way that activates it early enough to catch critical errors?
• Any way to simulate netconsole behavior by redirecting kernel logs over the network before userland?

Any suggestions or insight would be appreciated. Thank you again for your time and all the great tools you provide!

Koinin,

> However, as expected, if the system fails to
> boot (e.g. issues in initramfs or mounting root),
> I do not get any kernel logs via netconsole —
> since the module hasn’t been loaded yet.

> I want to receive early kernel logs over
> netconsole — as early as possible — ideally
> starting right after U-Boot, even before the
> rootfs is mounted.

See these 2 tutorials in the Wiki

Quote

Netconsole

Use netconsole to troubleshoot uBoot without a serial cable
Use netconsole to troubleshoot Debian kernel booting

But don't set up netconsole in u-boot yet. I need to rerun some test, u-boot netconsole seems to have some problem with the latest kernels. But this is not your goal any way. You only want to see the log, not interacting with netconsole.

You can set up netconsole in Debian using the 2nd tutorial (make the module loaded early during boot).

The shortcoming with netconsole is you will see the kernel log (i.e. dmesg), but you won't see any activities between the time the kernel has booted and before the rootfs mounting.

====

I know some old NAS have the ability to route system log to other node in the network. However, I don't recall what they did and how much info got sent.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)