debian testing: 2016-05-01

Blah…

https://lists.debian.org/debian-project/2016/04/msg00012.html

<i>When there is a response - and there isn't always - it's usually "nobody
currently maintains httpredir, sorry".

So, it appears as if currently nobody has time or the energy to take
care of [httpredir.debian.org](http://httpredir.debian.org) properly.</i>

https://lists.debian.org/debian-project/2016/04/msg00018.html

So it was good for a year…

https://lists.debian.org/debian-devel-announce/2015/05/msg00003.html

yuck…

Regards,

Heh, this is why I do not like non standard stuff . . .funny this sort of thing happens very rarely though . . .

So I’m, prepping to make my own “production” image; prior to installing a ton of development tools, and figured I’d point a few things out. Most this is for Robert when he gets around to worrying about all this, if it all. But there is nothing stopping anyone else form using this information.

Trim out uneeded cruft:

william@beaglebone:~$ sudo apt-get install ncdu
william@beaglebone:~$ cd /

william@beaglebone:/$ sudo ncdu

. . . And then navigate around in ncdu to find uneeded large files, and directories.

A 24Megabyte file ?!
22.4MiB [##########] libicudata.so.52.1

william@beaglebone:/$ sudo apt-get remove libicu52
. . .
After this operation, 28.9 MB disk space will be freed.
Do you want to continue? [Y/n]

william@beaglebone:/$ sudo apt-get purge --auto-remove libicu52

— /usr/share --------------------------------------------------------------------------------------------------------
/…
36.6MiB [##########] /locale
15.2MiB [#### ] /doc
7.2MiB [# ] /man

— /lib --------------------------------------------------------------------------------------------------------------
/…
68.4MiB [##########] /modules

— /var/cache --------------------------------------------------------------------------------------------------------
/…
40.5MiB [##########] /apt

A lot of cruft in these 3 locations. Much, of it can be removed, but must be careful what you remove in /lib/modules. If you do not know what to remove, then do not touch anything . . .

@Robert,

/lib/firmware no longer exists ?

I'm guessing you have the "console" image?

Correct, it's pretty empty..

(no firmware is required to "flash" the eMMC, that's the console's main
requirement)

Regards,

I’m guessing you have the “console” image?

Correct, it’s pretty empty…

(no firmware is required to “flash” the eMMC, that’s the console’s main requirement)

Regards,

So if i want to use this as a production image i need to mkdir /lib/firmware/ and then bb.org-overlay git, install and all that ? I really do not want the IoT image . . . I did not check it at all, but I’m sure it’s full of stuff I’d never use.

What you saying, i need to package bb.org-overlay.. :wink:

sudo apt-get install git-core device-tree-compiler build-essential

git clone https://github.com/beagleboard/bb.org-overlays
cd ./bb.org-overlays

./install.sh

Regards,

bone-debian-8.4-console-armhf-2016-05-01-2gb.img.xz

Is the image I have. Supposed to be the standalone sdcard image.

What you saying, i need to package bb.org-overlay… :wink:

sudo apt-get install git-core device-tree-compiler build-essential

<i>git clone [https://github.com/beagleboard/bb.org-overlays](https://github.com/beagleboard/bb.org-overlays)
cd ./bb.org-overlays</i>

./install.sh

No, what I’m saying is that we( I ) Just had a major version change, and something that used to be in place, is no longer in place. It’s confusing. All I really need to know is if I want use overlays, where do they go, and I believe you just answered my question. Which is pretty much exactly like upgrading from 3.8.x( for me ), except /lib/firmware needs to be created.

Debian’s “Firmware” page seemed to indicate that also, but you know how doc’s can be sometimes.

both the iot & lxqt images ship those.

The console does not.. (right now it would have to include
git-core/device-tree-compiler/build-essentials) which just add more weight..

Regards,

both the iot & lxqt images ship those.

*The console does not… (right now it would have to include git-core/device-tree-compiler/*build-essentials) which just add more weight…

Regards,

Robert Nelson
https://rcn-ee.com

So question. Would precompiling the device tree binaries, then creating /lib/firmware, and placing the binaries in that directory not work ? No this is not a smart ass question - But I do think it would work, just not sure why it’s not being done already.

As far as adding weight, I totally get it. Jessie seems to be heavier by nature because . . .
william@beaglebone:~$ cd /usr/share/locale/
william@beaglebone:/usr/share/locale$ sudo rm -r uk fr cs pl de vi nl sv ru es ja da it zh_CN ca hu tr eo id sl pt_BR bg fi sk pt
william@beaglebone:/usr/share/locale$ cd …/doc
william@beaglebone:/usr/share/doc$ sudo rm -r ./*
william@beaglebone:/usr/share/locale$ cd …/man/
william@beaglebone:/usr/share/man$ sudo rm -r ./*

Only netted me around 50MB. Image is still at 242MB, and it’s getting pretty close to being as lean as I’d want it to be. Well I could gain another 40M from apt cache, and perhaps 40M from removing modules . . . But that’s still 160M in size . . . way larger than Wheezy.

Anyway, do I need you to package anything up for me ? No . . . I just wanted to make sure /lib/firmware was still correct for Jessie. Especially since I’ve ripped out systemd, and was unsure if there was another mechanism for device tree overlays, or not.

*both the iot & lxqt images ship those.*

*The console does not.. (right now it would have to include
git-core/device-tree-compiler/**build-essentials) which just add more
weight..*

*Regards,*

*-- *

*Robert Nelson*
*https://rcn-ee.com/&gt;\*

So question. Would precompiling the device tree binaries, then creating
/lib/firmware, and placing the binaries in that directory not work ? No
this is not a smart ass question - But I do think it would work, just not
sure why it's not being done already.

Correct, that's one reason why the shipped "./dtc-overlay.sh" is in the
repo, so you can build the cross-dtc.

As far as adding weight, I totally get it. Jessie seems to be heavier by
nature because . . .
william@beaglebone:~$ cd /usr/share/locale/
william@beaglebone:/usr/share/locale$ sudo rm -r uk fr cs pl de vi nl sv
ru es ja da it zh_CN ca hu tr eo id sl pt_BR bg fi sk pt
william@beaglebone:/usr/share/locale$ cd ../doc
william@beaglebone:/usr/share/doc$ sudo rm -r ./*
william@beaglebone:/usr/share/locale$ cd ../man/
william@beaglebone:/usr/share/man$ sudo rm -r ./*

Only netted me around 50MB. Image is still at 242MB, and it's getting
pretty close to being as lean as I'd want it to be. Well I could gain
another 40M from apt cache, and perhaps 40M from removing modules . . . But
that's still 160M in size . . . way larger than Wheezy.

DEBUG_INFO is enabled by default with the kernel now, so the modules are
bigger..

Anyway, do I need you to package anything up for me ? No . . . I just

wanted to make sure /lib/firmware was still correct for Jessie. Especially
since I've ripped out systemd, and was unsure if there was another
mechanism for device tree overlays, or not.

rsync/patch has a few dependices cut them out..

Regards,

rsync/patch has a few dependices cut them out…

I’m not sure what you mean, but if you mean systemd deps . . . this how is how removed systemd. Pretty much like http://without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_jessie/sid_installation but slightly modified.

william@beaglebone:~$ sudo apt-get update
william@beaglebone:~$ sudo apt-get install sysvinit-core sysvinit-utils
william@beaglebone:~$ sudo cp /usr/share/sysvinit/inittab /etc/inittab

william@beaglebone:~$ sudo su
root@beaglebone:/home/william# echo -e ‘Package: systemd\nPin: release *\nPin-Priority: -1’ > /etc/apt/preferences.d/systemd
root@beaglebone:/home/william# echo -e ‘\n\nPackage: systemd\nPin: release *\nPin-Priority: -1’ >> /etc/apt/preferences.d/systemd
root@beaglebone:/home/william# reboot

william@eee-pc:~$ ssh william@bbb
william@beaglebone:~$ sudo apt-get remove --purge --auto-remove systemd

no if you remove rsync and patch, that will allow you to remove a few more
large dependices..

Regards,

no if you remove rsync and patch, that will allow you to remove a few more large dependices…

Regards,

Ah, ok thanks :slight_smile: Not sure I’ll need either on the development image, but I may as well remove them now and reinstall later if needed.

william@beaglebone:~$ sudo apt-get remove --purge --auto-remove rsync patch
[sudo] password for william:
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following packages will be REMOVED:
patch* rsync*
0 upgraded, 0 newly installed, 2 to remove and 2 not upgraded.
After this operation, 809 kB disk space will be freed.

Well, maybe not so large :wink:

humm, thought they pulled in python-minimal, guess not..

Regards,

Anyway, yeah I do appreciate it Robert, but that one thing just didn’t pan out heh. In the end, I do like to have as small an image as possible, but it only matters to a point. Meaning, I’ll try, and perhaps even try too hard to get my image small, but it’s not super important once I’m feeling pretty good about not having too much dead weight around. 242M is really not all that large, and it’ll get bigger too once I have Nodejs compiled and installed. I think ~400M-500M would still be a pretty deal.

FYI.

On the my BBB with the 2016-05-01 lxqt testing image
I’d not apt-get installed anything.

I did:
sudo apt-get update
sudo apt-get upgrade

There were 5 packages to be upgraded:
bb-bonescript-installer-beta c9-core-installer libssl1.0.0 openssl rcnee-access-point

The bb-bonescript-installer-beta upgrade failed.
Killed appeared after the line CXX(target) Release/obj.target/…/epoll.o

Fire up memtester on your board:

debian@beaglebone:~$ sudo memtester 200
memtester version 4.3.0 (32-bit)
Copyright (C) 2001-2012 Charles Cazabon.
Licensed under the GNU General Public License version 2 (only).

pagesize is 4096
pagesizemask is 0xfffff000
want 200MB (209715200 bytes)
got 200MB (209715200 bytes), trying mlock ...locked.
Loop 1:

Regards,

Its been running for several hours and has completed four loops, I’ll leave it running overnight and follow-up if it prints anything but “OK”,

However, at this point it doesn’t look like this is the problem.

Something seems rotten in apt-get land.

Well . . . I’m in the middle ( or something ) of compiling Node 4.2.6 from Node.org sources . . . so far so good, but it’s been compiling for the last 2-3 hours . . .

In the mean time I’m dorking around with the rpi3 that came in today, and seriously considering using it as an armv7 build system. I’m still not fond of the original rpi’s but these things have some serious spunk. Still I’m a bit miffed that it seems we’re forced to use “raspbian”. The main contention, how does one load the needed board files, etc . . .

Did i ever mention I hate non standard things ? Particularly Debian . . .