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-devel-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
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 debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545c96a2@yahoo.com.au
Re: debootstrap and cdebootstrap vs systemd
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 debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545ca22c.7060...@yahoo.com.au