matteo | hi all | 00:09 |
---|---|---|
matteo | what are tha lpia compiler flags? | 00:11 |
=== ALo is now known as ALoGeNo | ||
=== foka_ is now known as foka | ||
persia | chuck: A couple people have tried it on the EeePC : general consensus is the 1) It takes a *long* time to install without feedback, and 2) the EeePC is not a MID. Look for Ubuntu Mobile in intrepid. | 02:18 |
persia | ian_brasil: -monitor stdio puts the KVM monitor in the shell from which you launched KVM, which can give you useful metacontrol of your instance. | 02:18 |
ian_brasil | persia: ok thanks | 02:21 |
ian_brasil | re-rolling the squashfs makes the hd work for its money ;) | 03:11 |
persia | ian_brasil: /tmp on tmpfs can help with that. | 03:11 |
persia | Also, the 20080913 image appears to have suffered a mishap, so one still can't install (although it's usable as a live image). | 03:12 |
ian_brasil | i don't understand | 03:12 |
persia | I added the following to /etc/fstab: | 03:13 |
persia | tmpfs /tmp tmpfs nodev,nosuid 0 0 | 03:13 |
ian_brasil | ah,ok | 03:14 |
persia | What that does it create a /tmp that is half the size of physical RAM, and anything stored in /tmp goes to RAM. In practice, much of it ends up being committed to swap, but it means that it only gets written to disk when the space in /tmp exceeds the cache buffers, rather than immediately, which can speed up operations on temporary files for machines with slower access to secondary storage (not SSD) | 03:14 |
persia | (or even not 10K drives - just having a 7200, 5400, or slower drive makes this a win) | 03:15 |
persia | Of course, the downside is that one wants to clean up /tmp to hibernate, and it's in RAM, so if one is short RAM, it may limit the size of what one can put in /tmp. | 03:15 |
ian_brasil | i will try that for sure. its a good job you are always here and don't sleep much persia ;) | 03:19 |
persia | ian_brasil: I do sleep. That's why it took me so long to answer your question about -monitor. | 03:19 |
ian_brasil | ok..well thanks anyway | 03:23 |
ian_brasil | damn, out of space again | 03:26 |
ian_brasil | it is annoying that it gets right to the end before this error | 03:27 |
persia | It's hard to know how well the chroot will compress in advance, and when it copies the squashfs, there might just not be enough room. | 03:28 |
persia | Also, still out of space after running apt-get clean? Is this a different issue? | 03:29 |
persia | Lastly, do you have firefox installed? Some of the earlier images did, and you might be able to remove it to regain space. | 03:29 |
ian_brasil | i will try and remove firefox | 03:31 |
persia | You might also install deborphan and see what else can be dropped. Alternately pull a new image :) | 03:33 |
ian_brasil | i think the space issue is going to cause a lot of confusion/questions..i think i will write a wiki page about this at some point | 03:48 |
persia | Probably best if you just mention it as a warning on the current wiki page. I think you are the primary user of this now: ogra and I have used it some, but not to the extent you use it. | 03:54 |
ian_brasil | OK..space is a concern in order that the image fits on a 512MB pen drive , right? | 03:56 |
ian_brasil | just want to clarify this | 03:56 |
persia | Well, it's of interest to me, as I only have one pen drive > 512M, but they sell them at the corner store here, so it's not essential or anything. | 03:59 |
persia | Anyway, the current images are well over 512M, so since that criteria hasn't been met, it's not worth trying to enforce it unless you have a good idea about which packages we would do better without, and we can try to find out why they are being installed. | 04:00 |
ian_brasil | i am asking why is there the 20MB additional size limit when you are working inside the chroot...i missed that part of the conversation earlier | 04:04 |
persia | ian_brasil: It's just an arbitrary number. | 04:05 |
persia | Essentially, the VFAT image needs enough extra space to hold the kernel, the manifests, the preseeding, and the boot configuration files. | 04:05 |
persia | 20M was determined as a number that would probably handle all that without much fuss. | 04:06 |
persia | After the images were available, ogra put together the image-editing script, which opened new possibilities. | 04:06 |
persia | At this point, it's a matter of debate whether the image should contain more empty space (longer downloads, but more flexible) or stay small. | 04:06 |
persia | Personally, I think it's better to stay small, and upgrade an installed system, but that's currently blocked on https://launchpad.net/ubuntu/+source/debian-installer/20080522ubuntu14/+build/715838 | 04:07 |
ian_brasil | ah i understand now | 04:07 |
persia | With luck, the image generated in ~21 hours will work for installs. If not, I'm 100% certain the image generated in ~69 hours will allow installs. | 04:08 |
persia | (I very much suspect the image generated in ~45 hours will be identical to the one in ~21 hours) | 04:09 |
ian_brasil | i am in the camp of longer downloads with more space...with this you can make a larger theme and customize more for an OEM | 04:13 |
persia | ian_brasil: I guess, but I'd suspect most OEMs would prefer the even greater flexibility of generating the images themselves. | 04:14 |
persia | To do that, just use the squashfs-editing portion of the image-editor script, and then create a VFAT image of sufficient size, and stuff in the squashfs, kernel, preseeds (likely different for OEMs anyway), manifests (also likely different for replicable installs), and boot hints. | 04:15 |
persia | syslinux the VFAT image, and you're done. | 04:16 |
persia | The key part here is that the OEM likely wants to change the preseeds and manifests to change the way the install works. | 04:16 |
persia | For someone just playing around, adding a couple packages to the image works. This is also very important when testing changes to enable new hardware. | 04:17 |
persia | For hardware enablement, once it's complete, I'd hope to get support into the official images. | 04:17 |
persia | For installing a couple fun packages that someone always uses, 20M (or maybe 30M) ought be enough. Too much size makes latency *very* painful for those of us with long-haul connections to cdimage.ubuntu.com | 04:18 |
persia | Also, for folk with download caps, an extra 100M every few days can add up quickly to a 2G or 3G ceiling. | 04:18 |
ian_brasil | I suppose this depends to a certain extent on the OEM. In my experience some do not want to get involved in this level of customization...they just ask can I put my own applications and my own theme on ume...a quick and easy way to do enable this to happen could give this sector a good kickstart...maybe a community maintained larger vfat image might work for this? | 04:31 |
persia | ian_brasil: Could be, although I'd think putting together a script to expand the VFAT is probably easier, both to maintain, and to get hosted. | 04:33 |
persia | I'm thinking just something that takes an existing .img as an argument, and a second argument that says how much space to add. It then creates a VFAT that is the desired amount larger, and copies in the contents, for later use with the image editor. | 04:33 |
persia | Does that sound useful to you> | 04:34 |
persia | s/>/?/ | 04:34 |
ian_brasil | that sounds extremely useful to me | 04:36 |
persia | It's also not that big, and reusable. | 04:37 |
ian_brasil | and a much better idea than big downloads | 04:37 |
persia | I'm chasing a few other things today, but if you've time to put something together, I'm happy to test, or act as a sounding board if you want to talk through something. | 04:38 |
ian_brasil | ok...i will try to hack something up this weekend for that | 04:38 |
persia | ian_brasil: Oh, right, it's still Friday night for you :) | 04:40 |
ian_brasil | yes, talking of which it is time to sleep! thanks again for the advice | 04:42 |
persia | Have a good night. | 04:44 |
=== asac_ is now known as asac | ||
crevette | hey people | 16:43 |
crevette | just a dumb question, bluez 4 is not targeted for intrepid? | 16:43 |
=== Snookie is now known as Guest83413 | ||
=== foka_ is now known as foka | ||
=== Snookie is now known as Guest83869 | ||
=== Guest83869 is now known as snookie | ||
=== snookie is now known as Guest82291 | ||
=== Guest82291 is now known as snookie | ||
=== snookie is now known as Guest94106 | ||
=== Snookie is now known as Guest96899 | ||
=== Guest96899 is now known as snookie | ||
=== snookie is now known as Guest11420 | ||
=== Guest11420 is now known as snookie2 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!