debootstrap and cdebootstrap vs systemd

classic Classic list List threaded Threaded
8 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

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

Lennart Sorensen
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

Kenshi Muto
In reply to this post by Simon Richter-2
Hi Simon,

At 6 Nov 14 22:14:10 GMT,
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.

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

#668001 with a patch.
Unfortunately it is judged too late to go in Jessie.

Thanks,
--
Kenshi Muto
[hidden email]


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