| pnphi | How choice RAM of qemu-system-arm | 02:01 |
|---|---|---|
| mythos | pnphi, qemu-system-arm -m 256 -append "mem=256M ..." <-- do you want to specifiy how much ram is available? | 02:06 |
| pnphi | i want > 256 | 02:06 |
| pnphi | more ? | 02:06 |
| mythos | results in segfaults, as far as i know | 02:07 |
| pnphi | what is segfaults ? | 02:07 |
| mythos | pnphi, http://en.wikipedia.org/wiki/Segfault | 02:08 |
| twb | You could use qemu-arm-static instead and just run it in a chroot instead of with a separate arm kernel | 02:20 |
| twb | Then you'd have access to the entire host system's ram | 02:20 |
| pnphi | how to change Memory of qemu-system-arm ? ? more 256 ?? | 02:22 |
| === Jack87|Away is now known as Jack87 | ||
| steev_ | is there any way to get rid of the 'Gtk-Warning **: Unable to locate theme engine in module_path: "pixmap",' messages? I can't seem to find the pixmap engine | 04:00 |
| steev_ | i thought it was part of gtk2-engines, but that is already installed | 04:02 |
| steev_ | aha, it's gtk2-engines-pixbuf (why is it called pixbuf when it installs libpixmap.so ?) | 04:03 |
| twb | steev_: hysterical raisins | 04:05 |
| twb | You should not need that driver unless you're using a very silly and inefficient GTK theme, though | 04:05 |
| steev_ | twb: well i'm running arduino, though there are a few other apps that pop up the messages that get installed by ubuntu-desktop | 04:06 |
| twb | Specifically, one that works by stretching small images (usually 2x2) to fake gradients. | 04:06 |
| steev_ | and it's using the defaults | 04:06 |
| twb | steev_: interesting | 04:06 |
| lilstevie | even chromium shows that | 04:07 |
| lilstevie | on x86 | 04:07 |
| twb | You could try something like echo 'gtk-theme-name = "Raleigh"' >> ~/.gtkrc-2.0 | 04:07 |
| twb | Although gnome will cause that dotfile to be ignored :-/ | 04:08 |
| lilstevie | steev, I wouldn't be overly concerned | 04:08 |
| twb | Hmm, on oneiric I don't have gtk2-engines-pixbuf, I do have libgdk-pixbuf2.0-0, I do not get that warning AFAIK | 04:08 |
| twb | http://cyber.com.au/~twb/.gtkrc-2.0 is my GTK2 theme | 04:09 |
| twb | Using epdfview and midori GTK2+ apps, but no gnome | 04:09 |
| steev_ | twb: this is on a precise armhf install from -core, apt-get installed minimal, standard, desktop, then adding a few special things | 04:09 |
| steev_ | namely our ancient efika kernel (we're working on a new one, i swear) | 04:10 |
| twb | Well, suffice to say that it WFM without that warning and without that .so, so it is apparently POSSIBLE to avoid the warning | 04:10 |
| steev_ | i haven't changed anything from the defaults (except editing /usr/bin/ubiquity to change oom_score_adj to oom_adj otherwise ubiquity dies, and deleting the /usr/share/applications/ubiquity-gtkui.desktop file because I was tired of seeing Install RELEASE in my sidebar) | 04:11 |
| lilstevie | steve@steve-tf201:~/Downloads$ chromium-browser | 04:12 |
| lilstevie | (chromium-browser:4567): Gtk-WARNING **: Unable to locate theme engine in module_path: "pixmap", | 04:12 |
| twb | lilstevie: is gnome-settings-daemon running? | 04:12 |
| lilstevie | that is on oneiric-armel | 04:12 |
| lilstevie | 1259 ? Sl 0:16 /usr/lib/gnome-settings-daemon/gnome-settings-daemon | 04:13 |
| twb | That's why | 04:13 |
| lilstevie | heh | 04:13 |
| twb | It causes all your dotfiles to be ignored and overridden by gconf | 04:13 |
| twb | So whatever silly pixmap-based theme you're using, is not mentioned in .gtkrc-2.0 | 04:14 |
| twb | You may find changing your theme to (e.g.) raleigh in GNOME's control center, causes the warning to go away | 04:14 |
| steev_ | i haven't bothered to look in precise, i'm okay with installing pixbuf, it's all of one file and like 4 docs | 04:15 |
| twb | Indeed, but using it will increase (probably significantly) the bandwidth consumed between X server and apps | 04:16 |
| lilstevie | in any case, it is only a warning | 04:16 |
| twb | And also it's a stupid ugly irresponsible design :-/ | 04:16 |
| twb | lilstevie: right | 04:16 |
| twb | lilstevie: although not loading that driver basically means you get a GTK theme that looks different | 04:17 |
| lilstevie | twb, well this is an out of the box configured install | 04:17 |
| lilstevie | and same as on my desktop | 04:18 |
| lilstevie | same deal there too | 04:18 |
| lilstevie | :p | 04:18 |
| twb | Then I guess ubuntu's default theme is silly and asks for a feature it doesn't install by default | 04:18 |
| lilstevie | so maybe it needs a bugreport | 04:18 |
| twb | I agree | 04:18 |
| steev_ | i'll let twb file it and get the karma | 04:20 |
| lilstevie | yep twb can have it :p | 04:20 |
| lilstevie | I don't care enough to file a bug report | 04:20 |
| lilstevie | :p | 04:20 |
| twb | I can't even reproduce your silly problem, so I won't report it | 04:21 |
| lilstevie | if(WARNING){ ignore;} | 04:21 |
| twb | Also I have a policy on not reporting problems to launchpad because it isn't debbugs | 04:21 |
| lilstevie | twb, heh you can't reproduce it because you are silly and use xinit | 04:21 |
| twb | If you mean I don't waste time starting X when I don't need it, sure | 04:23 |
| lilstevie | well samsung repair man be here | 04:24 |
| lilstevie | later | 04:24 |
| * twb struggles to turn that into a joke | 04:24 | |
| === Jack87 is now known as Jack87|Away | ||
| recur | from make, is there a way to force use of a different linker? | 06:02 |
| twb | make LD=gold | 06:02 |
| twb | Of course that assumes your make rules aren't silly | 06:03 |
| recur | ah interesting, it's still using the wrong one when I pass that | 06:03 |
| recur | I'm trying to crosscompile libpng | 06:03 |
| recur | I'll take a look at the make rules, tahnks :) | 06:03 |
| twb | Cross-compiling is a whole extra ballgame, one with which I am less familiar | 06:03 |
| twb | Hmm, default gmake rules actually don't call LD, they call CC or FC with linker options | 06:04 |
| twb | http://paste.debian.net/158723/ | 06:05 |
| recur | ohh, hmm | 06:05 |
| twb | Suggest you find someone good at cross-compiling and ask them | 06:05 |
| recur | thanks, will do :) | 06:05 |
| NekoXP | recur, what linker are you trying to use? | 06:27 |
| recur | Hi NekoXP : I was able to get it working by editing libpng's Makefile :) | 07:07 |
| hrw | ogra_: thx for comment | 09:28 |
| ogra_ | np :) | 09:28 |
| twb | Ahahahaha | 09:36 |
| twb | Sorry, wrong channel. | 09:36 |
| twb | When someone has a minute, I'd like to know if "w3m http://www.menumate.com.au/sofias-pizza-house" generates gc warnings | 09:38 |
| twb | poss. only happen when w3m-img is installed. I'm getting them on oneiric in screen in fbcon. I wasn't geting them a while back, might have been before I switched to ARM tho | 09:38 |
| twb | (Except tell me tomorrow because I'm about to go to dinner.) | 09:39 |
| sveinse | ogra_: What does fixrtc do specifically? Could it affect valid time (Hw clock > Fs timestamp) in any way? | 09:40 |
| ogra_ | it checks if the last mount time of the disk is in the future, if so, it sets the hwclock to that time | 09:41 |
| ogra_ | (plus a few seconds) | 09:41 |
| hrw | ogra_: janimo` will be next to comment - he complained yesterday to me about 'why you are not motu/core-dev yet' :D | 09:41 |
| ogra_ | heh | 09:41 |
| hrw | https://blueprints.launchpad.net/linaro-ubuntu/+spec/toolchain-backports-ppa-update-12.03 - one 'simple' ppa update | 09:42 |
| ogra_ | sveinse, indeed it could, if the time of the machine that last mounted the disk was wrong (in the future) it would move your board to that time (plus a few seconds) ;) | 09:43 |
| sveinse | ogra: interesting. So if user erroneously sets the date to sometime in the future, he will either have a non-working system or stuck with this future time, right? | 09:45 |
| sveinse | ogra_ ^ | 09:45 |
| ogra_ | not if his system is networked | 09:45 |
| ogra_ | ifup calls ntpdate on connect | 09:45 |
| ogra_ | that will correct the time and on unmount (shutdown) the time of the disk will be correct | 09:46 |
| ogra_ | if the system is non networked your statement is true indeed | 09:46 |
| ogra_ | but thats still better than hanging in an endledd mountall fsck loop on boot ;) | 09:46 |
| sveinse | If the mounttime is indeed written on umount, then it does not matter if its ntp or the user which corrects the clock | 09:47 |
| ogra_ | right, but something *has* to correct it indeed | 09:48 |
| sveinse | yep, I feared that fs mounttime was the last 'mount' time and not umount | 09:48 |
| ogra_ | well, check the code, iirc i made it check for the last unmount time, if not, thats indeed a bug | 09:49 |
| sveinse | in mountall source, right? | 09:49 |
| ogra_ | no, the fixrtc script somewhere in /usr/share/initramfs-tools | 09:50 |
| sveinse | thanks, I'll check | 09:50 |
| ogra_ | oh, i think i did use last mount time, but that gets updated on umount | 09:52 |
| * ogra_ remembers again | 09:52 | |
| janimo` | hrw, I am missing the context in the scrollback. Not sure what I am next to comment on. If you have a MOTU application written up then great :) | 10:27 |
| ogra_ | i guess he wants you to comment on his wiki ;) | 10:28 |
| janimo` | ogra_, I think that's the context/link I miss in scrollback | 10:30 |
| hrw | janimo`: https://wiki.ubuntu.com/MarcinJuszkiewicz/DeveloperApplication-MOTU | 10:31 |
| hrw | btw: http://marcin.juszkiewicz.com.pl/2012/03/06/updated-cross-toolchain-for-ubuntu/ | 10:31 |
| janimo` | hrw, added note. Good luck! :) | 10:36 |
| hrw | janimo`: thx | 10:40 |
| sledges | hello | 11:40 |
| sledges | where can I access sources to i.MX53 hardware graphics drivers? | 11:41 |
| sledges | used by UBUNTU 1109 IMX53 build | 11:41 |
| ubot2` | Ubuntu bug 1109 in gringotts "No desktop entry in /usr/share/applications" [Medium,Fix released] https://launchpad.net/bugs/1109 | 11:41 |
| ogra_ | sledges, no, you used the linaro 1109 ubuntu build, ask in #linaro | 12:04 |
| ogra_ | ubuntu didnt have any 11.09 release :) | 12:05 |
| sledges | ogra_, you are right | 12:07 |
| sledges | 'cause all i could obtain for now were source of kernel, but nothing outside | 12:07 |
| ogra_ | i dont think the binary drivers for mx53 are made available by freescale though | 12:08 |
| ogra_ | *the sources for the binary drivers | 12:08 |
| ogra_ | but ask the guys that build the image ;) | 12:08 |
| sledges | i use ltib from freescale for imx53, and their kernel is just rubbish :)) but provides the rest of binary drivers from sources.. | 12:10 |
| sveinse | ogra_: We're seeing that the mount time (or last write time) is never updated in the fs. This is why the clock is always reset by fixrtc. / is mounted with noatime, could this be the cause? | 12:37 |
| === chrisccoulson_ is now known as chrisccoulson | ||
| ogra_ | no, noatime shouldnt affect mount time | 12:38 |
| ogra_ | iirc | 12:38 |
| ogra_ | try it ;) | 12:38 |
| sveinse | I just did and I see that dumpe2fs always reports the same timestamp on last write time and last mount time | 12:39 |
| ogra_ | hmm, it shouldnt | 12:39 |
| ogra_ | but try with noatime removed and see if that fixes it | 12:40 |
| sveinse | This is weird! noatime does not affect the last mount time either | 12:44 |
| sveinse | But I am indeed writing to the fs | 12:45 |
| sveinse | That shouldn't matter when I come to think about it. As long as the hw clock is newer than the fs, then it ought to work | 12:47 |
| sveinse | What I'm seeing is that the clock is _always_ reset to the date of the last mount time, so getting the clock from HW might not work properly | 12:48 |
| ogra_ | well, do you power off the board com,pletely and have no RTC battery on that board ? | 12:53 |
| ogra_ | then you indeed will always have a reset HW clock | 12:53 |
| sveinse | ogra_, there is a RTC battery and hwclock reports correct rtc clock across reboots. | 13:07 |
| ogra_ | then it should not attempt toi set the clock at all | 13:08 |
| sveinse | Where does it compare the clock? My /usr/share/initramfs-tools/scripts/local-premount/fixrtc contains http://paste.ubuntu.com/871392/ | 13:10 |
| ogra_ | it doesnt | 13:11 |
| ogra_ | intrestingly | 13:11 |
| ogra_ | i know my original version did | 13:11 |
| sveinse | this is in natty | 13:11 |
| ogra_ | the script comes from lucid | 13:11 |
| ogra_ | sveinse, that looks like a bug | 13:14 |
| sveinse | Ok. I think we need to refrain from using fixrtc and rather make our own init script which replaces hwclock and make it last-mount-time aware | 13:15 |
| ogra_ | well, you should file a bug and make me fix fixrtc ;) | 13:15 |
| sveinse | This is currently holding back production, so I can't wait for an upstream resolution | 13:16 |
| ogra_ | all you need it to convert the date to a timestamp and compare against the hwclock | 13:16 |
| sveinse | where should I file the bug? Ubuntu-11.04 ? | 13:17 |
| sveinse | ogra_ bug #947988 | 13:27 |
| ubot2` | Launchpad bug 947988 in initramfs-tools "fixrtc kernel option always sets system time" [Undecided,New] https://launchpad.net/bugs/947988 | 13:27 |
| ogra_ | thx | 13:28 |
| sveinse | np | 13:28 |
| ogra_ | sveinse, bug has a patch, could you test it ? | 13:51 |
| ogra_ | argh and LP messed up the style | 13:51 |
| ogra_ | added a .patch file now | 13:54 |
| * sveinse is embarrased. Forgetting all about update-initramfs... | 14:26 | |
| sveinse | ogra_ it works | 14:26 |
| sveinse | yet I observe that my ext4 fs "last mount time" seems to be written at mount and not on umount. last write time is never touched | 14:27 |
| sveinse | if and if ubuntu shutdown really runs any umount on rootfs | 14:28 |
| ogra_ | great, did you counter test (with a mount time in the future) too ? | 14:31 |
| sveinse | Yes, I did. Both prior and former dates | 14:32 |
| ogra_ | i need to be sure the old behavior still works before applying the patch | 14:32 |
| ogra_ | awesome ! | 14:32 |
| * ogra_ includes in the next upload then | 14:32 | |
| sveinse | (when) will this be published into natty? | 14:32 |
| * sveinse is holding back production until fix is available... | 14:33 | |
| sveinse | I confirm that my ubuntu system does not write "last mount time" to disk when ubuntu shuts down. It only writes upon startup | 14:38 |
| sveinse | This means that with the fixrtc option, the user will never be able to turn the clock back in time | 14:38 |
| ogra_ | thats illogical | 14:57 |
| ogra_ | your last mount time will never be newer than the installation date | 14:58 |
| ogra_ | if the RTC is set properly after the fist boot (by ntpdate or the user) the mount time will be updated next time you boot to a proper time | 14:59 |
| ogra_ | sveinse, ^^^ | 14:59 |
| ogra_ | indeed that fails if your system clock is set years in the future during install, but thats a special case i'm willing to live with | 15:01 |
| === chrisccoulson_ is now known as chrisccoulson | ||
| rbasak | Is fixrtc in the kernel or early userspace? | 15:04 |
| rbasak | (OOI) | 15:04 |
| ogra_ | initrd | 15:04 |
| ogra_ | see the backlog | 15:04 |
| ogra_ | init-premount to be precise | 15:05 |
| rbasak | thanks, I didn't go back far enough | 15:07 |
| oneric | hi all | 15:14 |
| oneric | i put SD on Board, when i start with ubuntu, start always the system configuration of ubuntu | 15:15 |
| oneric | it not install | 15:15 |
| oneric | i have pandaboard | 15:15 |
| sveinse | ogra_ The reason I ask is because a user did indeed make a mistake when setting the time. He sat i to 2013. In this case, and if rtcfix is used, the user nor ntpdate will never be able to correct the time back to 2012 | 15:16 |
| xranby | oneric: thats normal, you are booting a preinstalled image | 15:16 |
| sveinse | Because AFAICS "last mount time" is only updated when ubuntu is mounting root, never on shutdown | 15:17 |
| ogra_ | sveinse, right, he can just drop fixrtc from the cmdline in that case | 15:17 |
| sveinse | Hence, the "last mount time" will only move forward in time | 15:17 |
| ogra_ | and it will be updated properly on next boot | 15:17 |
| xranby | oneric: you are expected to see a welcome screen where you select language timezone keyboard etc. when the setup are complete your panda will reboot and start ubuntu from the same sdcard | 15:17 |
| ogra_ | i think for the normal usecase its a proper assumption that your clock moved forward normally and RTC will be > mount time and thus the mount time will be updated | 15:18 |
| oneric | xranby when the setup is complete my panda reboot and restart configuration | 15:18 |
| ogra_ | in cases where you did weird things to the clock, manual intervention is required | 15:19 |
| sveinse | Is this limitation (linux wont boot when date is in the past) constant across all linuxes? Because I've never seen this issue until now | 15:19 |
| ogra_ | it will boot ... | 15:20 |
| sveinse | With that rationale I agree that it's not occurring very often | 15:20 |
| sveinse | boot = start in runlevel 2 ;) | 15:20 |
| ogra_ | thats a weird statement as runlevel 2 is identical to 3-5 in debian and ubuntu :) | 15:20 |
| xranby | oneric: can you tell which install image you used and which instructions you followed to prepare your sd card? | 15:21 |
| sveinse | "on stopped rc" to use more upstart lingo then | 15:21 |
| ogra_ | the original issue for having fixrtc was that mountall/fsck freaked out and went into an endless loop when you didnt have an RTC battery (like 99% of the dev boards we support) | 15:21 |
| ogra_ | that it fixes a wrong RTC setting is just a sideefect | 15:22 |
| ogra_ | *effect | 15:22 |
| oneric | xranby: http://www.omappedia.com/wiki/Prebuilt_ubuntu_binaries | 15:22 |
| sveinse | our board just stopped in mid-boot. mountall seemed to hang forever (not fsck) | 15:22 |
| ogra_ | oneric, http://wiki.ubuntu.com/ARM/OMAP | 15:23 |
| ogra_ | sveinse, thats weird | 15:23 |
| ogra_ | mountall itself doesnt even care about timestamps | 15:23 |
| ogra_ | but it calls fsck which has been fixed since i wrote fixrtc | 15:23 |
| ogra_ | the loop shouldnt happen at all anymore and fsck should just exit with a warning | 15:24 |
| ogra_ | (which you dont see due to the splash) | 15:24 |
| oneric | i have used this ogra https://wiki.ubuntu.com/ARM/OmapNetbook is correct but restart always configuration system | 15:24 |
| ogra_ | but in any case if you dont do weird things with your clock, fixrtc should work properly | 15:24 |
| oneric | ogra you speak to me? | 15:25 |
| ogra_ | oneric, start over, i would guess your SD is corrupt somehow | 15:25 |
| sveinse | And no or invalid date (including into the future) is the state of the RTC when it comes fresh out of production. If ubuntu is booted on a system with future RTC date, then rootfs is mounted and last mount time is updated with the future, which we're stuck with. | 15:26 |
| sveinse | Unless altering kernel params post install then | 15:26 |
| oneric | ogra i must reformat SD? | 15:27 |
| oneric | i formAT sd like ext3 | 15:27 |
| ogra_ | oneric, just follow the setps from the wiki again | 15:27 |
| ogra_ | you dont format anything | 15:27 |
| oneric | nothing? | 15:27 |
| oneric | i only rewrite? | 15:27 |
| ogra_ | just follow the steps on the wiki, there is no formatting at all involved | 15:27 |
| oneric | but i have used 11.10 | 15:28 |
| xranby | oneric: http://wiki.ubuntu.com/ARM/OMAP use these instructions | 15:28 |
| ogra_ | right | 15:28 |
| oneric | yes | 15:28 |
| oneric | no problem with ubuntu 11.10? | 15:28 |
| ogra_ | nope | 15:28 |
| ogra_ | has been tested many times and is used by many people | 15:28 |
| oneric | but now | 15:29 |
| ogra_ | just follow http://wiki.ubuntu.com/ARM/OMAP | 15:29 |
| oneric | i had format sd ext3 | 15:29 |
| oneric | can be this a problem? | 15:29 |
| xranby | oneric: then you are doing something wrong | 15:29 |
| ogra_ | and use the instructions for your release | 15:29 |
| oneric | xranby now? | 15:30 |
| ogra_ | just follow the instructions on the wiki | 15:31 |
| ogra_ | the method there will wipe the ext3 filesystem anyway | 15:31 |
| xranby | oneric: for example if your sdcard reader are at /dev/sdX you should be using the sudo sh -c 'zcat ./ubuntu-11.10-preinstalled-desktop-armel+omap4.img.gz |dd bs=4M of=/dev/sdX ; sync' | 15:31 |
| oneric | yes yes | 15:31 |
| oneric | thanks for help i retry | 15:32 |
| oneric | but i moust unmount SD first? | 15:32 |
| ogra_ | you should, yes | 15:33 |
| oneric | ahh | 15:33 |
| oneric | i before not unmount,,, can be this a problem? | 15:33 |
| shadeslayer | hi,I was wondering, does anyone have instructions on how to setup a ARM VM with qemu? | 15:33 |
| sveinse | ogra_ how would you do this in production when the RTC is invalid/has random contents: 1) Boot the system with fixrtc to allow the system to boot, 2) Set the proper date, 3) Remove the fixrtc kernel option | 15:34 |
| xranby | oneric: that can cause problems | 15:35 |
| infinity | sveinse: Why is (3) required at all? | 15:35 |
| sveinse | You see, I'm not too fond of changing critical files during boot, like bootloader setting because it increases the product to fail later | 15:35 |
| sveinse | infinity: Because fixrtc ensures that the system clock is the newest of the HW clock or the 'last mount time' from the rootfs. | 15:36 |
| ogra_ | infinity, because he has users that set their date to 2013 | 15:36 |
| sveinse | Or the RTC is invalid (future date) from bugus data in production | 15:36 |
| ogra_ | which on next boot sets the mount time to 2013 ... then if the clock is corrected your mount time is in the future for the next year | 15:37 |
| ogra_ | so fixrtc will go on to update over and over | 15:37 |
| infinity | sveinse: It doesn't actually do that. But Oli's point is fair. | 15:37 |
| sveinse | infinity: I'd like to agree, but I have devices which fails production over this right now | 15:38 |
| ogra_ | fixrtc indeed functions on the assumption that the last mount time was the install date and is in the past while the clock is updated to a correct date | 15:39 |
| infinity | sveinse: Hrm? I'm looking at the code. It doesn't pick the "latest", it just sets it to the rootdev's timestamp, full stop. | 15:39 |
| oneric | how unmount SD | 15:39 |
| sveinse | infinity: yep, that | 15:39 |
| oneric | ? | 15:39 |
| ogra_ | infinity, see bug 947988 | 15:39 |
| ubot2` | Launchpad bug 947988 in initramfs-tools "fixrtc kernel option always sets system time" [High,Triaged] https://launchpad.net/bugs/947988 | 15:39 |
| ogra_ | i'm about to add that code bit | 15:39 |
| oneric | ogra how unmount sd from terminal? | 15:40 |
| infinity | ogra_: I think fixrtc should have been named nortc, so it discouraged use in cases other than the one it was written for. :P | 15:40 |
| ogra_ | heh, feel free to rename it | 15:40 |
| ogra_ | though i think the check is valid | 15:40 |
| ogra_ | oneric, sudo umount <path to your SD device> | 15:41 |
| ogra_ | iirc thats described on the wiki | 15:41 |
| sveinse | in our setup the problem is this: 1) our fs image has valid dates when produced, hence "last mount time" is always correct. 2) The RTC may or may not have valid date and/or a date into the future | 15:41 |
| infinity | ogra_: The check is reasonable, right up until someone makes a dev board with no rtc that has a default system time of 2020. | 15:41 |
| ogra_ | heh, who would do that | 15:42 |
| oneric | sudo unmount /dev/sdb/ not work | 15:42 |
| ogra_ | probably people in 2021 ... | 15:42 |
| sveinse | The current (before 947988) is not good that either, because it *always* sets the systime from last mount time | 15:42 |
| oneric | sudo: unmount: command not found | 15:42 |
| infinity | sveinse: But this is a preinstall / factory imaging thing, right? | 15:43 |
| ogra_ | oneric, read exactly what i typed above | 15:43 |
| infinity | sveinse: In your case, you can surely have your installed re-run flash-kernel with a new cmdline as the last step. | 15:43 |
| sveinse | infinity: Preinstalled sdcard and then booted in production | 15:43 |
| infinity | s/installed/installer/ | 15:43 |
| infinity | Or is there no "installer", per se? | 15:43 |
| infinity | (I assume there's at least something) | 15:44 |
| sveinse | No installer. Everything is preinstalled. | 15:44 |
| ogra_ | you could preseed a late-command in oem-config | 15:44 |
| ogra_ | (if preseeding would work) | 15:44 |
| infinity | If he was using oem-config. | 15:44 |
| oneric | ogra you can write command pls? | 15:44 |
| infinity | But he did just say "there's no installer". | 15:44 |
| ogra_ | which remonds me ... | 15:44 |
| ogra_ | oneric, there is no "n" in umount | 15:44 |
| ogra_ | well, there is one | 15:44 |
| sveinse | We have a oem-config-like system, so we can run something post first-boot | 15:44 |
| ogra_ | just not in the place you put it | 15:44 |
| oneric | sorry | 15:45 |
| oneric | :) | 15:45 |
| ogra_ | sveinse, well, then do that | 15:45 |
| ogra_ | and remove the fixrtc option | 15:45 |
| infinity | sveinse: Right, then it makes sense to use fixrtc on first-boot, and rewrite the cmdline after that. | 15:45 |
| sveinse | We are not updating any kernel or initramfs at this stage, so I'd try, for the risk of the product, not to have to mock around with anything related to booting | 15:45 |
| infinity | sveinse: I don't see a sane way to make fixrtc guess what it should do. Either it compares and that's wrong, or it doesn't compare and that's wrong. | 15:45 |
| ogra_ | you should rewrite it anyway to have a proper root=UUID= entry | 15:46 |
| sveinse | I'm considering dropping the use of fixrtc, as is creates more troubles than good, i think | 15:46 |
| * ogra_ doesnt think so ... unless someone sets a relly weird date | 15:47 | |
| ogra_ | but up to you :) | 15:47 |
| ogra_ | i will add the check anyway | 15:47 |
| sveinse | ogra_ you don't want to know: All produced sdcards have the same uuid as this is generated before the card is copied | 15:47 |
| infinity | ogra_: Really weird dates are precisely his issue, I think. | 15:47 |
| ogra_ | oh my | 15:47 |
| infinity | ogra_: And I think your check might actually make it strangely worse (or differently broken). | 15:47 |
| sveinse | the purpose of the first-boot (oem-config-ish) is to uniquify the product | 15:48 |
| ogra_ | infinity, well, on the assumption that a user sets the date manually (while ntpdate already set it correctly) to a weird time in the future | 15:48 |
| infinity | sveinse: You can set a new UUID during your uniquification process. | 15:48 |
| oneric | ogra how can i check for device for my SD? | 15:48 |
| oneric | sde1,sde2,sde3? | 15:48 |
| ogra_ | checl dmesg | 15:48 |
| oneric | i must put sde3 or sde? | 15:48 |
| sveinse | infinity: yep, exactly | 15:48 |
| ogra_ | *check | 15:48 |
| infinity | ogra_: His issue wasn't about users, it was about the battery-backed RTCs potentially having "weird dates" even before the system is imaged. | 15:49 |
| ogra_ | infinity, well, the initial start of this discussion was about a user who set a date of 2013 | 15:49 |
| infinity | ogra_: Which, to be fair, is (way) out of the scope of what fixrtc is meant to deal with. But yeah, it means your fix will fix the constant re-running, but break that case. | 15:49 |
| ogra_ | hours ago | 15:49 |
| sveinse | Well coming back to our issue at hand: I can't be without some fixrtc in some form as mountall hangs if the RTC date is older than the more correct 'last mount time' | 15:49 |
| sveinse | I can't use fixrtc as the RTC date may be into the future, and then 'last mount time' gets updated with the invalid future date | 15:50 |
| infinity | sveinse: If Oli makes the comparison fix, I think that's probably correct, in the face of what fixrtc is meant to do, but it does, obviously, fail to fix anything if clocks are in the future. | 15:50 |
| ogra_ | sveinse, it wont unless your SD write date is even further in the future | 15:50 |
| ogra_ | as i said several times already | 15:51 |
| infinity | sveinse: And, I'm afraid, there's no fix for that. You can't write something that says "sometimes pick the RTC, and sometimes pick the filesystem, but we can't tell you which without talking to a human or checking a wall clock." | 15:51 |
| oneric | ogra: you know LTIB? | 15:51 |
| ogra_ | oneric, nope | 15:51 |
| oneric | i have also another Board IMX53 freescale | 15:51 |
| sveinse | infinity: IMHO there is one remedy to all of these issue: Apply Oliver's patch, and then if ubuntu could update 'last mount time' to the system time when umount is called, then that would work I think | 15:51 |
| ogra_ | oneric, we do have images for imx53 too | 15:51 |
| infinity | sveinse: No. | 15:52 |
| oneric | it not start | 15:52 |
| * ogra_ hasnt tested any mx53 images since i dont own the HW | 15:52 | |
| infinity | sveinse: Because with Oli's patch, you get the issue that dates set in the future stay in the future forever (or weird pre-imaging RTC dates end up being the true date), which you're arguing you don't want. | 15:52 |
| ogra_ | the only sane way is use fixrtc with my patch and update the cmdline during sys configuration | 15:53 |
| infinity | sveinse: We literally can't fix both issues without human intervention. Your computer can't know which date is right. We can either say "pick the biggest one", "pick the smallest one", "always use the RTC" or "always use the filesystem", but we can't mix and match. | 15:53 |
| oneric | fist i want start with panda board! | 15:53 |
| oneric | ok ogra i have put sd on panda | 15:54 |
| sveinse | infinity: No, because assuming the user or NTP changes the system clock while the system is running, hwclock-save will save the correct time into the RTC. If umount also wrote the system time into 'last mount time', then the system would start correctly the next time even with fixrtc | 15:54 |
| oneric | board | 15:54 |
| oneric | and it start with ubuntu | 15:54 |
| infinity | sveinse: Oh, I see what you're saying. So, even if it's incorrect on one boot, you want it to be forced correct for subsequent ones by rewriting the last mount time. That solves all but the "RTC is wrong" problem, I guess. | 15:55 |
| ogra_ | right, we did have that in the past (a hwclock init script on shutdown) | 15:56 |
| infinity | sveinse: Of course, it also becomes a complete lie then, and breaks long-running systems. | 15:56 |
| sveinse | Yes. If RTC is wrong, then its wrong. Either user or NTP can correct that | 15:56 |
| infinity | sveinse: (Last mounted is *meant* to be last-mounted, not "last-touched") | 15:56 |
| ogra_ | and as i said before, fixrtc was written for the usecase where you actually install ubuntu | 15:57 |
| infinity | sveinse: If you have a system up for 400 days, the last-mount time should be 400 days ago, not "Just now, because I rebooted". If we update it that way, timed fscks never happen. | 15:57 |
| ogra_ | the time drift you have then wont be big | 15:57 |
| oneric | ogra i entered on ubuntu and now i'msetting system configuration | 15:58 |
| sveinse | infinity: I totally agree. It's just that we assume in fixrtc that the written timestamp is correct, which it may not. | 15:58 |
| ogra_ | oneric, did it do the resizing and one reboot properly ? | 15:58 |
| infinity | sveinse: No real fix for that. Like I said, we should probably rename fixrtc to nortc, so people use it for what it was intended, a best-approximation of having no battery-backed RTC. :P | 15:58 |
| oneric | resizing? | 15:58 |
| ogra_ | sveinse, right, as i saidm, it was written for our images where a user installs them manually | 15:59 |
| sveinse | I agree that this isn't neccessarily a fix for every ubuntu system out there (the shudown last mount thing) | 15:59 |
| ogra_ | oneric, yes, the image resizes itself to the full size of the SD and then reboots | 15:59 |
| sveinse | I'm considering doing a remount on rootfs on these special occations | 15:59 |
| infinity | sveinse: The shutdown last-mount thing is just plain wrong. It's overloading last-mount to now be a timekeeping service, and breaks its actual intended use. | 15:59 |
| sveinse | agree | 16:00 |
| oneric | i dont know, now ubuntu is installing keyboard configuration | 16:00 |
| infinity | sveinse: Now, doing that on your own images, say, on a product that never does times fscks anyway (and has that set to -1), then go nuts. ;) | 16:00 |
| infinity | s/times/timed/ | 16:00 |
| ogra_ | oneric, well, did it reboot once before you got into the setup program ? | 16:00 |
| ogra_ | else your system may not function correctly | 16:00 |
| sveinse | infinity: That's another good point. The image is valid prior to the first boot. Then the RTC is wrong and 'last mount time' is set into the future. Now the image will never be checked (except for mount counts) until this future time is met... | 16:01 |
| sveinse | OOI does desktop linux behave the same way? I.e. won't do a full start unless the hw clock is newer than the 'last mount time' ? | 16:03 |
| infinity | "desktop linux"? | 16:04 |
| infinity | Making Ubuntu what, exactly? :) | 16:04 |
| sveinse | natty amd64 using gnome ;) | 16:04 |
| infinity | amd64 and armel are no different in that regard. | 16:04 |
| oneric | ogra | 16:04 |
| infinity | Or in any regard, really. | 16:04 |
| oneric | ogra: it work | 16:05 |
| oneric | thanks | 16:05 |
| oneric | many thanks! | 16:05 |
| sveinse | that intersting, because this is the first time I've actually had to struggle with clock settings | 16:05 |
| GrueMaster | sveinse: For a test, I took a panda daily image, removed the "fixrtc" from the commandline, and booted with no networking. The system came up with 1989, which is still more valid than 1970, and it booted through oem config into unity with minor issues (background mainly). | 16:05 |
| infinity | Because your amd64 system has a battery-backed-rtc and doesn't use 'fixrtc' on the command line. | 16:05 |
| infinity | If an intel/powerpc/whatever system suddenly finds itself in 1970, you have exactly the same problems. Now, as GrueMaster points out, this has been reduced from errors to warnings in precise. | 16:06 |
| sveinse | Our HW system don't work without fixrtc. We're running natty and mountall simply hangs duing boot if the RTC time is less than the last mount time from the rootfs | 16:06 |
| infinity | (And possibly oneiric?) | 16:06 |
| infinity | sveinse: Yes, this is fixed in newer releases. | 16:07 |
| sveinse | That is perhaps and probably a bug, but we haven't time to fix that | 16:07 |
| infinity | It occurs to me that natty is EOL, and this discussing (from an Ubuntu perspective) is somewhat moot as a result. | 16:07 |
| infinity | Cause we can't "fix it" for you, even if we want to. | 16:08 |
| infinity | ie: we can no longer upload to the archive. :P | 16:08 |
| infinity | Oh, wait. No. | 16:08 |
| infinity | I can't count. | 16:08 |
| infinity | But it's almost EOL! ;) | 16:08 |
| oneric | someone know LTIB? | 16:08 |
| ogra_ | GrueMaster, well, the issue is that he isnt using a panda and that his systems can have really really weird clock settings apparently :) | 16:08 |
| sveinse | I'm not asking for a fix either, just advice | 16:08 |
| * ogra_ thought we gave the right advice already | 16:08 | |
| ogra_ | use fixrtc on first boot, remove it from the cmdline after system configuration | 16:09 |
| infinity | sveinse: My advice would be, perhaps, to install a small shutdown script that does your hackish "set last-mount stamp on shutdown", and combine that with ogra's patch. | 16:09 |
| GrueMaster | What type of system? I'm assuming arm based (otherwise the conversation should be somewhere else). | 16:09 |
| infinity | sveinse: But do that if (and ONLY if) you also aren't doing timed fscks. | 16:09 |
| ogra_ | GrueMaster, no idea :) but yeah, likely arm based since we are in #ubuntu-arm | 16:09 |
| oneric | i have freescale imx53 | 16:09 |
| oneric | but i have problem with ltib | 16:09 |
| oneric | i want install ubuntu on my imx53 | 16:10 |
| infinity | sveinse: And yeah, "use it only on first boot" is also a perfectly valid option. | 16:10 |
| infinity | sveinse: I tihnk the paranoia that end users might screw up their RTC is sort of out of your domain. | 16:10 |
| sveinse | GrueMaster: omap3 devices. Custom HW for custom application | 16:10 |
| GrueMaster | What about preloading the rtc with a semi-sane time from u-boot? Like the u-boot build timestamp? | 16:10 |
| infinity | GrueMaster: This is a battery-backed RTC, it shouldn't need preloading at all. | 16:10 |
| ogra_ | aww, dont bring more variables into the discussion ! | 16:10 |
| GrueMaster | This way, your rtc is always in the past, but reasonablly close. | 16:11 |
| infinity | GrueMaster: His complaint is that it might be wrong on first boot, not that it will be wrong forever. | 16:11 |
| sveinse | infinity: It certainly is. My concern is that production works, not if uses is capable of setting the correct date! | 16:11 |
| ogra_ | GrueMaster, the prob is that you would have to have u-boot to only do it once | 16:11 |
| GrueMaster | infinity: I have x86 systems that have had failing rtc batteries. I don't rely on that always. | 16:11 |
| infinity | GrueMaster: Yes, but resetting the date on every boot when it may have already been correct (and now you've just made it incorrect) is a bit odd too. ;) | 16:12 |
| * sveinse is grateful for advice from ogra_ and infinity | 16:12 | |
| ogra_ | and we happily give it :) | 16:12 |
| infinity | sveinse: I honestly see no One True Solution to any of this. fixrtc + running ntpdate as early as possible gets you past most of the big hiccups, though. | 16:13 |
| infinity | sveinse: And, at the end of the day, who cares if your last-mount time is incorrect forever? | 16:13 |
| infinity | sveinse: I mean, it matters if you're using that feature, but given your willingness to overwrite the date with bogus values, you're obviously not. ;) | 16:13 |
| ogra_ | it wont be once your rtc is right, fixrtc is gone and you reboot :) | 16:14 |
| suihkulokki | fixrtc and running ntpdate before mounting root partition read-write would be quite bulletproof (assuming available network) | 16:14 |
| ogra_ | suihkulokki, right, and it falls with that assumption :) | 16:14 |
| infinity | ogra_: Yes, running once feels right to me, but then he's paranoid about users setting their clocks incorrectly later, and wants to force-fix it again. | 16:14 |
| ogra_ | yep | 16:14 |
| sveinse | infinity: I have never cared about last mount time until mountall stopped working! When the RTC always is newer than the FS, I really don't care about last mount time | 16:15 |
| infinity | suihkulokki: There'd be a lot of early boot mangling to do for him to rethink things and bring up the network in time for an initramfs-based ntpdate, I imagine. | 16:15 |
| ogra_ | mountall not working is worth a bug btw ... | 16:15 |
| suihkulokki | otoh if you don't have network, your sense of "real time" is kinda lost | 16:15 |
| ogra_ | in case i didnt mention that yet :) | 16:15 |
| infinity | suihkulokki: Unless he's already booting via a method that gives him a ghetto network (ie: bootp/tftp) | 16:15 |
| ogra_ | suihkulokki, exactly ... and thats what fixrtc is for | 16:15 |
| sveinse | ogra_, I'll do that when I've untied the flock in production | 16:16 |
| ogra_ | in its current state it just forces the clock to last mount time of the disk | 16:16 |
| ogra_ | sveinse, thanks ! | 16:16 |
| ogra_ | under the assumption that you used an ubuntu image and wrote it to the disk at some point ... to make sure your RTC isnt set to the epoch... nothing more | 16:17 |
| ogra_ | (indeed that also fails if the machine you wrote it on has no rtc .... *g*) | 16:17 |
| infinity | ogra_: No it doesn't... | 16:18 |
| sveinse | ogra_, ubuntu image = debootstrapped ubuntu-minimal with our custom kernel on top? Does that count? | 16:18 |
| infinity | ogra_: The last-mount time is from the buildds. | 16:18 |
| ogra_ | infinity, is it ? | 16:19 |
| ogra_ | oh, right, it is the filesystem we look at | 16:19 |
| infinity | ogra_: Well, unless you make a habit of mounting your SD cards after you zcat/dd them, I don't. | 16:19 |
| ogra_ | not the device | 16:19 |
| ogra_ | yeah | 16:19 |
| ogra_ | i was thinking device ... i usually mount them though to make surer the dd worked fine :) | 16:19 |
| oneric | someone can help me pls? | 16:20 |
| ogra_ | but i'm special and paranoid in that regard | 16:20 |
| infinity | oneric: I'm not sure what you need help with. You said you have an i.MX53 (Quickstart, I assume?), and you want to play with Ubuntu on it? We have an "mx5" image, and instructions on how to boot it. | 16:21 |
| infinity | oneric: https://wiki.ubuntu.com/ARM/MX5 | 16:22 |
| sveinse | Please let me get this straight: If fixrtc isn't used, the system wont start (in fact mountall hangs, but that's a bug) if the RTC time is older than the FS. If fixrtc is used the system will always start, but the user can never set the time backwards. | 16:24 |
| ogra_ | only with my recent fix | 16:26 |
| ogra_ | else you will end up in the condition you had before we discdussed the fix | 16:27 |
| sveinse | Altering 'last mount time' may have sideeffects in respect of time based disk checking | 16:27 |
| sveinse | yes | 16:27 |
| sveinse | I foreseeing that customer services won't be happy because there will be at least one customer which happens to set the wrong date into the future. Neither options are a solution :( | 16:29 |
| sveinse | Well, I'm repeating myself. Thanks all for your considerations | 16:29 |
| sveinse | I have to think about this. It's apparently not straight forward | 16:29 |
| sveinse | when will support for natty be dropped? | 16:31 |
| ogra_ | in 12 months | 16:32 |
| ogra_ | all arm releases we had up to now are 18months supported | 16:32 |
| ogra_ | err, in less than 12 actually | 16:32 |
| ogra_ | 7 or so | 16:33 |
| GrueMaster | Natty will drop off shortly after 12.10 release. | 16:33 |
| GrueMaster | November time frame. | 16:33 |
| sveinse | As an end-user mfg, we are ultimately responsible for the product we ship. We have a full natty mirror which we froze some time ago to run QA on the system. | 16:35 |
| sveinse | The product will be supported by us well beyond when natty is dropped by ubuntu | 16:36 |
| ogra_ | ouch | 16:36 |
| ogra_ | that will surely leave you with security holes at some point | 16:37 |
| ogra_ | unless you backport all CVEs yourself to your mirror | 16:37 |
| GrueMaster | sveinse: What is your targeted release date? | 16:38 |
| sveinse | Q2, but we are ramping up production now | 16:38 |
| GrueMaster | Ouch. So too late to update to at least Oneiric. | 16:39 |
| sveinse | oh, indeed. that's why I'm bothing with natty | 16:39 |
| sveinse | Well I have to leave. Thanks all, esp. ogra_ and infinity | 16:42 |
| GrueMaster | Will they be field upgradeable? It isn't too painful to do a kind of firmware reflash a few months after the first production iteration. | 16:42 |
| ogra_ | enjoy your evening | 16:42 |
| GrueMaster | Have a good evening. | 16:42 |
| sveinse | GrueMaster: Yes. It's sdcard based. Upgrade is in fact apt-get dist-upgrade.... One of the huge benefits from using debs in a system | 16:43 |
| GrueMaster | Ok, so it isn't going to be locked down. That is good. Otherwise I would have suggested that once you get this natty based image frozen, start working on a precise image for release mid-late Q3. | 16:44 |
| ogra_ | you still need an oneiric one ... else you have no upgrade path | 16:45 |
| GrueMaster | ogra_: I don't know the project or the design. I was thinking along the lines of a complete system upgrade, treating the image as a contained firmware set. | 16:46 |
| GrueMaster | But open upgradeable is better. | 16:46 |
| === zyga-xchat is now known as zyga | ||
| === prpplague^2 is now known as prpplague | ||
| danboid | I've installed last nights omap4 amhf 12.04 server and the nic isn't working on my pandaboard | 17:02 |
| danboid | Any other panda users here having this prob or not? | 17:04 |
| danboid | 'usb start' in u-boot sees my network port OK | 17:05 |
| GrueMaster | danboid: I haven't tried it yet. Give me 20 minutes and I can check. | 17:05 |
| danboid | GrueMaster, OK, thanks | 17:05 |
| danboid | bbl | 17:07 |
| AbuDawud | I have a Transformer Prime running Ubuntu 9.10. I'd like to try and get it up to current release but when attempting a distribution upgrade I am getting repo errors for Lucid. | 17:34 |
| AbuDawud | Is there a repo I should add before attempting to upgrade the distribution or am I stuck on Karmic for the time being | 17:35 |
| AbuDawud | The errors are "W:Failed to fetch http://archive.ubuntu.com/ubuntu/dists/lucid/main/binary-armel/Packages.gz | 17:36 |
| GrueMaster | AbuDawud: You are getting repo errors on Armel Lucid? What kind of errors? | 17:36 |
| AbuDawud | it appears the directories for armel do not exist there | 17:36 |
| GrueMaster | Ah. If this is armel, you need ports.ubuntu.com/ubuntu-ports. | 17:36 |
| AbuDawud | GrueMaster: Trying that, thanks | 17:37 |
| AbuDawud | GrueMaster: should the line be 'deb http://ports.ubuntu.com/ubuntu-ports karmic non-free' ? | 17:39 |
| GrueMaster | I use "deb http://ports/ubuntu.com/ubuntu-ports main restricted multiverse universe". That should get you everything except ppa's and private repos. | 17:40 |
| GrueMaster | Oops. Add "karmic" before main. | 17:40 |
| AbuDawud | hm, I guess I have to let my stupidity show a bit, the oldest dist there is lucid, if I am moving from old-releases to ports how to I do that? | 17:44 |
| GrueMaster | "do-release-upgrade" ? | 17:45 |
| AbuDawud | what I'm saying is I'm transitioning from archive.ubuntu.com to ports.ubuntu.com, if I add the ports repo it still throws an error about not finding the archive repo when attempting to upgrade | 17:49 |
| GrueMaster | Hmm. I'm really not sure what to tell you. Even Lucid is no longer really supported on arm, it just floats along with the LTS on x86. | 17:50 |
| GrueMaster | And I don't ever remember arm being available on archive.u.c. | 17:50 |
| AbuDawud | for lucid its not, it stops at karmic -.- | 17:51 |
| GrueMaster | Try setting the apt sources to "deb http://ports.ubuntu.com/ubuntu-ports lucid main restricted multiverse universe", then "apt-get update" followed by do-release-upgrade. | 17:53 |
| GrueMaster | I meant, I don't remember arm EVER being on anything but ports.ubuntu.com. | 17:54 |
| AbuDawud | GrueMaster: looks like thats working, oh well not enough disk space, new problem! | 18:01 |
| AbuDawud | thanks though | 18:01 |
| GrueMaster | Can't help there, sorry. :P | 18:01 |
| AbuDawud | it looks like its trying to write to the device root instead of the chroot I assigned, man I suck at this | 18:02 |
| === zyga is now known as zyga-afk | ||
| === yofel_ is now known as yofel | ||
| shadeslayer | Hi, I don't suppose someone could point me to a precise arm kernel that I could use with qemubuilder? | 18:55 |
| GrueMaster | shadeslayer: Try the omap kernel. | 18:55 |
| GrueMaster | http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux/linux-image-3.2.0-18-omap_3.2.0-18.28_armhf.deb | 18:56 |
| shadeslayer | GrueMaster: sure, but where is it? Inside this : http://cdimage.ubuntu.com/daily-preinstalled/current/precise-preinstalled-desktop-armhf+omap4.img.gz ? | 18:57 |
| shadeslayer | okay | 18:57 |
| shadeslayer | uhh | 18:57 |
| shadeslayer | GrueMaster: I need a vmlinuz | 19:02 |
| GrueMaster | download the deb, run "dpkg -x linux-image-3.2.0-18-omap_3.2.0-18.28_armhf.deb ." and you will have one in ./boot. | 19:04 |
| shadeslayer | aha | 19:09 |
| shadeslayer | GrueMaster: thanks! | 19:09 |
| * prpplague grumbles about the "issues" with firefox on his desktop ubuntu installation after doing an upgrade | 19:22 | |
| GrueMaster | prpplague: Do you know much about the beagleXM, rev b in particular? | 19:25 |
| rcn-ee | just an es core bump over the rev a. ;) | 19:26 |
| prpplague | GrueMaster: just general info, i wasn't on the team for that | 19:26 |
| GrueMaster | Hmmm. I'm seeing an issue with the nic not detecting link unless I physically unplug and plug in. | 19:27 |
| GrueMaster | Our kernel dev has a Rev A & Rev C, and claims they just work. | 19:27 |
| GrueMaster | Ok, nic just sprouted to life. System was idle at the desktop for ~10 minutes. Seems like it isn't getting enough power or something. | 19:28 |
| rcn-ee | GrueMaster, one of my xM B's does that every once in a while.. seemed kernel dependent.. rmmod smsc95xx /modprobe smsc95xx always seemed to bring it back.. | 19:28 |
| GrueMaster | interesting. | 19:29 |
| GrueMaster | Well, it has been like this since beginning Oneiric. Odd that it only happens all the time on mine. | 19:30 |
| GrueMaster | Fully reproducible. | 19:30 |
| GrueMaster | I also found that if I compile smsc95xx into the kernel (instead of as a module), it works consistently. | 19:31 |
| GrueMaster | And the Angstrom test image works of course. | 19:32 |
| rcn-ee | btw, they are also touching the power rails for smartreflex 1.5, so it could be a power sideeffect.. | 19:34 |
| GrueMaster | Yea, it feels like a low power issue. Like a capacitor isn't charging or something. | 19:37 |
| === pizthewiz_ is now known as pizthewiz | ||
| ogra_ | shadeslayer, http://ports.ubuntu.com/dists/precise/main/installer-armel/current/images/ has a plain kernel | 20:00 |
| ogra_ | http://ports.ubuntu.com/dists/precise/main/installer-armel/current/images/omap/cdrom/ actually | 20:00 |
| shadeslayer | cool! But I already ran qemubuilder, so ... :) | 20:01 |
| ogra_ | heh, k | 20:01 |
| * prpplague grumbles | 20:23 | |
| prpplague | GrueMaster: after i did an upgrade last week my desktop is acting totally funky | 20:24 |
| prpplague | GrueMaster: i think we should just blame ogra_ | 20:24 |
| ogra_ | prpplague, yeah, sorry, i wasnt cautious and broke it ... will fix it with the next update you run :P | 21:07 |
| prpplague | hehe | 21:07 |
| ogra_ | :) | 21:07 |
| * prpplague had a cow when looking at travel prices for the next linaro connect | 21:16 | |
| newtony2 | so ummm i need python on and iphone... ummm i found a git but i dont know anything about git... any help? | 23:16 |
| infinity | newtony2: That's really way out of scope for this channel. | 23:20 |
| newtony2 | oh well iphone is an arm processor | 23:21 |
| infinity | Is your iPhone running Ubuntu? | 23:22 |
| lilstevie | newtony2, you would be better off asking in a iPhone room | 23:22 |
| lilstevie | there is python stuff on cydia | 23:22 |
| newtony2 | kewl thx | 23:24 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!