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