| jjardon | Related: https://storyboard.baserock.org/#!/story/19 | 00:07 |
|---|---|---|
| *** zoli__ has quit IRC | 00:11 | |
| *** bashrc_ has quit IRC | 01:26 | |
| *** mauricemoss_ has quit IRC | 01:26 | |
| *** CTtpollard has quit IRC | 01:26 | |
| *** sambishop has quit IRC | 01:26 | |
| *** fay_ has quit IRC | 01:26 | |
| *** flatmush has quit IRC | 01:26 | |
| *** nowster has quit IRC | 01:26 | |
| *** tiagogomes_ has quit IRC | 01:26 | |
| *** paulw has quit IRC | 01:26 | |
| *** fay_ has joined #baserock | 01:26 | |
| *** bashrc_ has joined #baserock | 01:26 | |
| *** mauricemoss_ has joined #baserock | 01:26 | |
| *** paulw has joined #baserock | 01:27 | |
| *** nowster has joined #baserock | 01:27 | |
| *** CTtpollard has joined #baserock | 01:27 | |
| *** franred has quit IRC | 01:27 | |
| *** sambishop has joined #baserock | 01:27 | |
| *** franred has joined #baserock | 01:27 | |
| *** flatmush has joined #baserock | 01:28 | |
| *** tiagogomes has joined #baserock | 01:28 | |
| *** zoli__ has joined #baserock | 04:27 | |
| *** zoli__ has quit IRC | 05:26 | |
| *** zoli__ has joined #baserock | 05:46 | |
| *** Albert_ has joined #baserock | 07:09 | |
| *** a1exhughe5 has joined #baserock | 07:16 | |
| *** mdunford has joined #baserock | 07:41 | |
| *** rdale has joined #baserock | 07:49 | |
| *** mariaderidder has joined #baserock | 08:00 | |
| *** jonathanmaw has joined #baserock | 08:12 | |
| Kinnison | Hmm, someone needs to update storyboard to use the new SSL cert | 08:13 |
| *** edcragg has joined #baserock | 08:21 | |
| pedroalvarez | yes, we should :) | 08:28 |
| *** ssam2 has joined #baserock | 08:32 | |
| *** ChanServ sets mode: +v ssam2 | 08:32 | |
| *** gary_perkins has joined #baserock | 08:34 | |
| ssam2 | the root file system on my Jetson keeps becoming readonly for some reason | 08:56 |
| ssam2 | dmesg is just full of errors from systemd-journald being unable to write to it, nothing useful | 08:56 |
| ssam2 | rebooting seems to fix each time, but there's clearly a bug somewhere | 08:57 |
| DavePage | Is smartctl useful here? Could be a dodgy disk? | 09:03 |
| rjek | ssam2: Can you disable systemd-journald from logging to dmesg, or increase the size of the dmesg buffer so you can see what was logged when the error occured? | 09:05 |
| ssam2 | DavePage: the rootfs is a partition on the built-in flash MMC in the Jetson. I don't know if there's an equivalent to SMART for those | 09:09 |
| ssam2 | rjek: that's a good idea | 09:09 |
| rjek | ssam2: There are lots of reasons why a file system might get automatically remounted read-only, but it's normally an assertion failure or similar in the file system implementation. | 09:10 |
| rjek | Which would suggest file system corruption, but this might be caused by a controller or drive failure, which would hopefully be also logged in dmesg allowing you to distinguish between a software or a hardware fault. | 09:10 |
| ssam2 | [ 730.708070] mmcblk0: timed out sending r/w cmd command, card status 0x900 | 09:17 |
| ssam2 | [ 730.715427] blk_update_request: I/O error, dev mmcblk0, sector 2443712 | 09:17 |
| ssam2 | [ 730.722364] BTRFS: bdev /dev/mmcblk0p2 errs: wr 18, rd 0, flush 0, corrupt 0, gen 0 | 09:17 |
| ssam2 | that doesn't look good | 09:17 |
| *** lachlanmackenzie has joined #baserock | 09:17 | |
| tiagogomes | mmm, how do I drop patches in gerrit? | 09:17 |
| tiagogomes | that is, abandon | 09:17 |
| ssam2 | there should be a button, to the right of the commit message | 09:18 |
| *** Krin has joined #baserock | 09:19 | |
| tiagogomes | I just see a reply button | 09:19 |
| ssam2 | down a bit | 09:20 |
| tiagogomes | I was not signed in | 09:21 |
| tiagogomes | I found it | 09:21 |
| dabukalam | can anyone tell me the exact date of the initial Baserock release? I haven't yet been able to fathom it from the mailing list or the git logs | 09:22 |
| rjek | dabukalam: https://wiki.baserock.org/releases/ | 09:25 |
| rjek | "Rebel Mountain was released on the 10th July 2012" | 09:25 |
| Kinnison | And it was the first release | 09:25 |
| Kinnison | Cf <20120710152037.GX31576@somnambulist.local> | 09:25 |
| rjek | I'm sure there was an Accelerated Vegetable release once, and that's not listed. | 09:25 |
| richard_maw | the naming scheme was such that you could get a phrase by suffixing the name of one of the release artifacts | 09:25 |
| dabukalam | The inital release was 2? | 09:25 |
| richard_maw | we did internal releases first | 09:26 |
| Kinnison | one internal release, then rebel mountain | 09:26 |
| * richard_maw is just disappointed that he wasn't allowed to have a release called Buttery Biscuit | 09:26 | |
| dabukalam | cool, thanks | 09:26 |
| *** wdutch_ is now known as wdutch | 09:26 | |
| * rjek sneers at release names. | 09:26 | |
| richard_maw | was Secret Volcano the third release or the first internal one? | 09:27 |
| rjek | "Secret Volcano was released on the 20th August 2012" | 09:27 |
| Kinnison | accelerated vegetable was the first release | 09:27 |
| Kinnison | (internal) | 09:27 |
| * Kinnison can find internal discussions from late may 2012 which suggest accelerated vegetable had been released before then internally | 09:28 | |
| * rjek wanted it to be Vegetable Accelerator, but apparently that didn't fit in with the selected scheme. | 09:28 | |
| radiofree | ssam2: i'm under the impression that's file system corruption | 09:28 |
| radiofree | i have a jetson here that does that occasionally (maybe after a day.. maybe after a few hours) after i did the "resize max" | 09:29 |
| radiofree | reboot fixes it, fsck.btrfs doesn't seem to do anything | 09:29 |
| rjek | radiofree: ssam2: A timeout sending a r/w command to an MMC block device sounds like a hardware problem, not a software one? | 09:29 |
| radiofree | rjek: i believe it is | 09:29 |
| radiofree | (hardware) | 09:29 |
| rjek | (Could be a /driver software/ problem, obv, but not a btrfs problem) | 09:29 |
| rjek | Ah, misunderstood what you said, sorry | 09:30 |
| ssam2 | right. remind me why I can't just cross-compile from my laptop again :( | 09:30 |
| radiofree | i don't think the emmc likes btrfs taking up everything | 09:30 |
| rjek | ssam2: gobject-introspection! :) | 09:30 |
| radiofree | ssam2: if you need to build i have a jetson here with cache from master the other day | 09:30 |
| radiofree | it's cache from a devel-system + all of the weston image | 09:30 |
| ssam2 | thanks, but I'm ok for builds right now | 09:31 |
| franred | good morning guys, there are several patch-series that would be nice if someone can have a look at them today: http://paste.baserock.org/ojiyazuvuw | 09:54 |
| straycat | yes, buttery biscuit would have been good | 09:54 |
| tiagogomes | pedroalvarez, jjardon can you please +1 again my Ironic changes again? I had to re-submit the changes because I wanted them merged to master instead of openstack-on-baserock and cherry-picking to another branch with Gerrit didn't work | 09:56 |
| jjardon | tiagogomes: I was about to ask why did you abandon them :) let me take a look | 10:01 |
| jjardon | tiagogomes: Did you make any changes? | 10:02 |
| tiagogomes | jjardon, I had to fix some conflicts. In openstack-no-configure, some code was moved into another section: https://gerrit.baserock.org/#/c/357/1/openstack-nova.configure instead of https://gerrit.baserock.org/#/c/337/1/openstack-nova.configure | 10:07 |
| tiagogomes | jjardon, that should be the only change | 10:07 |
| *** mariaderidder has quit IRC | 10:27 | |
| *** mariaderidder has joined #baserock | 10:28 | |
| franred | tiagogomes, could you rebase https://gerrit.baserock.org/#/c/356/ ? it is getting me a weird error when I've tried it | 10:38 |
| tiagogomes | franred, | 10:39 |
| tiagogomes | franred, sure | 10:39 |
| tiagogomes | the rebase button didn't work for me though | 10:39 |
| franred | try to rebase manually and send the 2 remaining patches again, I will merge them | 10:39 |
| tiagogomes | 'kay | 10:40 |
| tiagogomes | franred, can you try again | 10:54 |
| franred | tiagogomes, sure | 10:57 |
| franred | tiagogomes, ironic merged | 10:58 |
| richard_maw | \o/ | 10:59 |
| tiagogomes | franred \o/ | 10:59 |
| pedroalvarez | \o/ | 11:02 |
| ssam2 | does anyone have an idea why a rootfs for Jetson might fail to mount an external SATA drive? | 11:07 |
| ssam2 | a previous build on the same Jetson successfully mounts it | 11:08 |
| ssam2 | kernels appear to be both 3.18.0, although I've not checked the exact commit SHA1s yet | 11:08 |
| paulsherwood | /etc/fstab ok? | 11:08 |
| ssam2 | this is not the same Jetson that had rootfs corruption errors, by the way | 11:08 |
| ssam2 | /etc/fstab is the same in both versions of /etc | 11:08 |
| ssam2 | i've different the whole of /etc and not found much of interest | 11:08 |
| ssam2 | I'm down to comparing SHA1s in /baserock/*.meta, but that will take a while... | 11:09 |
| paulsherwood | ssam2: if there's anything diff at all, please could you paste both? | 11:09 |
| ssam2 | *diff'ed, not different | 11:09 |
| ssam2 | sure | 11:09 |
| ssam2 | http://sprunge.us/FRMB | 11:10 |
| ssam2 | it's a bit of a dull read :) | 11:10 |
| ssam2 | clearly systemd has changed, maybe that is the issue | 11:11 |
| paulsherwood | you think? :) :-) | 11:12 |
| paulsherwood | ssam2: i have a jetson you could experiment on if that would help? | 11:13 |
| ssam2 | i've got 2 here | 11:13 |
| paulsherwood | heh | 11:13 |
| ssam2 | same issue with both | 11:14 |
| paulsherwood | :( | 11:15 |
| ssam2 | i've now verified the kernel is identical in both systems, and will try reverting the last change to the systemd ref in master | 11:15 |
| ssam2 | i wonder if the actual problem I'm trying to solve (.py files being overwritten with random hex strings on a Calxeda distbuild node) can be put down to systemd as well! | 11:16 |
| paulsherwood | that would be spooky | 11:17 |
| DavePage | paulsherwood: First draft of a VET one-pager for Genivi at https://docs.google.com/document/d/107rS_hwlUOklxFHKgggM3zziHYIYxgs0D_8hwbfSkqE/edit | 12:21 |
| DavePage | Oops, wrong window, sorry | 12:27 |
| *** DavePage has left #baserock | 12:27 | |
| radiofree | jonathanmaw: seems the demo platform uses a different weston? | 12:43 |
| radiofree | http://git.projects.genivi.org/?p=meta-genivi-demo.git;a=tree;f=recipes-graphics/wayland/weston;h=aa322319e3dd0b4cd00106703e71de6dd4a65c6f;hb=HEAD | 12:43 |
| radiofree | there's things like http://git.projects.genivi.org/?p=meta-genivi-demo.git;a=blob;f=recipes-graphics/wayland/weston/browser_poc_hack.patch;h=8714db19c7a0a2e1a5fc1d109e0f849bccc1d7e6;hb=HEAD | 12:43 |
| radiofree | though i have no idea how they turn http://git.projects.genivi.org/?p=meta-genivi-demo.git;a=blob;f=recipes-graphics/wayland/weston_1.5.0.bbappend;h=5f820b11e4b2344d4fbd9df5b1ab2801a794a5b4;hb=HEAD in to where to get the source from | 12:44 |
| jonathanmaw | radiofree: my best guess is that it's overlaid on top of meta-ivi's weston_1.5.0 | 12:45 |
| radiofree | jonathanmaw: i *think* https://github.com/ntanibata/weston-ivi-shell/tree/genivi-1.3.0 + ivi-extension 1.3.0 | 12:48 |
| radiofree | + ivi-shell-click-event.patch + 0001-Enable-disable-default-virtual-keyboard.patch on top of weston | 12:49 |
| radiofree | but that's a total guess really | 12:49 |
| radiofree | but they say they use ivi-extension 1.3.0, and the tarnyko branch was just weston 1.5.0 with whatever was around at the time from tanibata's repo patched on top | 12:50 |
| radiofree | this is going off http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/tree/meta-ivi/recipes-graphics/wayland/weston_1.5.0.bbappend | 12:50 |
| radiofree | i can't turn that into a source repo + branch | 12:50 |
| radiofree | there's a comment at the top Branch: genivi-1.2.0, but there is no genivi-1.2.0 branch in that tarnyko branch | 12:52 |
| radiofree | can anyone read yocto? do you know where the source for this is actually cloned from? | 12:52 |
| radiofree | jonathanmaw: http://git.yoctoproject.org/cgit/cgit.cgi/meta-ivi/commit/meta-ivi/recipes-graphics/wayland/weston_1.5.0.bbappend?id=0628e4d2a9bc07eb0c7cdc9eda5ba508ea1fb5ac | 12:57 |
| radiofree | i can't find "the one from yocto" though, probably just stock weston 1.5.0? | 12:58 |
| Zara | radiofree: I'm currently struggling with something similar. I thought the source just referred to the stuff in the 'weston' folder here, but maybe I'm misinterpreting the question | 13:00 |
| radiofree | aha,"the one from yocto" is in poky | 13:00 |
| radiofree | jonathanmaw: it's just a release tarball, either 1.5.0 or 1.6.0 (depending on the version of poky they are using) | 13:01 |
| radiofree | http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/wayland/weston_1.6.0.bb | 13:01 |
| radiofree | Zara: there's a SRC_URI for things | 13:02 |
| radiofree | but in the meta-ivi case that's not in that file, it inherits it from the yocto release | 13:02 |
| ssam2 | here's an exciting new bug (possibly caused by the systemd update) -- /etc/resolv.conf on a Baserock system lists 'nameserver 2001:4860:4860::8844' as its first entry, and DNS resolution doesn't work | 13:04 |
| ssam2 | it lists 8.8.8.8 as its second entry, and can ping 8.8.8.8 | 13:04 |
| ssam2 | and if I put 8.8.8.8 at the top, DNS resolution works | 13:04 |
| ssam2 | this might be a Busybox limitation that we've not hit before | 13:05 |
| bjdooks | resolver libraries try hard to use entry #1 | 13:05 |
| Zara | ah, okay, glad I've been warned about that because I haven't come across it yet. (It took me a long enough to work out what was going on when the SRC_URI pointed to files in a directory in the same repo as the recipe...) | 13:06 |
| ssam2 | bjdooks: to the extent of ignoring entry #2 completely? seems a bit dumb.. | 13:06 |
| ssam2 | not that dumb software should come as a surprise | 13:07 |
| bjdooks | it takes a long time to try #2 | 13:07 |
| persia | ssam2: Can you ping 2001:4860:4860::8844? | 13:08 |
| radiofree | Zara: for http://git.projects.genivi.org/?p=meta-genivi-demo.git;a=blob;f=recipes-graphics/wayland/weston_1.5.0.bbappend;h=5f820b11e4b2344d4fbd9df5b1ab2801a794a5b4;hb=HEAD i think that inherits meta-ivi, which inherits yocto | 13:08 |
| ssam2 | persia: PING 2001:4860:4860::8844 (2001:4860:4860::8844): 56 data bytes | 13:08 |
| ssam2 | ping: can't create raw socket: Address family not supported by protocol | 13:08 |
| radiofree | since there's no way it could ever work with the version from yocto | 13:08 |
| persia | Get a better ping, or try `ping6 ...` | 13:08 |
| ssam2 | ping6 gives same error. This is on Calxeda, the ipv6 driver may just not work ? | 13:09 |
| Kinnison | ssam2: Are you expecting ipv6 support? | 13:09 |
| bjdooks | it /should/ work, however do we have ipv6 support on office network? | 13:10 |
| Kinnison | Of course we don't | 13:10 |
| persia | ssam2: Or there is something else not working. Sounds like a system problem, rather than no working IPv6 routing (although that may also be the case, once you saolve the system problem) | 13:10 |
| ssam2 | Kinnison: I'm just expecting name resolution to work. I don't care about the protocol in this case | 13:10 |
| Kinnison | ssam2: aah | 13:11 |
| persia | Sadly, the resolver depends on having transport that works to the addresses in resolv.conf | 13:11 |
| persia | Maybe try not to use IPv6 there if IPv6 isn't working? | 13:12 |
| ssam2 | persia: /etc/resolv.conf is being created by systemd-network, so I suspect I need to do something about that | 13:13 |
| ssam2 | http://git.baserock.org/cgi-bin/cgit.cgi/delta/systemd.git/commit/?id=822db23cfa98a9fbc48f41e11caafb6f1017e052 may be the reason... | 13:15 |
| * persia looks | 13:16 | |
| persia | I don't blame that at all, and like that commit. | 13:17 |
| Zara | radiofree: is there an explanation of how the inheritance works anywhere? (or how to know if something is being inherited) (I'm looking at openbmc, so the specifics are different) | 13:17 |
| persia | If you're receiving a resolver list from DHCP, you should very much preserve the order, or face the wrath of the network maintainers. | 13:17 |
| persia | In your specific case, I'd recommend asking the folk who provide your DHCP to not provide an IPv6 resolver when providing an IPv4 address. | 13:18 |
| ssam2 | I've noticed that another machine on the same network uses an internal nameserver | 13:18 |
| persia | Since DHCP isn't used to provide IPv6 addresses, it is almost never a good idea to provide IPv6 nameservers in DHCP. | 13:18 |
| ssam2 | so this machine is probably doing something special by using 8.8.8.8 and that IPv6 address | 13:19 |
| ssam2 | it is on a different subnet. perhaps that's why we've not seen this issue before now | 13:19 |
| persia | It is worth tracking down the source of those values. | 13:19 |
| persia | If they are DHCP, the DHCP server is likely misconfigured. | 13:20 |
| persia | If it is not DHCP, something else interesting is happening that would be good to understand. | 13:20 |
| ssam2 | i'll try to track down what serves DHCP to this machine | 13:20 |
| persia | ssam2: A quick search suggests dhcping and dhquery might be useful tools for that, if you have to debug the protocol | 13:25 |
| persia | https://github.com/CyberShadow/dhcptest may also work, although it was originally developed for Windows | 13:27 |
| paulsherwood | 2015-04-17 13:25:21 [openstack-system-x86_64] Now cached as openstack-system-x86_64@ab44d6c512e382cd2df0401b2ea71c7d62dd5a5874528f97ae639138d42eab28 | 14:04 |
| *** zoli__ has quit IRC | 14:13 | |
| straycat | if anyone's got a moment to check out https://gerrit.baserock.org/#/c/368/ it's upstream's unit file modified so it restarts on-failure and comes after the swift setup. it only gets installed with swift | 14:17 |
| straycat | merged thanks | 14:24 |
| *** zoli__ has joined #baserock | 14:33 | |
| radiofree | Zara: i have no idea about documentation | 14:34 |
| radiofree | and i may be totally wrong about it, i'm just guessing that's how it works | 14:34 |
| *** zoli__ has quit IRC | 14:40 | |
| Zara | radiofree: no worries. fwiw I think you're right about it; I found something that looks similar in openbmc. (ie: https://github.com/facebook/openbmc/tree/master/meta-facebook/meta-wedge/recipes-wedge/lm_sensors seems to add some extra config to https://github.com/openembedded/meta-openembedded/tree/master/meta-oe/recipes-support/lm_sensors .) | 14:44 |
| pedroalvarez | Anybody fancies a bit of reviewing? https://gerrit.baserock.org/#/q/topic:baserock/openstack-in-baserock-3-nodes | 14:50 |
| *** cosm has joined #baserock | 14:52 | |
| pdar | If anyone has time to review my patches to integrate openstack's ceilometer service into the baserock openstack stuff I'd be most greatful. These are they https://gerrit.baserock.org/382, https://gerrit.baserock.org/383, and https://gerrit.baserock.org/384. | 14:55 |
| straycat | jjardon, i appreciate https://gerrit.baserock.org/#/c/385/1 but this is not a good time | 15:05 |
| straycat | give us a few days to let openstack settle and we can consider dropping the conf ext | 15:06 |
| straycat | it will require patching ntpd really | 15:06 |
| jjardon | straycat: sure, Ive just put it there before I forgot | 15:06 |
| paulsherwood | 2015-04-17 15:56:45 [genivi-baseline-system-x86_64-generic] Now cached as genivi-baseline-system-x86_64-generic@3addbab1d9f32c354e5e1431c517eea325a98927b4894a4e9045e6d0d4d40eb4 | 15:09 |
| radiofree | pdar: 383 and 384 already have +2? | 15:20 |
| radiofree | sorry, 382 and 383 | 15:20 |
| ssam2 | I don't have time to review anything this afternoon but I'm happy for anything that needs merging to be merged | 15:23 |
| pdar | radiofree: great! they were fresh off the press when I posted. Apologies. | 15:26 |
| pdar | thanks for the speedy reviews | 15:26 |
| *** mdunford has quit IRC | 15:34 | |
| *** mdunford has joined #baserock | 15:48 | |
| *** a1exhughe5 has quit IRC | 16:02 | |
| *** mdunford has quit IRC | 16:06 | |
| ssam2 | for those following the saga of the .py files being overwritten by random hex strings, I've managed to reproduce the problem with an x86 rootfs hosted on the same NFS server | 16:32 |
| ssam2 | so we can rule out random ARM / Calxeda issues as the cause | 16:33 |
| ssam2 | i guess now I'll try deploying the nfs root to my laptop | 16:34 |
| ssam2 | and see if the Trove nfs server is at fault | 16:34 |
| ssam2 | deploying the system to a rawdisk image didn't show the problem, so it is pointing to NFS | 16:34 |
| * pedroalvarez sends https://gerrit.baserock.org/388 | 16:39 | |
| pdar | how do I push revisions in gerrit? | 16:41 |
| ssam2 | if you use git-review, just git-review again (new commit with same change-id) | 16:41 |
| ssam2 | without git-review, push to wherever you pushed before (again, push a new commit with the same change-id as the change you're updating) | 16:42 |
| *** CTtpollard has quit IRC | 17:01 | |
| pdar | Thanks ssam2 | 17:01 |
| *** bashrc_ has quit IRC | 17:02 | |
| *** mdunford has joined #baserock | 17:03 | |
| *** Krin has quit IRC | 17:04 | |
| *** sambishop has quit IRC | 17:06 | |
| *** tiagogomes has quit IRC | 17:12 | |
| *** mariaderidder has quit IRC | 17:14 | |
| *** jonathanmaw has quit IRC | 17:18 | |
| *** gary_perkins has quit IRC | 17:20 | |
| *** edcragg has quit IRC | 17:24 | |
| *** paulw has quit IRC | 17:40 | |
| *** zoli__ has joined #baserock | 17:40 | |
| pedroalvarez | Wow! Openstack on Baserock!! | 17:41 |
| pedroalvarez | http://wiki.baserock.org/guides/openstack-on-baserock/ | 17:41 |
| *** franred has quit IRC | 17:41 | |
| rdale | are there any guidelines to using 'linux32' with a morph build? | 17:42 |
| jjardon | pedroalvarez: \o/ | 17:42 |
| ssam2 | rdale: if you're using a chroot, run 'linux32 enter-baserock' so the whole chroot sees 32-bit arch | 17:43 |
| ssam2 | i've never tried 'linux32 morph build xxx', but that should probably work too | 17:43 |
| rdale | thats what i'm doing | 17:43 |
| rdale | and stages 1 and 2 of gcc worked, but it is as though stage3 of gcc didn't get run under linux32 | 17:44 |
| ssam2 | weird. I don't know why, i'm afraid | 17:44 |
| jjardon | seems the ./native-bootstrap > build.log 2>&1 trick worked for ARMv5 as well | 17:44 |
| rdale | ssam2: i'll try starting a chroot under linux32 and see if that is any different | 17:44 |
| *** zoli__ has quit IRC | 17:45 | |
| *** sambishop has joined #baserock | 17:45 | |
| *** lachlanmackenzie has quit IRC | 18:21 | |
| ssam2 | so, booting a system off NFS from my laptop (when I finally got it to work) shows the same 'files being overwritten with random hex strings' bug | 18:29 |
| ssam2 | but the same system deployed to rawdisk did not | 18:29 |
| ssam2 | this doesn't make the slightest bit of sense. | 18:30 |
| *** ssam2 has quit IRC | 18:30 | |
| paulsherwood | erk | 19:07 |
| persia | I wonder if it might be related to https://bugzilla.redhat.com/show_bug.cgi?id=156307 | 19:10 |
| paulsherwood | that's a *long time ago* ? :) | 19:11 |
| persia | Essentially, the .pyc files are being written at runtime in many cases, and closely-timed writes and reads can cause issues with NFS. | 19:12 |
| persia | Faster networking, closer timesync, and some delays between compilation and read might help, but I'm not sure python works that way. | 19:12 |
| persia | Also, from the bug description, it sounds like it is really hard to reliably reproduce. Maybe also related to load on the NFS server, or something. | 19:12 |
| persia | The bug is old, but remains unsolved. Most projects (including RHEL) remove old bugs if they cannot be reproduced, assuming they were fixed upstream somehow. | 19:13 |
| persia | That this was closed "cantfix" suggests to me that it is an architectural issue with NFS. | 19:14 |
| ratmice__ | doesn't look like the .pyc compiler attempts to append to .pyc files afaict, NFS seems to have known issues with an inability to do atomic appends | 19:41 |
| persia | I thought the pyc compiler did overwrites. | 19:44 |
| persia | The bug I linked was about a race condition, where the overwrite is still in-process to the backing store, but the NFS server seems to get confused. | 19:45 |
| *** Albert__ has joined #baserock | 19:48 | |
| *** Albert_ has quit IRC | 19:48 | |
| ratmice__ | doesn't look like PEP-0304 ever happened, to allow you to specify where to generate/search for bytecode, and 3147 doesn't appear like it'd be any help | 20:02 |
| *** cosm has quit IRC | 21:17 | |
| *** cosm has joined #baserock | 21:34 | |
| *** Albert__ has quit IRC | 22:49 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!