Kirkwood U-Boot and Debian Installer Script (WORK-IN-PROGRESS)

This is the working thread for the script to install latest U-Boot and Debian rootfs for Kirkwood boxes.

Requirements:

This script shall install the latest u-boot and Debian rootfs from bodhi's released binaries on supported Kirkwood boxes.

Derived Requirements:

None.


Links to released binaries
======================


1. Rootfs

debian-kirkwood-rootfs-bodhi-latest.tar.bz2
https://bitly.com/2agPH5E

changes_log.txt
https://www.dropbox.com/s/ow9kfrthisgao28/changes_log.txt


2. U-Boot

uboot.bodhi.latest.environment
https://bitly.com/2akfqZj

uboot.bodhi.latest.environment.img
https://bitly.com/2akeSCD

uboot.bodhi.latest.environment.64K.img
https://bitly.com/2abh2oe

uboot.bodhi.latest.dockstar.mtd0.kwb
https://bitly.com/2aDBfsm

uboot.bodhi.latest.goflexhome.mtd0.kwb
https://bitly.com/2aDBPGs

uboot.bodhi.latest.goflexnet.mtd0.kwb
https://bitly.com/2ayyzuS

uboot.bodhi.latest.iconnect.mtd0.kwb
https://bitly.com/2a6M5WP

uboot.bodhi.latest.netgear_ms2110.mtd0.kwb
https://bitly.com/2al8b6E

uboot.bodhi.latest.nsa310.mtd0.kwb
https://bitly.com/2agOXxN

uboot.bodhi.latest.nsa310s.mtd0.kwb
https://bitly.com/2a6LPax

uboot.bodhi.latest.nsa320.mtd0.kwb
https://bitly.com/2aDBT9w

uboot.bodhi.latest.nsa325.mtd0.kwb
https://bitly.com/2ayyyY5

uboot.bodhi.latest.pogo_e02.mtd0.kwb
https://bitly.com/2ayyCah

uboot.bodhi.latest.pogo_v4.mtd0.kwb
https://bitly.com/2aRl1YM

uboot.bodhi.latest.sheevaplug.mtd0.kwb
https://bitly.com/2aBZuFC

uboot.bodhi.latest.t5325.mtd0.kwb
https://bitly.com/2aFz3h0

changes_log.txt
https://www.dropbox.com/s/u89i2qllgr5jwzq/changes_log.txt


Kirkwood Installer GitHub

https://github.com/mibodhi/kirkwood

kirkwood-installer script, tools, and md5/sha256 hashes.

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



Edited 10 time(s). Last edit at 12/22/2016 04:45PM by bodhi.

This is what I had in mind:

Take a look at Jeff's script, can we fork and modify it?
https://github.com/mibodhi/Older-U-Boot


This latest tarball might have most binaries you need.
http://forum.doozan.com/read.php?3,27280

I've made sure that each binary in this tarball is a Debian squeeze static binary. This is required when we install from stock OS (Linux 2.6.xx).

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



Edited 2 time(s). Last edit at 07/18/2016 01:43AM by bodhi.

Sure, I can modify that, expanding it to work for all other devices in the list and add some stuff for partitioning a drive.



Edited 2 time(s). Last edit at 07/18/2016 01:45AM by bodhi.

