Booting ArchLinuxARM on a Seagate GoFLEX Home

Bodhi,

I don't know if this is the right place to ask question below. If not, I will ask on the ArchLinuxARM forum.

I have a Seagate GoFLEX Home flashed with your 2017.07 U-Boot Kirkwood - GoFlex Home and it has no problem to boot up with a debian ARM OS. Right now, I would like my Seagate GoFLEX Home to boot and/or run ALARM (Arch Linux ARM) OS. So, I downloaded and extracted the ArchLinuxARM-2018.04-kirkwood-rootfs.tar.gz on a USB memory stick and notice its /boot directory only contains ONLY two files, i.e. initramfs-linux.img and uImage. Since it does not come with a .dtb file, I have my /boot/uEnv.txt configured as shown below and my device won't boot. Perhaps, I did something wrong or may be your uboot doesn't support ALARM OS? Do you think you can help me out in this case?

devices=usb ide
disks=0 1 2 3 4 5 6 7
dtb_file=

habibie,

devices=usb ide
disks=0 1 2 3 4 5 6 7
dtb_file=

The above is correct, to remove the dtb_file env so that the boot commands will not try to use it.

> I would like my Seagate GoFLEX Home to boot
> and/or run ALARM (Arch Linux ARM) OS. So, I
> downloaded and extracted the
> ArchLinuxARM-2018.04-kirkwood-rootfs.tar.gz
> on a USB memory stick and notice its /boot
> directory only contains ONLY two files, i.e.
> initramfs-linux.img and uImage.

The kernel in this rootfs is either non-FDT kernel or the kernel is FDT but the DTB must have been embedded inside uImage. The initramfs-linux.img is basically what is inside a typical uInitrd.

So all you need to do is the make a uInitrd file.

Mount this drive on another Linux box. Assuming it is mounted at /media/sdb1.

cd /media/sdb1/boot
mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-linux.img-2018-04-arch  -d initramfs-linux.img uInitrd
sync

Try booting with it. If you have netconsole, you should see uImage and uInitrd loaded and the kernel will start.

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



Edited 1 time(s). Last edit at 04/13/2018 01:31AM by bodhi.

Bodhi,

Thank you and now my Seagate GoFLEX Home can boot ARCHLinux ARM. The only problem is to find out how to enable SSH which bt default is locked. I read this secure shell as well as did a google search and am still facing with the ssh login issue, i.e. ssh connection refused. I am hoping someone here knows the answer before I will post the question on the ArchLinuxARM forum.

habibie,

A couple things to do/look at:

1. Log in with serial console if you have one, and regenerate SSH keys. Or mount this drive on another Linux box and chroot into it to do that.

2. Look at the sshd rules in its config file for allowing root log in. If it is indeed set up to disallow root login, you could try log in with alarm user instead of root. And then change this rule.

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

bodhi Wrote:
-------------------------------------------------------
> habibie,
>
> A couple things to do/look at:
>
> 1. Log in with serial console if you have one, and regenerate SSH keys. Or mount this drive on another Linux box and chroot into it to do that.
>
I don't have a serial console on this device. So, I resorted to the 2nd option through chroot. However, this gives me some problems as shown below:

[root@debian /]# ssh-keygen -t rsa -C "myEmail@example.com"
Couldn't open /dev/null: No such file or directory
[root@debian /]# ls -la /dev/null
ls: cannot access '/dev/null': No such file or directory
[root@debian /]# mknod /dev/null c 1 3
[root@debian /]# chmod 666 /dev/null 
[root@debian /]# ssh-keygen -t rsa -C "myEmail@example.com"
PRNG is not seeded
[root@debian /]#

> 2. Look at the sshd rules in its config file for allowing root log in. If it is indeed set up to disallow root login, you could try log in with alarm user instead of root. And then change this rule.
>
I am not sure exactly what you meant here. However, if you meant the /etc/ssh/sshd_config file, then I already have added the following to the file and still not able to ssh into my arch.

AllowUsers alarm
PermitRootLogin yes

My understanding is ALARM (ARCH Linux ARM) has changed to block the default SSH to make it a more secure system. I don't need this and am looking to simply revert the configuration back to a normal ssh on port 22. I am not worrying this device will get hacked or not.

>
> My understanding is ALARM (ARCH Linux ARM) has
> changed to block the default SSH to make it a more
> secure system. I don't need this and am looking to
> simply revert the configuration back to a normal
> ssh on port 22. I am not worrying this device will
> get hacked or not.

