On Fri, Nov 07, 2014 at 12:40:29PM +0200, Riku Voipio wrote:
> > debootstrap --include and --exclude should work.
>
> Yes of course. If not there could be a --variant=sysvinit, but clearly
> it should be possible to debootstrap without systemd.
I'd say every --variant except the default should
On Fri, Nov 07, 2014 at 08:30:32PM +1100, csir...@yahoo.com.au wrote:
> Apologies in advance. You really hit a nerve here.
>
> Kernel 3.7 was released December 2012. Debian project created a dependency on
> this for the default init system roughly 15 months later. Which is fine, and
> perfectly
Le 07. 11. 14 13:32, csir...@yahoo.com.au a écrit :
Finally can I just re-iterate: these are not "old" or obscure SoCs; TI
and freescale each have massive sales in CPU lines that don't have
>3.0 kernels. The world's biggest Qseven COM vendor doesn't have an
ARM board that supports >3.0 kernels.
-Original Message-
From: Riku Voipio
To: csir...@yahoo.com.au
Cc: debian-devel@lists.debian.org, debian-embed...@lists.debian.org
Sent: Fri, 07 Nov 2014 22:36
Subject: Re: debootstrap and cdebootstrap vs systemd
> If you choose an old Soc vendor kernel, you effectively choose to use
On Fri, Nov 07, 2014 at 08:30:32PM +1100, csir...@yahoo.com.au wrote:
> "Don't accept old kernels" is almost equivalent to telling many
> unrelated businesses in a particular ecosystem to burn their
> investments and start again from scratch, just because the SoC and/or
> board vendors have a broke
On Fri, Nov 07, 2014 at 10:00:38AM +0100, Thorsten Glaser wrote:
> On Fri, 7 Nov 2014, Adam Borowski wrote:
>
> > You can chroot to the system from the host machine, and upgrade to sysvinit.
> > If your host can't run arm code, install qemu-user-static and copy
> > /usr/bin/qemu-arm-static to the
On 07/11/14 21:12, Marco d'Itri wrote:
> Yes, your ecosystem is broken. That's your prerogative, but please do
> not pretend that Debian has to support it.
>
Where did you hear me say Debian has to support it? I'm reacting to the
whimsical suggestion that running a new kernel is just a matter of
On Nov 07, csir...@yahoo.com.au wrote:
> "Don't accept old kernels" is almost equivalent to telling many
> unrelated businesses in a particular ecosystem to burn their
> investments and start again from scratch, just because the SoC and/or
> board vendors have a broken business model. And that'
For what it's worth, some of the boards I work with aren't emulated by
QEMU either.
However, for me that did not turn out to be a problem for chrooting into
my alien rootfs just to run apt/dpkg & friends.
Qemu only has to emulate a very minimal/"thin" CPU environment when
chrooting with binfmts,
-Original Message-
From: Cyril Brulebois
To: Simon Richter
Cc: debian-devel@lists.debian.org, debian-embed...@lists.debian.org,
debootst...@packages.debian.org, cdebootst...@packages.debian.org
Sent: Fri, 07 Nov 2014 10:45
Subject: Re: debootstrap and cdebootstrap vs systemd
>
On Fri, 7 Nov 2014, Adam Borowski wrote:
> You can chroot to the system from the host machine, and upgrade to sysvinit.
> If your host can't run arm code, install qemu-user-static and copy
> /usr/bin/qemu-arm-static to the target system.
This is no fix. There are systems Qemu does not emulate.
de
On Thu, 06 Nov 2014, Simon Richter wrote:
> I've run into a bit of a problem building a root filesystem for an ARM
> system where the kernel shipped by the vendor is 2.6 based. As systemd
> does not work there, I tried installing a sysvinit based system using
> --include and --exclude to (c)deboots
On Thu, Nov 06, 2014 at 11:14:10PM +0100, Simon Richter wrote:
> I've run into a bit of a problem building a root filesystem for an ARM
> system where the kernel shipped by the vendor is 2.6 based. As systemd
> does not work there, I tried installing a sysvinit based system using
> --include and --
Simon Richter (2014-11-06):
> I've run into a bit of a problem building a root filesystem for an ARM
> system where the kernel shipped by the vendor is 2.6 based. As systemd
> does not work there, I tried installing a sysvinit based system using
> --include and --exclude to (c)debootstrap.
>
> In
For the same reasons, for what it's worth I have a multistrap .conf
which achieves sysvinit booting rootfs (but perhaps I'm doing some
post-configure apt-get install commands in the build script, I'll have
to check).
If you're interested in the multistrap config let me know. My workflow
with this
15 matches
Mail list logo
