pinebook_install_to_SD.sh - Printable Version +- PINE64 (https://forum.pine64.org) +-- Forum: Pinebook (https://forum.pine64.org/forumdisplay.php?fid=76) +--- Forum: General Discussion on Pinebook (https://forum.pine64.org/forumdisplay.php?fid=77) +--- Thread: pinebook_install_to_SD.sh (/showthread.php?tid=4998) |
pinebook_install_to_SD.sh - MarkHaysHarris777 - 08-23-2017 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 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 ) Updated Instructions. RE: pinebook_install_to_SD.sh - tlaswell - 08-28-2017 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? RE: pinebook_install_to_SD.sh - MarkHaysHarris777 - 08-28-2017 (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. 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. |