Do NOT install SliTaz .deb on Raspberry Pi Model 2 at this time

For those not familiar with it, SliTaz is a very light weight and reasonably fun distribution of Linux that runs well from a Live-CD. I’ve used it on several machines from time to time. My only complaint has been that the main (old) version I’ve run has a horrid orange motif to the desktop (then again, I’ve been too lazy to bother to change it… and in Fall it fits right in ;-)

Well, I found that they have a version for the Raspberry Pi. So downloaded it. They also have a version that you can install as a ‘.deb’ package in Raspbian and make the machine dual boot with the SliTaz using the R.Pi SD card but just loading itself into memory. Kinda just what I want some times. Boot to memory, don’t hit the card, but let me access it if desired. So I decided to try that. ( It is called “dual boot” on this page: )

The install was darned easy. Here I list the files in my download directory prior to the actual install command. The “pilfs” group is the Pi-Linux-From-Scratch that does the compile and build on your box. While that takes 12 hours on the Pi (but might be faster on the Pi.M2) it also means the compile time choices can inspect your hardware and make better choices (like, oh, using hardware random generator or using hardware floating point better or…) No, not all builds do that, but some are smart enough to look around and adapt. So on the “someday todo” is a LFS build. It also means you have YOUR source code to inspect and make sure it isn’t different from the copy you downloaded at that Starbucks back when…

Then there is the “slitaz” group where you can see the choice of a ‘base’ version (no windows manager) and the “desktop” version that does “do windows”, along with one that ends in armhf.deb file suffix. That’s the one that makes it dual boot. Installing it is near trivial (as seen in the next line with the dpkg command). Took maybe 2 minutes?

pi@RaPiM2 ~/Downloads $ ls -l
total 1178240
-rw-r--r-- 1 pi pi    185753 Aug  1 23:23 CentOS-5.11-i386-bin-DVD-1to2.torrent
-rw-r--r-- 1 pi pi    624768 Aug  3 16:28 FDTD.pdf
-rw-r--r-- 1 pi pi 233704548 Aug  7 08:42 pilfs-base-20150623.img.xz
-rw-r--r-- 1 pi pi 217064852 Aug  6 21:35 pilfs-base-rpi2-20150623.img.xz
-rw-r--r-- 1 pi pi 661094715 Aug  6 23:12
-rw-r--r-- 1 pi pi  35161404 Aug  6 20:23 slitaz-20140329-1_armhf.deb
-rw-r--r-- 1 pi pi  22889303 Aug  6 20:05 slitaz-rpi-base-20140329.tar.bz2
-rw-r--r-- 1 pi pi  35741738 Aug  6 20:12 slitaz-rpi-desktop-20140329.tar.bz2
pi@RaPiM2 ~/Downloads $ sudo dpkg -i slitaz-20140329-1_armhf.deb 
Selecting previously unselected package slitaz.
(Reading database ... 89961 files and directories currently installed.)
Unpacking slitaz (from slitaz-20140329-1_armhf.deb) ...
Setting up slitaz (20140329-1) ...
Extracting /var/os/slitaz ...
102561 blocks
67902 blocks
Update /var/os/slitaz/etc/fstab ...
Update /boot ...
The SliTaz boot menu is available for the next (re)boot.
pi@RaPiM2 ~/Downloads $ 

Then it’s just shut down, and reboot, right?


I now have a chip that boots to a black screen hung state. Doesn’t even give me the “which OS to boot?” message. Just “power on and hang”.

Clearly their boot manager is dumbfounded by the R.Pi_Model_2 and just dies.

So, until they sort that bit of floating debris out of their process:

Absolutely AVOID the SliTaz .deb install on the Raspberry Pi Model 2

I’ll now be spending who knows how long trying to unscramble those particularly anoying eggs and getting my boot back like it ought to be. Hopefully not too hard.

Worst case? I go back to the build script and run it again… (and the noted changes in comments…) and then suck the saved bits of downloads and account data off of this chip onto the new chip. It is all there (as evidenced that I was able to copy the above install log off of it…) and only the boot is broken.

Sidebar On Chromebox and Debian Hung GPU on Intel

I am making this posting on the old Evo under the Debian that hangs the GPU. It has sat idle for a week or so since I was not all that interested in trying to fix the display bug in the Intel driver. A short web search showed it in numerous releases over many years, often claimed fixed, then not; and sorting out just what driver might actually be the right one and with which magic sauce was not “worth it”. I can run it as is with only the occasional need to kill a rogue Xorg process when the GPU hangs, and then it’s fine until rebooted – even if the graphics are slow and jerky being done in the CPU. Here’s what the log looks like:

root@EVOdebian:/var/log# tail -f Xorg.0.log
[    69.165] (II) intel(0): Modeline "1152x864"x0.0  108.00  1152 1216 1344 1600  864 865 868 900 +hsync +vsync (67.5 kHz e)
[    69.166] (II) intel(0): Modeline "1680x1050"x0.0  187.00  1680 1800 1976 2272  1050 1053 1059 1099 -hsync +vsync (82.3 kHz e)
[    69.166] (II) intel(0): Modeline "1600x1200"x0.0  162.00  1600 1664 1856 2160  1200 1201 1204 1250 +hsync +vsync (75.0 kHz e)
[    69.166] (II) intel(0): Modeline "1400x1050"x0.0  121.75  1400 1488 1632 1864  1050 1053 1057 1089 -hsync +vsync (65.3 kHz e)
[    69.166] (II) intel(0): Modeline "1400x1050"x0.0  156.00  1400 1504 1648 1896  1050 1053 1057 1099 -hsync +vsync (82.3 kHz e)
[    69.166] (II) intel(0): Modeline "1280x1024"x0.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz e)
[    69.166] (II) intel(0): Modeline "1280x960"x0.0  108.00  1280 1376 1488 1800  960 961 964 1000 +hsync +vsync (60.0 kHz e)
[    69.166] (II) intel(0): Modeline "1600x1200"x0.0  202.50  1600 1664 1856 2160  1200 1201 1204 1250 +hsync +vsync (93.8 kHz e)
[   115.768] (EE) intel(0): Detected a hung GPU, disabling acceleration.
[   115.769] (EE) intel(0): When reporting this, please include i915_error_state from debugfs and the full dmesg.

