pinebook_install_to_SD.sh
#1
Brick 
Greetings,  

  The purpose of this post is to make the Pine Installer script available (on the forum) for Pinebook users who want to create SD cards on their Pinebook using the SD card slot, which will allow making SD cards directly on the Pinebook from the network;  this script is similar to the pin64_install_to_emm.sh , as well the rock64_install_to_SD.sh.

  The script does require the  curl  package,  as well the  jq  package.

(  This script allows you to burn Pinebook images from the network, to the SD card while booted from eMMC  )

pinebook_install_to_SD.sh

Code:
#!/bin/bash

set -eo pipefail

if [[ "$(id -u)" -ne "0" ]]; then
    echo "This script requires root."
    exit 1
fi

echo "Pine A64/Pinebook release installer!"
echo "(C) 2017. Kamil Trzciński (https://ayufan.eu)."
echo ""

usage() {
   echo "Usage:"
   echo "$ $0 <system> [version]"
   echo ""
   echo "Systems:"
   echo " - xenial-minimal (https://github.com/ayufan-pine64/linux-build/releases)"
   echo " - xenial-mate (https://github.com/ayufan-pine64/linux-build/releases)"
   echo " - xenial-i3 (https://github.com/ayufan-pine64/linux-build/releases)"
   echo " - android-7.0 (https://github.com/ayufan-pine64/android-7.0/releases)"
   echo " - android-7.1 (https://github.com/ayufan-pine64/android-7.1/releases)"
   echo ""
   echo "Version:"
   echo " - latest will be used if version is not defined"
   exit 1
}

if [[ $# -ne 1 ]] && [[ $# -ne 2 ]]; then
   usage
fi

#if [[ ! -d /sys/devices/soc.0/1c10000.sdmmc/mmc_host/mmc1 ]]; then
#    echo "You should boot from SD card"
#    exit 1
#fi

#if [[ ! -e /dev/mmcblk1 ]]; then
#    echo "You should boot from SD card"
#    exit 1
#fi

case "$1" in
   xenial-minimal|xenial-mate|xenial-i3)
       REPO="ayufan-pine64/linux-build"
       PREFIX="$1-$(cat /etc/pine64_model)-bspkernel-"
       SUFFIX="-[0-9]*.img.xz"
       ARCHIVER="xz -d"
       ;;

   android-7.0|android-7.1)
       REPO="ayufan-pine64/$1"
       if [[ "$(cat /etc/pine64_model)" == "pinebook" ]]; then
           PREFIX="$1-pine-a64-pinebook-v"
       elif [[ "$(cat /etc/pine64_model)" == "sopine" ]]; then
           PREFIX="$1-pine-a64-sopine-v"
       else
           PREFIX="$1-pine-a64-v"
       fi
       SUFFIX="-r[0-9]*.img.gz"
       ARCHIVER="gzip -d"
       ;;

   *)
       echo "Unknown system: $1"
       echo ""
       usage
       ;;
esac

VERSION="$2"

