Raspbian Squeezed

The new images fit in less than 2GB so no more stupidly buying 8GB cards ! I'm glad I kept my stock of 2GB and 4GB cards !

However, there is a BIG problem when you want to "cook" your own images : the stock image automatically resizes/expands the main partition ON FIRST BOOT !

How braindead is that ? I can see some justification but there is no obvious way to turn this off...

https://ubuntu-pi-flavour-maker.org/

Why bother anymore ?

(ah yes, the "read only" technique is still relevant)

http://wiki.linuxaudio.org/wiki/raspberrypi

The configuration of the Pi is not automated but the little script to configure JACK is similar to what I already do:

#!/bin/bash

## Stop the ntp service
sudo service ntp stop

## Stop the triggerhappy service
sudo service triggerhappy stop

## Stop the dbus service. Warning: this can cause unpredictable behaviour when running a desktop environment on the RPi
sudo service dbus stop

## Stop the console-kit-daemon service. Warning: this can cause unpredictable behaviour when running a desktop environment on the RPi
sudo killall console-kit-daemon

## Stop the polkitd service. Warning: this can cause unpredictable behaviour when running a desktop environment on the RPi
sudo killall polkitd

## Only needed when Jack2 is compiled with D-Bus support (Jack2 in the AutoStatic RPi audio repo is compiled without D-Bus support)
#export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/dbus/system_bus_socket

## Remount /dev/shm to prevent memory allocation errors
sudo mount -o remount,size=128M /dev/shm

## Kill the usespace gnome virtual filesystem daemon. Warning: this can cause unpredictable behaviour when running a desktop environment on the RPi
killall gvfsd

## Kill the userspace D-Bus daemon. Warning: this can cause unpredictable behaviour when running a desktop environment on the RPi
killall dbus-daemon

## Kill the userspace dbus-launch daemon. Warning: this can cause unpredictable behaviour when running a desktop environment on the RPi
killall dbus-launch

## Uncomment if you'd like to disable the network adapter completely
#echo -n “1-1.1:1.0” | sudo tee /sys/bus/usb/drivers/smsc95xx/unbind
## In case the above line doesn't work try the following
#echo -n “1-1.1” | sudo tee /sys/bus/usb/drivers/usb/unbind

## Set the CPU scaling governor to performance
echo -n performance | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

"Release early, release often" they say, but at least release something that somehow works ;-)

When I started this, I had just squeezed raspbian down to 520MB (a 200MB .gz can be found there http://ygdes.com/Squeezed/ please be nice with my bandwidth and quota) but it was not automated and I had broken a few things. It's still usable over ssh or if you have a QWERTY keyboard but I'm not totally happy with it.

Now Jessie is out (of proportions) and I'm fighting with the dead weight. I learn to use resize2fs but the official image won't resize when the image in loop-mounted, for reasons that still escape me. I have conceded that a 8GB card is necessary during the image configuration, then resize2fs can be run on the skimmed card. So yes it can fit in 4GB.

This is not finished however but the beginning works so I put the scripts there http://ygdes.com/Squeezed/Squeezed.20151003.tgz
I know I have a weird coding style with bash and I hope you don't mind. It's just memories from an old Linux From Scratch-based project ;-)

The "hardening part" is not yet provided but it's a little procedure that is described in the previous log at the end of http://ygdes.com/Squeezed/install_20150926.txt

I am doing a routine test of the scripts before I release an early version and I discover that a new archive version is available:

2015-09-24-raspbian-jessie.zip : 1332985725 bytes

25% larger than the previous version ! That's insane ! But not as much as the image's size itself:

2015-09-24-raspbian-jessie.img : 4325376000 bytes

SDcards, and storage devices in general, don't have all the same exact size so with some bad luck, it is easy to get a 4GB flash card that is not suitable for this image... So I insert my work card in my computer to check :

fdisk -l

Disk /dev/mmcblk0: 3,7 GiB, 3980394496 bytes, 7774208 sectors

What the f*** Raspberry Pi Foundation, what the holly f*** ?

