debootstrap and cdebootstrap vs systemd

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

debootstrap and cdebootstrap vs systemd

Simon Richter-2
Hi,

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 short: this does not work. The end result is a systemd based system.
If I use the --foreign flag, sysvinit is added to the download, and an
attempt at installation is made when the system is booted, but this
fails due to an unresolved conflict.

The system image left is unable to boot, due to a segmentation fault in
systemd (which is is probably not that important, as older kernels are
unsupported anyway), and is stuck with a kernel panic.

I haven't found a combination of flags that would create a root
filesystem without systemd, as the dependency resolver in these tools
will always pull it back in.

Being able to create a root file system using debootstrap is IMO a
rather central feature of the Debian distribution, and I'd prefer not to
give it up.

I don't have a lot of time in the coming months, but I could probably
clear a weekend. Would it make sense to organize a meeting (Linuxhotel?)
to fix this?

   Simon


signature.asc (308 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: debootstrap and cdebootstrap vs systemd

csirac2
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 involves qemu-binfmts on the build host (actually docker)
which may or may not be desirable

On 07/11/14 09:14, Simon Richter wrote:

> Hi,
>
> 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 short: this does not work. The end result is a systemd based system.
> If I use the --foreign flag, sysvinit is added to the download, and an
> attempt at installation is made when the system is booted, but this
> fails due to an unresolved conflict.
>
> The system image left is unable to boot, due to a segmentation fault in
> systemd (which is is probably not that important, as older kernels are
> unsupported anyway), and is stuck with a kernel panic.
>
> I haven't found a combination of flags that would create a root
> filesystem without systemd, as the dependency resolver in these tools
> will always pull it back in.
>
> Being able to create a root file system using debootstrap is IMO a
> rather central feature of the Debian distribution, and I'd prefer not to
> give it up.
>
> I don't have a lot of time in the coming months, but I could probably
> clear a weekend. Would it make sense to organize a meeting (Linuxhotel?)
> to fix this?
>
>    Simon
>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/545BFC67.8070609@...

Reply | Threaded
Open this post in threaded view
|

Re: debootstrap and cdebootstrap vs systemd

Cyril Brulebois-4
In reply to this post by Simon Richter-2
Simon Richter <[hidden email]> (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 short: this does not work. The end result is a systemd based system.
> If I use the --foreign flag, sysvinit is added to the download, and an
> attempt at installation is made when the system is booted, but this
> fails due to an unresolved conflict.
>
> The system image left is unable to boot, due to a segmentation fault in
> systemd (which is is probably not that important, as older kernels are
> unsupported anyway), and is stuck with a kernel panic.
>
> I haven't found a combination of flags that would create a root
> filesystem without systemd, as the dependency resolver in these tools
> will always pull it back in.
>
> Being able to create a root file system using debootstrap is IMO a
> rather central feature of the Debian distribution, and I'd prefer not to
> give it up.
>
> I don't have a lot of time in the coming months, but I could probably
> clear a weekend. Would it make sense to organize a meeting (Linuxhotel?)
> to fix this?
You might want to stop accepting 2.6 as a base kernel version.

Anyway, just use debootstrap and switch to sysvinit afterwards, done.

Mraw,
KiBi.

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: debootstrap and cdebootstrap vs systemd

Adam Borowski-3
In reply to this post by Simon Richter-2
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 --exclude to (c)debootstrap.
> In short: this does not work.

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.

--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/20141106233306.GA7793@...

Reply | Threaded
Open this post in threaded view
|

Re: debootstrap and cdebootstrap vs systemd

Don Armstrong
In reply to this post by Simon Richter-2
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)debootstrap.

This sounds like #668001. Try applying the patch there, and see if that
works.

--
Don Armstrong                      http://www.donarmstrong.com

Let the victors, when they come,
When the forts of folly fall
Find thy body by the wall!
 -- Matthew Arnold


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/20141107000217.GN24038@...

Reply | Threaded
Open this post in threaded view
|

Re: debootstrap and cdebootstrap vs systemd

Thorsten Glaser-6
In reply to this post by Adam Borowski-3
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.
debootstrap --include and --exclude should work. (I very
vaguely recall getting angry at them at some point in
the past too, and just resorting to $EXTRAPACKAGES in
pbuilderrc instead, requiring cowbuilder --update right
after cowbuilder --create, once or even twice, to get
things to the right state. So they might not work ☹)

bye,
//mirabilos
--
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/alpine.DEB.2.11.1411070958590.22398@...

Reply | Threaded
Open this post in threaded view
|

Re: debootstrap and cdebootstrap vs systemd

csirac2
In reply to this post by Cyril Brulebois-4
-----Original Message-----
From: Cyril Brulebois <[hidden email]>
To: Simon Richter <[hidden email]>
Cc: [hidden email], [hidden email], [hidden email], [hidden email]
Sent: Fri, 07 Nov <a href="tel:201410">2014 10:45
Subject: Re: debootstrap and cdebootstrap vs systemd

> You might want to stop accepting 2.6 as a base kernel version.

Apologies in advance. You really hit a nerve here.

Kernel 3.7 was released December <a href="tel:2012">2012. Debian project created a dependency on this for the default init system roughly 15 months later. Which is fine, and perfectly understandable. It makes sense. I don't want to argue that.

But please don't make light of the situation for those who can't apt-get install hardware-redesign beg-silicon-vendor-for-updates port-and-re-validate-custom-undocumented-modules go-back-in-time-and-teach-hardware-engineers-linux-kernel-lifecycle

3.7 is less than 2 years ago even today, apparently even that is a blip in many embedded hardware solutions' life-cycle. Some manufacturing sectors are still selling m68k and Z80 CPUs. For SoCs though, it seems the tradition is: fork a particular Linux kernel release, mangle it beyond recognition, throw it over the wall and then act like customers are speaking an alien language if they ever ask for updates.

"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's hard to explain to business people and even hardware engineers that a chip/board/subsystem is "unsupported" even though supply guarantees stretch out to the year <a href="tel:2020">2020 and beyond.

And for all I know, perhaps these businesses deserve everything that happens to them, who knows.
Reply | Threaded
Open this post in threaded view
|

Re: debootstrap and cdebootstrap vs systemd

csirac2
In reply to this post by Thorsten Glaser-6
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, just enough to support a few kernel syscalls to
your host computer's native Linux kernel. I don't think qemu is doing
any peripheral/memory-layout/IO etc emulation when used like this -
those things (Eg. networking, file-system access) are provided by thin
wrappers to the host system's kernel, kind of like WINE.

On 07/11/14 20:00, 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 target system.
> This is no fix. There are systems Qemu does not emulate.
> debootstrap --include and --exclude should work. (I very
> vaguely recall getting angry at them at some point in
> the past too, and just resorting to $EXTRAPACKAGES in
> pbuilderrc instead, requiring cowbuilder --update right
> after cowbuilder --create, once or even twice, to get
> things to the right state. So they might not work ☹)
>
> bye,
> //mirabilos


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/545C96A2.409@...

Reply | Threaded
Open this post in threaded view
|

Re: debootstrap and cdebootstrap vs systemd

Marco d'Itri
In reply to this post by csirac2
On Nov 07, [hidden email] 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's hard to explain
> to business people and even hardware engineers that
> a chip/board/subsystem is "unsupported" even though supply guarantees
> stretch out to the year 2020 and beyond.
Yes, your ecosystem is broken. That's your prerogative, but please do
not pretend that Debian has to support it.

--
ciao,
Marco

signature.asc (662 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: debootstrap and cdebootstrap vs systemd

riku voipio-7
In reply to this post by Thorsten Glaser-6
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 target system.
>
> This is no fix. There are systems Qemu does not emulate.

But afaik all debian archs are? From the ports side qemu doesn't do
hppa, and m68k and sparc64 are probably buggy. Nothing unfixable, just
that nobody has cared enought to get them fixed :)

And for not-even-in-ports architectures debootstrap is not really
relevant.

> 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.

Riku


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/20141107104029.GA13109@...

Reply | Threaded
Open this post in threaded view
|

Re: debootstrap and cdebootstrap vs systemd

csirac2
In reply to this post by Marco d'Itri
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 chioce.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/545CA22C.7060702@...

Reply | Threaded
Open this post in threaded view
|

Re: debootstrap and cdebootstrap vs systemd

riku voipio-7
In reply to this post by csirac2
On Fri, Nov 07, 2014 at 08:30:32PM +1100, [hidden email] 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's hard to explain
> to business people and even hardware engineers that a
> chip/board/subsystem is "unsupported" even though supply guarantees
> stretch out to the year 2020 and beyond.

If you choose an old Soc vendor kernel, you effectively choose to use old
userland from the same era. Better do your business plan based on it:

 "we won't upgrade userspace except for backported critical fixes and
 features we REALLY need"

And it probably not that bad deal anyways. Instead wondering how to
adapt your existing working code to new userland (say initscripts to
systemd), your engineers can spend time working on something that
actually matters to your customers.

Riku



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/20141107111829.GB13109@...

Reply | Threaded
Open this post in threaded view
|

Re: debootstrap and cdebootstrap vs systemd

csirac2
-----Original Message-----
From: Riku Voipio <[hidden email]>
To: [hidden email]
Cc: [hidden email], [hidden email]
Sent: Fri, 07 Nov <a href="tel:201422">2014 22:36
Subject: Re: debootstrap and cdebootstrap vs systemd

> If you choose an old Soc vendor kernel, you effectively choose to use old
>userland from the same era. Better do your business plan based on it:

> "we won't upgrade userspace except for backported critical fixes and
> features we REALLY need"

Thanks Riku, however what's best for my userland should be up to me to figure out. Thanks to the amazing emdebian toolchain, it's trivial to build my system for any supported debian release. The Debian ecosystem also makes it trivial to rebuild packages from source, for example to make headless or "nox" versions where necessary.

Coupled with a completely automated, continuous build setup (from source for non-standard bits, including boot loader & kernel) I really enjoy developing for Debian!

But the software I maintain, not to mention its supporting pieces, run in places other than embedded. Maintaining two release branches in light of the ease of building and maintaining sid userland isn't an obvious choice.

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. Even gumstix, popular in the open source scene, their newest boards don't have kernels >3.5.
Reply | Threaded
Open this post in threaded view
|

Re: debootstrap and cdebootstrap vs systemd

Jean-Christian de Rivaz
Le 07. 11. 14 13:32, [hidden email] 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. Even gumstix, popular in the
> open source scene, their newest boards don't have kernels >3.5.

Mainline kernel usually support all those chips just fine if the chip
manufacturer upload his kernel patches to the mainline as it should do.
If you take the risk to work with a chip manufacturer that don't upload
his patches to the mainline kernel, then you have to assume this risk,
not the distribution. I have experienced this situation many time. This
was the standard 15 years ago, but now more and more chips manufacturers
understand the importance of uploading there patches to the mainline
kernel, so you have more choice in not falling into that bad situation.

Jean-Christian


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/545CCC80.8000006@...

Reply | Threaded
Open this post in threaded view
|

Re: debootstrap and cdebootstrap vs systemd

Lennart Sorensen
In reply to this post by csirac2
On Fri, Nov 07, 2014 at 08:30:32PM +1100, [hidden email] 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 understandable. It makes sense. I don't want to argue that.

Well I know wheezy runs fine on a 3.0 kernel.  Not sure how much further
back you can go.  Of course that was as far as I can tell released Around
August of 2011, so only another year and a bit longer.

> But please don't make light of the situation for those who can't apt-get install hardware-redesign beg-silicon-vendor-for-updates port-and-re-validate-custom-undocumented-modules go-back-in-time-and-teach-hardware-engineers-linux-kernel-lifecycle

If udev decides to stop supporting kernels without some useful recent
feature, do you expect Debian to keep patching to code to support older
kernels that even Debian has no intention of using in new releases?
What would be the point of that?

> 3.7 is less than 2 years ago even today, apparently even that is a blip in many embedded hardware solutions' life-cycle. Some manufacturing sectors are still selling m68k and Z80 CPUs. For SoCs though, it seems the tradition is: fork a particular Linux kernel release, mangle it beyond recognition, throw it over the wall and then act like customers are speaking an alien language if they ever ask for updates.
>
> "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's hard to explain to business people and even hardware engineers that a chip/board/subsystem is "unsupported" even though supply guarantees stretch out to the year 2020 and beyond.

Well if you don't try to explain it, you will be stuck with the problems
forever.

Where I work we make it clear to the suplier that support for the chip has
to be mainlined to Linus's tree, or we don't want to deal with the chip.
We know what it is like to deal with a vendor kernel that isn't maintained
and we don't want to do that.  We want nothing to do with SDKs or
BSPs either.  They are not useful for long term maintainance of a product.
They are harmful.

> And for all I know, perhaps these businesses deserve everything that happens to them, who knows.

Sounds fair to me.  They are doing things wrong and hurting their
customers.

--
Len Sorensen


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/20141107145016.GR24110@...

Reply | Threaded
Open this post in threaded view
|

Re: debootstrap and cdebootstrap vs systemd

Adam Borowski-3
In reply to this post by riku voipio-7
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 have no systemd.  No init
at all would be better, but excluding an essential package (init) makes
dist-upgrades not fun.

* minbase
Not suitable for booting without further work.
* buildd
Init is not needed, bloat is highly harmful (unpacking the chroot without
CoW takes 5x the time to build a small package!), so a slim init like
sysvinit is much preferred.
* fakechroot|scratchbox
Not meant/capable of booting on their own (chroot only).


--
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: https://lists.debian.org/20141107212503.GA14737@...