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: http://arm.slitaz.org/rpi/ )
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 pilfs-showcase-20121101.zip -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”?
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…)
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 ;-)