Some thoughts about the script (following Jeff's structure).

1. u-boot images will be at my Dropbox folder and have generic names:

u-boot-bodhi-latest.<platform>.mtd0.kwb

2. u-boot md5 and sha256 individual files will be at my doozan.com folder and have generic names:

u-boot-bodhi-latest.<platform>.mtd0.kwb.md5
u-boot-bodhi-latest.<platform>.mtd0.kwb.sha256

3. rootfs file will be at my Dropbox folder and have generic name

debian-kirkwood-rootfs-bodhi-latest.tar.bz2

4. rootfs md5 and sha256 individual files will be at my doozan.com folder and have generic names:

debian-kirkwood-rootfs-bodhi-latest.tar.bz2.md5
debian-kirkwood-rootfs-bodhi-latest.tar.bz2.sha256


4. We need to consider different mtdparts definition in determining where mtd0 is. This is a little bit elaborate, because some stocks have varied mtdparts definition (e.g. Zyxel, iConnect, Pogo V4,...)


.... More thought TBD.

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



Edited 2 time(s). Last edit at 07/18/2016 01:45AM by bodhi.

bodhi Wrote:
-------------------------------------------------------
> 3. rootfs file will be at my Dropbox folder and have generic name
> debian-kirkwood-rootfs-bodhi-latest.tar.bz2

I have yet to test the busybox in your toolbox, does it have a tar that can decompress bz2 ?

Because on Zyxel for example bz2 isn't decompressable by stock firmware.

For the same reason I was thinking about having the script download separately (in uncompressed form) each tool in your toolbox from your dropbox or something.
It's not like tar.bz2-ing 4 tools in a single package to save a few MBs matters that much.

>
> 4. We need to consider different mtdparts
> definition in determining where mtd0 is. This is a
> little bit elaborate, because some stocks have
> varied mtdparts definition (e.g. Zyxel, iConnect,
> Pogo V4,...)
>

Since the script knows what device it is working on because the user answered the question at startup (as it must install the right uboot), I'd say to just make a hard-coded list where each device/class has its own mtd0 place.
Of course we will need to find stock uboot envs for all boxes we support.

I'm not a fan of asking the device to figure out these things by itself if we can avoid it.
Of course I should be able to add safety checks to make sure that the hardcoded mtd0 place in the list contains an uboot/envs.



Edited 3 time(s). Last edit at 07/18/2016 01:46AM by bodhi.

> I have yet to test the busybox in your toolbox,
> does it have a tar that can decompress bz2 ?

Yes. I have not tested a whole archive. But it should work.

> For the same reason I was thinking about having
> the script download separately (in uncompressed
> form) each tool in your toolbox from your dropbox
> or something.
> It's not like tar.bz2-ing 4 tools in a single
> package to save a few MBs matters that much.
>

Yes. That's my intention to put everything in their corresponding folders. But the rootfs will be in tar.bz2, and can be unzipped by the busybox bz2.

> > 4. We need to consider different mtdparts
> > definition in determining where mtd0 is. This is
> a
> > little bit elaborate, because some stocks have
> > varied mtdparts definition (e.g. Zyxel,
> iConnect,
> > Pogo V4,...)
> >
>
> Since the script knows what device it is working
> on because the user answered the question at
> startup (as it must install the right uboot), I'd
> say to just make a hard-coded list where each
> device/class has its own mtd0 place.
> Of course we will need to find stock uboot envs
> for all boxes we support.

Yes it must flash a common env (the current default envs image). And adjust the envs for each supported box. Or I create a separate default envs image for each box.

In either cases, we need to adjust ethaddr after flashing. Because even though the randomly-generated ethaddr in my default envs should work, ethaddr could be troublesome for certain box if users need to adjust it later in Debian.

> I'm not a fan of asking the device to figure out
> these things by itself if we can avoid it.
> Of course I should be able to add safety checks to
> make sure that the hardcoded mtd0 place in the
> list contains an uboot/envs.

No need to, since we know the box name. That should identify the corresponding envs.

================================

Two more things needed to be considered:

1. The box HP T5325 use SPI flash, so flashing commands are different.

2. The installer script should write the /etc/fw_env.config file to the stock /etc so the envs can be used right away. The installer script general setup should be similar to to the HP T5325 installation: http://forum.doozan.com/read.php?3,26562

When I wrote the instruction for the HP T5325, I has this installer script in mind. So it could be used as a general guideline for the installer script.

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

Hm, I started working on the script.

Do we still need the part of the script that on start checks if stock uboot matches a md5?

I don't know but I don't think most devices will have the same uboot md5.

Also, jeff's script expects to check the md5 of tools too.


I have a dropbox account already so I'm going to make all tests with that for the moment.

> Also, jeff's script expects to check the md5 of
> tools too.
>

I think it is a good idea. Since the tools, u-boot images, rootfs will be in dropbox, but the list of valid md5s will be stored in this site (I need to populate them in my folder).

> Do we still need the part of the script that on
> start checks if stock uboot matches a md5?
>

This was one of the way to see if the installation is a u-boot upgrade from older but non-stock u-boot. So the script checks it against a list of valid u-boot md5s.

> I don't know but I don't think most devices will
> have the same uboot md5.

True, only a group of Kirkwood boxes share the same stock u-boot (Dockstar, Pogo E02, GoFlex). The other boxes stock u-boot are different (eg. Zyxel, iConnect).

> I have a dropbox account already so I'm going to
> make all tests with that for the moment.

Sure.


Back on the topic of checking md5s. Checking md5 or sha256 for each dropbox file is must. But checking the current u-boot md5 is really a precaution to detect an unkown current u-boot, so the users can be warned that there is a risk of bricking if s/he goes ahead with flashing. So in order to do this, I need to generate md5 for each u-boot image that I have released, and add them to the existing valid md5 list.

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

bodhi Wrote:
-------------------------------------------------------
> > Also, jeff's script expects to check the md5 of
> > tools too.
> >
>
> I think it is a good idea. Since the tools, u-boot
> images, rootfs will be in dropbox, but the list of
> valid md5s will be stored in this site (I need to
> populate them in my folder).
>

Could'nt you have all files downloadable from your github site? For an example of others distributing releases right from their github account see https://github.com/pepe2k/u-boot_mod/releases for u-boot releases for various Atheros based SOCs.

ray,

I've considered that before, but GitHub was hacked during that time, iirc. So I wanted to come back to this after a while.

In the beginning, the reason I stored all the binaries in Dropbox, was so that I can use bitly shortening links to look at the download statistic and gauge the popularity of each u-boot and kernel package. IOW, I'd like to spend more time on the boxes that have the largest download count. Does GitHub releases storage have statistics keeping? I would move all my files there instead of using link shortening if I can be sure of this.

BTW, Jeff gave me quite a bit of storage on this site, but I think for large files like rootfs tarballs, it is best to keep them at a public download service such as dropbox to save bandwidth. And it is a good practice to keep files and hashes on different server.

Thanks for the suggestion. Perhaps we can look for more GitHub info.

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

Looking at the github repository I indicated above it doesn't appear that any download statistics are included.

Ray

well, since the script is going to download both file and md5 checksum file, you may only need to keep the md5 checksum on a server that can track the downloads.

Also, I could integrate basic telemetry in the script too, it would also help in gathering info about stock uboot md5s, having a database of stock uboots and their envs, and so on if I have a place I can send files into (an ftp account somewhere?).

EDIT: quick update, it seems jeff is hosting also a mke2fs binary that can format ext4 too (i just tested), don't know if it is static but it was downloaded/used by his script so it's getting pressed into service for our needs too.
busybox in your toolbox provides a fdisk so the script can partition and format ext4 the disk now.
I have already written the code to deal with partitioning/formatting/extracting rootfs in my older (dead) project so I'm just copy-pasting it.

Currently I'm still moving current code into functions I can call from a main switchcase (so we can handle different devices and their firmwares) and putting placeholders where I need to write things, nothing is working for now.

By the way, I'm making it in a way that should work fine also calling this script in Debian, so it can be used to update the uboot even after there is Debian in the box.



Edited 2 time(s). Last edit at 07/23/2016 12:35PM by bobafetthotmail.

> well, since the script is going to download both
> file and md5 checksum file, you may only need to
> keep the md5 checksum on a server that can track
> the downloads.

Actually, it is harder with the script to track download. bitly redirects to dropbox with browser. I'm not sure Google shorten links can be resolved in the script? I could put the md5 checksum file links there.


>
> Also, I could integrate basic telemetry in the
> script too, it would also help in gathering info
> about stock uboot md5s, having a database of stock
> uboots and their envs, and so on if I have a place
> I can send files into (an ftp account
> somewhere?).
>

That's a good idea! we don't have all the plugs. Or we could enlist people to make the hashes with their stock u-boot.

> EDIT: quick update, it seems jeff is hosting also
> a mke2fs binary that can format ext4 too (i
> just tested), don't know if it is static but it
> was downloaded/used by his script so it's getting
> pressed into service for our needs too.
> busybox in your toolbox provides a fdisk so
> the script can partition and format ext4 the disk
> now.
> I have already written the code to deal with
> partitioning/formatting/extracting rootfs in my
> older (dead) project so I'm just copy-pasting it.
>
> Currently I'm still moving current code into
> functions I can call from a main switchcase (so we
> can handle different devices and their firmwares)
> and putting placeholders where I need to write
> things, nothing is working for now.
>
> By the way, I'm making it in a way that should
> work fine also calling this script in Debian, so
> it can be used to update the uboot even after
> there is Debian in the box.

Sounds great!

I need to get to work populating the dropbox files and doozan files. Hopefully tomorow.

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

> Actually, it is harder with the script to track download. bitly redirects to dropbox with browser. I'm not sure Google shorten links can be resolved in the script? I could put the md5 checksum file links there.

AFAIK bitly redirects correctly wget (what is used in the script to fetch files), don't know about tracking but it should be dealt with server-side.

I'm probably going to implement some fallbacks with curl or other possible http downloader programs the firmware can have to download at least the busybox tool with whatever is available (with or without md5 checks), then use the busybox's wget + md5 checks for everything else.

this is an example with a random link I got from here https://github.com/paweljw/debian-recovery

wget http://bit.ly/1zI6Pbg                                                                                                             
--2016-07-24 00:30:40--  http://bit.ly/1zI6Pbg                                                                                                               
Resolving bit.ly (bit.ly)... 67.199.248.10, 67.199.248.11                                                                                                    
Connecting to bit.ly (bit.ly)|67.199.248.10|:80... connected.                                                                                                
HTTP request sent, awaiting response... 301 Moved Permanently                                                                                                
Location: https://raw.githubusercontent.com/paweljw/debian-recovery/master/bootstrap.sh [following]                                                          
--2016-07-24 00:30:40--  https://raw.githubusercontent.com/paweljw/debian-recovery/master/bootstrap.sh                                                       
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.12.133                                                                            
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.12.133|:443... connected.                                                        
HTTP request sent, awaiting response... 200 OK                                                                                                               
Length: 463 [text/plain]                                                                                                                                     
Saving to: ‘1zI6Pbg’                                                                                                                                         
                                                                                                                                                             
100%[===================================================================================================================>] 463         --.-K/s   in 0s      

2016-07-24 00:30:41 (217 MB/s) - ‘1zI6Pbg’ saved [463/463]

##doing a cat on the downloaded file to see its contents:

cat 1zI6Pbg
#!/bin/bash

# http://bit.ly/1zI6Pbg

function bang()
{
        echo "# Ten skrypt jest smutny jesli nie jestes rootem"
        echo "# Aktualny uzytkownik to:"
        whoami

        echo "# Instalacja GITa"
        apt-get update
        apt-get -qq -y --force-yes install git mc

        echo "# Ide do /tmp"
        cd /tmp

        echo "# Klonuje skrypty rozruchowe"
        rm -rf debian-recovery
        git clone https://github.com/paweljw/debian-recovery.git
        cd debian-recovery
        chmod +x payloads/*
        run-parts ./payloads
}

Edited 5 time(s). Last edit at 07/23/2016 05:40PM by bobafetthotmail.

> > Actually, it is harder with the script to track
> download. bitly redirects to dropbox with browser.
> I'm not sure Google shorten links can be resolved
> in the script? I could put the md5 checksum file
> links there.
>
> AFAIK bitly redirects correctly wget (what is used
> in the script to fetch files), don't know about
> tracking but it should be dealt with server-side.
>

I think this is fine.

> I'm probably going to implement some fallbacks
> with curl or other possible http downloader
> programs the firmware can have to download at
> least the busybox tool with whatever is available
> (with or without md5 checks), then use the
> busybox's wget + md5 checks for everything else.
>
> this is an example with a random link I got from
> here https://github.com/paweljw/debian-recovery
>
>

> wget http://bit.ly/1zI6Pbg                        
>                                                   
>                                  
> --2016-07-24 00:30:40--  http://bit.ly/1zI6Pbg    
>                                                   
>                                                   
>     
> Resolving bit.ly (bit.ly)... 67.199.248.10,
> 67.199.248.11                                     
>                                                   
>            
> Connecting to bit.ly (bit.ly)|67.199.248.10|:80...
> connected.                                        
>                                                   
>     
> HTTP request sent, awaiting response... 301 Moved
> Permanently                                       
>                                                   
>      
> Location:
> https://raw.githubusercontent.com/paweljw/debian-r
> ecovery/master/bootstrap.sh [following]           
>                                               
> --2016-07-24 00:30:40-- 
> https://raw.githubusercontent.com/paweljw/debian-r
> ecovery/master/bootstrap.sh                       
>                                
> Resolving raw.githubusercontent.com
> (raw.githubusercontent.com)... 151.101.12.133     
>                                                   
>                    
> Connecting to raw.githubusercontent.com
> (raw.githubusercontent.com)|151.101.12.133|:443...
> connected.                                        
>                
> HTTP request sent, awaiting response... 200 OK    
>                                                   
>                                                   
>     
> Length: 463 [text/plain]                          
>                                                   
>                                                   
>     
> Saving to: ‘1zI6Pbg’                          
>                                                   
>                                                   
>         
>                                                   
>                                                   
>                                                   
>     
> 100%[=============================================
> ==================================================
> ====================>] 463         --.-K/s   in 0s
>      
> 
> 2016-07-24 00:30:41 (217 MB/s) - ‘1zI6Pbg’
> saved [463/463]
> 
> ##doing a cat on the downloaded file to see its
> contents:
> 
> cat 1zI6Pbg
> #!/bin/bash
> 
> # http://bit.ly/1zI6Pbg
> 
> function bang()
> {
>         echo "# Ten skrypt jest smutny jesli nie
> jestes rootem"
>         echo "# Aktualny uzytkownik to:"
>         whoami
> 
>         echo "# Instalacja GITa"
>         apt-get update
>         apt-get -qq -y --force-yes install git mc
> 
>         echo "# Ide do /tmp"
>         cd /tmp
> 
>         echo "# Klonuje skrypty rozruchowe"
>         rm -rf debian-recovery
>         git clone
> https://github.com/paweljw/debian-recovery.git
>         cd debian-recovery
>         chmod +x payloads/*
>         run-parts ./payloads
> }
> 
>

I think perhaps we should just keep the tools binaries on this site. It makes things a little simpler. And continue to keep the images at dropbox with bitly links?

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

>I think perhaps we should just keep the tools binaries on this site. It makes things a little simpler. And continue to keep the images at dropbox with bitly links?

This is your call, I don't know what is better for your workflow and for the script calling a link here is the same as calling a link from dropbox.

bobafetthotmail Wrote:
-------------------------------------------------------
> >I think perhaps we should just keep the tools
> binaries on this site. It makes things a little
> simpler. And continue to keep the images at
> dropbox with bitly links?
>
> This is your call, I don't know what is better for
> your workflow and for the script calling a link
> here is the same as calling a link from dropbox.

OK. I will keep them in dropbox for now.

I forgot an issue: running wget in stock OS. In the past, people has report that the stock wget does not work with https. Dropbox uses https (even if it accept http, it will redirect to https). And the busybox tool in my binpack is busybox-static_1.17.1-8_armel.deb (to make sure it can be used in various stock OS).

Was the wget result above from this busybox wget?

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

bodhi Wrote:
-------------------------------------------------------
>
> I forgot an issue: running wget in stock OS. In
> the past, people has report that the stock wget
> does not work with https. Dropbox uses https (even
> if it accept http, it will redirect to https). And
> the busybox tool in my binpack is
> busybox-static_1.17.1-8_armel.deb (to make sure it
> can be used in various stock OS).
>
> Was the wget result above from this busybox wget?

No. I tried now with the busybox's and it fails saying "not an http or ftp url".

Google tells me the busybox team did not add ssl libraries to busybox so none of their tools can work with https or ftps.

Google also reports a (pretty recent) script here to statically cross-compile a https-capable wget for ARM http://www.matteomattei.com/cross-compile-wget-statically-for-arm/
I hope it's easy to do for you (and you have the time to), otherwise I'll try myself to compile it.



Edited 1 time(s). Last edit at 07/25/2016 05:21AM by bobafetthotmail.

> Google also reports a (pretty recent) script here
> to statically cross-compile a https-capable wget
> for ARM
> http://www.matteomattei.com/cross-compile-wget-sta
> tically-for-arm/
> I hope it's easy to do for you (and you have the
> time to), otherwise I'll try myself to compile it.

Would be nice to compile this natively on Kirkwood box.

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

BTW,

Jason did it here:

http://forum.doozan.com/read.php?2,24248,24493

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

bodhi Wrote:
-------------------------------------------------------
> BTW,
>
> Jason did it here:
>
> http://forum.doozan.com/read.php?2,24248,24493

Good, saves us the time to set up the compilation in squeeze.

From the github https://github.com/pepaslabs/pogoplug_static_binaries he also has a mkswap binary, could you add both to the tools?

This week I should post a partial script for testing, that only downloads tools, partitions/formats a drive and installs the rootfs in it. For now it will still have links to my dropbox (and to his amazon s3 for the wget) for tools and things.



Edited 1 time(s). Last edit at 07/25/2016 02:38PM by bobafetthotmail.

bobafetthotmail Wrote:
-------------------------------------------------------
> bodhi Wrote:
> --------------------------------------------------
> -----
> > BTW,
> >
> > Jason did it here:
> >
> > http://forum.doozan.com/read.php?2,24248,24493
>
> Good, saves us the time to set up the compilation
> in squeeze.
>
> From the github
> https://github.com/pepaslabs/pogoplug_static_binar
> ies he also has a mkswap binary, could you
> add both to the tools?
>

Sure. I wll compile it too.

> This week I should post a partial script for
> testing, that only downloads tools,
> partitions/formats a drive and installs the rootfs
> in it. For now it will still have links to my
> dropbox (and to his amazon s3 for the wget) for
> tools and things.

Cool.

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

Good, so I'm now releasing a partial script for testing purposes.

What this script does:
-asks user what they want to do (please write "00" or "01" as other entries are disabled )
-downloads and checks md5 of all tools
-asks user what drive he wants to install Debian on (showing what drives are available and their sizes/filesystems)
-formats the drive according to its detected size (anything bigger than 33GB gets a swap partition and a data partition)
-downloads and checks the rootfs (currently rootfs 4.4)
-extracts its contents in the rootfs partition
-deletes temporary downloaded files (also in your windows PC :P )

Features:
-designed to work in both stock firmware and Debian
-downloads most of the tools and all of md5 files from my dropbox

If you want to help out, feel free to test it but be aware that it is BETA, so IT MAY EAT YOUR KITTEN, do backups and put kittens in a safe place before using it.

Also, feel free to comment about how I've written it.

Usage:

download the script attached to this post with wget from inside the stock firmware (or Debian),
write chmod +x kirkwood-installer.sh
write ./kirkwood-installer.sh to start the script and then follow instructions.

EDIT: file deleted, please look in posts below for updated version



Edited 1 time(s). Last edit at 07/30/2016 11:38PM by bobafetthotmail.

I've uploaded the realease binaries. Will post the links soon.

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

I've updated the first post to include description and links to binaries.

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

Ok, so first test found a bug, here http://forum.doozan.com/read.php?8,29231,29236#msg-29236

Fixed version attached to this post.

it's called kirkwood-installer-fix1.sh, so please adapt the instructions above to its new name.


bodhi Wrote:
-------------------------------------------------------
> I've updated the first post to include description
> and links to binaries.

thanks, will switch to that when I've finished bugfixing, and also upload the script in that github repo. It will require a non-https link to download so you will still have to keep the "distribution version" on this site, but if the script is on github people can see and contribute to it more easily.



Edited 1 time(s). Last edit at 07/31/2016 01:00AM by bobafetthotmail.

Next test, I got some questions and hints for you to know and making things possibly a bit easier in the long:

1. Is it possible to change the download location in some way, so that the filename wasn't so weird? At the moment the download's file name is:

-rwxr-xr-x    1 root     root        37142 Jan  1 00:00 file.php?3,file=941,filename=kirkwood-installer-f

2. I am starting SSH manually using my serial interfaces after every reboot, so I can copy the whole scrollback buffer in opposite to serial. Enabling SSH through pogoplug seems completely impossible with my two new GoFlex Nets. (The dropbear init script doesn't even exist).

3. Also I noticed that there are some differences, depending on whether I'm using serial or SSH. The reboot command for example only exists using serial.

4. Should I reboot between testing '00' and testing '01'? (I did so, yet.)

5. I attached the results as they would take rather much space here. (Is there a way for folding message parts in the forum?)

6. In short, the obvious problem I could see at a glance, was:

If everything looks good, type 'ok' to continue: 
ok
Good, now we need to know what device we are working on
here is a list, please write the number of the device
00. download and unpack toolbox
01. make a Debian rootfs in a drive
1.Zyxel nsa310
2.Zyxel nsa325v1 or nsa325v2
3.Pogoplug
00
downloading tools
mkdir: cannot create directory '': No such file or directory

For both options.



Edited 5 time(s). Last edit at 07/31/2016 03:21AM by ElMariachi.

ElMariachi Wrote:
-------------------------------------------------------
> 1. Is it possible to change the download location
> in some way, so that the filename wasn't so weird?
> At the moment the download's file name is:
>

> -rwxr-xr-x    1 root     root        37142 Jan  1
> 00:00
> file.php?3,file=941,filename=kirkwood-installer-f
>

write

wget -O  ./kirkwood-installer-fix2.sh     /link/to/download

this should download the script and save it with the right name (or whatever name you give it anyway).
If the onboard wget complies.


>
> 2. I am starting SSH manually using my serial
> interfaces after every reboot, so I can copy the
> whole scrollback buffer in opposite to serial.
> Enabling SSH through pogoplug seems completely
> impossible with my two new GoFlex Nets. (The
> dropbear init script doesn't even exist).

I'm not sure about what you are doing here.
Hmm, maybe I have understood.
Did tutorials like this not work? http://morschi.com/2012/10/05/seagate-goflex-net-debian/

If you say that you cannot copy around what you write on serial, change the program you use for serial interface.
On linux I use simply "screen" and Kde's default terminal.
What are you using for serial, are you on windows?

> 3. Also I noticed that there are some differences,
> depending on whether I'm using serial or SSH. The
> reboot command for example only exists using
> serial.

Hm, noted. I will probably change it to a shutdown without prompt.

> 4. Should I reboot between testing '00' and
> testing '01'? (I did so, yet.)

yes, reboot. But you can just test 01 for now as 01 does what 00 does and then some.

> 5. I attached the results as they would take
> rather much space here. (Is there a way for
> folding message parts in the forum?)

No, it is a rather basic forum, attach a txt file will be enough.

> 6. In short, the obvious problem I could see at a
> glance,

sigh, fixed again, can you try again with the script attached to this post?



Edited 3 time(s). Last edit at 07/31/2016 10:59AM by bobafetthotmail.

> I'm not sure about what you are doing here.
> Hmm, maybe I have understood.
> Did tutorials like this not work?
> http://morschi.com/2012/10/05/seagate-goflex-net-d
> ebian/

Yes, that's what I meant. I had the problem that the pogoplug website wouldn't offer the "Enable SSH" checkbox to me. I tried allowing all types of cookies, resetting caches, three different webbrowsers, each on two different PCs, tried reregistering (activating) the GoFlex in pogoplug and whatever. But the SSH option would never ever show up. I also contacted pogoplug support, but they didn't even try helping me, but answered by sending useless standard form mails three times.


> If you say that you cannot copy around what you
> write on serial, change the program you use for
> serial interface.
> On linux I use simply "screen" and Kde's default
> terminal.
> What are you using for serial, are you on
> windows?

I am using screen in mint 17.3 MATE. What I meant is that I can copy some text in this mode, but the terminal window won't offer scrollback feature in screen mode. So I could only copy so many lines as they fit within the window's height. It's no problem enabling SSH through serial and then copying the buffer from the SSH window, but I only said this so you know what exactly I'm doing, in case it might make a difference for your script.

> sigh, fixed again, can you try again with the
> script attached to this post?
Of course :)

Failing with:

# Successfully installed /tmp/tools/fw_printenv.
# checking for /etc/fw_env.config...

# Installing /etc/fw_env.config...
/etc/fw_env.config
https://dl.dropboxusercontent.com/u/47541136/linux/tools_for_Kirkwood_installer/fw_env.config
https://dl.dropboxusercontent.com/u/47541136/linux/tools_for_Kirkwood_installer/fw_env.config.md5
/etc/fw_env.config.md5
/etc/fw_env.config.md5: Read-only file system
/etc/fw_env.config.md5: Read-only file system
## Could not install /etc/fw_env.config from https://dl.dropboxusercontent.com/u/47541136/linux/tools_for_Kirkwood_installer/fw_env.config, exiting.
-bash-3.2#

Full log is attached.

ElMariachi,

> I am using screen in mint 17.3 MATE.

Don't use screen. Install picocom and use that. Screen is the worst to use with serial console.

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