if [[ -z "$VERSION" ]]; then
    VERSION=$(curl -f -sS https://api.github.com/repos/$REPO/releases/latest | jq -r ".tag_name")
    if [ -z "$VERSION" ]; then
        echo "Latest release was not for $1."
       echo "Please go to: https://github.com/$REPO/releases/latest"
       exit 1
    fi

    echo "Using latest release: $VERSION from https://github.com/$REPO/releases."
fi

NAME="$PREFIX$VERSION$SUFFIX"
NAME_SAFE="${NAME//./\\.}"
VERSION_SAFE="${VERSION//./\\.}"

echo "Looking for download URL..."
DOWNLOAD_URL=$(curl -f -sS https://api.github.com/repos/$REPO/releases | \
   jq -r ".[].assets | .[].browser_download_url" | \
   ( grep -o "https://github\.com/$REPO/releases/download/$VERSION_SAFE/$NAME_SAFE" || true))

if [[ -z "$DOWNLOAD_URL" ]]; then
   echo "The download URL for $NAME not found".
   echo "Look at https://github.com/$REPO/releases for correct versions."
   exit 1
fi

echo "Doing this will overwrite all data stored on eMMC."

while true; do
   echo "Type YES to continue or Ctrl-C to abort."
   read CONFIRM
   if [[ "$CONFIRM" == "YES" ]]; then
       break
   fi
done

echo ""
echo "Using $DOWNLOAD_URL..."
echo "Umounting..."
umount -f /dev/mmcblk1* || true
echo ""

echo "Downloading and writing to /dev/mmcblk1..."
curl -L -f "$DOWNLOAD_URL" | $ARCHIVER | dd bs=30M of=/dev/mmcblk1
sync
echo ""
echo "You may want to run now pine64_remove_boot0.sh to make the current device unbootable."
echo ""

echo "Done."
Notes:
Place the script in the normal place    /usr/local/sbin/pinebook_install_to_SD.sh
make the script executable with :
sudo  chmod  0775  /usr/local/sbin/pinebook_install_to_SD.sh
sudo  chown  root  /usr/local/sbin/pinebook_install_to_SD.sh
sudo  chgrp  root  /usr/local/sbin/pinebook_install_to_SD.sh
To run the script and get usage:
sudo  /usr/local/sbin/pinebook_install_to_SD.sh
To run the script and load xenial-i3 :
sudo  /usr/local/sbin/pinebook_install_to_SD.sh   xenial-i3

If you do not specify a version then the script will pull the most recent (non pre release) from the repos.

(  This script allows you to burn Pinebook images from the network, to the SD card while booted from eMMC  )
Rolleyes

Updated Instructions.
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply
#2
I get that sometimes it is safer to start from a fresh image rather than upgrading a current image. The problem is figuring out what I have done in the past so I can redo it on a new image. I guess the first step would be to do something like "apt list --installed" to list what packages I have installed. Next would be to back up my home directory. Finally the tricky part is to backup or list changed config files usually based in /etc directory tree.

After all the pre-work then actually boot from the new image. Now to run DIFF or something to look at config changes and missing packages. The installed packages restore is sort of what Android does when I have to get a new phone. Google asks me if I want to restore all my installed apps. The hard part is remembering all my logins, that is why I write down the logins to get my password keeper updated.
The beauty of the Pinebook configuration is that we can run from the SD card until we are happy with the new config then burn it to EMMC.

Are there any shell scripts to do something like this load extra packages and compare configurations?
  Reply
#3
(08-28-2017, 12:30 PM)tlaswell Wrote: I get that sometimes it is safer to start from a fresh image rather than upgrading a current image.  The problem is figuring out what I have done in the past so I can redo it on a new image.  I guess the first step would be to do something like "apt list --installed" to list what packages I have installed.  Next would be to back up my home directory.  Finally the tricky part is to backup or list changed config files usually based in /etc directory tree.

After all the pre-work then actually boot from the new image.  Now to run DIFF or something to look at config changes and missing packages.  The installed packages restore is sort of what Android does when I have to get a new phone.  Google asks me if I want to restore all my installed apps.  The hard part is remembering all my logins, that is why I write down the logins to get my password keeper updated.
The beauty of the Pinebook configuration is that we can run from the SD card until we are happy with the new config then burn it to EMMC.

Are there any shell scripts to do something like this load extra packages and compare configurations?


Everyone has their own way of doing what you describe;  most builders makers produce their own scripts to make sure that they don't forget anything in the build and that the builds are consistent from release to release.

Its funny you mention this , because I'm in the process of updating mine today , and preparing to share the concept on the forum;  that is not quite ready.

What I have done for quite some time is to create a simple text file on my /root dir ( sudo -i ) that has an ordered list of everything I have "done" to the image on that card ( or that particular drive or removable media , whether it be thumb drive or SSD , whatever ). 

          sudo  -i
          touch  card_id

Every time I "do" something to that card I edit the card_id file ( which has hostname and uname -a at the top ) and add a date-time "change-log" entry with a description of the activity, any resources used, any dependencies, and any other notes that would be necessary for reproducing the card from a base image ( whatever that might be ).

I do this even for simple additions to the card like installing htop, or installing minicom, or for other things like wifi configuration or keyboard remapping.  There are just too many little details that can get lost in the shuffle when trying to build a working system from a base image that its insane to not keep track of changes like this.

Over the years I have also tried to use spread-sheets for the same purpose;  however, I really find that a simple free form text file is the best tool overall and easiest tool generally.

I keep my card_id files in several places ( like all of my DNA ) so that I don't lose my work, and I index and track ( compare ) the important ones ( like all of my scripts and software engineering regardless how detailed or apparently trivial ).


We all know that the job ain't done till the paper-work is finished. If I'm working with a team ( whether that team was IBM for almost thirty years, or Pine Inc, or just my personal lab )  its less important to me that codes function correctly or that builds work right.  The truly important aspect of all of software engineering is whether the job ( whatever that is ) is documented well enough that someone else can take it and reproduce the experiment , or alternatively take it over and make it work correctly , or fork it effectively !



Having said all of that;  the final step in the documentation process is to automate the  card_id  file.  In other words, build a script that will automatically build the card.  This is more complicated than I'm making it sound,  but the idea is that a bash script is used to perform the card build changes ( from base image ) so that the reproduced card is identical and consistent with the parent card, and the owner ( usually me ) doesn't have to pull his beard out trying to remember everything that went into that system!

Even if all you have is that card_id file ( the change log file ) when you get that new board and go to prepare its SD card or eMMC module ( or SSD drive ) the whole process is less stressful because you have a road map laid out in front of you ( that you wrote for yourself ) which helps to make sure that the card goes from base image to functional system without any misses in a systematic way.

Shy
marcushh777    Cool

please join us for a chat @  irc.pine64.xyz:6667   or ssl  irc.pine64.xyz:6697

( I regret that I am not able to respond to personal messages;  let's meet on irc! )
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)