Then I'd suggest you ask how to do this at ALARM site.

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

Bodhi, OK and thank you very much for helping out. I will try to ask this in @ALARM forum.

Finally, I managed to SSH login into my Seagate GoFLEX running on Arch Linux ARM OS (see my post on ARCH Linux here).

habibie Wrote:
-------------------------------------------------------
> Finally, I managed to SSH login into my Seagate
> GoFLEX running on Arch Linux ARM OS (see my post
> on ARCH Linux
> here).

That solution is number 1 on my list above.

1. Log in with serial console if you have one, and regenerate SSH keys. Or mount this drive on another Linux box and chroot into it to do that.

I am surprised you have to do that. Perhaps your PC side has a very strict policy. Usually we just got some notice that the box that you trying to connect has some SSH key conflicts that you need to resolve, i.e. are you sure you want to connect? ... things of that nature.

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



Edited 1 time(s). Last edit at 04/23/2018 01:23AM by bodhi.

Bodhi,

There were to problems that I had to fix, i.e. (1) enable SSH socket and (2) regenerate SSH keys (as you pointed out in your 1st post above.

Anyway, it looks like I am facing another problem with my ARCH Linux ARM. I certainly don't know what will be next once this problem gets resolved. ;)

habibie,
>
> Anyway, it looks like I am facing
> another
> problem with my ARCH Linux ARM. I certainly
> don't know what will be next once this problem
> gets resolved. ;)

:) Does it occur to you that you perhaps you should run Debian?

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

bodhi Wrote:
-------------------------------------------------------
> habibie,
> >
> > Anyway, it looks like I am facing another problem with my ARCH Linux ARM. I certainly don't know what will be next once this problem gets resolved. ;)
>
> :) Does it occur to you that you perhaps you should run Debian?
>
TBH, my preference is with debian.

I would like to test ALARM to see if it will give a much better R/W NFS throughput. Right now, I am only getting about 40/20 MBps R/W NFS throughput while my SATA HDD can achieve 100+ MBps R/W throughput. Basically, what is mentioned in this NFS poor write performance is exactly what I have experienced through with my Seagate GoFLEX Home as my NFS server. I did a sysctl tuning as mentioned in the link and it does increase the write performance from 20 Mbps up to 25 MBps (a 25% increase). Since I am not familiar with the JUMBO frame and also don't know if my AT&T router/modem has a support for JUMBO frame, I can't give this a try to see if it will increase the R/W NFS performance.. I tried to change both rsize and/or wsize on my NFS client to mount my NFS drive, but mount on my NFS client always shows both rsize and/or wsize is set to 16384 (see my post). I really don't know if this kind of R/W NFS performance is the maximal I can get since no one here responded to my post. Anyway, the author from the link did an extensive tests and it seems to indicate the bottleneck is caused by the NFS stack. Also, I wonder how is samba compared to NFS in this case.

Quote

I tried to change both rsize and/or wsize on my NFS client to mount my NFS drive, but mount on my NFS client always shows both rsize and/or wsize is set to 16384 (see my post).

You need to solve this problem on the client side first before you can do any serious measurement.

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

bodhi Wrote:
-------------------------------------------------------
>

Quote

I tried to change both rsize and/or wsize on my NFS client to mount my NFS drive, but mount on my NFS client always shows both rsize and/or wsize is set to 16384 (see my post).

>
> You need to solve this problem on the client side first before you can do any serious measurement.
>
Bodhi, no matter what values, i.e. 4096, 8192, 32678, etc., I tried to change for the both rsize and/or wsize on the client, mount always shows they are set to 16384.

habibie Wrote:
-------------------------------------------------------
> bodhi Wrote:
> -------------------------------------------------------
> >

Quote

I tried to change both rsize and/or wsize
> on my NFS client to mount my NFS drive, but mount
> on my NFS client always shows both rsize and/or
> wsize is set to 16384 (see my post).

> >
> > You need to solve this problem on the client
> side first before you can do any serious
> measurement.
> >
> Bodhi, no matter what values, i.e. 4096, 8192,
> 32678, etc., I tried to change for the both rsize
> and/or wsize on the client, mount always shows
> they are set to 16384.

Is it true for Arch Linux on your GoFlexHome NFS sever too? after the mount, do you know which NFS protocol is being used for the mount on client side?

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

