Re: Concatenateable images (armhf) currently not working?

[Christian Pernegger]

2016-03-10 21:34 GMT+01:00 Karsten Merker :
> do you by chance have the LIME2 connected to a gigabit ethernet
> switch?  If yes, could you try using a 100MBit-Switch instead?

I've managed the install by now with the jessie image and lots and
lots of retries. I'd been wondering about it being slow, but had no
idea what or why ... The installed system makes it quite clear that
Gigabit Ethernet is unusable on that board. 40 KiB/s in aptitude and
the serial console is faster than an ssh connection, it's a wonder the
installer worked at all.

(It's not like I didn't research these boards for days before
ordering. Criteria: runs proper Debian and has proper Ethernet, unlike
the RPi it was meant to replace. Oh the irony.)

Is it possible to have the installer do ethtool -s eth0 speed 100
duplex full or similar on A20? Would make it a lot less painful.

> As you wrote that you have no problems in armbian: which kernel
> do you use in armbian - mainline ("vanilla" in armbian terms) or
> sunxi-3.4 ("legacy" in armbian terms)?

The legacy one. But I did neglect to test the network, it may well be
just as bad.

> Is it possible that you have downloaded the hd-media images instead
> of the netboot images for alpha5 and the daily builds?

There's multiple "SD-card-images" directories? And of course I got the
wrong one. Sorry. Today's really not my day.

Any idea if the Gbit is fixable in software?

Regards,
Christian

Concatenateable images (armhf) currently not working?

[Christian Pernegger]

Hi,