It’s a dice role on the hang of the GPU causing a runaway X process, or just a flicker and keep going with slow graphics. A remote SSH login can kill the X runaway if needed, then all is good until reboot.

I tried to use the Chromebox to make this posting. It sits right next to the R.Pi and I just move the HDMI cable, wireless kb dongle and such over to it and press power on. But

After several minutes, I could not get the plain text file into the WordPress editor on Chrome.

I could get the file to open in (something) and see it. It would let me “select all”. But not “copy”.

Launching the “Google Apps” document editor, it doesn’t see “.txt” files…

And so it goes. That “Chrome Straightjacket” biting again. It REALLY wants to prevent you from doing things like “cut / paste” that bypass their servers where they can grab a copy. Yet even there, that it is so hard core against .txt files is just a pointless PITA.

Is there some way? Maybe, but frankly, it was far easier to just boot the EVO and deal with the Intel GPU / X issue and have tools that just work. Copy, paste, done.

All of which gives a pretty good example of why I’m a Unix / Linux user by preference. No straightjacket on what I can do. No “my way or the highway”. Even WITH the pimples, warts, and occasional workarounds for some insufficiently working parts (old and crusty or new and not tested enough or…) I able to get done what I want to do and in a way that doesn’t take an hour to figure out. (Many tools have not changed since the ’80s and the skill set is still just fine…)

So I’m typing this on an old Compaq Evo (yup, pre-HP Merger) using Debian and not on my nearly new (year old?) HP Chromebox.

I still like the Chromebox, but it is for very limited things only. I’ve mostly used it for browsing, Netflix, and the occasional posting. All that fits its ideas about the world. Here I wanted to do a tiny little simple thing (cut / paste from text file to browser window) and it balked. “Since that doesn’t share the data with Google, why let it happen?” seems to be the mindset. Or maybe “no end-user type would use a .txt file so ignore it”?

Oh Well.

Now that the Evo is booted and stable, I’ll be using it as the repair station for the Raspbian / SliTaz chip. I’ll also likely be doing any browsing and posting from here for a day or three as I sort things out. We’ll see. ( I do like the box, and the OS. Just would like it more with a working GPU driver…)

In Conclusion

Since I’m a “fix it” kinda guy, it doesn’t really bother me if things break. If nothing else, it lets me keep the skills polished and find out where I’m weak (or what I really just don’t like). So when a client has a problem I’m likely to “have clue”, or have enough clue to know I don’t want to take that contract; nor bid it low…

I have 2 working and stable XP boots / boxes. I have a working and stable CentOS with GIStemp on it (along with a nice userland). I have a working Raspberry Pi B+ typically doing infrastructure server things. I have a working Chromebox (where my only complaint is their designed-in-straightjacket mentality and their “all your data are belong to us” style). And I have two OTHER working and stable Raspberry Pi Model 2 chips so could have just used one of them. But I thought that nice SD card slot on the Chromebox would make it easy to read the SD card… The point being that I’m not short on computes and stable boxes. It’s just that I like Debian better than CentOS and the Evo has a very quiet fan… Similarly the Chromebox is near fanless and the R.Pi is silent.

The quiet profiles matter more to me than working through some “issues”.

So when I’m griping about things (like now) don’t take that as me suffering. It’s just me explaining what works fine, and where there be dragons, or slime… or mudballs…

So in that light, this is just a posting saying that I hit a mudball from the Chromebox trying to make it do what it doesn’t want to do (or hides really well…) and a touch of slime in the highly persistent i915 Intel GPU driver issues; and that “Here There Be Dragons!” on the SliTaz .deb on the R.PiM2.

So duck the mudball, avoid the dragon, and some hip boots get you through the slime OK… besides, it’s quiet walking through the slime in hip boots ;-)

Subscribe to feed

About E.M.Smith

A technical managerial sort interested in things from Stonehenge to computer science. My present "hot buttons' are the mythology of Climate Change and ancient metrology; but things change...
This entry was posted in Tech Bits and tagged , , , , , , , , , . Bookmark the permalink.