bodhi Wrote:
-------------------------------------------------------
> habibie Wrote:
> -------------------------------------------------------
> > bodhi Wrote:
> >
> -------------------------------------------------------
> > >

Quote

I tried to change both rsize and/or wsize on my NFS client to mount my NFS drive, but mount on my NFS client always shows both rsize and/or wsize is set to 16384 (see my post).

> > >
> > > You need to solve this problem on the client side first before you can do any serious measurement.
> > >
> > Bodhi, no matter what values, i.e. 4096, 8192, 32678, etc., I tried to change for the both rsize and/or wsize on the client, mount always shows they are set to 16384.
>
> Is it true for Arch Linux on your GoFlexHome NFS sever too? after the mount, do you know which NFS protocol is being used for the mount on client side?
>
Unfortunately, I can't test this with ALARM on my GoFLEX Home since it does not recognize my SATA HDD.

WIth the debian ARM on my GoFLEX Home NFS server, mount on my NFS client shows with NFSv4. I can configure my NFS client to use NFSv3 and mount on my NFS client also shows both rsize and/or wsize gets set to 16384. I don't suppose setting both sync and/or async on an NFS client configuration will help because they are still set to 16384.

habibie,


> Unfortunately, I can't test this with ALARM on my
> GoFLEX Home since it does not recognize my SATA
> HDD.

Export the mount using USB folder. Just to see if it is the same buffer size behavior. Once you determined ALARM's behavior then please let me know.

Both rsize and wsize are negotiated between the client/server. Even you specify that on the client side, it is both the server and client that determine the sizes that they can use.

I don't really care much about speed (I have enough in my home network), so I did not spend time to tune any of the settings. But this is something interesting that might be related to the rootfs, so I'll look at this wsize/rsize issue when I have time.

It's good if you could gather info about ALARM.

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

habibie,

Running Debian rootfs on GoflexHome. Execute these commands at the Linux shell.

/etc/init.d/nfs-kernel-server stop
echo 65536 > /proc/fs/nfsd/max_block_size
/etc/init.d/nfs-kernel-server start

Now try to mount one of the NFS shares exported by the GoflexHome from your PC using wsize and rsize 65536.

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



Edited 1 time(s). Last edit at 04/25/2018 11:24PM by bodhi.

bodhi Wrote:
-------------------------------------------------------
> habibie,
>
> Running Debian rootfs on GoflexHome. Execute these commands at the Linux shell.
>
>

> /etc/init.d/nfs-kernel-server stop
> echo 65536 > /proc/fs/nfsd/max_block_size
> /etc/init.d/nfs-kernel-server start
>

>
> Now try to mount one of the NFS shares exported by the GoflexHome from your PC using wsize and rsize 65536.
>
Bodhi,

I just tested the above recommendation from you and it does improve the write throughput from 27 MBps to 36 MBps.Thank you.

BEFORE:
[habibie@linux:/home/local/PEOPLE/habibie 6%] ~ dd if=/dev/zero of=/mnt/devel/junk/bigfile.dat bs=4M count=1024 oflag=direct
1024+0 records in
1024+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 159.035 s, 27.0 MB/s
0.008u+2.172s=2:39.23e(1.3%) TDSavg=0k+0k+0k max=6048k 0+8388608io 0pf+0sw

AFTER:
[habibie@linux:/home/local/PEOPLE/habibie 7%] ~ dd if=/dev/zero of=/mnt/devel/junk/bigfile.dat bs=4M count=1024 oflag=direct
1024+0 records in
1024+0 records out
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 119.26 s, 36.0 MB/s
0.006u+2.052s=1:59.45e(1.7%) TDSavg=0k+0k+0k max=5984k 0+8388608io 0pf+0sw
[habibie@linux:/home/local/PEOPLE/habibie 8%] ~

To make this change stick through a reboot, I did some google searches and found this post (from ARCH Linux forum), but it does not seem to work and I don't know why. I created a /lib/systemd/system/nfs-server-config.service file (see below) with some modifications from the above link. Then, created a symlink from /etc/systemd/system/multi-user.target.wants/nfs-server-config.service to /lib/systemd/system/nfs-server-config.service.

[Unit]
Description=NFS server config
Requires= proc-fs-nfsd.mount

After= proc-fs-nfsd.mount
Before= nfs-server.service

