[00:38] i would assume 0x000000, but surely the whitepapers address that === sparq_ is now known as sparq [09:48] Aside from the Beagleboard, does anyone have a nifty ARM board? [09:51] I remember some years ago, there was a sort of nifty MIPS mini-desktop thingy (the Qube, I think), but they got bought by Sun and kind of vanished. [09:56] The gumstix overo has gotten a couple comments lately. [09:57] you mean the cfobalt cube ... that wasnt a desktop machine [09:57] *cobalt [09:58] http://en.wikipedia.org/wiki/Cobalt_Qube [09:59] sparq: sheevaplug ? there is also literally thousands of nifty arm boards out there :) [10:00] There's also a heap of NAS boxes of various flavours, some of which have interesting features (e.g. RAM slot or PCIe slot). [12:38] I'm trying to use apt on an arm system but I'm getting : E: Unable to determine a suitable packaging system type [12:39] any idea what determines the packaging system type ? :) [12:58] kbingham, I think it's Apt::System from the apt configuration. [12:58] I've just been looking in apt/apt-pkg/init.cc (which generates the error), but I can't really understand why it might occur. [12:59] yes - i've just got to init.cc after a google ... [12:59] I suspect that you're not running an Ubuntu rootfs, but I'm not cool enough to understand why it might fail. [12:59] no - i tried an ubuntu fs and too many things were getting in the way to boot up [12:59] so i thought drop back to the original fs - and just copy over the /etc/apt [13:00] idea being that i would be able to apt-get install packages ... [13:00] but allas i think i was trying to be too simple. [13:01] Yeah. Just a bit. [13:01] What sort of issues were you encountering trying to boot? [13:03] it was stopping during the rc stuff [13:03] so then i tried appending init=/bin/sh to the kernel line and it just hung [13:03] dm355 evm board by the way - 300mhz arm. [13:03] Did you construct an ubuntu initramfs, and feed it that? [13:04] (and also, did you have a kernel that can use an initramfs?) [13:04] this is a 2.6.18 kernel [13:05] 2.6.18 is capable of initramfs, but it's a compile-time choice. [13:05] where does the initramfs come in ? [13:05] And I'm not sure if that version has all the syscalls Jaunty might expect. [13:05] why does it need it [13:05] I'll take those in reverse order :) [13:06] :) [13:06] It needs it because the system is designed to come up flexibly to support lots of different use cases. [13:06] sounds reasonable :) [13:06] So someone might need to get the network working before they have access to secondary storage, or someone might need to load special modules before they can access some device, etc. [13:07] this is nfsboot by the way ... [13:07] so network is up before filesystem starts loading... [13:08] the boot scripts wouldn't disable/reconfigure the ifconfigs would they perhaps ... [13:08] hmmm [13:08] How it works is that the kernel loads, and rather than trying to load some known device as root, it loads the initramfs as a ramfs, does more stuff (e.g. starting the network, loading modules, etc.), and then it does a pivot_root to some real root filesystem, and then completes the startup. [13:08] This way there is a complete (if very minimal) userspace to handle special stuff before it starts mounting devices, etc. [13:09] hmmm - where does this happen - i guess i can just strip it out .. ? [13:09] stripping it out would be tricky. [13:09] my kernel has all drivers required for the boot built in [13:10] Well, except you get a hang with init=/bin/sh [13:10] Which means something isn't there. Hard to say what. It's unlikely to be an actual problem with /bin/sh. more likely something about loading the rootfs or initialising the console, etc. [13:10] try /bin/bash instead [13:11] ogra, You think it's really a problem with dash? [13:11] I'd think it was more likely to be an issue with udev interaction and the console, or something like that. [13:11] there are some env vars that arent being hardcoded in dash iirc [13:12] at which rc script does the normal boot stop ? [13:12] ogra : that worked :) [13:13] a normal boot should work as well though [13:14] perhaps its just hiddeously slow [13:14] i'd left it for 5 minutes before thinking it had stalled -perhaps it needs longer [13:14] i rather think your kernel might miss options [13:15] or has some misconfiguration [13:15] ogra: what comes to mind? my other filesystem boots fine? [13:15] apparmor and procps are typical candidates [13:15] but of course that was designed for it :) [13:15] well, where exactly does it stop ? [13:16] whats the last message you see when booting [13:16] hangon - played round lots since then - i'll scan up the serial logs [13:22] [ OK ]ivating swap... [13:22] * Checking file systems... fsck 1.41.4 (27-Jan-2009) [13:22] [ OK ] [13:22] [ OK ]nting local filesystems... [13:22] [ OK ]ivating swapfile swap... [13:22] [ OK ]figuring network interfaces... [13:22] [ OK ]ting up console font and keymap... [13:22] [ OK ]rting system log daemon... [13:22] [ OK ]rting kernel log daemon... [13:23] this was an ubuntu-minimal build from build-arm-rootfs [13:23] mv /etc/rc2.d/S50klogd /etc/rc2.d/K50klogd [13:23] try that if you are logged in with init=/bin/bash [13:24] i can do it on the host [13:24] and then try a normal boot [13:24] well, then that [13:24] if that works tickle amitk until he tells you why the kernel logging doesnt work :P [13:25] ok - rebooting now - it wsa S11klogd though [13:26] oh, k [13:27] its 50 here [13:27] odd!? [13:27] shouldn't matter too much though :) [13:27] right [13:27] some of the stages are really slow ... wait ... [13:27] [ OK ]rting system log daemon... [13:27] [ OK ]rting kernel log daemon... [13:27] hehe [13:28] its in rc3.d too [13:29] doesnt matter, it defaults to rc2 [13:29] hmm ok - then i did something else wrong ... [13:34] theres also S10sysklogd -> ../init.d/sysklogd [13:34] is that the same/different? [13:34] move it for a test :) [13:34] after this boot cycle [13:34] it takes a long time on setting preliminary keymap :S [13:34] sysklogd doesnt print the "Starting kernel log daemon..." msg though [13:36] and setting up console font and keymap also takes a long time ... [13:36] thats normal [13:36] at least on very low power systems [13:36] ok - so this time definitely without klogd [13:36] [ OK ]figuring network interfaces... [13:36] [ OK ]ting up console font and keymap... [13:36] [ OK ]rting system log daemon... [13:36] so i'm gunna say its whatever comes after the klogd :) [13:36] i see S70bootlogs.sh [13:38] well, most of that are no-ops anyway [13:38] oh, wait, you work on a serial console ? [13:38] .... yes [13:38] did you configure upstart to spawn a serial tty even ? [13:38] on the basis of i don't konw the answer to your question - i'll say no :) [13:38] ah [13:38] well, then move back your klogd ... it wasnt hanging [13:38] just switchin to VT ? [13:38] :) [13:38] ok - where do i configure upstart ... [13:40] cp /etc/event.d/tty1 /etc/event.d/ttyS0 [13:40] edit the respawn line to point to your serial tty [13:40] something like: respawn /sbin/getty -L ttyS0 9600 vt100 [13:40] (or whichever is your serial device: some people need /etc/event.d/ttyUSB0, etc. [13:40] yeah [13:40] your system was booting fine, you would have had a tty on a LCD screen or vga [13:40] ttyS0 it is :) thanks :) [13:40] just not on the serial console [13:40] hmmm nope - no output [13:40] i assume it goes to /dev/fb0 ? [13:43] to /dev/console [13:43] hmmm yeah that probably doesn't go far :) [13:43] You might be able to pass console= to the kernel on boot. [13:43] you indeed need the proper console line in your kernel args too [13:43] my console=/dev/ttyS0 [13:43] no other console option ? [13:43] Kernel command line: console=ttyS0,115200n8 ip=dhcp root=/dev/nfs rw nfsroot=10.150.16.29:/opt/root/davinci/ubuntu/,nolock mem=116M video=davincifb:vid0=0,2500K:vid1=0,2500K:osd0=l [13:46] can i remove keyboard-setup and console-setup from init as they take >30 seconds to pass ? [13:46] (ps... i now have console :) ) [13:46] [ OK ]rting kernel log daemon... [13:46] Ubuntu 9.04 mpc-dm355 ttyS0 [13:46] mpc-dm355 login: [13:46] :) [13:51] hmm just need to fix up my users. [13:51] would seem i used -l admin -p admin - and it didn't like that on the build-arm-rootfs script [13:51] init=/dev/bash followed by a useradd i think :) [13:53] ahem ; s/dev/bin/ :) [14:00] everytime i boot it tells me i have to change the password. How do i stop it? [14:01] admin is a reserved groupname [14:02] ahh ok :) [14:08] hmmm no - every account is expiring passwords almost immediatly .. ? [14:08] ohhh wait [14:08] that might be becuase the time on the board is many years out or soemthing silly [14:08] jan-1 1970 :) [14:08] hehe [14:08] would that make passwords expire? [14:08] not with the recent jaunty [14:08] ? you say that like it would have done before ? [14:08] there was a bug with the date and pw expiriy but that was fixed before final [14:08] hmmm am i maybe on an old version ? [14:08] becuase my init script files were different too :) [14:08] yeah, smells a bit like, when did you bui#ld the rootfs ? [14:08] today :) [14:08] i did a wget http://people.ubuntu.com/~ogra/arm/build-arm-rootfs [14:09] thats fine ... [14:09] its not the script that has the bug [14:09] it was the passwd binary [14:13] do you know what package passwd is in ? [14:13] i'll try and see what version i'm on [14:13] i think it was the shadow package, NCommander did the fix [14:13] but that package comes from the archive in the fixed version [14:13] do you use some local mirror ? [14:13] i simply ran your build-arm-rootfs script [14:16] yes, that defaults to ports.ubuntu.com [14:16] it might be realted to you using the username "admin" [14:17] no - i've created a new user dm355 [14:17] ? [14:17] hmmm though ... [14:17] afterwards you did :) [14:17] indeed :) [14:17] ogra, yeah, it was a bug in how user creation is handled on misset clocks [14:17] right [14:17] anyway to analyse if this is it ? [14:17] i havent had it on any of my builds, no matter how the clock was set [14:19] argh. [14:19] ok - i think my user accounts are really scrwed :) [14:19] as user admin - i did useradd dm355 [14:19] but of course dm355 isn't in sudoers and i can't su :( [14:19] hehe [14:20] never ever use useradd manually [14:20] use adduser [14:20] oh well - back to init=/bin/bash :) [14:20] ogra: noted :) [14:26] is it possible to remove the password enforcment? [14:26] or remove passwords altogether [14:26] I don't need one :) [14:27] i deleted the dm355 account and admin account - then re-created using adduser [14:27] but its still expiring :S [14:35] NCommander: even root is being told to change the password :( [15:09] kbingham, try setting your ARM's clock. This should be fixed though [15:09] have set resolv.conf and added ntpdate-debian & to rc.local :) [15:09] (clock isn't held through reboots) [15:10] NCommander: just to check the obvious - am I on the correct passwd (if that the app thats affected) [15:10] e514c60293dad2e1ad0599950d250e39 /usr/bin/passwd [15:10] kbingham, I can't check at the moment, but as long as your running a jaunty newer than Beta 1-2, your ok [15:10] I haven't got a clue what jaunty it is - its just whatever was built with the build- script [15:10] no worries though [18:05] https://launchpad.net/ubuntu/jaunty/armel/mjpegtools/1:1.9.0-0.0 seems to be stating armel supports mjpegtools - but it wasn't seemingly available by apt-get in my armel rootfs ... do I need to add a different repository other than ports.ubuntu.com to get this support ? [18:19] kbingham, You need to enable multiverse in your /etc/apt/sources.list [18:19] bah - easy as that - figures - thanks persia [18:20] kbingham, On the LP pages like that, there's a "Component" entry. Just make sure your components list includes it if you want to see that package. [18:21] ahh i see it now :) thanks [18:21] Be aware that things in universe may have licenses that prohibit source modifications, prohibit commercial use, prohibit use for specific purposes (e.g. military), have patent restrictions in some jurisdictions, prohibit distributing compiled source, or many other things. [18:22] Before using the package, you'll want to read /usr/share/doc/${packagename}/copyright to find out what license you're accepting when you use it. [18:22] All of it is free to redistribute, but that's about the only guarantee. [18:22] Err, things in *multiverse* [18:22] ahh free to distribute is different from free to use then :) [18:22] universe is all free software. [18:23] kbingham, Sometimes. For example, I might write a program and require anyone who uses it to send me a postcard. [18:23] I can also allow anyone to distribute it. [18:23] This is free for redistribution, so it can be mirrored, but anyone who actually uses it needs to send me a postcard. [18:24] (most stuff of this class has been fixed to request that users send postcards, rather than require it, but there's still a bit left) [18:25] Or I might write a tracking and guidance system, and feel it should only be used for model rocket enthusiasts, and not for cruise missles. [18:26] hehe [18:28] These are actual examples of licenses :) There's all sorts of nifty stuff there. [18:29] One of my favorites is an implementation of an old Atari Game, where the authors secured permission to use the original art & music, but were unable to secure permission to change it in any way. [18:30] So it can be mirrored, and used, but the spelling errors can never be fixed. [18:35] hehe [18:35] oh i managed to get my apt-get working on my existing filesystem [18:35] copied over var/lib/dpkg, var/lib/apt, var/lib/aptitude over whatever was already there [18:36] now i dont' get the "unable to determine suitable packaging system type" error [18:37] if this works then no more crappy cross-compiler errors for me :) [19:11] hi guys [19:11] question [19:11] i got jaunty running on omap3evm [19:11] what would be the simplest way to get some gui going [19:11] ? [19:17] dmt0, apt-get install xubuntu-desktop ? [19:17] Or kubuntu-desktop, or ubuntu-desktop ? [19:18] (really depends on which gui you want) [19:18] basically my goal is just to demo any gui software piece [19:19] not necessarily the whole environment [19:19] dmt0, Well, easiest way is to install one of the desktop metapackages. [19:19] Hard way is to install the X server, and then install the stuff you want to demo, and then install whatever you need to make sure you get an X session. [19:19] in my current setup i don't have enough space for xubuntu desktop [19:19] i have a 2GB flash card here [19:20] i see [19:20] ok, let's try the hard way [19:20] thanks persia )) [19:21] Good luck :) === bradf is now known as bradf__afk [23:03] hey guys [23:04] jaunty on omap3evm [23:04] what should xorg.conf contain? [23:04] i'm trying to startxfce4, get one error [23:04] FBIOBLANK: invalid argument [23:05] cursor appears, touchscreen works [23:05] and than x freezes [23:05] has than been seen before? [23:08] Yep. I have the same problem on my EVM board [23:08] Both on the OMAP2 and OMAP3 [23:08] I'm working on the issue now [23:11] cool