| === asac_ is now known as asac | ||
| === lilstevie is now known as lilstevie|ZNC | ||
| === lilstevie|ZNC is now known as lilstevie | ||
| === Lopi is now known as Lopi-dev | ||
| === Lopi-dev is now known as LopiX-dev | ||
| === LopiX-dev is now known as Lopi | ||
| sveinse | It is generally recommended to run a debootstrap installer for a target system on a native machine. Is it considered safe to do installations/upgrades (like apt-get update and such) for a target chroot system on a native machine? | 17:52 |
|---|---|---|
| sveinse | persia ^^ | 17:53 |
| persia | sveinse, All native operations are considered safe and expected to work. Foreign operations may work, but aren't promised to do so. | 23:14 |
| persia | The common pattern for generating an image is to use debootstrap to create a base filesystem, then to install packages into that, then to wrap the bundle for deployment onto target systems, which then perform the upgrades. | 23:15 |
| sveinse | thanks. What do you mean by "wrap the bundle" ? | 23:19 |
| persia | Implementations differ, but it's essentially taking some bundle of files (the chroot), and putting in some structure that may be treated as a filesystem. | 23:20 |
| sveinse | Ah, ok, then I understand. It's the part where in our case, generate the uSD card image FS | 23:21 |
| persia | This may involve copying it into a loop-mount, running something like mksquashfs or ubunize, etc. | 23:21 |
| sveinse | yep | 23:21 |
| persia | Precisely. | 23:21 |
| sveinse | But you mention the upgrade post deployment or am I misunderstanding? | 23:22 |
| persia | Some implementations will create a loop-mount first, then mount it, then debootstrap on that mount: but this requires knowing the space you require in advance. | 23:22 |
| persia | Yes, upgrades are usually post-deployment. | 23:22 |
| persia | So, when you construct the filesystem, you want to construct it to include all the updates available at the time of filesystem creation. | 23:23 |
| persia | If you have -updates in your sources.list when creating it, apt will take care of this for you. | 23:23 |
| persia | Then, post-deployment, end-users will continue to update their systems, which provides a channel for bugfixes, security fixes, etc. | 23:24 |
| sveinse | Here's how I think it should be (from my understanding): 1) debootstrap chroot, 2) install packages into chroot, 3) create uSD image from chroot, 4) Install into device. The user should then not have to see an upgrade process while his first boot. Or? | 23:24 |
| persia | Some users may choose to "upgrade", meaning to move to the next release of Ubuntu, but this is outside the scope of your filesystem creation. | 23:24 |
| persia | The user *may* see an update process at first boot, depending on the time between filesystem creation and first-boot. | 23:25 |
| persia | For each Ubuntu release, we generally have 10-15 updates available at the time of the release announcement, so 0.1% of packages. | 23:25 |
| persia | (or a bit less, but close to that) | 23:26 |
| persia | So, you're a bit different, because you're doing a derivative, with a fair bit of software that isn't in the Ubuntu repositories. | 23:26 |
| sveinse | Yeah, that will happen if the user has a working internet access on the device. I.e. the device will apt-get update itself upon firstboot | 23:26 |
| persia | Right. | 23:27 |
| persia | You'll need to have available repositories containing that software, to provide updates and security fixes to it. | 23:27 |
| persia | (unless you got things working with qt4-x11, and want to put your stuff in the regular archives :) ) | 23:27 |
| persia | The moreso because if you just point users at the regular archive, they may end up with updates that impact your software. | 23:28 |
| sveinse | What exactly triggers the apt-get update in the first place? The first boot? | 23:28 |
| persia | There's a few things. | 23:29 |
| persia | So, if you're using oem-config (recommended), I believe there's an update at first boot as part of that. | 23:29 |
| sveinse | yeah, ok | 23:29 |
| persia | There's a bunch of packages in the archive that provide scheduled update-type stuff: some will do an apt-get update, some will just check to see if one needs to be done, some will update the cache and download (but not install) all the updates, and some will automatically update the software. | 23:30 |
| persia | If you want any of these features, you'll want to have one of those packages included in your filesystem. | 23:31 |
| sveinse | yes. The only detail which comes into mind now, is the fact that the user may not have setup the wireless yet, so internet will not be available early in the process | 23:32 |
| persia | I think that if oem-config doesn't have access to the internet, it doesn't ask the user questions about it. | 23:32 |
| persia | (but you want to test, especially in your (fairly different) environment) | 23:33 |
| sveinse | Anyways, my question was how to migrate from nothing via debootstrap to the device image, and I got my answer, thanks | 23:33 |
| sveinse | I'll dive into oem-config later -- but I will eventually | 23:34 |
| persia | If you're planning scheduled updates, the recommendation is to have something that uses update-notifier-common (you may find muon-notifier a good example from which to collect code) | 23:34 |
| * sveinse taking notes | 23:34 | |
| persia | Sorry. I don't mean to overwhelm you :) | 23:35 |
| sveinse | No, no problem. I'm just afraid of coming back weeks later and repeating the same questions :P | 23:36 |
| sveinse | In fact, I'm grateful | 23:36 |
| sveinse | Obviously from our previous discussions, the way I've found is not necessarily the correct way of doing things | 23:37 |
| persia | At least it's not the way that things are commonly done in Ubuntu, so may not be getting the level of testing you might expect. | 23:38 |
| persia | I'm hesitant to say that other ways are wrong (with specific exceptions), if they are known to work. | 23:38 |
| sveinse | Since my setup is somewhat unique, I need to do the testing and QA qualification anyways. I wouldn't expect nor ask that of the community | 23:39 |
| persia | Heh. If you are planning on a product release and don't have an internal qualification process, something is likely to go very wrong, even if you weren't special. | 23:41 |
| sveinse | very true | 23:41 |
| persia | That said, it makes sense to select solutions that are more common in many cases, as they likely receive more testing, are more mature, etc. | 23:42 |
| persia | (this isn't always the case: sometimes there are cool new things that are genuinely good, but they do require more attention if selected, just in case) | 23:42 |
| sveinse | as said before, we're living on the edge between native and cross compilation, so in that respect we are stretching the Ubuntu normal way of doing things. I believe neither method is bad, just different. So we know the added risk of being on that edge | 23:44 |
| persia | I agree that neither is bad. I'm deeply suspicious of mixing them. I can only wish you luck. | 23:44 |
| sveinse | But that being said, we are actually considering buying a target system (for the build server) to do the debootstrap staging and making the final images | 23:45 |
| persia | Some of them are getting *really* inexpensive these days. Pandas and Quickstarts seems to work rathre nicely, considering the cost. | 23:46 |
| sveinse | But for performance reasons, I belive we will cross build some of the binary debs (kernel, Qt libs and Qt app -- all of which are designed well for cross compilation) | 23:46 |
| persia | And everyone else is coming out with similar things (although I haven't gotten as much feedback about them) | 23:46 |
| persia | Development-performance, build-time performance, or run-time performance? | 23:47 |
| persia | I think they ought be equivalent for runtime performance. | 23:47 |
| sveinse | Yup, The IT dept will cheer the day I come with a armel box in a 19" rack. (And I'm not to persue a rack building process like you guys are doing for your pandas :) ) | 23:47 |
| sveinse | But I admire you're effort on that | 23:48 |
| persia | cross-build for development performance makes sense, although in Ubuntu a final native build is always done for deployment. | 23:48 |
| sveinse | your | 23:48 |
| sveinse | yes | 23:48 |
| persia | Thank davidm: it's his idea, and his labour. Lovely stuff though. | 23:48 |
| sveinse | BTW does anyone here know how I can list which dirs and their order ld.so is searching for so's? I'm not sure if "cat /etc/ld.so.conf.d/*.conf" is giving the right order | 23:55 |
| persia | I think it does. | 23:57 |
| persia | If not, then the .d implementation is not matching expectations. | 23:57 |
| persia | `ldconfig -p` seems to generate something that may help if you're encountering an issue. | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!