[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/bin/bash -c 'echo 1048576 > /proc/fs/nfsd/max_block_size'

Edited 5 time(s). Last edit at 04/26/2018 04:07PM by habibie.

habibie,

> I just tested the above recommendation from you
> and it does improve the write throughput from 27
> MBps to 36 MBps.Thank you.

Cool!

> ExecStart=/bin/bash -c 'echo 1048576 >
> /proc/fs/nfsd/max_block_size'[/code]

Go for broke? :) that's the maximum allowed, but it might cause you some problem because the amount of RAM is limited on the GoFlex.

As for systemd issue, I think your best bet is asking at the Arch site.

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

Bodhi,

OK and thank you.

habibie,

How was the NFS buffer size 1048576 working out? have you found a good size for GF Home?

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

Hello Bodhi,

The NFS buffer size 1048576 working out very well for me.

habibie Wrote:
-------------------------------------------------------
> Hello Bodhi,
>
> The NFS buffer size 1048576 working out very well
> for me.

How well? can you mount a NFS share on GF Home with that 1048576 size on the client PC? or it will reduce the buffer size to a smaller value?

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

Bodhi,

I have several Linux desktop computers and they are now able to share the NFS drive from my GoFLEX Home unit with a rsize/wsize buffer size 1048576 for about 36 MBps write throughput sans a problem. I wish it could give more.

/etc/exports on NFS server:
[root@debian:/root 9%] # cat /etc/exports 
# /etc/exports: the access control list for filesystems which may be exported
#               to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
#
/srv/devel      192.168.1.0/24(rw,root_squash,insecure,async,no_subtree_check,no_wdelay)
[root@debian:/root 10%] #

NFS client:
[root@linux:/home/local/PEOPLE/habibie 31%] # nfsstat -m
/mnt/devel from 192.168.1.8:/srv/devel
 Flags: rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.6,local_lock=none,addr=192.168.1.8

[root@linux:/home/local/PEOPLE/habibie 32%] #

One more thing to do is to make the setting stick through a reboot. Apparently, this approach won't work (I believe it is based on a systemd init). I tried adding echo 1048576 > /proc/fs/nfsd/max_block_size to /etc/default/nfs-kernel-server file as shown below, but it does not work on a reboot. However, after a reboot, executing a /etc/default/nfs-kernel-server stop and /etc/default/nfs-kernel-server start will work to set /proc/fs/nfsd/max_block_size to 1048576.

[root@debian:/root 8%] # cat /etc/default/nfs-kernel-server 
# Number of servers to start up
RPCNFSDCOUNT=32

# Runtime priority of server (see nice(1))
RPCNFSDPRIORITY=0

# Options for rpc.mountd.
# If you have a port-based firewall, you might want to set up
# a fixed port here using the --port option. For more information, 
# see rpc.mountd(8) or http://wiki.debian.org/SecuringNFS
# To disable NFSv4 on the server, specify '--no-nfs-version 4' here
RPCMOUNTDOPTS="--manage-gids"

# Do you want to start the svcgssd daemon? It is only required for Kerberos
# exports. Valid alternatives are "yes" and "no"; the default is "no".
NEED_SVCGSSD=""

# Options for rpc.svcgssd.
RPCSVCGSSDOPTS=""

echo 1048576 > /proc/fs/nfsd/max_block_size
[root@debian:/root 9%] #

habibie,

Many thanks for starting this topic, I've just managed to get Arch Linux booting with one of bodhi's uBoots following instructions here.

Arch Linux boots fine, the only trouble is that the USB stick is mounted ro:-

/dev/sda1 on / type ext3 (ro,relatime,data=ordered)

I managed to remount it rw using:-

mount -o remount,rw /dev/sda1 /

but don't know how to make it persistant. I note that fstab is empty:-

[root@alarm ~]# cat /etc/fstab
# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>

Is this what is causing the problem?

balanga Wrote:
-------------------------------------------------------
> I managed to remount it rw using:-
>

> mount -o remount,rw /dev/sda1 /
>

>
> but don't know how to make it persistant. I note
> that fstab is empty:-
>

> [root@alarm ~]# cat /etc/fstab
> # Static information about the filesystems.
> # See fstab(5) for details.
> 
> # <file system> <dir> <type> <options> <dump>
> <pass>
>

>
> Is this what is causing the problem?

Certainly is!

Just changed it to:-

[root@alarm ~]# cat /etc/fstab
# Static information about the filesystems.
# See fstab(5) for details.

# <file system> <dir> <type> <options> <dump> <pass>
/dev/sda1	/         	ext3      	rw,relatime,data=ordered	0 1

and it works.