"A human being should be able to change a
diaper, plan an invasion, butcher a hog, conn a ship, design a
building, write a sonnet, balance accounts, build a wall, set a bone,
comfort the dying, take orders, give orders, cooperate, act alone,
solve equations, analyze a new problem, pitch manure, program a
computer, cook a tasty meal, fight efficiently, die gallantly.
Specialization is for insects." (Robert A. Heinlein)
Tuesday, 25 December 2018
Saturday, 27 October 2018
Hard disk upgrading with Clonezilla
Some
time ago my desktop computer welcomed me with an unpleasant message:
the main hard drive was likely to fail soon.
When
you receive similar messages you never know how soon “soon”
means. Since disk drives prices are reasonably low I decided not to
waste time, I so bought a new, bigger, hard drive to replace the
faulty one.
Upgrading
the computer main drive could be a time consuming business if done
“by hand” since it means copying all system and user data.
Fortunately many tools exist in the Linux world to ease the process,
among them Clonezilla.
Clonezilla
Clonezilla
is a, very small foot-print, Linux distribution dedicated to disk and
partition backup or cloning. I already used it once
to backup EEEPC original Xandros installation. I downloaded
Clonezilla ISO image and installed it on a SUB disk using Unetbootin.
Because of its very small size I’ve been able to install Clonezilla
on a old 1GB USB drive.
Before
starting Clonezilla Iinstalled the new drive on my desktop PC
together with the old one and partitioned it using Gparted.
At
boot Clonezilla offer some boot options, I selected the default one
Then,
once the system had started, after the long
language and keyboard selection menu, I’ve
been shown several options. I selected to work in a “device-device”
mode then selected the “local
partition-to-local
partition” copy mode.
I
proceeded with copying partition one from the old disk to partition
one in the new disk, once completed I repeated with partition two.
At
last I powered of the computer, removed the old faulty disk and left
the new one in its place. I restarted the system but, the new disk
didn’t boot.
After
a while I figured I forgot that Clonezilla, when copying
partition-by-partition, didn’t copy boot information. Not a big
deal, once you understand it.
Eventually
I started again the system using Clonezilla and, using command line
interface, I installed GRUB
on the new disk.
sudo mkdir /mnt/ubuntu
sudo mount /dev/sda1 /mnt/ubuntu
sudo grub-install --boot-directory=/mnt/ubuntu/boot /dev/sda
After
this my computer started, working like before.
By
the Way now I have a unreliable spare 500 GB hard disk, what could I
use it for?
Labels:
CloneZilla
,
GRUB
,
Linux
,
upgrade
Saturday, 29 September 2018
Things to remember: mount your USB drives using UUID
This
is just a short post to remember myself, and hopefully to my few
readers, how a little more research before doing things could save
from problems in future. I had to disconnect all my computer, the
Raspberry and every devices because of some maintenance works I hhad
to do at home. As often happens when I connected all back not
everything worked as before.
Worst
of all was the Raspberry Pi 3 that didn’t boot anymore or, at
least, the boot process crashed betore turning on the network. I had
to attach the Raspberry to my TV to discover that the boot process
failed while trying to mout the attached USB drives. After some
swapping of available USB slots I managed to get back to the original
working position. I had to solve the problem definitively.
Mounting
drives using UUID
USB
drive devices are assigned on a per position basis. This is usually
irrilevant for removable drives but it can become a problem when
using USB for fixed, mounted on boot, drives. The solution is
defining drives non by using their assigned device but the device
unique identifier (UUID). The funny thing is that the solution was
already on display in Raspberry “fstab” file since the system
uses a similar identifier (PARTUID) in order to mount boot and root
partitions.
The
drive UUID can be easly printed by using “blkid” or “lsblk”
commands. Here the vary informative output produced by “lsblk”
command:
sudo lsblk -o UUID,NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL,MODEL
once
identified drive UUIS is just matter of replacing it inside
“/etc/fstab” file like this:
# USB Disk
#/dev/sda1 /media/usbdisk ext4 rw,defaults 0 0
#/dev/sdb1 /media/backup xfs rw,defaults 0 0
UUID=bc83dfb9-ebc5-4a96-9cd2-0657fa767717 /media/usbdisk ext4 rw,defaults 0 0
UUID=debd0d49-549a-4187-8284-f20dc3c8f986 /media/backup xfs rw,defaults 0 0
Labels:
fstab
,
Mount
,
Raspberry-Pi
,
UUID
Saturday, 7 July 2018
The joy of virtualization: Docker
I
took a relative pause from experimenting with Raspberry Pi to report
my first experiences with something completely different. One of the
first things you realize while programming server-side is how your
program is only one piece of a bigger puzzle. Your application
usually runs inside a container, connects to a database, expose or
consume services and so on ... Solving this puzzle means defining an
installation procedure that becomes different and sometime more
complex by changing or scaling the installation target.
Docker
Docker
is an container platform
that overcomes the installation problems by producing a
ready-to-install standardized operating-system-level
virtual machine, packed with everything your application needs to be
run. Unlike other virtualization solutions a Docker image only
contains what
your application needs without having to
install and run a full hardware simulation
like, for example, in Virtual
Box.
Installation
Docker
is available in two versions a professional “enterprise”
edition and a community one (Docker
CE) free to download. Installing Docker CE on Ubuntu is just
matter of adding Docker repository address
sudo apt-get update
sudo apt-get install apt-transport-https ca-certificates curl software-properties-commoncurl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -sudo apt-key fingerprint 0EBFCD88sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
Then
installing it using the usual apt command
sudo apt-get updatesudo apt-get install docker-ce
Once
the installation completed the current user, or any user who will use
Docker, must be added to the “docker” group.
sudo adduser maxx docker
After
logging out and in again Docker was ready for use and command
docker info
Correctly
reported the empty environment initial state
First
run
In
order to test Docker is correctly installed and running a simple
“hello-world” image is available. Just by calling the command:
docker run hello-world
Docker
take care of downloading the image from its repository, installing
and running it.
Another
interesting image to start with is, as suggested in hello-world
printout, the “ubuntu” image that installs and starts a
console-only Ubuntu virtual machine with no effort.
Labels:
Development
,
Docker
,
Linux
,
Ubuntu
,
Virtualization
Sunday, 3 June 2018
Simple hardware interface for the Raspberry Pi Zero
I
spent some hours, last weekend, working to another little step into
my Raspberry Zero camera project. After experimenting remote software
interface possibilities I started building some minimal bare hardware
interface in order to, at least, safely turn on and off the Raspberry
Pi.
A
bare minimum interface
The
bare minimum hardware interface for a Raspberry project is made of a
power push-button and a status LED telling if the device is still
active or it can be safely removed from power.
Plenty
of tutorials are available on the Internet, I mostly followed
instructions from here
and here.
The
power status information is directly provided from the UART pin
without the need of writing additional software. UART must be enabled
in ‘/boot/config.txt’ configuration
file
enable_uart=1
Then I just connected a LED diode between UART pin and ground (trough a current limiting resistor of course).
Also
the wake-up functionality is implemented by briefly connecting GPIO
pin 6 to ground trough a normally-open push button.
Labels:
Interfacing
,
Python
,
Raspberry-Camera
,
Raspberry-Pi
,
Raspberry-Pi-Zero-W
Saturday, 21 April 2018
Remotely controlling the Raspberry Pi Zero and Pi Camera
Here
I am continuing my very slow paced building of a Raspberry Pi Zero
based camera. After experimenting with raspberry-desktop file
exchanging I’ve now took some time experimenting with remote
controlling options. I’ll eventually have to wire to the Raspberry
some, at least minimal, physical interface, but remote control,
trough a Android smart-phone, could be a viable solution
to avoid a too
complex hardware interface.
The
ready-made solution: Raspicam Remote
The
first solution I found in Android Play store has been Raspicam
Remote.
Raspicam is a quite simple application providing a simple but
complete user interface and connecting to the Raspberry Pi using
Wi-Fi and SSH.
Unfortunately
Raspicam doesn’t work on my old phone (Jelly bean) but it works
fine in my much newer tablet. I understand you can’t keep backwards
compatibility with everything. Other solutions are available but they
look more suited for remote surveillance than camera interface.
The
mostly Do-it-yourself solution: BlueDot
Interfacing
to the Raspberry trough Wi-Fi offers clear advantages a specially in
terms of connection speed but also poses some disadvantage.
Setting-up a Wi-Fi connection might be trivial while at home where is
available an already configured access point but it’s not the same
while outside. Connecting the Raspberry with a smart-phone using
Wi-Fi means configuring
one of them to act as access-point, its not difficult but it might
become tricky. Also on the power consumption aspect must be kept in
consideration especially for the device acting as access-point.
Bluetooth
overcomes both set-up and power consumption problems in exchange, of
course, for transfer speed and connection range.
Here
comes to play BlueDot:
a simple looking Android application
that together with a easy to use Python library
allows a unidirectional Bluetooth communication between smart-phone
and a Raspberry device.
Labels:
Linux
,
Raspberry-Camera
,
Raspberry-Pi
,
Raspberry-Pi-Zero-W
,
remote-control
Saturday, 3 March 2018
Sharing files on the Raspberry Pi Zero W
I
eventually managed to find some time to continue working to my
Pi-zero camera project. During initial tests I took advantage of
Pi-Zero wireless interface and used “sftp" command in order to
transfer files between Raspberry and desktop computer. A more
suitable way of transferring files using USB, like real digital
cameras, would be of course advisable.
Raspberry
Pi Zero as mass storage
The
Pi Zero USB port is directly
connected to processor, unlike others Raspberrys using
a on-board USB Hub.
This, cheaper, solution means
the Pi Zero can be configured to act as USB host,
like a computer, or as
a “USB gadget”
like all cell-phones and digital cameras do. In
order to activate such “USB gadget”
mode some
specific “dcw2” kernel modules must be enabled, in my specfic
case the needed module is called “g_mass_storage”. I followed
this simple
guide from a Github user.
First I enabled DCW2 USB driverecho "dtoverlay=dwc2" | sudo tee -a /boot/config.txtecho "dwc2" | sudo tee -a /etc/modules
sudo dd if=/dev/zero of=/usb-drive.img bs=1M count=1000sudo mkdosfs -F 32 /usb-drive.imgOnce the Raspberry PI is conncted to a computer the mass storage can be enabledl ike this
sudo modprobe g_mass_storage file=/usb-drive.img stall=0 removable=1and disabled with following modprobe command
sudo modprobe -r g_mass_storage
the same virtual
disk can be availabe to Raspberri PI by mounting it
sudo mkdir /media/usb-drivesudo mount -o loop,rw /usb-drive.img /media/usb-drive/of course the same virtual disk cannot be both available as mass storage drive and mounted on Raspberry at the same time, since it could lead to disk corruption. The camera software will have so to manage the switch between two modes.
Labels:
Raspberry-Camera
,
Raspberry-Pi
,
Raspberry-Pi-Zero
,
Raspberry-Pi-Zero-W
,
Raspian
,
USB-OTG
Wednesday, 17 January 2018
New toy on the desk: Raspberry PI zero W and Raspberry Camera
Just
before Christmas I have been to an electronics and surplus fair where
I bought myself, among other things, a new Raspberry
family “thing”. I started with a vague idea of building my very
own “hackable” camera. I didn't have, and still don't, have a
definitive idea of how it must be or what to do with it ... just it
must be hackable i.e. I must be able to reprogram it once I need it
for something else. I so bought a Raspberry
Pi Zero kit, including the official withe-red
case heath sink and male pin strip, and a 8 M pixel Pi
Camera.
Headless
installation
I'm
getting quite used to prepare and install Raspberry Pi images, it's
the fourth time, almost always headless. Plenty
of tutorials
can be found
on the Internet by the way. This time is
not very different apart from just one detail: I had to configure the
Raspberry to connect to WIFI network from the very beginning.
So
after copying the latest Raspbian image on the micro-SD card withe
the usual “dd” command
sudo dd if=2017-11-29-raspbian-stretch-lite.img of=/dev/sdd
I
configured Raspbian to enable SSH by default
sudo touch /media/maxx/boot/ssh
Then
on the same root directory I created a “wpa_supplicant” WIFI
configuration file
sudo vim.tiny /media/maxx/boot/wpa_supplicant.conf
Where
I wrote down my wireless network configuration
country=ITctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdevupdate_config=1
network={ssid="WIFI"psk="secret"}
At
last I powered the Raspberry Pi and scanned the WIFI network for the
new entry computer.
I
connected trough SSH and I went, of course, trough the usual
post-installation operations like changing the Pi user password and
expanding the file system to the full micro-SD extent.
Pi
Camera installation
Once
I verified the Raspberry was correctly working I powered it back down
and connected the Pi Camera using the small flat cable also included
in the Pi-Zero kit I bought.
Labels:
Installation
,
Linux
,
Raspberry-Camera
,
Raspberry-Pi
,
Raspberry-Pi-Zero
,
Raspberry-Pi-Zero-W
,
Raspian
Subscribe to:
Posts
(
Atom
)