**** BEGIN LOGGING AT Sat Jun 18 02:59:56 2011 Jun 18 16:54:11 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? Jun 18 16:54:46 persia ^^ Jun 18 22:15:42 sveinse, All native operations are considered safe and expected to work. Foreign operations may work, but aren't promised to do so. Jun 18 22:16:57 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. Jun 18 22:21:35 thanks. What do you mean by "wrap the bundle" ? Jun 18 22:22:26 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. Jun 18 22:23:00 Ah, ok, then I understand. It's the part where in our case, generate the uSD card image FS Jun 18 22:23:14 This may involve copying it into a loop-mount, running something like mksquashfs or ubunize, etc. Jun 18 22:23:21 yep Jun 18 22:23:25 Precisely. Jun 18 22:23:51 But you mention the upgrade post deployment or am I misunderstanding? Jun 18 22:24:14 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. Jun 18 22:24:23 Yes, upgrades are usually post-deployment. Jun 18 22:24:42 So, when you construct the filesystem, you want to construct it to include all the updates available at the time of filesystem creation. Jun 18 22:25:16 If you have -updates in your sources.list when creating it, apt will take care of this for you. Jun 18 22:25:58 Then, post-deployment, end-users will continue to update their systems, which provides a channel for bugfixes, security fixes, etc. Jun 18 22:26:24 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? Jun 18 22:26:30 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. Jun 18 22:27:06 The user *may* see an update process at first boot, depending on the time between filesystem creation and first-boot. Jun 18 22:27:38 For each Ubuntu release, we generally have 10-15 updates available at the time of the release announcement, so 0.1% of packages. Jun 18 22:27:49 (or a bit less, but close to that) Jun 18 22:28:39 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. Jun 18 22:28:41 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 Jun 18 22:28:48 Right. Jun 18 22:29:14 You'll need to have available repositories containing that software, to provide updates and security fixes to it. Jun 18 22:29:36 (unless you got things working with qt4-x11, and want to put your stuff in the regular archives :) ) Jun 18 22:30:22 The moreso because if you just point users at the regular archive, they may end up with updates that impact your software. Jun 18 22:30:31 What exactly triggers the apt-get update in the first place? The first boot? Jun 18 22:30:42 There's a few things. Jun 18 22:31:11 So, if you're using oem-config (recommended), I believe there's an update at first boot as part of that. Jun 18 22:31:28 yeah, ok Jun 18 22:32:18 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. Jun 18 22:32:50 If you want any of these features, you'll want to have one of those packages included in your filesystem. Jun 18 22:34:05 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 Jun 18 22:34:40 I think that if oem-config doesn't have access to the internet, it doesn't ask the user questions about it. Jun 18 22:35:07 (but you want to test, especially in your (fairly different) environment) Jun 18 22:35:25 Anyways, my question was how to migrate from nothing via debootstrap to the device image, and I got my answer, thanks Jun 18 22:35:45 I'll dive into oem-config later -- but I will eventually Jun 18 22:35:54 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) Jun 18 22:36:32 * sveinse taking notes Jun 18 22:37:26 Sorry. I don't mean to overwhelm you :) Jun 18 22:37:56 No, no problem. I'm just afraid of coming back weeks later and repeating the same questions :P Jun 18 22:38:17 In fact, I'm grateful Jun 18 22:39:07 Obviously from our previous discussions, the way I've found is not necessarily the correct way of doing things Jun 18 22:40:11 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. Jun 18 22:40:36 I'm hesitant to say that other ways are wrong (with specific exceptions), if they are known to work. Jun 18 22:41:28 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 Jun 18 22:42:44 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. Jun 18 22:42:53 very true Jun 18 22:44:08 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. Jun 18 22:44:36 (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) Jun 18 22:46:12 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 Jun 18 22:46:39 I agree that neither is bad. I'm deeply suspicious of mixing them. I can only wish you luck. Jun 18 22:47:07 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 Jun 18 22:47:59 Some of them are getting *really* inexpensive these days. Pandas and Quickstarts seems to work rathre nicely, considering the cost. Jun 18 22:48:10 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) Jun 18 22:48:21 And everyone else is coming out with similar things (although I haven't gotten as much feedback about them) Jun 18 22:48:55 Development-performance, build-time performance, or run-time performance? Jun 18 22:49:06 I think they ought be equivalent for runtime performance. Jun 18 22:49:13 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 :) ) Jun 18 22:49:48 But I admire you're effort on that Jun 18 22:49:53 cross-build for development performance makes sense, although in Ubuntu a final native build is always done for deployment. Jun 18 22:49:55 your Jun 18 22:50:09 yes Jun 18 22:50:17 Thank davidm: it's his idea, and his labour. Lovely stuff though. Jun 18 22:57:03 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 Jun 18 22:59:16 I think it does. Jun 18 22:59:32 If not, then the .d implementation is not matching expectations. Jun 18 23:00:59 `ldconfig -p` seems to generate something that may help if you're encountering an issue. Jun 18 23:11:06 Is there a packages.ubuntu.com which search the armel packages? Jun 18 23:14:06 No, nothing on ports.ubuntu.com shows up somewhere like that. Jun 18 23:15:50 The best option is to use a package manager in an armel environment *OR* to pull local copies of the Packages files, and then dig through them (apt-cache can be tricked into using an alternate file, and grep-dctrl (from dctrl-tools) gives even more options. Jun 18 23:16:43 I can run apt-cache natively and search from it. Albeit I don't know how to find the name of a package when I know the name of the file Jun 18 23:16:47 *but* there ought be almost no difference in the available packages on a per-architecture basis. Jun 18 23:17:16 Install apt-file for that (although `dpkg -S ${FILE}` works for currently-installed files) Jun 18 23:17:28 thanks Jun 18 23:18:06 Or just use packages.ubuntu.com : the contents of packages really shouldn't differ much between architectures Jun 18 23:18:18 (although they do for some special cases) Jun 18 23:18:59 Hmm. It does in this case: I'm looking for the powervr/SGX drivers rsalveti added. These are OMAP3 specific Jun 18 23:20:14 https://wiki.ubuntu.com/ARM/OMAP/Graphics might help with that Jun 18 23:20:54 perfect! Thanks Jun 18 23:21:03 I believe those drivers *only* work on the PVR core in omap3, and don't do the right thing for arbitrary PVR implementations. Jun 18 23:22:13 Yes, I'm aware of that. I've been talking to rsalveti earlier Jun 18 23:22:25 thanks anyways **** ENDING LOGGING AT Sun Jun 19 02:59:57 2011