=== [XeN] is now known as [XeN]-away
=== [XeN]-away is now known as [XeN]
=== asac_ is now known as asac
[10:02] <daurnimator> anyone about?
[10:02] <daurnimator> i'm tryign to boot natty on my beagleboardxm
[10:02] <daurnimator> it gets to a busybox terminal...
[10:03] <daurnimator> but I don't know how to boot into X/gnome
[10:06] <persia> Which image are you using?
[10:07] <daurnimator> ubuntu-11.04-preinstalled-netbook-armel+omap.img.gz
[10:08] <persia> That *should* (eventually) launch X.  Do you have any errors in the busybox shell?  What are you using for console?
[10:09] <daurnimator> I jst have it plugged into my tv.
[10:09] <daurnimator> (console is coming oup on tv)
[10:14] <daurnimator> on boot it goes: caching vfat content, re-writing vfat partition, checking filesystem before resizing. then drops to busybox with: No init found. Try passing init= bootarg
[10:14] <daurnimator> window 25
[10:20] <persia> Hrm.
[10:20] <persia> How did you write the SD card?
[10:22] <daurnimator> from my laptop with guzip -c | dd
[10:23] <persia> I haven't seen it done that way before, but I can't imagine why it wouldn't work :)  Nice optimisation.
[10:24] <daurnimator> uh' what other way would you do it?
[10:24] <persia> It looks like there's some issue resizing the filesystem for initial boot.
[10:24] <persia> Most folk use two steps: 1) uncompress, 2) copy to SD.
[10:24] <persia> There are, of course, N methods to achieve either 1) or 2).
[10:24] <persia> And, like I said, doing it all in one line should make no difference.
[10:25] <persia> For some hardware, attempting to write with `cat` rather than `dd` seems to cause issues (but for some people it works).
[10:25] <persia> Anyway, that's just me asking common questions to try to apply a known solution to an unknown problem :)
[10:27] <persia> So, if I had your symptoms, I'd probably try rewriting the SD (cosmic ray protection), then trying fsck in the busybox shell, and attempting to manually step through the initramfs scripts to get a more interesting error.
[10:27] <daurnimator> I was going off https://wiki.ubuntu.com/ARM/OmapNetbook anyway :P
[10:29] <persia> Heh.  Last time I saw that page it recommended `zcat > ${DEVICE_NAME}`.  I'm glad to see that it's getting better :)
[10:49] <daurnimator> so what file do I change?
[10:49]  * daurnimator pokes persia 
[10:52] <persia> I've no idea what file to change to "make it work".  As I said before, I'd start with cosmic-ray-paranoia, then an fsck in the busybox shell, than attempting to manually process the initramfs scripts.
[10:54] <daurnimator> well I'm looking at the uboot partition now...
[10:54] <daurnimator> something in boot.scr?
[10:55] <persia> If you reached the message you posted at :16, uboot is working fine for you.  The issue is happening inside the initramfs.
[10:55] <daurnimator> I was imagining boot.scr was passing bad paramteres or something
[10:55] <persia> And that's really hard to debug *except* from inside.  Were I in that situation, I'd leave the VFAT partition alone.
[10:56] <persia> Potentially, but if you hadn't previously modified it, the chances are fairly low (or there would be many people complaining)
[10:57] <daurnimator> so; what do I do :P ?
[10:57] <persia> Well, did you try rewriting the SD card?
[10:58] <persia> If so, have you tried running fsck from the busybox prompt when you get the error?
[10:58] <daurnimator> not yet: use same method?
[10:58] <persia> May as well: it's a reasonable one.
[11:04] <daurnimator> does the blocksize matter/
[11:04] <persia> Yes, but.
[11:05] <persia> You want to pick a blocksize that is larger than the allocation unit of the storage medium, or you may end up requiring more allocation units than you would otherwise expect for naive implementations of storage allocation algorithms (unchangeable: built into the MMC implementation on the SD card)
[11:05] <daurnimator> but?
[11:07] <persia> You want to pick a blocksize that is smaller than any potential overflow buffer in the delivery pipeline.  Ideally, there aren't any, but using e.g. blocksizes larger than available RAM may cause issues in certain circumstances.
[11:07] <daurnimator> right.
[11:08] <persia> So, in practice, for relatively sane values of blocksize, it doesn't matter.  I usually use 1M or 4M, but there's lots of working values.
[11:11] <daurnimator> don
[11:11] <daurnimator> I don't suppose theres any issue with using an 8gb SDHC card?
[11:19] <daurnimator> ah turns out my download is corrupt
[11:30] <persia> Shouldn't be any issues with size: I've seen folk with 4, 8, 16.  Ah, excellent: the issue is identified.
[13:36] <daurnimator> gah
[13:36] <daurnimator> this download is corrupt too
[13:36] <daurnimator> anyone have a torrent or something?
[13:37] <daurnimator> the zsync thing also failed. downloaded the hole thing then aborted cause of a gzip error or something
[13:37] <daurnimator> *whole
[13:40] <persia> Ugh.
[13:40] <persia> I generally use rsync: in cases where I've had issues in the past, sometimes multiple runs sorts it.
[13:43] <daurnimator> persia: flail.
[13:44] <persia> Yep :)  Sorry I don't have any more constructive ideas.
=== GrueMaster_ is now known as GrueMaster