Hey Everyone,
debian backports has been kindly enough to provide a systemd bump (230) from (215) via backports.
I’d like to add this by default to our repo, as systemd 230 brings in some nice enhancements.
Especially with regards to boottime…
v215 (x15)
17 seconds on average
v230 (x15)
debian@beaglebone:~$ systemd-analyze
Startup finished in 4.439s (kernel) + 7.779s (userspace) = 12.218s
To “test” add this experimental repo:
deb [arch=armhf] http://repos.rcn-ee.com/debian-exp/ jessie main
Then just:
sudo apt-get update ; sudo apt-get dist-upgrade ; sudo reboot
So, please test, if the results are positive, i’d like to move it our default repo in a couple weeks…
Regards,
This has now been pushed to Jessie, i'm pretty happy with the v215 ->
v230 systemd improvements..
Regards,
This has now been pushed to Jessie, i’m pretty happy with the v215 →
v230 systemd improvements…
So, I’ve been noticing that apt-get upgrade has been braking existing images( rendering APT virtually unusable). So when I say “virtually unusable”, I mean that APT is put into a state where it half installs package dependencies , and can not figure out how to fix it’s self. Passed that, there is no clear way to fix the problem. So when I say this keep in mind i have years of debian experience, and was not able to figure out in a timely fashion ( a few hours ) how to fix this.
Has this been resolved ?
In the last month, we had two big transitions..
bb-doc-bone101-jekyll -> bone101
bb-bonescript-installer-beta -> bonescript
i know these where not pretty from the apt point of view:
But, this should have pulled things thru:
sudo apt-get update ; sudo apt-get dist-upgrade
bone101/bonescript got moved around and split up properly
(/var/lib/cloud9 /usr/share/bone101), and jekyll is no longer silently
running behind the scenes taking io/cpu cycles..
Then we've learned that "npm install xyz" is BAD, so no 'New" packages
do that, but there is still one old one i need to update to the new
method.. (haven't updated it since to keep that issue from poping up)
Regards,
Ug, so we’d for all intents and purposes be installing sid of wheezy packages on our Jessie images ? Not a clean result in that case, which is not a complaint. But instead and observation to just not use apt-get upgrade.
Everything is built in a Jessie sbuild, nothing is getting cross installed..
The issue, is with how apt's update works::
"apt-get update" updates packages when a new version is available.
BUT, if that version update grows a new dependency, then 'update'
locks that package version, till you run "apt-get dist-upgrade"...
There is a new example coming shortly..
ti wl18xx firmware package, used by the bbgw:
https://github.com/rcn-ee/repos/tree/master/bb-wl18xx-firmware/suite/jessie/debian
it's calling a ti tool "calibrator"
https://github.com/rcn-ee/repos/blob/master/bb-wl18xx-firmware/suite/jessie/debian/bb-wl18xx-wlan0#L51
I need to package this tool, as currently i'm building in the image builder:
https://github.com/RobertCNelson/omap-image-builder/blob/master/target/chroot/beagleboard.org-jessie.sh#L342-L352
when i finally package this "ti-calibrator", i'll add a dependicy to
bb-wl18xx-firmware's control file..
Then you'll have to:
sudo apt-get update ; sudo apt-get dist-upgrade
Just, to update: bb-wl18xx-firmware
Regards,
BUT, if that version update grows a new dependency, then ‘update’
locks that package version, till you run “apt-get dist-upgrade”…
ah, ok, I’ll give that a shot.
It has in the past always been my understanding that dis-upgrade was for upgrading to a new, or “different” Debian. e.g. Wheezy, or Jessie to “testing”, or “unstable”, or in the most recent Wheezy to Jessie.
I recently went through the the same thing on RiPi2, needed apt-get update ; apt-get dist-upgrade
I’m not sure the original apt designers envisioned all the firmware blobs required by these ARM processors which seem to require a lot of synchronized changes.
I’m looking forward to testing the new bone101 stuff , hopefully I can get to it this week end.
Had a weird problem with the RiPi2 after the upgrade – it wouldn’t boot headless (no mouse/keyboard/monitor) unless a USB hub was plugged it and it was picky about which of my three cheap hubs worked 
Talk about a troubleshooting nightmare and lots of cussing and wasted time, but its working great now. Needing the hub is not a total waste as it makes a good power supply for my Adafruit Fona cellular module that gives a backup path for text alerts from my BBW IOT application that is continuously evolving.