Re: BeagleBone Black apt oddness
On Sun, Nov 10, 2013 at 8:41 PM, Paul Wise <pabs@debian.org> wrote:
> On Mon, Nov 11, 2013 at 8:12 AM, Robert Nelson wrote:
>
>> I agree, there are a lot of "security" issues with the Demonstration
>> image, it's purpose is primary for initial board development and
>> testing and should never be used in the field as is..
>
> This thread shows that people are using the images so I think you
> should withdraw the images, fix the issues and or issue a statement
> about this on the download site.
The images are being fixed, via the generation script.. So the next
release this week will have the fixes, and the old ones will be
removed.. (i've been pushing out new images on average about once a
month since we started the beagleboard.org project..)
>
>> The initial image is created by "debootstrap --foreign".. then (qemu
>> static on x86 or a chroot on arm) is used to add other packages, to
>> finish the install and
>> generate the initrd..
>
> You can add extra packages with --include=
Yeap, the --include is also currently utilized, just not 100%.. I was
involved with the original project-rootstock, so my generation script
has renamed closely compatible with that old script.. Just need to
finish porting everything..
>
> If you do that and can arrange for the debootstrap second stage to be
> run on the device after first bootup instead of in qemu, that would
> mitigate any security issues that might be present due
> maintainer-scripts stuff.
That would be an awesome goal, it would allow the end user to do so
much of the customization themselves, from setting up users, locales,
etc... I can imagine d-i could be used to achieve that.. I just don't
know enough of debian internals to make that work, as I mostly do
kernel/uboot work..
One of the main reasons, for running the second stage in a chroot/qemu
is what seams like a simple Chicken/Egg problem we have.. How do we
generate the "arm" initrd on an "x86" linux host for debian wheezy?
So here are the things currently done in the chroot/qemu "second
stage" with my images...
package updates ( wheezy-updates & security.debian.org repo's )
additional packages (this needs be converted to --include)
locales generation (not a requirement, but it fixed email/bugs from users..)
kernel install (initrd generation)
user setup (with sudo access)
startup script is setup ( insserv )
"source save" ( apt-get source --download-only <every package shipped> )
>> With v3.12.x final, only dtb changes are required for bbb..
>> https://github.com/RobertCNelson/linux-dev/tree/am33x-v3.12/patches/omap-next-dt
>> (all heading to v3.13-rc0)
>> (minus the cape stuff as that still needs the overlay infrastructure
>> panto just posted as a review for on lkml this last week..)
>
> Sounds like good progress!
>
>> vs the quick 5 minute flashing script from the demonstration images..
>
> That is the advantage of per-machine images but with so many devices
> out there it quickly gets non-scalable from a Debian perspective. With
> armmp we can possibly change that and make a few classes of useful
> images though.
That's actually my only one device image, done at the request by the
manufacture to appease Windows/Mac users. I'd rather they download a
live-cd, but....
As more thing hit mainline your armmp kernel is going to become more
used within debian. Actually with a pure mainline v3.12.x, there are
a few imx6 based devices you guys should now be able to support out of
the box.. Just need u-boot binaries, and someone to test/etc... I'm
just never sure who to ping at debian, as i see a lot of boards before
they end up in consumer hands..
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
Reply to: