Re: debootstrap and cdebootstrap vs systemd
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 km...@debian.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109004731.5a29f4920...@mail.topstudio.co.jp
Re: debootstrap and cdebootstrap vs systemd
-Original Message- From: Cyril Brulebois k...@debian.org To: Simon Richter simon.rich...@hogyros.de Cc: debian-de...@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 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 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 2020 and beyond. And for all I know, perhaps these businesses deserve everything that happens to them, who knows.
Re: debootstrap and cdebootstrap vs systemd
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 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 debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107145016.gr24...@csclub.uwaterloo.ca
Re: debootstrap and cdebootstrap vs systemd
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 debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545bfc67.8070...@yahoo.com.au
Re: debootstrap and cdebootstrap vs systemd
Simon Richter simon.rich...@hogyros.de (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 Description: Digital signature
Re: debootstrap and cdebootstrap vs systemd
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 debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141106233306.ga7...@angband.pl
Re: debootstrap and cdebootstrap vs systemd
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 debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107000217.gn24...@rzlab.ucr.edu
