Now we could not install on i386, we need a wiki page for how to
debug quickly on i386
On Mon, 2025-04-21 at 13:12 +0200, Bastien Roucaries wrote:
Now we could not install on i386, we need a wiki page for how to
debug quickly on i386
It's easy to setup an i386 container with Incus, which is how I've
been running 32bit builds/debugging for the past few years. Assuming
you've already got Incus configured to your liking:
$ sudo apt install distrobuilder squashfs-tools-ng
$ sudo distrobuilder build-incus /usr/share/distrobuilder-images/debian.yaml ./trixie.i386/ -o image.release=trixie -o image.architecture=i386
$ incus image import --alias trixie.i386 ./trixie.i386/incus.tar.xz ./trixie.i386/rootfs.squashfs
$ incus launch trixie.i386
mmdebstrap --variant=apt --arch=i386 --chrooted-customize-hook=bash unstable /dev/nullThis one does not fully work for core dump....
On Thu, May 01, 2025 at 12:28:10PM +0000, Mathias Gibbens wrote:
On Mon, 2025-04-21 at 13:12 +0200, Bastien Roucaries wrote:
Now we could not install on i386, we need a wiki page for how to
debug quickly on i386
It's easy to setup an i386 container with Incus, which is how I've
been running 32bit builds/debugging for the past few years. Assuming
you've already got Incus configured to your liking:
$ sudo apt install distrobuilder squashfs-tools-ng
$ sudo distrobuilder build-incus /usr/share/distrobuilder-images/debian.yaml ./trixie.i386/ -o image.release=trixie -o image.architecture=i386
$ incus image import --alias trixie.i386 ./trixie.i386/incus.tar.xz ./trixie.i386/rootfs.squashfs
$ incus launch trixie.i386
I just set up a schroot[1]. I have a handy-dandy schroot setup script
which makes it super easy[2] to create an amd64, i386, and arm64
(using qemu) build chroots. This was originally created to let random >graduate students or kernel newbies set up a kernel file system test >appliance[3][4], but these days I very often use this for general >cross-architecture debian development.
[1] https://wiki.debian.org/Schroot
[2] https://github.com/tytso/xfstests-bld/blob/master/setup-buildchroot
[3] https://thunk.org/gce-xfstests
[4] https://github.com/tytso/xfstests-bld/blob/master/Documentation/building-xfstests.md
I will also use sbuild with git-buildpackage when creating
hermetically built packages for uploading, but that's a lot more
complicated to set up.
Le jeudi 1 mai 2025, 17:26:34 heure d’été d’Europe centrale Jochen Sprickerhof
a écrit :
mmdebstrap --variant=apt --arch=i386 --chrooted-customize-hook=bash unstable >> /dev/nullDo not get my core file in container /var/lib/systemd/coredump/ but in host / >var/lib/systemd/coredump/
It should be really documented.
Le jeudi 1 mai 2025, 17:26:34 heure d’été d’Europe centrale Jochen Sprickerhof
a écrit :
mmdebstrap --variant=apt --arch=i386 --chrooted-customize-hook=bash unstable >> /dev/nullThis one does not fully work for core dump....
Try on the container:
#include <stdlib.h> // C
void main(void)
{
abort();
}
Do not get my core file in container /var/lib/systemd/coredump/ but in host / >var/lib/systemd/coredump/
* Bastien Roucaries <rouca@debian.org> [250501 17:41]:
Le jeudi 1 mai 2025, 17:26:34 heure d’été d’Europe centrale Jochen >Sprickerhof>
a écrit :
mmdebstrap --variant=apt --arch=i386 --chrooted-customize-hook=bash
unstable /dev/null
Do not get my core file in container /var/lib/systemd/coredump/ but in host >/ var/lib/systemd/coredump/
It should be really documented.
It already is: https://github.com/systemd/systemd/blob/main/docs/COREDUMP.md says:
| ... taking comprehensive effect on all userspace.
So yeah, once you install systemd-coredump and use the defaults, the system-wide coredump handler handles core dumps.
Chris
* Bastien Roucaries <rouca@debian.org> [2025-05-01 17:40]:
Le jeudi 1 mai 2025, 17:26:34 heure d’été d’Europe centrale Jochen >Sprickerhof>
a écrit :
mmdebstrap --variant=apt --arch=i386 --chrooted-customize-hook=bash
unstable /dev/null
This one does not fully work for core dump....
Try on the container:
#include <stdlib.h> // C
void main(void)
{
abort();
}
Do not get my core file in container /var/lib/systemd/coredump/ but in host >/ var/lib/systemd/coredump/
That's a limitation of systemd-coredump or the kernel, depending on how
you see it. From a quick look the pattern in
/proc/sys/kernel/core_pattern is not namespaces so mmdebstrap can't
change it but the kernel supports adding user namespaces to it:
https://www.kernel.org/doc/html/latest/admin-guide/sysctl/kernel.html#core-p attern
So systemd-coredump could do that but it would probably need to know the mmdebstrap internals to du so. So I guess disabling systemd-coredump
would make the most sense.
Cheers Jochen
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 163:00:56 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,509 |