Quoting Linux-Fan (2020-02-13 21:40:13) > Jonas Smedegaard writes: > > > Quoting Linux-Fan (2020-02-13 20:29:47) > > > 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)
[...] > > 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 dearly recommend you to file bugreports: From your approach it sounds like if nothing else then you have found bugs in the documentation! As you might have noticed as well, Johannes (author of mmdebstrap) is excellent not only in writing code but also in bug hunting! I really admire his attention to detail! > > 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? Pleay around with different modes, but don't settle with working around possibly buggy code or documentation: Please contribute by sharing the (possible) flaws you stumble upon in your exploration of this novel tool. > 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. Sounds like you could also help by sharing what you have found works for you so far: Create a page at wiki.debian.org and/or blog about it! > > 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. I recognize the dilemma. You can postpone, but the obvious solution to that issue of yours is to buy a few more boards so you have some to play with. And sure, AMD64 is faster than 32-bit ARM - but what I was thinking was to use your shiny new 64-bit Olimex Teres-1 laptop that you go buy right after reading this email :-D > And then, running oldstable and a non-Debian kernel, I would not > consider it a good "development machine" from the software side > either? Your _development_ environment would not be oldstable but testing: Even if your target system is oldstable, you still want to develop on a system which includes mmdebstrap ;-) > 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). I certainly don't recommend RPi. I recommend OSHW-certified boards like the Olimex LIME2 - quite similar to the one you already got. ...but really, all of this is badly suited for this user mailinglist. I can suggest that we move further discussion to the #tinker irc channel and/or join the tinker team mailinglist, both places is used for me and a few others trying to streamline bootstrapping of Debian on tiny ARM boards. More info at https://wiki.debian.org/DebianTinker I am eager to hear more details about your journey so far, and to compare with my own... :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