14 Responses to Do NOT install SliTaz .deb on Raspberry Pi Model 2 at this time

  1. M Simon says:

    Still Programming in “C” ? My condolences.

  2. E.M.Smith says:

    @M. Simon:

    Sorry, not following. I didn’t say anything about programming in C.

    FWIW, I program in anything that’s needed. Heck, I’d even use FORTH if it was the best fit ;-)

    While C isn’t my favorite, nor my strongest, it’s an OK language. (Beats the pants of APL and PL/1 and COBOL and even Pascal IMHO. All of which I’ve used to some, often small, degree.)

    But this posting is about installing a compiled .deb package (that was made from a script, per the web page) and not about writing a C program. I also have no idea what language was used for the obliquely referenced Intel GPU driver and would not be surprised to find it in C, or not.

    Finally: No condolences needed, please keep them for those who would benefit… I’m pretty much a language agnostic; but I do have “novelty seeking behaviour”, and that means that I like to take a “language dip” into other languages, often. On one occasion that lead me to take a dip into FORTH (enjoyable, if a bit low level for most of what I do) and having learned to program on an Burroughs B6700 that is a stack machine, the stack approach is attractive. (Also having started with an HP programmable calculator using RPN, I backwards think to tend. ;-) so found the approach charming in FORTH).

    But the world is dominated by register boxes and RPN is not to be found anymore in any common places. Similarly, the use of languages best suited to those machines and the problems they solve tends to larger wordier languages.

    FWIW, most of what I do has a significant amount of “shell script wrapper” around it. It is a “threaded interpretive language” where you build up a library of words over time… Familiar? ;-)

    In any case, the last “C” I wrote was about a decade back, I think. Since then I’ve mostly just compiled the work of others and occasionally read some of it.

    But take heart, the JAVA VM is a stack (with one notable exception) machine and Java is pervasive. (But I’ve never needed to learn it… and the idea of running a Java VM inside a real OS on a VM instance inside shared hardware in a rack… well, it just offends my sense of efficiency…)

    Meanwhile, back at the R.Pi.

    I’m going to give the chip a try in the R.Pi B+ later tonight (when I don’t need the DNS service, Bittorrent server, etc. etc. that it’s doing now) and see if it works there. If so, that would make the “fix” easier. (That is highly unlikely to involve C, but very likely to involve scripts… and config files).

  3. tom0mason says:

    Very interesting post thanks for the update. I must make time for playing with a Raspberry Pi — maybe soon.
    I’ve tried a few Linuxes but not Slitaz yet, it looks interesting as it has my favorite desktop of Openbox as it’s standard. May try it over the next few days.
    So far I have stayed with PCLinuxOS as it is a simple rolling release that just works for me, (yes I’ve had to hack it a bit to make it fit to my ancient hardware but that’s Linux). No video player enabled on this box as it just burns-up the Pentium III in this old box, as does commenting on WordPress! Sound works fine via alsa. The other good thing about this Linux release is the people maintaining it are quite conservative about what and how up-dates/upgrades are done (KISS principle and plenty of hand-holding for newbies via their forum).
    I can’t imagine you would change to it but I thought I’d ‘put it out there’ just in case others were looking for a reliable Linux to try.

  4. E.M.Smith says:


    I’m an OS Slut. I like to try them all ;-) (Sometime even for money… that I suppose makes me an OS Whore then…) So I’m fairly likely to give PCLinuxOS a try just because it exists, but even more so with your recommendation and the description as a bit conservative. While I like Debian, it seems just a bit more “experimental” than I normally like. (CentOS is very nice in that regard, but too “up tight” for a daily driver, what with the screen lockout happening if you leave the keyboard for 2 minutes and being about 5 years back on some kinds of code – like browsers are having issues with current security features and HTML5). So a 1/2 way ground between them is what I’m pining for. From the description, this might be it.

    It is Mandrake / Mandriva based, so a sort of a Red Hat root. I’ve heard of Texstar before, and while I don’t remember where, I do remember thinking I agreed with him. The wiki makes it sound interesting:

    The precursor to PCLinuxOS was a set of RPM packages created to improve successive versions of Mandrake Linux (now Mandriva Linux). These packages were created by Bill Reynolds, a packager better known as Texstar. From 2000 to 2003, Texstar maintained his repository of RPM packages in parallel with the PCLinuxOnline site. In an interview, Reynolds said he started PCLinuxOS “to provide an outlet for [his] crazy desire to package source code without having to deal with egos, arrogance and politics.”

    In October 2003, Texstar created a fork of Mandrake Linux 9.2. Working closely with The Live CD Project, Texstar has since developed that fork independently into a full-fledged distribution. The initial releases were successively numbered as “previews”: p5, p7, p8 up to p81a, then p9, p91, p92, and p93.

    Although it retains a similar “look and feel” to Mandriva Linux, PCLinuxOS has diverged significantly. The code was officially forked from Mandrake 9.2 into an independent project in 2003. After three years of continuous development, the developers took advantage of further development in (the renamed) Mandriva in late in 2006 for PCLinuxOS 2007. In the releases before 2007, it was normally necessary to perform a re-installation.

    I ran Mandrake for a while, and tried Mandriva, but the “politics” aspect this mentioned kind of bothered me too. IIRC, source was made a little harder to get, or packaged oddly, or some such. At any rate, I “moved on” and used R.H. for a few years instead. If Texstar had the same issues, but fixed them instead, it ought to be a decent distribution.

    Also looks like The Community generally is not fond of “systemd” and is not going there, at least per this page:

    As that panders to my bias against systemd, they must be right! ;-)

    Given that I’m looking for a 1/2 house between CentOS (and they go to systemd in the 7.x series so I’m stuck in 6.x land anyway) and Debian (WeeHaw ride ’em Cowboy!!!) what has also stated an intent to go to systemd… and I don’t want systemd… this RH based distribution just might be the one… I do like KDE (at least, the old KDE…) and they have the lighter weight desktops available, so generally “looks good”. I’ll likely give it a spin on some box or other.

    @Topic of R.PiM2 Hang:

    Some more info.

    That chip would not work on the Pi B+ either, but it did give me the Raspberry screen and option of holding down shift to enter “rescue mode”. If you continue to boot, it hangs. But you can get to NOOBS via rescue. Unfortunately, NOOBS just wants you to reinstall the OS and blow everything away. If I wanted to do that, I’d just format and put NOOBS on the chip. ….

    So I’ve got it mounted on the Evo and I’m sucking off the partitions so I can put back what-all I’ve accumulated while using it IFF I need to do a reformat / start over. Then I’m going to muck about for a little while down in the various boot areas to see if I can crowbar it back to life. After about an hour of that, I’ll likely take the faster path of “reinstall and copy back the file systems I’ve saved”.

    FYI, here’s list of partitions that NOOBS builds on the chip:

    file -s /dev/sdb1
    /dev/sdb1: sticky DOS/MBR boot sector, code offset 0x58+2, OEM-ID "MSWIN4.1", sectors/cluster 16, reserved sectors 54, Media descriptor 0xf8, sectors/track 32, heads 64, hidden sectors 2048, sectors 1681546 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 821, serial number 0xece5ec59, label: "RECOVERY   "
    file -s /dev/sdb2
    /dev/sdb2: sticky DOS/MBR boot sector; partition 1 : ID=0x83, start-CHS (0x0,0,0), end-CHS (0x0,0,0), startsector 8192, 1048576 sectors; partition 2 : ID=0xf, start-CHS (0x0,0,0), end-CHS (0x0,0,0), startsector 1056768, 124928 sectors, extended partition table (LBA)
    file -s /dev/sdb3
    /dev/sdb3: sticky Linux rev 1.0 ext4 filesystem data, UUID=2590e571-2bfc-40f6-9894-ac21784382ce, volume name "SETTINGS" (extents) (huge files)
    file -s /dev/sdb4
    /dev/sdb4: cannot open `/dev/sdb4' (No such file or directory)
    file -s /dev/sdb5
    /dev/sdb5: sticky Linux rev 1.0 ext4 filesystem data, UUID=3c3e6ad4-089a-4ef7-99a5-de1f3cef8bab, volume name "data" (extents) (large files) (huge files)
    file -s /dev/sdb6
    /dev/sdb6: sticky DOS/MBR boot sector, code offset 0x3c+2, OEM-ID "mkfs.fat", sectors/cluster 4, root entries 512, Media descriptor 0xf8, sectors/FAT 120, sectors/track 16, heads 4, hidden sectors 2752512, sectors 122880 (volumes > 32 MB) , serial number 0x5e7d574, label: "boot       ", FAT (16 bit)
    file -s /dev/sdb7
    /dev/sdb7: sticky Linux rev 1.0 ext4 filesystem data, UUID=2ef86634-719c-4fc2-94ba-7ca73ca76d8f, volume name "root" (extents) (large files)

    It looks to me like they carried over the PC behaviour of a 4th “partition” that is just a pointer to the following logical partitions.

    #7 is where all the Raspbian software lives along with the “home” directories. That is, it looks like it has all of the Linux Land in it.

    #6 claims to be a MBR Master Boot Record and I think that is likely the place I need to “fixup”:

    root@EVOdebian:/WD/home/PiM2/T6# ls
    bcm2708-rpi-b.dtb       bootcode.bin  COPYING.linux  fixup_db.dat  kernel7.img       menu.txt        raspbian     slitaz-live   start.elf
    bcm2708-rpi-b-plus.dtb  cmdline.txt   fixup_cd.dat   fixup_x.dat   LICENCE.broadcom  os_config.json  slitaz       start_cd.elf  start_x.elf
    bcm2709-rpi-2-b.dtb     config.txt    fixup.dat      issue.txt    overlays        slitaz-base  start_db.elf

    #5 is that 512 MB optional partition you can make at build time.

    root@EVOdebian:/WD/home/PiM2# ls T5
    config.txt  ems.BuildStuff  lost+found  os_config.json  README.txt
    root@EVOdebian:/WD/home/PiM2# more T5/README.txt 
    Data Partition README
    This is a 512MB ext4 format partition for you to use as a shared data partition between your currently installed OSes.
    For example, you might want to use this to hold your /home directory.

    That leaves partitions 1, 2, and 3.

    #3 looks like it is for NOOBS:

    root@EVOdebian:/WD/home/PiM2/T3# ls -l
    total 16
    drwxr-xr-x 4 root root 4096 Dec 31  1969 cache
    -rw-r--r-- 1 root root  580 Dec 31  1969 installed_os.json
    drwx------ 2 root root 4096 Dec 31  1969 lost+found
    -rw-r--r-- 1 root root   84 Dec 31  1969 noobs.conf

    I looked in noobs.conf and it seems to match my settings. The dates are interesting. Says the clock was not set when these were written. Not a surprise, really, as the R.Pi has no HW clock and if these were written before NTP was up, well…

    #2 claims in the file -s listing to be a MBR, but I can’t mount it to inspect it. (Note the lack of “FAT” in the listing or of EXT or of…) If anyone knows how to mount this, let me know. I plan to just ignore if for now.

    #1 looks to be the “recovery” images and copies that NOOBS can’t find at recovery boot anymore. If I can’t change the boot enough to get things up on their own, I may try changing it just enough to get the recovery to work. (Mostly as an exercise in skill building… yes, I’m playing ;-) But generally it looks like I can ignore it if desired.

    Saved Data

    FWIW, I’ve copied all the mountable partitions over to the EVO (as you can tell from the prompts in the text copied above). The command I used is pretty simple, but nice to know about. I typically install it as “cpdir” for copy directory. I first wrote it before there were recursive options to “cp” that let it copy whole directory trees, and I’m just in the habit of keeping it around. It also illustrates some of why Unix / Linux folks like this world more than PCs… You can do so much with so little. I.e. terse with power.

    root@EVOdebian:~# cat /usr/local/bin/cpdir
    (cd $1; tar cf - . ) | (cd $2 ; tar xvf -)

    The “cat” is just printing out the file in /usr/local/bin/cpdir which is listed on the next line.

    Lets say I entered the command:
    cpdir /home/mydir /backups/to/save

    The first part spawns one shell that goes off to run on it’s own. That’s what the parenthesis do. Inside that shell, it changes directory to the first argument (/home/mydir) and starts to make a “tar” archive format “tarball” of everything it finds there. The “c” means create. The “f” says to make a file, not send it to tape or media. Then the fun bit. The “-” says that the “file” really is the pseudo file of a “pipe”. It tells tar to send the output to a pipe connector. Now, outside that shell:

    The next symbol “|” is the pipe symbol. It says “catch the output of the preceding command” (which we told to send out the tarball stream) and connect it to the next “command”. That next command is another () set that says to spawn another shell. So the output of that first shell is being piped into the second shell. Then, that second shell:

    Inside the second spawned shell, the first thing it does is change directory to the $2 parameter which is /backups/to/save. Then (that’s what the “;” does, is say do the first command, then…) it starts its own “tar” program running. This “Tape ARchiver” has different options. It says to “x” extract the tarball do it “v” verbosely (i.e. give each file name as it is extracted and written) and get the input from a named “f” file… that is then given as “-” that tells it the name of the file isn’t a name, it’s an incoming pipe.

    Whew! That’s a LOT for 29 characters to say ( or a bit over 35 if you count the spaces, but some of them are optional…)

    So I did that with each of the mounted file systems. As I’d mounted them on /T1 to /T7 and the target was on the WesternDigital disk in a directory I made named /WD/home/PiM2/T{number} I could copy all of each partition by doing:

    cpdir /T1 /WD/home/PiM2/T1
    cpdir /T3 /WD/home/PiM2/T3

    etc. etc.

    Now I can go hack around on the chip and if I screw something up, I can just restore that partition. Or I could just remake the chip with the build script and copy back the #7 partition contents (that looks like the only one I care about).

    BTW, IF I’d only wanted to make the tarball, and not unpack it. Just have it around “in case” and not for looking over the contents on the other machine, I could have just done a much simpler command.

    cd /T1
    tar cv . > /WD/home/PiM2/T1.tar

    Or, if I wanted to do this but without changing my current working directory:

    (cd /T1; tar cv . > /WD/home/PiM2/T1.tar)

    root@EVOdebian:/WD/home/PiM2# (cd /T1; tar cv . > /WD/home/PiM2/T1.tar)

    Which shows from the prompt that I’m nowhere near the /T1 directory, but want to be where I can look at the results once it is done. The lines following the command show the output of the ‘v’ option where we can see each file being copied.

    When it finishes, I can see the tarball just with a simple file listing since my working directory didn’t change when I spawned that subshell to do the copy.

    root@EVOdebian:/WD/home/PiM2# ls -l
    total 762940
    drwxr-xr-x  4 root root      4096 Dec 31  1969 T1
    -rw-r--r--  1 root root 780451840 Aug  8 07:15 T1.tar
    drwxr-xr-x  2 root root      4096 Aug  8 05:57 T2
    drwxr-xr-x  4 root root      4096 Aug  8 06:46 T3
    drwxr-xr-x  2 root root      4096 Aug  8 06:00 T4
    drwxrwxrwx  4 root root      4096 Jul 28 14:20 T5
    drwxr-xr-x  7 root root      4096 Dec 31  1969 T6
    drwxr-xr-x 26 root root      4096 Jul 28 14:11 T7

    The tarball (T1.tar) has a size of 780 MB. Note the first letter is a “d” for directory for the others like /T1 while it is a “-” for this plain file. It is “read write” by the owner (but only “read” for everyone else) and is owned by root in the root group. “x” means “executable” for plain files (that is, it is a command that can be run) while it means “you can change directory into here” for directories.

    Well, so much for the tour of Linux tools I’m using… Time for me to get on with inspecting the boot sector and see if I’m doing an “unscramble the eggs” or just a “new install and restore the user data”… But in any case, at this point I have a direct recovery path.

    Once recovered, I’ll duplicate the chip for faster recovery next time…

  5. E.M.Smith says:

    OK, I’ve recovered “the chip” to a run-able state again.

    Basically, I just compared the recently date stamped files on the 8 GB chip that I’d configured first, the 64 GB chip that I installed a half dozen systems onto, and the one that was broken by the slitaz.deb. Then I made a “good guess” about how it worked, and what was likely the broken / missing bit.

    After looking at a bunch of things, it looks like when you have more than one OS installed, the boot is somewhat different (some things are put in directories named for the OS) and the “conversion” broke the ability of a native R.PiB+ to just boot the regular kernel while at the same time not having a kernel that would work with the R.PiM2.

    In particular:

    The kernel run by the Pi B+ (and, one presumes, A and etc.) is named kernel.img. That run by the R.PiM2 is named kernel7.img.

    root@EVOdebian:/WD/home/PiM2/64mix/T8# ls -l
    total 19136
    -rwxr-xr-x 1 root root    4423 Apr 27 12:40 bcm2708-rpi-b.dtb
    -rwxr-xr-x 1 root root    4702 Apr 27 12:40 bcm2708-rpi-b-plus.dtb
    -rwxr-xr-x 1 root root    5690 Apr 27 12:40 bcm2709-rpi-2-b.dtb
    -rwxr-xr-x 1 root root   17900 Apr 27 12:40 bootcode.bin
    -rwxr-xr-x 1 root root     120 Dec 31  1979 cmdline.txt
    -rwxr-xr-x 1 root root    1801 Jul 23 15:35 config.txt
    -rwxr-xr-x 1 root root   18693 Apr 27 12:40 COPYING.linux
    -rwxr-xr-x 1 root root    2366 Apr 27 12:40 fixup_cd.dat
    -rwxr-xr-x 1 root root    6161 Apr 27 12:40 fixup.dat
    -rwxr-xr-x 1 root root    9216 Apr 27 12:40 fixup_db.dat
    -rwxr-xr-x 1 root root    9214 Apr 27 12:40 fixup_x.dat
    -rwxr-xr-x 1 root root     137 May  6 23:31 issue.txt
    -rwxr-xr-x 1 root root 3930004 Apr 27 12:40 kernel7.img
    -rwxr-xr-x 1 root root 3974884 Apr 27 12:40 kernel.img
    -rwxr-xr-x 1 root root    1447 Apr 27 12:40 LICENCE.broadcom
    -rwxr-xr-x 1 root root   18974 Sep 25  2013
    -rwxr-xr-x 1 root root     284 Dec 31  1979 os_config.json
    drwxr-xr-x 2 root root    4096 Dec 31  1979 overlays
    -rwxr-xr-x 1 root root  567672 Apr 27 12:40 start_cd.elf
    -rwxr-xr-x 1 root root 4644712 Apr 27 12:40 start_db.elf
    -rwxr-xr-x 1 root root 2664088 Apr 27 12:40 start.elf
    -rwxr-xr-x 1 root root 3621768 Apr 27 12:40 start_x.elf

    This “ls” listing in the 64mix chip shows both kernels, while the broken one does not have the kernel.img present. It was moved to a subdirectory.

    root@EVOdebian:/WD/home/PiM2/64broke/T6# ls -l
    total 15268
    -rwxr-xr-x 1 root root    4423 Apr 27 12:40 bcm2708-rpi-b.dtb
    -rwxr-xr-x 1 root root    4702 Apr 27 12:40 bcm2708-rpi-b-plus.dtb
    -rwxr-xr-x 1 root root    5690 Apr 27 12:40 bcm2709-rpi-2-b.dtb
    -rwxr-xr-x 1 root root   17900 Apr 27 12:40 bootcode.bin
    -rwxr-xr-x 1 root root      41 Aug  7 16:04 cmdline.txt
    -rwxr-xr-x 1 root root    1857 Aug  7 16:04 config.txt
    -rwxr-xr-x 1 root root   18693 Apr 27 12:40 COPYING.linux
    -rwxr-xr-x 1 root root    2366 Apr 27 12:40 fixup_cd.dat
    -rwxr-xr-x 1 root root    6161 Apr 27 12:40 fixup.dat
    -rwxr-xr-x 1 root root    9216 Apr 27 12:40 fixup_db.dat
    -rwxr-xr-x 1 root root    9214 Apr 27 12:40 fixup_x.dat
    -rwxr-xr-x 1 root root     137 May  6 23:31 issue.txt
    -rwxr-xr-x 1 root root 3930004 Apr 27 12:40 kernel7.img
    -rwxr-xr-x 1 root root    1447 Apr 27 12:40 LICENCE.broadcom
    -rwxr-xr-x 1 root root   18974 Sep 25  2013
    -rwxr-xr-x 1 root root     253 Aug  7 16:04 menu.txt
    -rwxr-xr-x 1 root root     284 Dec 31  1979 os_config.json
    drwxr-xr-x 2 root root    4096 Dec 31  1979 overlays
    drwxr-xr-x 2 root root    4096 Aug  7 16:04 raspbian
    drwxr-xr-x 2 root root    4096 Aug  7 16:04 slitaz
    drwxr-xr-x 2 root root    4096 Aug  7 16:04 slitaz-base
    drwxr-xr-x 2 root root    4096 Aug  7 16:04 slitaz-live
    -rwxr-xr-x 1 root root  567672 Apr 27 12:40 start_cd.elf
    -rwxr-xr-x 1 root root 4644712 Apr 27 12:40 start_db.elf
    -rwxr-xr-x 1 root root 2664088 Apr 27 12:40 start.elf
    -rwxr-xr-x 1 root root 3621768 Apr 27 12:40 start_x.elf
    root@EVOdebian:/WD/home/PiM2/64broke/T6# ls raspbian/ 
    cmdline.txt  config.txt  kernel.img  menu.txt

    (Note that the naming on the location of these directories marks this one as ’64broke’ and partition ‘6’ of that chip.)

    This one has the regular Pi kernel moved into a directory named “raspbian” and has some slitaz directories. The expectation of the .deb package clearly being that those are the two kernels you will run.. and both likely unable to run on the R.PiM2. OK…

    So the first thing I did was just put a copy of that kernel back at the “one level up” in case it was needed to boot this chip on an older Pi B+ model. This is likely irrelevant, but it was a “sanitation measure” in that it costs nearly nothing (some bytes on the chip) and might be helpful later, but does nothing bad to leave a copy where it had been before.

    So in my copy of the working chip directory, I copied that kernal.img file to the mount point of the actual chip partition (as opposed to my ’64broken’ copy of it):

    cp kernel.img /T6

    I then compared two files. cmdline.txt and config.txt with their counterparts, and did a ‘fix up’ on the differences.

    root@EVOdebian:/WD/home/PiM2/64mix/T8# diff cmdline.txt /T6/cmdline.txt
    < dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p9 rootfstype=ext4 elevator=deadline rootwait
    > root=/dev/null rdinit=/sbin/piboot quiet
    root@EVOdebian:/WD/home/PiM2/64mix/T8# cp cmdline.txt /T6

    For the “diff” command, the LT caret means taken out while the GT caret (right angle bracket) means put in; to change one file to the other.

    So here I copied the working one to the broken actual chip. I just copied the longer working one over the shorter non-working on. Then changed the root target to be the right partition number (remember that the 64mix chip had a load of OSs on it so numbers are 2 higher, while I just needed the one on the 7 partition on the single OS chip…

    The final text actually looks like:

    dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p7 rootfstype=ext4 elevator=deadline rootwait

    I don’t know if that was the fix, or if the next change was the fix, but both together did work. “Someday” I’ll go back and test them one at a time…

    root@EVOdebian:/WD/home/PiM2/64mix/T8# diff config.txt /T6/config.txt
    < arm_freq=1000
    > arm_freq=900
    < core_freq=500
    < sdram_freq=500
    > core_freq=250
    > sdram_freq=450
    > kernel=slitaz/kernel.img
    > initramfs slitaz/rootfs-base.gz

    Most of the differences were the overclock settings that had been ‘backed out’ in the most recent changes. So I left them backed out. But those two lines at the bottom, the added kernel= and initramfs slitaz were commented out. I wanted to remove those references to the slitaz kernel on the suspicion that it was a Pi Model 1 kernel and not going to work in any case.

    Again, I don’t know which of these two changes made it work. I suspect most likely the last one, but only testing will tell.

    So, basically, put back a copy of the Pi B+ kernel, just in case, then
    changed the “cmdline.txt’ file to be like the working one (9 changed to 7),
    and finally, commented out the two new lines at the bottom of config.txt

    Now it boots once again into my fully configured and working R.PiM2 machine with all data and configurations intact.

    I’m now a happy camper… (who knows more than he wanted to know about how the R.Pi boot process with multiple OSs works…)

    Once again I can get back to doing things that matter to me and get out of the ‘fixing what broke but ought not’ business.


    New Postings coming soon, now that I’m no longer fixing up other folks breakage of my stuff.

    (Yes, I know. They didn’t SAY that the .deb would work on the R.PiM2 and it was my fault for thinking that they had… error of assumption that having ONE thing they said worked on the Model 2 meant they had made both bits work… but really, how hard would it be for them to have said “This works on the Model 1″… )

    It’s late. I have other stuff to do. If anyone feels like giving the SliTaz folks a pointer to this so they know what to fix, please do. I’m unlikely to get around to it as I’m way behind where I want to be (and since I linked to their pages, they really ought to have followed the pingback and seen for themselves…) Besides, I’m a tiny bit grumpy right now and that’s not a good time to be telling folks they broke my toys….

    1/2 ;-)

  6. p.g.sharrow says:

    K.I.S.S. Lol…

    Dual Boot often results in problems. Multi Boot even worse. For those of us not so well versed, a deal killer.
    I would think changing the SD chip would be a better way for more normal people to change OS on a RasPi. The SD chip should only contain the OS and needed applications to do the service intended for the device. Thumb Drives for all other files. The computers and chips are inexpensive enough to be dedicated devices. Keyboards and Monitors are now the main expense.

    I’m glad you are poking under the hood and I am working on my farming ;-)

  7. E.M.Smith says:


    Well, yes and no ;-)

    Since part of my goal is to become versed in “under the hood” I go out deliberately looking for dragons… (Better advertising if you can put “Dragon Slayer” on your shield and mean it ;-) so when there is a “Here There Be DRAGONS!!” sign out, my response is “Oh Boy! Wax the lance and sharpen the sword, boys, we’re going Dragon Hunting!”.

    So, for example, on the 6 way boot chip, I wanted to play with the different OS types and see what they were like. Why blow off 6 chips I I can just use one? And avoid all the chip swapping? IFF it doesn’t work, I can have a little dragon hunting time, and if it does work, I can put “Made 6 way Boot Raspberry Pi just for fun” on the shield and calling card. ;-)

    But it did work, just fine.

    Now when I went to “production”, I did use a different 64 GB card with only the one target OS on it and called it done. At least for a while. (The idea being to build a PXE boot server on the chip and have about 40 GB of “OS of the day” I could PXE boot the Evo to be…) But…

    The SliTaz site went out of their way to say that the .deb was designed from the get go to just boot the SliTaz kernel and load their apps into RAM disk and use the Raspbian part of the chip as the file system… So more of “boot and a 1/2” than dual boot… Well, by definition that needs the Raspbian to be there… (They also have a stand alone version that could be a more normal dual boot… but I chose the “safe” option…. lucky me…)

    That, then, mucked up my “production” chip. ( I’d thought of trying it first on the 8 GB stand alone Raspbian that I’d gotten in the kit… but was too lazy to swap to it… I’d say “lesson learned”, but… )

    That kind of gave me two choices.

    1) Fix the chip.

    2) Re-run the build script (with accumulated changes) and re-install all data and customizing.

    Since #2 is The Microsoft Way, I have trouble choosing it just on principle… and since #1 puts more fun stuff on the calling card /. shield… Well, hey, wouldn’t like another dragon head on the wall… Besides, I might learn something. Maybe even to be less lazy and use the experimental chip for experiments…

    Best Practices

    Per “best practices” for using a R.Pi as a server, I’d basically agree with what you were saying. Mine had 1 purpose: PXE boot server with the attendant DHCP, DNS, and FTP servers that support it (and are expected to be on the same server). My mistake was do do the “play with Slitaz” function (or “service”) on that chip, instead of swapping to the “play with OSs” chip.

    I spent the early part of today moving my home directory onto a USB thumb drive (for performance testing – so far noticeably slower than the rotating real disk USB disk… but probably the slow cheap PNY USB thumb drive I’m using…) That same separation of OS from Data. Yet that data source could just as easily be an FTP or NFS server. (Eventually it will be an NFS server hidden…) In that way the OS is a generic thing. And the data unplugs and moves with you.

    My early conclusion is that I’ve had faster service from SD cards in an adapter (where the speed is on the chip) and much faster from a “Monster” brand USB thumb drive that I’m likely to move onto later. Lesson? Find out the speed and reputation of the USB thumb drive before moving onto it; speed varies a lot, as does write wear. (PNY had a couple of ‘talking dirt’ comments on one Linux board…. but I had this one already so figured why not test it… Hey, even a small dragon counts! )

    Later today I’m going to use a 4 GB chip to make a regular R.PiM2 SliTaz system (they have a M2 distro on the site) and try again. I’ll also be making one or two other “dedicated purpose” chips. At least one of them to be a “Live-CD” like “load all into RAMdisk and forget it when done” on the way to a full on TAILS port. As “someday” I’d like RaTails to integrate into the regular R.Pi build / boot process, time spent on this was just “motivated learning” of what I need to learn anyway…


    I have a working single boot chip for the PXE server (again…).
    I leaned a bit early things I’ll need for R.PiM2 boot integration anyway.
    The intent is to have a few stand alone chips for specific purposes.
    The multi-boot chip has served the purpose, and will likely be overwritten (now that I know I’m not going to run RISCos or most of the others… though only after I evaluate the Fedora and Arch Linux on it a bit more).
    A home directory on USB stick is done, and will be tested on various systems (likely to be kept, but only after moving to a faster stick… on the Evo Chrome browser say s “waiting for cache” a bit too often… that is in the .cache directory in your home directory where Chrome packrats pages)
    The NFS file server is 1/2 done, to eventually provide most systems their more generic spaces.
    Dividing the world into compute servers, remote provisioned OS copies (locked down), and separately stored data and file systems is the general model. Everything with a duplicate, backup, or replacement. Eventually data stores to be encrypted media and useless without the right magic sauce…

    For simple uses, like, say, a DHCP / DNS / Time server; just putting it all on one dedicated chip with a backup copy in an EMP proof can is likely more than enough. Since you need DHCP, DNS, and Time to get the other boxes up, it kind a needs to be stand alone. If this is the PXE server, you also get FTP too and your core is built with one chip. (Plus hub or router). The others can then be segmented more into compute hw, remoted OS, remote data… (or “cloud” in the new jargon, even if a local personal cloud…).

    Have you ever seen a longer way of saying: “Yup.”?

  8. p.g.sharrow says:

    Well, “Yup” doesn’t convey quite as much information. ……………
    A valuable description of proposed objectives, at least to me.
    I hope we can help with resources. pg.

  9. beng135 says:

    Maybe it was my older machine (~2010, 2.5 GhZ), but I tried running several Linux distros on a bootable 64 GB USB stick, and they were too slow to be useful (Puppy was barely useable, Mint slower still, and Ubuntu completely unusable). From that, I consider such sticks to be quite useful for storage, backup/recovery and testing, but not running distros from.

  10. E.M.Smith says:


    The “issue” is the way sticks do writes. Large blocks of bits are written in one go, due to the way the chips work (not exactly random access RAM…). So if you change one byte in a log file somewhere, you might end up with a 10,000 byte block being re-written. Multiply that by a chatty thing like Chrome browser cache and you can have 100,000 byte blocks read / writing all the time. That then puts you into ‘wear leveling’ land…

    To prevent wearing out one byte or bit, as some part of the chip get more ‘wear’ than others, the stick starts to move idle blocks to where active had been and vice versa. Now you have more 100,000 bytes of moves going on.

    All this makes them a bad choice for things with truly random and frequent accesses for write, like much of the Unix /. Linux files.

    The “fix” for this is to make a very compact Linux (definitely NOT a description of Ubuntu or Mint) and pull all the active bits into a “RAMdisk” only flushing through the “union file system” to the backend stick occasionally. That’s what systems like Puppy and Knoppix try to do.

    BTW, the way to test it is just to compare “running from stick” to running from disk or CD. I’m using a single CPU 2 GB memory ~2.5 GHz box right now. From disk, it’s just dandy. With JUST my home directory on the stick, it is still Just Dandy… except… Both Chrome (that has a .cache fetish) and IceWeasel (that isn’t telling me where it’s writing bits) have sporadic hangs as they try to dump a load of “something” into “somewhere” and end up waiting on the stick. “Top” shows that system in “wait” state for IO as the typing in the comment window hangs… and in Chrome it puts up a line of text at the bottom of the screen saying “waiting for .cache”… that is in my home directory…

    So this has told me I either need a much faster stick, or use a RAMdisk build.

    FWIW, I was using a 64 GB SD Class 10 chip as my home directory including Outlook Mail when forced to live on a Windowz box and it was just fine. Don’t think Windows is any less chatty, so I suspect it is either a different write method, or just a much faster chip.

    Later today I’ll be trying a “Monster” stick with fast I/O rating and then, if needed, that 64 GB chip on Linux.

    Aren’t you glad I’m doing this and not you? ;-)

    As it is, the “annoyance” is more than I’d want for a regular experience, but livable for a system where I wanted to be able to “pull the plug” in a hurry.

    I’ve also run distros from USB built with RAMdisk / ufs and found them very comfortable. Several Live-CD versions too. And on much slower machines than yours. So I suspect it was the distribution of Linux you used and not your computer, and then a slow stick. (Since they don’t advertise their speed ratings, some are quite slow for small file read / writes. Then when they do put speed, it is often XX/Mb/second and doesn’t say if that’s for ONE 1 MB file, or 1000 small file random writes… and that matters.)

    Eventually we’ll get really fast really random USB sticks suited to this use. For now, it’s a mixed bag and “go fish”…

  11. E.M.Smith says:


    I’ve just moved off of a PNY 32 GB stick and onto a “Monster” brand 32 GB stick. The difference in performance is striking. More in a posting soon, but the PNY has a tendency to sporadically “stall” while the Monster just flys consistently. I’m now quite happy using it as my home directory where the PNY had me doubting the whole concept.

  12. beng135 says:

    Aren’t you glad I’m doing this and not you? ;-)

    That made me laugh. Yes, it’s alot easier to sit & watch what you do (& try to understand). Sometimes when I tinker, all the technicalities form a tangled mess in my head & I have to take a break. Later, I realize “why not try THIS simple trick”, try it, and it works.

    Thanks for making programming sound like a great adventure…

  13. E.M.Smith says:


    Details in:

    You are most welcome! (And glad you got a chuckle…)

    It is important in programming / sys admin to keep a sense of humor; otherwise you start thinking about what 2 KV at a few dozen KVA can do … ;-)

    Per the “tangled mess”: Happens to us all. When I have that “hit the wall” moment, I stop and have a cup of coffee or tea. If that doesn’t work after a couple of tries, I have a glass of wine or beer. If that doesn’t work after a few tries, it’s tomorrow and I’ve forgotten what was the problem and have a whole new outlook on the task since everything from before is now lost to distant mists… 8-}

    And it IS an adventure… and like all adventures not always what was expected at the start…

  14. Pingback: RaTails – Draft High Level Steps | Musings from the Chiefio

Comments are closed.