Jonas Smedegaard writes:
Quoting Linux-Fan (2020-02-13 20:29:47) > Hello list members, > > having seen this recently on the mailing list, I am interested to try out > `mmdebstrap` (as a replacement for `debootstrap`). The ultimate goal of my > use of these utilities is to arrive at an image suitable for booting an > armhf > SBC (Banana Pi M2+ EDU). Existing (overly complicated and not debian-only)
[...]
> ~~~ > $ mmdebstrap stable test.tar
[...]
> '/tmp/mmdebstrap.r10cMA6wAV': Operation not permitted
[...]
> When I run the same command as root, it proceeds without error. However, I > wanted to try out this nice possibility of creating chroots without root > and so far, it does not seem to work. How can I get to work mmdebstrap without > being root? > > OS: Debian 10 (buster/stable) amd64. > /tmp resides on the root filesystem (ext4). Beware that this is more of a development question than a user question. Yes, developers are users too - my point is that those following this mailinglist are less likely to be able to help with issues of "splitting atoms" of an operating system than with adjusting configfiles of an officially installed one.
Thanks. I saw that there are some bug-reports and that development is active. Maybe it makes sense to do a bug-report, because from my point of view it is easy to reproduce (no need to bother with ARM yet, I just tried the "basic" invocation to create a stable chroot for my "native" amd64 architecture). Being such a simple invocation, I thought I must have made some rather obvious mistake, because my command very much follows the manpage. I had thought that the complex part would only come afterwards :)
I recommend to read section "MODES" in man page for mmdebstrap, which nicely lays out how different approaches complicates matters in different ways.
I saw it. For now, the "root" mode works. Before I think it automatically went with "fakechroot" and failed... maybe I should investigate this "unshare" mode? It is already very helpful that it runs faster than regular debootstrap and has the multiarch-things built in. I arrived at what seems to be a suitable image (not near the hardware to test at the moment...) in just a few hours -- back when I did it with debootstrap there was much more waiting involved and a lot of fiddling with qemu-user-static etc. which took me more than a day just for the filesystem tree.
One way to simplify things is to build on ARM.
The problem is: I have that board and it is usually "in use" (currently on oldstable). I can turn it off temporarily for testing, but it is not so much a "development system". Besides, I get the impression that even if the emulation is not really "faster" (?), it is less a stain on the hardware when I run the compute-intensive part on amd64 (usually a little server, currently a "sturdy enough" laptop :) ) than on the single board computer. And then, running oldstable and a non-Debian kernel, I would not consider it a good "development machine" from the software side either? For me it is one of the points to "take home" from buying a cheap ARM SBC: Software support can be difficult. So maybe next time I will be smarter to acquire something "amd64" or something well-supported like the "omnipresent" Raspberry Pi (although some recent list posts seemed to suggest that a "pure" Debian does not run on their newest incarnation yet...). On the other hand, this little Banana Pi M2+EDU despite being very little supported from the software side, seems to run just well 24/7 for prolonged amounts of time (it had more than 300 days of uptime, but as of now, everything is offline for maintenance).
Another is to generate not a filesystem but a tarball (and then use different approach to turn that into a bootable image).
Yes. Tarball sounds good. I understand that when going for a filesystem rather than tarball I would need to be root just to get the permissions right. And of course, in the end I will do (as root) a tar -C /mnt -xf ... to put everyting on the SD card. If I understand it correctly, for the bootable image, I will need the filesystem, but also a bootloader copied to a specific position on the SD card. In the past, this worked for my armbian+Debian mixture. Now I am working towards making the process based on Debian only to e.g. allow such things as kernel updates :) .
Yet another is (likely) to target bullseye instead of buster.
That is interesting, I did not think of that. If I get stuck, I will try that as well (would be quite a jump from oldstable to testing, though :) ). Thanks again Linux-Fan [...]
Attachment:
pgpfgy5HBkONl.pgp
Description: PGP signature