Re: Request for access to porterbox
On Thu, Jul 28, 2016 at 12:56:11AM +0200, Christian Seiler wrote:
> On 07/28/2016 12:21 AM, Adam Borowski wrote:
> > On Wed, Jul 27, 2016 at 11:07:17PM +0200, Christian Seiler wrote:
> >> m68k and sh4 do work in qmeu-user-static chroots, the setup
> >> is not quite as trivial however. (I can give you a tarball
> >> that will work in pbuilder and schroot though.)
> >
> > For qemu-user for sh4 it's:
> >
> > CHROOT=/srv/chroots/sh4 #name the chroot here
> > apt-get -y install debian-ports-archive-keyring qemu-user-static
> > btrfs subv create "$CHROOT" || mkdir "$CHROOT"
> > mkdir -p "$CHROOT/usr/bin"
> > cp -p /usr/bin/qemu-sh4-static "$CHROOT/usr/bin/"
> > debootstrap --arch=sh4 \
> > --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg \
> > unstable "$CHROOT" http://ftp.ports.debian.org/debian-ports/
>
> That works now? When I set up a SH4 chroot a while back, I had to
> use the qemu-sh4-static binary from the i386 version of the
> qemu-user-static package, because the amd64 version was broken.
> (Luckily, static linking.)
#805827 which is an ex-bug.
> qemu-debootstrap fails for m68k with Illegal Instruction at the
> beginning of debootstrap --second-stage. I did get a working
> chroot by fiddling with stuff for a while manually IIRC (not on
> the computer I'm currently on, I'd have to look that up), but I
> don't remember what I did.
I could swear this worked at some point. I guess the instruction set was
bumped recently.
> Actually, I remember now: you need to compile a custom version of
> qemu-m68k-static because upstream QEMU doesn't support the CPUs
> that Debian's port requires. It's even described on the Debian
> Wiki, see:
> https://wiki.debian.org/M68k/sbuildQEMU
Ie, "you need to get qemu with patches not yet merged upstream", a common
story (like other bugs mentioned).
> Plus, aptitude is broken on many (but not all) archs when used
> together with qemu-user-static (segfaults), so if you use that
> kind of chroot together with pbuilder, in my experience you need
> to revert to the classic satisfydepends (which is much slower)
> to make pbuilder work properly.
As debootstrap uses regular apt rather than aptitude, why would this be a
concern? And aptitude's dependency resolution is broken more often than
not, so sticking with apt is more reliable also on the installed system.
> Also, if you have debian-ports for the binary packages, you still
> need the normal archive for the source packages, so the deb and
> deb-src lines (if you want to add both to sources.list) diverge.
debootstrap doesn't have a way to use two archives, so this is something to
be configured once the chroot is installed.
> > Same works for all other archs supported by qemu, other than powerpcspe
> > (needs QEMU_CPU=e500v2).
>
> mips64el needs QEMU_CPU=mips64dspr2. (Most stuff works without
> that env var, but some things don't.)
gcc recently bumped to R2 ISA in 5.2.1-17.
> ppc64el needs QEMU_CPU=POWER8. (qemu-static-ppc64 and -ppc64el
> are basically the same save for endianness, but Debian's pp64el
> port requires a POWER8 CPU at least, whereas the ppc64 port runs
> on POWER5 and higher IIRC.)
#813698, an ex bug.
> I have never gotten sparc64 to work in qemu-user-static, that I
> only got working with qemu-system. (Debian Wiki contains some
> instructions for that though.)
Aye.
--
An imaginary friend squared is a real enemy.
Reply to: