I prefer to use 'console' images on my BBBs as they use less space and
I have no need for any of the extras provided by IOT or full GUI
images.
However the console images only seem to be listed in the weekly
snapshots section of the wiki, there aren't any 'recommended' console
images. Shouldn't there be a default/recommended console version as
otherwise I'm using 'bleeding edge'/beta sort of versions.
I only spotted this because I was wondering why the IOT version I
downloaded to put on someone else's BBB was Debian 9.3 but my console
one was running Debian 9.4! 
No, that's where I got the 'weekly snapshot' version of the console
image that I'm using. As it's under the heading "Debian Image Testing
Snapshots" it doesn't feel like one should be using the images there
for 'production' installs.
I was hoping there would be a 'recommeded' console image somewhere.
I've not got any actual problems, the install runs perfectly OK, but
for newcomers who want a console only installation it's quite
difficult to find one.
Chris:
What I have always done is to go here:
http://rcn-ee.net/rootfs/bb.org/testing/
or here:
https://debian.beagleboard.org/images/rcn-ee.net/rootfs/bb.org/testing/
and get the console version corresponding to the full release version.
So, there are console versions of the same software versions available.
— Graham
Not really, those are the weekly 'testing' snapshots. If you look
they are are Debian 9.4. The 'recommended' release versions on the
beagleboard.org site are all still Debian 9.3 (but there's not a
console version there).
If what you want is the console version corresponding to
Debian 9.3 2018-01-28 4GB SD LXQT image
And you go to
https://debian.beagleboard.org/images/rcn-ee.net/rootfs/bb.org/testing/2018-01-28/stretch-console/
it sure looks like Debian 9.3 to me.
The one you want is:
bone-debian-9.3-console-armhf-2018-01-28-1gb.img.xz
Now this one is for running from the uSD card.
If you want to turn it into a “flasher” you need to follow the instructions about editing the correct uEnv.txt file
— Graham
Yes, OK, that's a 9.3 console image but it's still only a weekly
'snapshot'.
I'm not personally desperately after an old[er] console image, I'm
just saying that there isn't a 'recommended' default console image
like there is for the IOT and full GUI images.
I think we’ve wrestled with this issue as well. We’re still working with Jessie console images from
https://rcn-ee.com/rootfs/bb.org/testing/2018-02-01/console/, and they seem to be pretty stable, from the testing we’ve done to date.
I’m not yet sure and am still very curious about the test results/testing status of the images which are placed in the testing folder. I THINK what you need to do is look at the github revision/commit history for each component (e.g. uboot, debian, and kernel version) in a given image) to see why an image was updated (e.g. 2018-01-01 to 2018-02-10, but if there’s a place which posts what the test results are (and a place for users to post their own experiences) for a given image, other than github, please let us know!!
Question(s):
For a given LXQT image, how much effort is involved in converting that “GUI” image to a console image? Can’t you just remove all of the “extra packages” from the LXQT image until you have the desired console image per the following procedure, or is it more involved than that? Aren’t the pinmuxes the same?
- Spit out the debian package list for an existing console image (even the weekly image).
- Spit out the debian package list for the released LXQT image (from the same desired major Debian revision as #1 (e.g. jessie, stretch)
- Compare the package lists from 1,2.
- Use apt remove on the released LXQT image to remove the “excess” packages in the LXQT image until it’s package list matches the package list of the console image?
Thanks!!
Jeff
Well, they are weekly testing releases.
And, some of those weekly testing releases are chosen to become formal releases.
And if they had to chang anything in them, there would be a new/different date/version on them.
So if you actually want the Console version corresponding to the formal ‘release’ version, there it is.
If you want Gerald to change something about how releases are posted, you will have to take that up with Gerald directly.
I think he is deliberately restricting what he posts on the release page, so he limits the damage a newbie can do to their BBB to just the plug-in card, which is easily re-programmable.
As far as:
“4) Use apt remove on the released LXQT image to remove the “excess” packages in the LXQT image until it’s package list matches the package list of the console image?”
Yes, you can do it that way, but it sure sounds like the “hard way” to me.
— Graham
[-- multipart/alternative, encoding 7bit, 270 lines --]
[-- text/plain, encoding quoted-printable, charset: UTF-8, 138 lines --]
Well, they are weekly testing releases.
And, some of those weekly testing releases are chosen to become formal
releases.
Yes.
And if they had to chang anything in them, there would be a new/different
date/version on them.
So if you actually want the Console version corresponding to the formal
'release' version, there it is.
Er, where? If the release version was marked/tagged somehow that
would be helpful but (as far as I can see) it isn't.
[snip]
As far as:
>>> "4) Use apt remove on the released LXQT image to remove the "excess"
packages in the LXQT image until it's package list matches the package list
of the console image?"
Yes, you can do it that way, but it sure sounds like the "hard way" to me.
Very hard work IMHO, it's non-trivial to work out which packages to
remove and I'm pretty sure that there's a *lot* to remove too.