[00:00] <NCommander> twb: old names die hard
[00:00] <NCommander> twb: and thats a story that can only be told with loads of booze and a NDA :-/
[00:00] <twb> Ugh
[00:00]  * NCommander actually loved China TBH
[00:00] <twb> Embedded hw vendors need to get a damn clue
[00:00] <NCommander> I didn't like having four days notice going to china for a month
[00:01] <mythos> NCommander, i already read out those u-boot parameters and wondered about those ip-addresses...
[00:01] <twb> You managed to get a visa in four days?  Wow.
[00:01] <NCommander> twb: heh, I already had the visa
[00:01] <NCommander> Which was obtained for the same reason in the lucid cycle
[00:01] <twb> Are you a canonical flunky?
[00:01] <NCommander> twb: yes :-P
[00:02]  * twb adds NCommander to list
[00:02]  * NCommander is listed
[00:02] <NCommander> mythos: if you got the u-boot paramters, do you have the bootcmd the board uses?
[00:03] <NCommander> that might give me a better idea on a scale of 1-5 on how screwed you are
[00:03] <mythos> NCommander, i'm not sure
[00:03] <mythos> but i'm going to nopaste it
[00:03] <NCommander> how'd you fish out the uboot paramaters? I never got uboot-tools to work properly (granted, I didn't try very hard)
[00:05] <mythos> NCommander, http://pastebin.de/22381
[00:06] <mythos> i booted up up with a usb-device dded /dev/mtd1
[00:06] <NCommander> mythos: oh, so it boots off USB?
[00:06] <NCommander> Sounds like ytour less screwed
[00:06] <mythos> not quite stable, but yes
[00:07] <NCommander> But yeah, thats a completely custom boot command compared to what I wrote for Ubuntu
[00:08] <twb> NCommander: what'd you write, the u-boot script?
[00:08] <NCommander> twb: basically hacked the bootloader to do something sane
[00:09] <NCommander> it probes all devices on USB/SATA, and looks for a boot.scr, then chainloads into that
[00:09] <twb> I guess probing mtd as well was nontivial?
[00:09] <mythos> the device has no initrd... the init is on /dev/sda1 and chroots into a sqashfs-filesystem
[00:09] <NCommander> twb: we didn't support it
[00:09] <mythos> i never saw anything like that
[00:09] <NCommander> Still don't support it actually (installer limitation)
[00:10] <twb> As in d-i can't install to mtd?
[00:10] <NCommander> twb: yeah. Its getting support via ubifs, but that still requires bootloader support to some extent
[00:10] <twb> I thought ubuntu arm installs were all still "dd this image to <magic place> and hope for the best"
[00:10] <NCommander> No, we had live and alternate and netboot for Dove
[00:10] <twb> Cool
[00:10] <NCommander> Panda is a new type of image called a preinstall
[00:11]  * NCommander implemented that deeper voodo
[00:11] <NCommander> *voodoo
[00:11] <twb> "preinstall" sounds like dd-and-hope to me ;-P
[00:11] <GrueMaster> Pretty much.  The main idea was that beagle/panda boots from removable SD.
[00:12] <GrueMaster> And ubiquity has a hard time repartitioning and reimaging the device it boots from.
[00:12] <NCommander> twb: pandas can only boot from SD*
[00:12] <NCommander> * - technically USB too, but thats not useful for standalone systems
[00:12] <GrueMaster> No, that just is the secondary boot device.  It can also boot from USB-Gadget.
[00:13] <GrueMaster> And it can be modified to boot from other devices.
[00:13] <NCommander> GrueMaster: that's what I meant when I said can boot from USB
[00:13] <GrueMaster> But that requires a soldering iron and steady hand.
[00:13] <NCommander> it can't load its bootloader from USB :-P
[00:13] <twb> GrueMaster: that's because ubiquity doesn't run 100% out of ram like d-i does
[00:13] <twb> boo ubiquity, stupid GUI junk
[00:13] <NCommander> twb: you can run ubiquity in 364MiB
[00:14] <NCommander> We did that in jaunty for imx51
[00:14] <NCommander> (karmic too)
[00:14] <NCommander> and d-i can be a serious RAM hog if it can
[00:14] <GrueMaster> twb: It is more than just ubiquity.  The packages would also be on the boot device.
[00:14] <mythos> NCommander, so, if i plug a hdd on the board, it would be able to boot from that?
[00:14] <NCommander> (d-i will usually OoM if it doesn't have at least 128 MiB in total RAM+swap)
[00:14] <twb> NCommander: what I mean is if I bootload the d-i netboot kernel and initrd, then I can do the install and blow away the boot medium entirely
[00:15] <NCommander> twb: yes (with the cavet that the installer doesn't fully enforce panda's unique boot partition requirements)
[00:15] <twb> NCommander: admittedly, the initrd needs a driver for the NIC and you can't use wpa yet
[00:15] <NCommander> twb: no, we ship the NIC driver.
[00:15] <GrueMaster> twb: That is different.  You aren't installing packages from the boot device to the repartitioned boot device with netboot.
[00:15] <NCommander> twb: GrueMaster uses netboot all the time
[00:16] <twb> GrueMaster: right, but what I *do* do sometimes, is put netinst d-i in /boot, point grub at it, then blow away the boot disk with a fresh install
[00:16] <twb> ubiquity can't do that, which suck
[00:16] <twb> ...s
[00:17] <GrueMaster> twb: Do you know the kind of overhead to do ubiquity netboot?  Can't do that type of install on any Linux distro that I know of.
[00:17] <twb> Exactly
[00:18] <NCommander> twb: ubiquity is a serpate codebase from d-i that exists to copy a squashfs into target filesystem, even if you could load it over netboot, you'd still have to feed a squashfs to it
[00:18] <GrueMaster> ubiquity is X based.  So is the Redhat installer (name escapes me atm) and the Suse installer.
[00:18] <NCommander> twb: d-i is fully supported for those who want/need it (I always use d-i to reinstall my laptop)
[00:18] <NCommander> and we have d-i gtk-installer if you really want flashy graphics
[00:18] <NCommander> (though I don't think we build gtk-installer out of the box for ubuntu)
[00:19] <twb> You don't as at lucid, anyway
[00:19] <twb> (re gtk d-i)
 what compelled you to zero sda though? <-- i wanted to try, if it is able to boot after that. it did once, than it only beeps twice and does nothing
[00:19] <mythos> sorry, i had to read it five-times to understand, what you meant
[00:27] <GrueMaster> mythos: Wow.  I just downloaded the recovery image for your hp, and I am appalled at how they mucked it together.
[00:29] <GrueMaster> Essentially, it looks like you format a USB drive, unzip the contents to it and reboot on your PC (not the thin client) to the USB stick.  It will boot a small linux image that on init will reflash the usb drive with the thin client image (which itsself is based on our Maverick image).
[00:30] <mythos> yes
[00:31] <mythos> indeed i reversed it to that state
[00:31] <GrueMaster> If you want to speed up the process (and have less of a chance of clobbering your PC), use win32-image-writer.  It is a windows program designed for this purpose.
[00:31] <twb> This is why we have FOSS
[00:31] <twb> So that we don't need to deal with that kind of vendor bullshit
[00:33] <mythos> GrueMaster, i don't know for what the tool is for
[00:33] <mythos> GrueMaster, fdisk, mkfs.vfat and unzip is quite easy, so ^^"
[00:34] <GrueMaster> If you are on a windows pc and you want to flash the recovery image for your HP POS^h Thin client, use win32-image-writer to flash the recovery image to the usb stick instead of their muck-around.
[00:34] <GrueMaster> Yes, but then it requires you to reboot your PC to the usb stick.
[00:35] <GrueMaster> Why reboot your PC?
[00:35] <twb> It also requires that you still *ahve* an x86 pc
[00:36] <GrueMaster> There is a compressed image in their zipfile at images/Z5D40019.dd.gz.  Uncompress that, and use win32-image-writer (windows) or dd (linux) to write that raw image to a usb stick, put it in the thin client and boot.
[00:37] <GrueMaster> twb: Most companies deploying these thin clients will have PCs (usually laptops) for their IT support staff.
[00:38] <mythos> GrueMaster, to whom are you responsing. for me, it is like i have someone on ignore <.<
[00:38] <GrueMaster> These are mainly sold as kiosk or point of sale systems.
[00:38] <GrueMaster> mythos: I was replying to twb.
[00:38] <twb> I give all my support staff the same shitty thin clients as the prisoners
[00:38] <twb> FWIW
[00:39] <mythos> GrueMaster, hmm... ok... but i check my ignorelist anyway ^^"
[00:39] <twb> mythos: probably my anti-ubiquity ranting :-)
[00:40] <mythos> twb, maybe :o
[00:43] <GrueMaster> Sadly I don't have an ignorefile.  I have to go on the basis that even trolls need help sometimes.  :P
[00:45] <mythos> you are a very nice guy, with nervs out of steel, GrueMaster ^^"
[00:54] <mythos> oh lucky, this channel is logged
[00:54] <GrueMaster> yep
[00:55] <mythos> then i don't need the verfification-client anymore
[01:11] <mythos> hmm... the initrd in this dove-image http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/release/ (inside the squashfs) is a dead link
[01:11] <GrueMaster> Yes, it is generated on install.
[01:12] <mythos> ok
[01:13] <mythos> but one question, if you don't mind
[01:13] <mythos> how is this "/casper/uInitrd: u-boot/PPCBoot image" created and is it modifyable?
[01:14] <GrueMaster> I'm listening (responding is still optional).  :P
[01:14] <mythos> *g
[01:14] <GrueMaster> The image was generated with our live-cd tools back when we were making them.
[01:14] <GrueMaster> I think we have moved to a new tool base now.
[01:15] <GrueMaster> As to modifying it, what needs to be modified?
[01:15] <mythos> i only want to look inside =)
[01:15] <GrueMaster> it's possible, but not easy.
[01:15] <GrueMaster> Ah.
[01:16] <GrueMaster> I have scripts for that.
[01:17] <mythos> if you give me some hints, i'm going to study it for myself =)
[01:17] <GrueMaster> mkdir initrd
[01:17] <GrueMaster> dd if=$1 skip=64 bs=1|zcat | (cd initrd;sudo cpio -id)
[01:17] <mythos> oh, that helps a lot, thx
[01:18] <GrueMaster> That "may" work.  Depends on how much u-boot header cruft is in the uInitrd and also if the initrd is gzipped.
[01:19] <GrueMaster> I've seen the header be as much as 72 bytes (skip=72) so play with it.  Make a backup first.
[01:21] <mythos> ok
[01:22] <mythos> nice, thanks =)
[01:23] <twb> Is there a functional difference between uinitrd and a normal initrd?
[01:23] <twb> Because if not the obvious way to build uinitrd (for boot, not install) would be update-initramfs
[01:24] <GrueMaster> twb: uInitrd are checksum signed for u-boot.
[01:25] <GrueMaster> same with uImage and boot.scr
[01:25] <twb> Ah, OK.
[01:26] <twb> How does u-boot know which key to check it against?  Wouldn't that be device/vendor specific?
[01:26] <GrueMaster> twb it is a checksum, not a signed key.
[01:27] <GrueMaster> Although it can be signed by the vendor (aka locked boot).
[01:27] <twb> Ah, I misunderstood.  I thought you were saying it generated a checksum and then signed that, or something
[01:27] <GrueMaster> No, it generates a checksum of the file and attaches it in a 64 byte header.
[01:28] <twb> You know how you can tell the kernel (at compile time) "tack this initrd onto yourself" ?  Can you do that post-compile?
[01:29] <GrueMaster> It can also generate a key signature that u-boot has built in so that vendors can lock users from rooting their devices (so far we're smart enough to get around that in most cases).
[01:30] <GrueMaster> Not sure.  I know aboot can do that.  That is how I boot panda w/o SD.  I use abootimg to combine kernel, initrd, and boot args into a single blob that I push down with a usbboot utility on the host system.
[01:30] <twb> Doesn't "get around it" usually involve exploiting bugs in their bootloader?
[01:32] <GrueMaster> Not sure.  I don't work that end personally.
[01:40] <AdamOutler> LetoThe2nd, I have performed step 1.
[01:41] <AdamOutler> I'm not sure about 2 and 3...  2)make sure the bootloader passes this ID 3) make sure the kernel contains a board support file bound to this id.
[01:44] <mythos> GrueMaster, it's lzma, thank you very much \o/
[01:44] <GrueMaster> You're welcome.  I'm off for now.
[01:44] <mythos> have a nice day
[11:43] <Riddell> infinity: are you a good person to ask about how to get an arm build with extra swap for qtwebkit?
[11:52] <infinity> Riddell: See -devel.
[13:05] <Spider-Pork> Hi. I'm using my panda rev A3 with kubuntu-desktop, installed with netboot. Board was compiling xbmc, suddenly it freezed. Through ssh connection i got this dmesg output https://ideone.com/GEKEq. Any idea? Thank you
[13:31] <ogra_> are you using an USB disk for your rootfs ?
[13:36] <Spider-Pork> yep ogra_
[13:36] <Spider-Pork> is an adaptor for IDE disk
[13:38] <ogra_> well, eth0 is a usb device as well, looks a bit like an issue with the host controller or its driver, file a bug against linux-omap4 with the data from your pastebin
[13:39] <Spider-Pork> ok thank you ogra_. Where I should post bug?
[13:39] <ogra_> see channel topic ;)
[13:40] <ogra_> or just use "ubuntu-bug linux-omap4" in a terminal
[13:41] <Spider-Pork> ok thank you again ogra_
[13:51] <ndec> ogra_: hi. i tried to upload a pkg with Arch = any-arm on our PPA, and the upload was rejected with "Cannot build any of the architectures requested: any-arm". is that expected?
[13:51] <ogra_> what would you expect "any-arm" to be ?
[13:52] <ndec> it uses the any-cpu convention from debian policy
[13:52] <ndec> it works with dpkg-buildpackage
[13:52]  * ogra_ never heard of it ... infinity ?? 
[13:52] <ndec> it would be any arch that is based on arm. so armel or armhf
[13:52] <ogra_> i would just put "armel armhf" in that field
[13:53] <ndec> sure, that works... but any-arm should work too ;-)
[13:53] <ndec> based on my understanding.
[13:53] <ndec> with any-arm, i can build locally with dpkg-buildpackage from a armel or armhf root fs
[13:53] <ogra_> well, as i said, i never head about that ...
[13:54] <ogra_> probably ask in #ubuntu-devel
[13:54] <ogra_> there might be people that have used it and are brighter than me ;)
[13:55] <ndec> ogra_: so i saw that you enabled armhf on tiomap-dev/release, can you also do it for all other PPA from tiomap-dev team?
[13:55] <ogra_> i can ask :)
[13:55] <ndec> thx
[13:55] <ogra_> will take a few days
[13:55] <ndec> sure
[14:01] <ogra_> ndec, btw dpkg-architecture -L should list all valid options for the Architecture field
[14:03] <ndec> ogra_: any-arm is indeed not listed. however the policy mentions 'architecture wildcard', http://www.debian.org/doc/debian-policy/ch-customized-programs.html
[14:06] <ogra_> ndec, well, there is a footnote (88)
[14:07] <ndec> yes, but this isn't very clear to me...
[14:07] <ogra_> i think our triplet uses armel and armhf in the end ... so arm wouldnt match if any-<arch> is a normalization of the triplet string
[14:08] <ogra_> as i said, better ask someone that knows more about it than me, but to me it appears that with the hf and el endings for our arch names any-arm cant work
[15:17] <sveinse> Are there any debian/ubuntu based busybox which can be compiled for armel?
[15:18] <ogra_> can you elaborate ?
[15:18] <ogra_> we have a bunch of busybox binary packages in ubuntu
[15:18] <sveinse> I'm investigating to make a small recovery partition, and need to execute a small script with mke2fs, tar and chroot
[15:18] <ogra_> just roll an initramfs with these included (hint: readf up about initamfs-tools)
[15:19] <sveinse> The selection of which initramfs can be controlled from the kernel parameter line, yes?
[15:20] <sveinse> Yes... It's loaded by u-boot, not the kernel nor init
[15:20] <ogra_> no, the tools to roll an initrd
[15:20] <sveinse> Well, then I have something to work on, thanks!
[15:20] <ogra_> you can add hooks to an ubuntu initrd and make it just include the binarties from the rootfs you like
[15:21] <ogra_> like mkfs and friends (chroot is in there by default already i think)
[15:23] <sveinse> ( I plan to put a small tarball with a minimal bootstrap image and a set of debs on a separate partition. The recovery process will then be to mke2fs root partition, unzip the tarball into the partition, chroot into it and install the rest of the debs )
[15:24] <sveinse> The boot partition holding the kernel image and/or the initrd for recovery is untouched by this
[15:39] <ndec> ogra_: so where should i open the bug? on the 'launchpad' project directly?
[15:40] <ogra_> look if there is a soyuz project, else just start with LP and leave it to the LP team to move it to the right component
[17:31] <ogra_> ndec, is GLES support affected by any of that syslink stuff you mention in your mail ? ppisati and i were just discussion in the kernel channel
[17:32] <ogra_> ndec, i dont mind having another release without mm support but we cant afford not shipping GLEs after all that work that went into unity GLES porting ... and by the looks of it ubuntu wont easily accept 3.3
[17:33] <ogra_> s/discussion/discussing/
[17:34] <ogra_> rsalveti, ^^^ any idea ?
[18:00] <rsalveti> ogra_: I don't think sgx would be a problem
[18:00] <rsalveti> with 3.2 or with 3.3
[18:00] <rsalveti> and something the lt can help fixing if if doesn't work
[18:01] <rsalveti> the syslink one is more complicated, because it's on top of another version, and a lot is happening at the kernel side
[18:01] <rsalveti> but for sgx it's an dkms package
[18:29] <ogra_> rsalveti, right, i thought so, ubuntu shipped with non working (existing)  MM stack before, i guess we can do that again, even if its not great
[18:39] <rsalveti> ogra_: yup
[20:24] <AdamOutler_> HI!
[20:25] <AdamOutler_> Something is blocking my access to Serial Console.  I can see output, but I cannot use the terminal.   I tried this: http://www.debuntu.org/how-to-set-up-a-serial-console-on-ubuntu  I have root access through RCS.d, so I can run anything.   what can I do to make my terminal start working again?
[20:26] <AdamOutler_> The terminal must be blocked by something..  I just don't know what.
[20:50] <AdamOutler_> any ideas?  I need a console.  I was able to get it once from /dev/ttyO2 on my UART.
[20:52] <GrueMaster> AdamOutler_: What image are you using?
[20:53] <AdamOutler_> GrueMaster, Texas Instruments, Blaze board,   on a device based on Blaze Board.
[20:54] <GrueMaster> ubuntu desktop image?
[20:54] <GrueMaster> You might not have /etc/init/ttyO2.conf for serial console.
[20:55] <AdamOutler_> yes.
[20:55] <AdamOutler_> I have prepared a ttyO2.conf, I also created the /dev/ttyO2 device.
[20:56] <AdamOutler_> I see dmesg output, but not Console.
[20:56] <GrueMaster> Not sure.  I haven't tested on a blaze in ages.
[20:56] <AdamOutler_> GrueMaster, maybe you can pastebin an OMAP ttyO2?
[20:56] <GrueMaster> You shouldn't need to create the ttyO2 device.
[20:57] <AdamOutler_> it was not there by default.
[20:57] <GrueMaster> Hmm.  I would check dmesg or syslog then to see if the kernel is detecting a serial port.
[20:57] <GrueMaster> Which kernel?
[20:59] <GrueMaster> My /etc/init/ttyO2.conf looks the same as the rest of the tty*.conf files, except the exec line is "exec /sbin/getty -L ttyO2 115200 vt102".  But if your system isn't detecting the serial port this is moot.
[21:11] <AdamOutler_> kernel for this device.
[21:11] <AdamOutler_> this kernel supports ttyO2 as a shell GrueMaster
[21:12] <AdamOutler_> hrm.. i'm using vt100  I'll try that.
[21:12] <GrueMaster> ttyO2 as a shell?  Maybe a console, but not a shell.
[21:13] <AdamOutler_> yeah, sorry..
[21:14] <AdamOutler_> GrueMaster, can you ls -l /dev/ttyO2 for me?
[21:14] <AdamOutler_> I have CRW-RW-RW
[21:15] <GrueMaster> crw------- 1 ubuntu tty 249, 2 2012-01-17 13:14 /dev/ttyO2
[21:15] <GrueMaster> udev should have created it on boot.
[21:15] <AdamOutler_> I created mine manually.  I'll try deleting it.
[21:16] <AdamOutler_> mknod ./ ttyO2 247 2
[21:16] <AdamOutler_> mine is a 247 when running under ubuntu.
[21:16] <AdamOutler_> er.. Android.
[21:17] <GrueMaster> I don't work with android here, so I won't be able to help.
[21:17] <AdamOutler_> understood.
[21:17] <AdamOutler_> I'm working with Ubuntu now.
[21:27] <AdamOutler_> GrueMaster, I put the following hack into my RC.local
[21:27] <AdamOutler_> while true
[21:27] <AdamOutler_> do
[21:27] <AdamOutler_>  exec /sbin/getty -L ttyO2 115200 vt102
[21:27] <AdamOutler_> done
[21:27] <AdamOutler_> it's still not working.
[21:28] <GrueMaster> Can you type "dmesg|fgrep ttyO2" and see what comes up?
[21:28] <GrueMaster> (or fgrep ttyO2 /var/log/syslog)
[21:29] <GrueMaster> I have a feeling the device isn't being configured.
[21:30] <AdamOutler_> I just booted without a device created, no change, I'm making a 249 device.
[21:30] <AdamOutler_> omap-hsuart.2: ttyO2 at MMIO 0x48020000 (irq = 106) is a OMAP UART2
[21:31] <GrueMaster> Ok, that is correct.  When the system boots, it should have a /dev/ttyO2 device already created by udev.
[21:34] <AdamOutler_> here's something interesting... I did an ls -l /dev/ttyO* and a  dmesg|fgrep ttyO
[21:34] <AdamOutler_> crw-rw---- 1 root dialout 247, 0 Jan 17 21:34 /dev/ttyO0
[21:34] <AdamOutler_> crw-rw---- 1 root dialout 247, 1 Jan 17 21:34 /dev/ttyO1
[21:34] <AdamOutler_> crw-rw---- 1 root dialout 247, 2 Jan 17 21:34 /dev/ttyO2
[21:34] <AdamOutler_> crw-rw---- 1 root dialout 247, 3 Jan 17 21:34 /dev/ttyO3
[21:34] <AdamOutler_> omap-hsuart.0: ttyO0 at MMIO 0x4806a000 (irq = 104) is a OMAP UART0
[21:34] <AdamOutler_> console [ttyO0] enabled
[21:34] <AdamOutler_> omap-hsuart.1: ttyO1 at MMIO 0x4806c000 (irq = 105) is a OMAP UART1
[21:34] <AdamOutler_> omap-hsuart.2: ttyO2 at MMIO 0x48020000 (irq = 106) is a OMAP UART2
[21:34] <AdamOutler_> omap-hsuart.3: ttyO3 at MMIO 0x4806e000 (irq = 102) is a OMAP UART3
[21:35] <AdamOutler_> my console is on ttyO0...  maybe I can hack it with a rm /dev/ttyO2;ln -P /dev/ttyO0 /dev/ttyO2;
[21:36] <GrueMaster> That is interesting.  I'd just create a /etc/init/ttyO0.conf and call it good.
[21:36] <AdamOutler_> that does not explain why my uart would be ported to ttyO0 and not be able to go to ttyO2...  it's odd
[21:37] <AdamOutler_> You can have multiple consoles correct? or is that wrong?
[21:38] <GrueMaster> Your device is creating multiple serial ports, but they aren't visible to the host pc.  Only one is (ttyO0 in this case).
[21:39] <AdamOutler_> GrueMaster, any ideas on that?
[21:39] <AdamOutler_> what did you mean by create an /etc/init/ttyO0.conf?
[21:40] <GrueMaster> Copy the /etc/init/ttyO2.conf file to /etc/init/ttyO0.conf, and edit the new copy to make sure it points to ttyO0.
[21:41] <AdamOutler_> but I'm monitoring on ttyO2.
[21:41] <AdamOutler_> by doing a symlink from ttyO0 to ttyO2 I was able to get a shell prompt
[21:43] <GrueMaster> I'll have to dig out my blaze and try.  I haven't worked with it since Natty (11.04), so I won't be much help until then.
[21:43] <GrueMaster> Which ubuntu release are you running on it?
[21:49] <AdamOutler_> 11.10
[21:49] <AdamOutler_> I think I have it now.
[21:49] <AdamOutler_> I just linked O2 back to the active O0 terminal
[21:49] <GrueMaster> Ok, I will try it shortly.