I'm trying to install stretch on an Olimex A20-OLinuXIno-LIME2
(Allwinner A20, armhf) using the concatenateable images:
* The jessie images from linked from
https://wiki.debian.org/InstallingDebianOn/Allwinner
(http://ftp.uk.debian.org/debian/dists/jessie/main/installer-armhf/current/images/netboot/SD-card-images/)
work, only (Release file, package) downloads will often fail and have
to be retried. In the end I couldn't finish the installation because
debootstrap / a debootstrap script couldn't be found. Might be my
hardware, though Armbian seems to run stably enough.
* The stretch a5 and daily (as of a half hour ago) images fail much
earlier and much more consistently. The installer fails to find an
installer ISO image right after locale selection and that's that.

This is just a heads-up as I won't have much time to debug this in the
next couple of days. If you have any questions, please CC me.

Regards,
Christian

Bug#433568: add vlan support

[Dimitri John Ledkov]

Hello,

On Wed, 27 Mar 2013 22:10:51 +0800 YunQiang Su  wrote:
> Thanks for Zhengpeng Hou, who points out that I leave a piece of code which is
> not used anymore in this patch. This piece of code make a more malloc while 
> not
> free.
>
> And I refresh this patch with the current git.
> This is the new patch.
>
> Any one has progress on rewriting it?


OMG, I just had to go through vlan pain, and *anything* would be
better than current situation, rewrite or not.

One thing I see missing is that apart from writing out correct
/etc/network/interface one also needs to install "vlan" package in the
target installation. Is this done somewhere?

Apart from that nit-pick, this is amazing, and I'm feeling like just
finally merging this.

Regards,

Dimitri.

Re: own cloud task in tasksel?

[James Bromberger]

On 10/03/2016 6:22 PM, Charles Plessy wrote:
> Le Thu, Mar 10, 2016 at 10:18:30AM +0100, Bastian Blank a écrit :
>> On Wed, Mar 09, 2016 at 11:51:58PM +0900, Charles Plessy wrote:
>>
>>> Maybe this problem can be solved by the use of metapackages ?  With the
>>> exclusion of cloud-init, specialised kernels etc., can we converge on a
>>> metapackage that would represent the most frequent expectations of users of
>>> non-minimal cloud images in Debian and elsewhere ?
>> Thats what a task is, a meta-package.
> Since debian-boot@l.d.o was CCed, I thought that "task" was employed to mean 
> "a
> metapackage built from the tasksel source package", not just any metapackage 
> in
> general.
>
> So let me rephrase:
>
> Is the proposal to go through tasksel ?  If yes, what are the expected
> advantages over the use of an ad-hoc metapackage ?
>
> Cheers,
>


All of what people generally want installed in their EC2 instances can
be achieved with a suitable boot time UserData section that Cloud-init
installs. So long as the base image has enough base packages to fetch &
install additional packages at boot; which means it has enough base
packages to be configured to make a request to a Debian repo by some
means (socks, or explicitly defined proxy, or private repository, or
direct) with simple configuration, then that's easy. So, for example, in
an EC2 metadata environment, setting the UserData to:

  #!/bin/sh
  apt-get update && apt-get install -y less unattended-updates



...will do what many users will want quite quickly.

I don't think that requires us to create additional base images that
cater for various combinations. Sometimes those base images want to
download packages from Storage (s3 or other external to the instance)
that the client wants to get using a script. So long as that instance
has the necessary tools (curl, wget, awscli in the case of EC2, plus the
lower layer SSL libraries that curl and wget use for https) then that's
provided ample means to deliver secured, authenticated payloads to the
instance. If the user wants a base image for their own purpose then they
can either take a base image, customise and "create image" of their
running server, or use the bootstrap-vz script to generate their own
images with their selected base packages.

One item of note that we have included in the AWS EC2 base images is the
apt-transport-https package, purely that, in environments where the
(customer organisational) security policy forbids the use of outgoing
HTTP from an instance, but permits (limited?) HTTPS, then permitting a
simple re-configuration of the base image sources.list file makes this
possible without being a chicken-and-egg problem.

Should users pre-bake their images? For large
organisations/corporates/governments/etc who may do hundreds of launches
per day, possibly in an auto-scale group - yes, so that the image, and
all launch time dependencies are pre-installed and not subject to
external services outside of the cloud provider that may not be
available during a launch. I've seen people bootstrap live pulls from
external revision control provider platforms- and then seen those
platforms be down when they've tried to launch. If you want to rely on
the stability and availability of an image, you should master your own
image and maintain that as an artifact for your environment.

If you're contemplating an ad-hoc meta-package instead - then perhaps
that is something that's more widely cloud and non cloud applicable -
such as what tasksel already has as tasks? But if a possible "cloud"
task was to contain utilities for various cloud vendors - then who
decides which vendors and utilities are included, and which ones are not
- and when does a small cloud provider get a task for their cloud
environment and APIs? Or do we make a "cloud-aws"and "cloud-azure"
tasks. If we do that, then why not include those utilities in the base
image(s) of those providers to start with. That starts to become
bloatware if I have a package where 90% of the content is for cloud
environments that I don't use, and I'm paying for the storage for these
utilities, times many instances. Even a task of "cloud-aws" may include
libraries and APIs for stuff I'll never use: the
Go/Python/R/perl/java/node/php SDKs when all I want is less?  So
updating the above simple UserData script to use tasksel is also trivial:

  #!/bin/sh
  apt-get update && tasksel install 


My preference is to keep the number of images per release to a minimum
with small deviations that ensure that the "base"image is universally
useful in each providers environment. We were, for a while, generating 4
images in EC2 per release (multiplied by 12 regions). Now we generate
one x86 64 bit image, and replicate it (PVM virtualisation and i386 is
sun-setting on AWS: amd64 HVM is everywhere). If you twist my arm then
perhaps an additional base image(s) for a new CPU architecture(s) may
one day be needed.


  James

-- 
/Mobile:/ +61 422 166 708, /Email:/ 

Re: own cloud task in tasksel?

[Charles Plessy]

Le Thu, Mar 10, 2016 at 10:18:30AM +0100, Bastian Blank a écrit :
> On Wed, Mar 09, 2016 at 11:51:58PM +0900, Charles Plessy wrote:
> 
> > Maybe this problem can be solved by the use of metapackages ?  With the
> > exclusion of cloud-init, specialised kernels etc., can we converge on a
> > metapackage that would represent the most frequent expectations of users of
> > non-minimal cloud images in Debian and elsewhere ?
> 
> Thats what a task is, a meta-package.

Since debian-boot@l.d.o was CCed, I thought that "task" was employed to mean "a
metapackage built from the tasksel source package", not just any metapackage in
general.

So let me rephrase:

Is the proposal to go through tasksel ?  If yes, what are the expected
advantages over the use of an ad-hoc metapackage ?

Cheers,

-- 
Charles

Re: own cloud task in tasksel?

[Bastian Blank]

On Wed, Mar 09, 2016 at 11:51:58PM +0900, Charles Plessy wrote:
> This reminds me #696154 ("Please install 'less' by default on official Debian
> AMIs.").  Basically, there is a tension between:

Also 'less' is already important, so it is supposed to be installed
somehow.

> Maybe this problem can be solved by the use of metapackages ?  With the
> exclusion of cloud-init, specialised kernels etc., can we converge on a
> metapackage that would represent the most frequent expectations of users of
> non-minimal cloud images in Debian and elsewhere ?

Thats what a task is, a meta-package.

Regards,
Bastian

-- 
I'm a soldier, not a diplomat.  I can only tell the truth.
-- Kirk, "Errand of Mercy", stardate 3198.9

Re: own cloud task in tasksel?

[Marco d'Itri]

On Mar 10, Martin Zobel-Helas  wrote:

> What are the minimal set of of packages then that should be installed in
> every cloud image?
Whatever is needed to boot it and let someone or something ssh on it.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: own cloud task in tasksel?

[Martin Zobel-Helas]

Hi, 

On Wed Mar 09, 2016 at 23:51:58 +0900, Charles Plessy wrote:
> Maybe this problem can be solved by the use of metapackages ?  With the
> exclusion of cloud-init, specialised kernels etc., can we converge on a
> metapackage that would represent the most frequent expectations of users of
> non-minimal cloud images in Debian and elsewhere ?
> 
> Back to the original question, I am not sure if tasks are a good solution to
> that problem, since most cloud images are not built with debian-installer.
> What would be the advantage over simple metapackages ?

Okay, let my phrase my question differently then: 

What are the minimal set of of packages then that should be installed in
every cloud image?

debootstrap --variant=minbase?
debootstrap --variant=scratchbox?

We should define this, and work on a policy then so we can publish that
policy enough in time for cloud providers to react for the stretch
release.

Cheers,
Martin
-- 
 Martin Zobel-Helas Debian System Administrator
 Debian & GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B