The filesystem has 715MB free, before the 100MB swap file is created. The filesystem should be 350MB smaller to fit in a 4BG card, and it's not hard to achieve. Just stop bundling junk with your images.

Correction :

# dd if=/dev/zero of=ZERO bs=4K

946167808 octets (946 MB) copiés

So why expand beyond the 4GB limit ?

The current Raspbian image takes 3GB and contains about 2GB of data (compressed down to 1GB of archive). This means that a 4GB card is necessary. It's today's standard size but can it be cheaper with a smaller image ?

I managed to squeeze Raspbian down to about 520MB so a 2GB SD card is possible. But I will have to shrink the ext4 fs instead of expanding it. Who needs to fit in 2GB? Does it make sense economically? What about older systems?

OK, I have one argument for the reduction : it saves time when writing the image to the flash card so I'll see how to reduce the partition's size to about 1GB...

The last version was quick and dirty and as it could be expected, it has a few shortcomings. So much in fact that it's better to do it all over, it's faster than trying to fix it.

The second time I do something, I don't want to have to do it by hand a 3rd time, which is ... likely. So I make more efforts and instead of just writing things down, I simply write a set of scripts. Like in the old times of LFS :-D

The problem is that there are now 2 platforms to run (host and Pi), so 2 sets of scripts. A new challenge for me, I'll see how I'll handle that gracefully :-D

Update:

I have now a set of bash scripts to safely automate the first parts, the easy ones. It runs on Linux and now uses a new trick to reduce the number of manipulations : simple data are changed or uploaded from the host computer by loop-mounting the image before it is written to Flash and booted.
The big issue is still the management of the debian/apt packages and so far this can only be done from the booted system. Similarly, the raspi-config part can't be automated yet, so more manual operations...

At least the set of scripts is modular and new steps can be added to provide more functionalities, on demand, for each project. Just "su" and run each script in order :-)

Today (saturday sept. 26th) I started with the original, official image

[yg@localhost RPi]$ wget 'https://downloads.raspberrypi.org/raspbian_latest'
[yg@localhost RPi]$ mv raspbian_latest 2015-05-05-raspbian-wheezy.img.zip
[yg@localhost RPi]$ shasum 2015-05-05-raspbian-wheezy.img.zip
cb799af077930ff7cbcfaa251b4c6e25b11483de  2015-05-05-raspbian-wheezy.img.zip
[yg@localhost RPi]$ /usr/bin/time unzip 2015-05-05-raspbian-wheezy.img.zip
[yg@localhost RPi]$ ls -al
-rw-r--r--.  1 yg   yg   3276800000  7 mai   01:00 2015-05-05-raspbian-wheezy.img
-rw-rw-r--.  1 yg   yg   1038523231  7 mai   17:55 2015-05-05-raspbian-wheezy.img.zip
[yg@localhost RPi]$ shasum 2015-05-05-raspbian-wheezy.img
fd11a319a8e93fc5f93902c67d337ad419706e5e  2015-05-05-raspbian-wheezy.img

[root@localhost RPi]# sha1sum 2015-09-26_Raspbian_Hardened.3276800000.img
694fc3dca01f8393675d5e7dbc705ec371af7554  2015-09-26_Raspbian_Hardened.3276800000.img
[root@localhost RPi]# gzip -k 2015-09-26_Raspbian_Hardened.3276800000.img
[root@localhost RPi]# sha1sum 2015-09-26_Raspbian_Hardened.3276800000.img.gz
4cec82c359ab7e8d0b74976309f9243f091b819b  2015-09-26_Raspbian_Hardened.3276800000.img.gz
[root@localhost RPi]# l 2015-09-26_Raspbian_Hardened.3276800000.img*
-rw-r--r--.  1 yg   yg   3276800000 26 sept. 06:27 2015-09-26_Raspbian_Hardened.3276800000.img
-rw-r--r--.  1 yg   yg    200269221 26 sept. 06:27 2015-09-26_Raspbian_Hardened.3276800000.img.gz

BEWARE ! IT'S CRUDE !

but I'm in a sort of rush because I want to have a complete public and working #SPI Flasher as soon as possible. Since you have all the instructions, you can spot errors, make your own version and send me patches.