*** wdutch_ has joined #baserock | 02:19 | |
*** wdutch has quit IRC | 02:21 | |
*** ratmice__ has quit IRC | 02:21 | |
*** ratmice__ has joined #baserock | 02:21 | |
*** zoli__ has joined #baserock | 05:36 | |
*** zoli__ has joined #baserock | 05:42 | |
*** zoli__ has quit IRC | 06:28 | |
*** zoli__ has joined #baserock | 06:29 | |
*** zoli__ has quit IRC | 06:30 | |
*** zoli__ has joined #baserock | 06:30 | |
*** zoli__ has quit IRC | 06:38 | |
*** zoli__ has joined #baserock | 06:38 | |
*** zoli__ has quit IRC | 06:51 | |
*** a1exhughe5 has joined #baserock | 08:08 | |
rdale_ | how do i add pylru to a baserock system to make the latest morph work? | 08:27 |
---|---|---|
petefoth | rdale_: details on http://wiki.baserock.org/guides/no-frills/, but basically | 08:28 |
petefoth | cd .. | 08:28 |
petefoth | git clone git://git.baserock.org/delta/python-packages/pylr | 08:28 |
petefoth | u | 08:28 |
rdale_ | ah ok - i was thinking it would use a python package manager, but for baserock that doesn't make sense | 08:29 |
petefoth | edit /usr/bin/morph as described on http://wiki.baserock.org/guides/no-frills/ | 08:29 |
rdale_ | yes, i've done that thank- it's working now i've install pylru | 08:31 |
petefoth | :) | 08:32 |
*** gfinney has joined #baserock | 08:33 | |
gfinney | good morning bench | 08:34 |
perryl | wrong window, gfinney? :) | 08:34 |
rdale_ | petefoth is doing some successful mentoring i believe | 08:35 |
perryl | :D | 08:35 |
gfinney | ha done it again! | 08:35 |
gfinney | When I start up it jumps from channel to channel and I get caught up in it. | 08:36 |
petefoth | :) | 08:37 |
*** jonathanmaw has joined #baserock | 08:46 | |
petefoth | apologies for multiple versions of the 'Add copyright headers...' patch. I will learn to address *all* review comments before resubmitting :) | 08:52 |
*** mdizzle has joined #baserock | 08:52 | |
*** bashrc has joined #baserock | 09:01 | |
Kinnison | win 23 | 09:08 |
Kinnison | oops | 09:08 |
*** edcragg has joined #baserock | 09:15 | |
*** CTtpollard has quit IRC | 09:17 | |
*** CTtpollard has joined #baserock | 09:24 | |
*** franred has joined #baserock | 09:26 | |
bashrc | in a definition file what does "landing" mean? | 09:46 |
rjek | I've not seen that before; could you give me some context? | 09:48 |
bashrc | I'm looking at the examples within firehose | 09:49 |
bashrc | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/firehose.git/tree/examples/linux-master.yaml | 09:50 |
pedroalvarez | definitons files doesn't have a "landing" field | 09:50 |
pedroalvarez | hm.. | 09:50 |
*** tiagogomes_ has joined #baserock | 09:51 | |
persia | That's just a configuration file for firehose: it happens to be yaml, and talk about repos, but isn't a definition at all. | 09:51 |
bashrc | another question is, in the above example how does the system know where the linux repo is? | 09:51 |
persia | I'm guessing, but I suspect from the baserock:baserock/definitions repo (or wherever is defined by landing:repo) | 09:52 |
SotK | I'd imagine it will use the repo defined in the stratum it references (although I may be completely wrong) | 09:52 |
bashrc | its tracking refs/heads/master, but how does it know where that is? | 09:52 |
persia | That's defined in the git repo for the "linux" chunk in the definitions. | 09:52 |
bashrc | ok | 09:52 |
persia | All that said, this format confuses me. I don't know why it needs all that info. | 09:53 |
bashrc | but the chunk definition is within landing, not tracking | 09:53 |
*** ssam2 has joined #baserock | 09:54 | |
*** ChanServ sets mode: +v ssam2 | 09:54 | |
persia | I think that makes sense because it refers to a chunk in the definitions for tracking, but I agree that this format is not particularly human-readable. | 09:54 |
*** Krin has joined #baserock | 09:57 | |
bashrc | definitions often seem to contain implicit information, which makes them not very human readable | 10:00 |
persia | Again, that isn't definitions at all. | 10:01 |
bashrc | also this might make them difficult to debug, except by manual grepping | 10:01 |
persia | So. to which implicit information do you refer? | 10:01 |
bashrc | things such as http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/strata/ruby/ruby.morph | 10:07 |
persia | What is implicit there? | 10:07 |
bashrc | any reference to where the code is coming from | 10:08 |
*** gary_perkins has joined #baserock | 10:08 | |
straycat | yes, it's a chunk morph, "where the code comes from" is defined in the stratum. | 10:09 |
persia | That belongs in the stratum. Since there is a one-to-many relationship between a chunk and the consuming strata, it has to be this way. Didn't we discuss this yesterday? | 10:09 |
bashrc | so in this case where is the stratum indicated? | 10:11 |
straycat | the stratum indicates where the chunk morph is, not the other way around | 10:11 |
persia | It *can't* be, because of the one-to-many relationship. | 10:11 |
Kinnison | In baserock, you don't get to think about "Ruby", you get think about "Ruby in the foobar stratum" | 10:12 |
franred | bashrc, when I read baserock definitions, I read them always from the top to the botton, clusters->systems->strata->chunks no in the other way around because if not you will miss lot of information | 10:12 |
SotK | `git grep "strata/ruby/ruby.morph"` will show you all the strata which use that chunk morphology | 10:13 |
straycat | https://bitbucket.org/pypa/setuptools/issue/356/importerror-has-no#comment-16095555 :( | 10:16 |
straycat | ssam2, "Should be $PREFIX/lib/systemd rather than /usr/lib/systemd" why? the systemd docs are quite clear the units go into /usr so why would it be $PREFIX? | 10:21 |
Kinnison | In case we ever build systemd with $PREFIX anything but /usr | 10:21 |
persia | e.g. for installing multiple systemds for testing | 10:22 |
straycat | Okay | 10:26 |
richard_maw | bashrc: persia has listed all the reasons why we initially had the repo/ref in the stratum, but that was also from a time before we had the chunk definition files in definitions.git, where it was much more important. We don't currently take advantage of the many to many relationship between strata and chunks anyway, since we put the chunk definition files in a subdirectory per-stratum. Right now it's mostly historical reasons and a lack of any | 10:30 |
Kinnison | cut off at 'lack of any...' | 10:31 |
Kinnison | richard_maw: ^^ | 10:31 |
richard_maw | lack of anyone providing the code to change it to allow the repo/ref in the chunk definition file | 10:31 |
richard_maw | thanks Kinnison | 10:31 |
bashrc | I see | 10:31 |
* Kinnison would have preferred the chunk morphologies in a top level chunks/ dir, but appreciates why we did it this way in the end | 10:32 | |
persia | I'd really not prefer that. If we're removing the potential to have many repos/refs to a chunk, I'd rather have a new file that just listed repos and refs for everything. | 10:32 |
persia | Kinnison: Unfortunately, at the time, we had not resolved the unique naming issue. | 10:32 |
Kinnison | persia: aye :( | 10:32 |
rdale_ | i tried to create a symbolic link in /bin for a chunk, but after the chunk was built i got an error when it was being set up in the staging area about a missing '/tools/bin' directory. when i created the link in /usr/bin everything was fine though | 10:34 |
persia | Ugh. The tools/bin issue should be entirely hidden by the completion of stage3 bootstrap. | 10:35 |
rdale_ | should i do some more investigation and report a bug? | 10:35 |
Kinnison | Certainly /tools shouldn't exist beyond build-essential stage 3 | 10:36 |
Kinnison | rdale_: are you manipulating things in build-essential? | 10:36 |
rdale_ | yes, i'm building musl in stage3 | 10:36 |
Kinnison | Aah, then yes you need to be careful about links | 10:36 |
pedroalvarez | ssam2, franred: I've changed more things in attr.morph, do you want me to resend? | 10:37 |
pedroalvarez | Well, I'll paste it here just in case: http://paste.baserock.org/ifumepopeh | 10:38 |
straycat | richard_maw, lack of anyone providing code for inlining chunks, with that | 10:39 |
franred | pedroalvarez, looks ok to me, and I trust you have tested it intensively, I don't need a v2 to give you a +1 | 10:40 |
pedroalvarez | I kind of think that it isn't whitespace safe, though | 10:41 |
persia | It is whitespace safe, but not quote-safe. | 10:42 |
Kinnison | My team is encountering a 'fun' issue with networkd -- our M400 nodes have 2 network interfaces, both have link and both have DHCP available on them -- both are needed in order for a node to behave properly (one internal network for NFS root, one external for internetworking) -- networkd seems to pick only one and shut down the other -- is there an easy config tweak to fix this? | 10:43 |
pedroalvarez | persia: :/ | 10:45 |
persia | pedroalvarez: IF you can figure out who to cause morph to put '"' in $PREFIX, you win. If not, you don't. | 10:46 |
pedroalvarez | It would have been easier to send a patch removing /usr/lib/*la files | 10:46 |
persia | Kinnison: For the multiple-interface case, the networkd docs seem to indicate defining a bridge. | 10:48 |
Kinnison | a bridge?! | 10:48 |
Kinnison | but these are separate networks | 10:48 |
Kinnison | i need the units to DHCP on *both* | 10:48 |
richard_maw | I've not seen anything to suggest that a bridge would be required | 10:48 |
persia | If that isn't what you want, then you're probably operating outside the "simple setups such as VMs or containers" that networkd is designed to solve. | 10:48 |
richard_maw | but I've not seen anything that should cause it to only DHCP on one interface either | 10:49 |
persia | Kinnison: Right. The most common case of two interfaces connected to a network is when one wants to team them, which is a different use-case. | 10:49 |
Kinnison | persia: aye, I appreciate this is not the common case, but I need to solve it :) | 10:49 |
richard_maw | persia: networkd is also supposed to scale to static network configuration for servers, replacing /etc/network/interfaces | 10:49 |
persia | richard_maw: Yes, but is it supposed to scale to dynamic network configuration for servers, routers, etc.? | 10:50 |
persia | I think it should, but I'm not sure the networkd folk agree with me. | 10:50 |
* persia always preferred to use dynamic networking for servers when a sysadmin | 10:50 | |
Kinnison | richard_maw: any idea what I should do? | 10:51 |
richard_maw | Kinnison: I'd suggest adding `[Service]\nEnvironment=SYSTEMD_LOG_LEVEL=debug\n` to systemd-networkd.service and looking at what it does with `journalctl -b -u systemd-networkd` | 10:51 |
richard_maw | it ought to DHCP on both interfaces | 10:51 |
Kinnison | I think it does, then whichever answers first wins and the other is shut down | 10:52 |
richard_maw | what does `networkctl` say? | 10:52 |
* Kinnison will have to go back to his colleagues and ask, thanks for the ideas, I'll make sure they're tried | 10:52 | |
richard_maw | what version of systemd do you have running on those nodes? | 10:52 |
Kinnison | I think something close to whatever is in master of definitions | 10:53 |
persia | Kinnison: If you can convince your collegues to join, it might be useful to have more direct conversation to investigate this sort of issue. | 10:53 |
richard_maw | 219 is in master then | 10:53 |
richard_maw | Kinnison: if it turns out that the second device does DHCP, but then shuts itself down before the lease expires, I think I saw someone in #systemd with the same problem, though he was running a frankenrelease | 10:56 |
pedroalvarez | attr fails to build with prefix: "/us er" and with prefix: /usr\" | 10:59 |
richard_maw | Kinnison: oh, and if you're running v219 of systemd, you can do `systemctl edit systemd-networkd`, and it'll open a text editor on a drop-in file | 11:00 |
pedroalvarez | ... and reload the unit once you are done | 11:00 |
persia | pedroalvarez: What is the error with "/us er"? | 11:01 |
richard_maw | pedroalvarez: can you try using single-quotes for the LOCAL_CONFIGURE_OPTIONS, so $PREFIX gets interpolated later? If so, you may be able to replace $PREFIX with "$PREFIX" in the string | 11:01 |
jjardon | richard_maw: thats cool | 11:02 |
jjardon | but I think it was available in 218 already? | 11:02 |
Kinnison | persia: :) | 11:05 |
Kinnison | kejiahu: Will you be able to try the suggestions from richard_maw? | 11:05 |
kejiahu | Kinnison, yes I am trying | 11:06 |
Kinnison | kejiahu: awesomesauce | 11:06 |
kejiahu | richard_maw: here is output of journalctl -b -u systemd-networkd https://admin.codethink.co.uk/pnopaste/?2452 | 11:07 |
jjardon | kejiahu: How the .network file(s) look like? | 11:10 |
jjardon | kejiahu: problably the fastest way is to ask in #systemd though | 11:11 |
edcragg | kejiahu: also, do you have internet connectivity after that? | 11:12 |
kejiahu | jjardon, what .network files are you talking about. | 11:13 |
kejiahu | edcragg, no the internet is not fixed on this node yet, I can provide a log after fix | 11:13 |
edcragg | /etc/systemd/network | 11:13 |
jjardon | kejiahu: Do you have any file in /etc/systemd/network/ ? | 11:13 |
kejiahu | jjardon: yes, https://admin.codethink.co.uk/pnopaste/?2453 | 11:14 |
edcragg | kejiahu: ok, i have a log for where it seems to configure properly, to compare | 11:15 |
edcragg | s/i/i will shortly/ | 11:15 |
jjardon | kejiahu: try to change DHCP=yes with DHCP=ipv4 | 11:15 |
edcragg | jjardon: yes, that's needed | 11:17 |
edcragg | networkd causes 70% CPU load with DHCP=yes on these systems | 11:20 |
kejiahu | edcragg, I seems be able to restart networkd and add ip route without specify DHCP=ipv4. here is the log after https://admin.codethink.co.uk/pnopaste/?2454 | 11:20 |
persia | Please post that somewhere we cal all read it? Perhaps http://paste.baserock.org? | 11:21 |
edcragg | kejiahu: i guess you have internet now, then? what about after reboot? | 11:21 |
kejiahu | persia: sorry, http://paste.baserock.org/uwokelibuw | 11:22 |
*** petefoth has quit IRC | 11:22 | |
kejiahu | edcragg, after reboot, it will lost the change | 11:22 |
edcragg | how come? | 11:22 |
*** petefoth has joined #baserock | 11:23 | |
kejiahu | edcragg, http://paste.baserock.org/aseminarav I have to re-apply the fix every time after reboot | 11:24 |
richard_maw | kejiahu: I didn't mean you should put the \n in the config file, I just didn't want to paste line breaks into IRC :¬) | 11:26 |
jjardon | kejiahu: can we see the log after the DHCP=ipv4 change? | 11:28 |
kejiahu | richard_maw, http://paste.baserock.org/ogowideqoh | 11:28 |
edcragg | kejiahu: you're missing a network interface terry | 11:29 |
kejiahu | edcragg, yes, it won't come up after rebooting | 11:29 |
kejiahu | edcragg, I have to manually turn it on every time | 11:30 |
jjardon | kejiahu: and what version of systemd is this? can you run systemctl --version? | 11:30 |
kejiahu | jjardon: it's 219 | 11:30 |
pedroalvarez | This attr thing is becoming really annoying :/ http://paste.baserock.org/hibugiwavo | 11:31 |
kejiahu | here is the log if I manually turn on the interface http://paste.baserock.org/qedaberalo | 11:33 |
richard_maw | kejiahu: this may not be related to your networking going away, but can you run `zcat /proc/config.gz | grep CONFIG_IPV6`? It may explain why you're chewing CPU if you don't turn it off. | 11:33 |
nowster | I read that interface name as EPNS... and thought about spoons. | 11:34 |
nowster | pedroalvarez: looks like something's gone very wrong with the environment variables | 11:34 |
nowster | eg. configure: error: expected an absolute directory name for --exec_prefix: "REFIX" | 11:35 |
persia | richard_maw: IPv6 needs to be disabled or CPU is used? | 11:35 |
kejiahu | richard_maw, it's # CONFIG_IPV6 is not set | 11:36 |
richard_maw | persia: I'm thinking more along the lines of systemd not expecting IPv6 to be disabled in the kernel, so it keeps retying | 11:36 |
richard_maw | Given the "Address family not supported by protocol" messages when it fails to bring the link up, I suspect it may be causing both issues | 11:37 |
persia | richard_maw: That makes sense. I think it's a bug in systemd to do that, but I can well imagine nobody considering the case where it is disabled. | 11:37 |
* Kinnison is confused as to why it's disabled, but imagines noone decided to turn it on in the arm64 defconfig | 11:38 | |
Kinnison | Well, we now know that we should add IPV6 to the list of things to turn on for "baserock compatibility" in our BSPs :) | 11:38 |
*** franred has quit IRC | 11:38 | |
richard_maw | having poked around in systemd.git, it looks like that's the cause, it has no detection for whether ipv6 is possible, and it has no logic to retry the link up without ipv6 | 11:41 |
Kinnison | Oh dear | 11:42 |
Kinnison | thanks | 11:42 |
Kinnison | kejiahu: add scripts/config -e IPV6 | 11:42 |
Kinnison | kejiahu: to the list of things in the .morph for the kernel in the M400 BSP | 11:43 |
Kinnison | that should fix things | 11:43 |
kejiahu | Kinnison: ok thanks | 11:45 |
richard_maw | If we've ever got a good reason to not have ipv6 on a system I'm sure #systemd would be interested in a patch, but I fear it would require someone with really good knowledge of how netlink operates. | 11:48 |
Kinnison | Surely you'd start with just trying to create an AF_INET6 socket and if that fails, just not bother setting it up | 11:48 |
paulsherwood | bwh: ^^ ? :-) | 11:49 |
richard_maw | Kinnison: AIUI they pack all the network config into one message, so it's atomic and needs fewer context switches, so you'd have to re-try the transaction without the AF_INET6 bits, and I see no evidence that the protocol tells you exactly which bit is wrong | 11:50 |
Kinnison | richard_maw: my point is, before you start network config, try and make an inet6 socket, if that fails, it's not worth packing the bits into the netlink message | 11:50 |
Kinnison | richard_maw: rather than trying to understand the error return, don't do the bad thing in the first place | 11:51 |
Kinnison | :) | 11:51 |
pedroalvarez | ssam2: thank you for your idea, it solved my issues with attr: http://paste.baserock.org/pikigudiso | 11:57 |
jjardon | So did the change DHCP=yes with DHCP=ipv4 solve the issue? or you still need to rebuild the kernel? | 11:58 |
*** franred has joined #baserock | 12:00 | |
franred | pedroalvarez, +1 to that version, it looks nicer | 12:05 |
pedroalvarez | franred: thanks :) | 12:06 |
jjardon | kejiahu: ^^ Im genuinely curious :) | 12:15 |
tiagogomes_ | I know that with DHCP=yes networkd has ~70% of cpu usage | 12:18 |
kejiahu | jjardon: with DHCP set to ipv4, the interface still doesn't come up automatically after reboot, but if I turn it on manually it will get an address | 12:18 |
kejiahu | jjardon, without ipv4 setting, after turnning on the interface, I have to manually add ip route to it | 12:19 |
paulsherwood | kejiahu: i assume a manual solution is not a real solution? | 12:20 |
kejiahu | paulsherwood, ideally it should set up ips during kernel booting. so Kinnison's fix should solve that. | 12:21 |
paulsherwood | kejiahu: ok :-) | 12:22 |
paulsherwood | pedroalvarez: what has happened to http://mason-armv7lhf.baserock.org? | 12:26 |
ssam2 | its build network is on pedro's desk :) | 12:28 |
paulsherwood | hah :) | 12:29 |
pedroalvarez | I really want to set it up again | 12:36 |
rdale_ | m4-tarball will only build with aclocal-1.14, and baserock has aclocal-1.15 - so i can't understand how m4 builds | 12:48 |
tiagogomes_ | rdale_ probably because we are not autoreconfiguring, so no need to run aclocal & friends | 12:50 |
rdale_ | i'm running the same command as in m4-tarball.morph - ./configure --prefix="$PREFIX" and so i would expect to do the same thing | 12:51 |
rdale_ | ah wait | 12:51 |
rdale_ | it doesn't call 'make' after that which is where it is going wrong for me | 12:52 |
kejiahu | can I distbuild only based on local repo? and not pushing it to remote origin? | 12:52 |
pedroalvarez | kejiahu: if there are local changes the code has to be pushed somewhere so all the workers get the same version | 12:53 |
pedroalvarez | s/code/definitions/ | 12:53 |
kejiahu | pedroalvarez, oh, yes, thanks | 12:55 |
bwh | paulsherwood: About IPv6 detection? | 12:55 |
bwh | It seems to be a complicated question | 12:56 |
bwh | but trying to create a socket seems like a reasonable way of detecting whether there's any point trying to set addresses | 12:58 |
bwh | Does systemd(-networkd) break if you put ipv6.disable=1 in kernel or module parameters? | 13:00 |
*** zoli__ has joined #baserock | 13:11 | |
paulsherwood | bwh: seemed folks were straying deep into networking and i immediately thought of you :) | 13:44 |
paulsherwood | kejiahu: can you answer the systemd question? | 13:45 |
pedroalvarez | [gcc] Elapsed time 00:10:49 | 13:46 |
paulsherwood | pedroalvarez: on which box? | 13:47 |
pedroalvarez | in a normal VM where it used to take 1h | 13:47 |
paulsherwood | whoah. what happened? | 13:47 |
persia | Didn't we stop building the tests that we weren't running anyway? | 13:48 |
kejiahu | paulsherwood, sorry I can't try that, as the system is netbooted, and kernel parameters are defined in some config file on the servers | 13:48 |
paulsherwood | kejiahu: can you create a vm to try it, on (say) x86? | 13:48 |
pedroalvarez | paulsherwood: not sure, maybe is time to measure the build times again? | 13:50 |
paulsherwood | pedroalvarez: sounds like a good idea - if i recover my jetson | 13:50 |
pedroalvarez | :) | 13:51 |
pedroalvarez | persia: I think we haven't stop building the tests yet, though | 13:52 |
pedroalvarez | somehow I don't trust this super-fast build time :/ | 13:53 |
paulsherwood | pedroalvarez: is this defs master, morph master? | 13:53 |
pedroalvarez | yes | 13:54 |
pedroalvarez | (some genivi changes on top) | 13:54 |
pedroalvarez | (not low level changes) | 13:54 |
* persia dislikes that people have to ask "which morph" when a morph is defined in definitions | 13:54 | |
paulsherwood | that's interesting... are you proposing that somehing should cause the morph defined in definitions to be the one that builds it? | 14:02 |
pedroalvarez | that sounds like dark magic to me | 14:03 |
kejiahu | paulsherwood, yes, I'll try it | 14:04 |
paulsherwood | not really.. a script could parse definitions, checkout morph, run it :) | 14:04 |
pedroalvarez | then you can't define systems that don't include morph? | 14:04 |
paulsherwood | pedroalvarez: true. | 14:05 |
pedroalvarez | I agree it's doable, but scary | 14:05 |
paulsherwood | fine shot, sir. | 14:05 |
persia | paulsherwood: Rather, I think the default behaviour for users should be to use the morph defined in definitions. | 14:05 |
persia | If one isn't using it, morph should warn, and users should probably upgrade to the devel defined in their definitions to continue. | 14:05 |
persia | I actively don't want magic involved in the process. | 14:06 |
paulsherwood | persia: i assume you mean some central 'version' of morph defined in, say, the VERSION file, rather than any morph specified in a system? | 14:07 |
persia | No, I mean the version of morph specified in a system. | 14:07 |
persia | There was a conversation earlier about removing the many-many relationships, so that a given commit of definitions only had a single version of every component defined. | 14:08 |
paulsherwood | i fear pedroalvarez already hit that idea firmly between the eyes? | 14:08 |
persia | where/when? | 14:08 |
* persia missed it, but would be happy to understand why it ought be dead | 14:09 | |
paulsherwood | it requires that there is a morph in the system to be built | 14:09 |
paulsherwood | unless, as per ybd, all definitions are parsed, and each component is uniquely definied | 14:09 |
persia | Regardless of ybd, I thought those were expected features of definitions v1. | 14:10 |
paulsherwood | not v1. we proposed that early versions would be tiny increments, to oil the process of versioning | 14:11 |
paulsherwood | jjardon has already posted patches for v1 | 14:12 |
persia | Ah, makes sens. | 14:12 |
tiagogomes_ | pedroalvarez, what's wrong with [gcc] Elapsed time 00:10:49 | 14:14 |
pedroalvarez | tiagogomes_: it built too fast, don't you think? | 14:15 |
pedroalvarez | I may have a super-VM and never realised | 14:15 |
pedroalvarez | tiagogomes_: it used to take around 1h (IIRC) | 14:15 |
tiagogomes_ | pedroalvarez when took around 1h? In armv8 IIRC it takes 8m | 14:16 |
pedroalvarez | tiagogomes_: before your upgrade | 14:16 |
tiagogomes_ | pedroalvarez, mmm, I activated some optimizations for stage2 gcc which could make stage3 gcc build faster | 14:20 |
pedroalvarez | great | 14:20 |
tiagogomes_ | particularly PPL and CLooG | 14:21 |
pedroalvarez | these are some build-times from some time ago: http://wiki.baserock.org/build-times/ | 14:21 |
radiofree | that's some optimisation... | 14:26 |
radiofree | previous jetson build time 01:30:33 [gcc] | 14:26 |
radiofree | when i built it the other day 2015-02-27 16:32:14 INFO [Build 21/192] [gcc] Elapsed time 00:22:00 | 14:26 |
pedroalvarez | radiofree: good to know :) | 14:27 |
*** wdutch_ is now known as wdutch | 14:28 | |
tiagogomes_ | yes, impressive optimization | 14:29 |
paulsherwood | radiofree: on jetson? | 14:32 |
rdale_ | if i run make in a chroot of a failed baserock chunk, make seg faults - is there some env variable i need to setup to stop that? | 14:34 |
bashrc | is there anyone knowledgable on morph plugins? | 14:34 |
radiofree | paulsherwood: yes that's on jetson | 14:34 |
pedroalvarez | rdale_: I hit the same error yesterday and I couldn't figure out why :/ | 14:36 |
rdale_ | oh dear - it make it hard to track down build problems | 14:36 |
pedroalvarez | rdale_: yes.. | 14:37 |
pedroalvarez | rdale_: I'd like to fix that, or at least undesrtand why is happening | 14:38 |
rdale_ | yes, i'm going to see if i can build strace and include it in my failed chunk - i don't have any debug tools otherwise | 14:38 |
tiagogomes_ | I hit the same problem in the past multiple times when I was hacking on build essential | 14:39 |
rdale_ | oh - and you didn't find a fix either? | 14:39 |
kejiahu | bwh, just tried to add ipv6.disable=1 in kernel command line, it seems it doesn't break systemd, but doesn't help with the network issue on moonshot nodes neither. | 14:40 |
tiagogomes_ | rdale_, I didn't investigated the root cause. try to copy your host strace into the the failed temp and then chroot | 14:41 |
rdale_ | i need an strace built with musl i think | 14:41 |
tiagogomes_ | ah | 14:42 |
tiagogomes_ | rdale_, you can also try chrooting with linux-user-chroot instead | 14:43 |
rdale_ | ah ok - i didn't know about that | 14:43 |
radiofree | the old morph logs used to give you the chroot command after a failed build | 14:44 |
radiofree | so you could just copy and paste that | 14:44 |
tiagogomes_ | rdale_, see command that morph uses to chroot, and use that. If it works for morph, it has to work for you as well | 14:44 |
rdale_ | right | 14:44 |
radiofree | for some reason the logs were changed and now it just gives me a load of non-useful information | 14:44 |
tiagogomes_ | radiofree, that was *very* handy | 14:44 |
radiofree | yeah i used it all the time | 14:45 |
rdale_ | yes, i find it annoying to keep having to change 'staging' to 'failed' in the path you do get | 14:45 |
jjardon | radiofree: file a bug report | 14:45 |
tiagogomes_ | rdale_, indeed, I felt that pain when updating gcc | 14:45 |
* richard_maw thought he saw a patch get merged to fix the s/staging/failed/ | 14:46 | |
radiofree | it did | 14:46 |
tiagogomes_ | radiofree, it would be even better if morph showed the chroot command in stderr if it failed | 14:46 |
paulsherwood | [Build 21/128] [gcc] Elapsed time 00:10:14 | 14:47 |
paulsherwood | (on macbookpro) | 14:47 |
radiofree | tiagogomes_: agree | 14:48 |
radiofree | this is the new output http://fpaste.org/193834/66907142/ | 14:48 |
radiofree | it's pretty horrific to extract the chroot command from that | 14:49 |
rdale_ | ah i've got the s/staging/failed/, it's just that i hadn't noticed | 14:50 |
radiofree | are there any plans to get a valid ssl certificate for gbo? | 14:52 |
bwh | kejiahu: I didn't expect it to help! What I meant was if ipv6 is enabled but you use that parameter, does systemd-networkd break the same way | 14:52 |
kejiahu | bwh, there are extra lines saying discovering ipv6 and can't start discovery. other than that, the behavours of interface seems to be the same as before http://paste.baserock.org/xiyupuzave | 15:03 |
*** tiagogomes_ has quit IRC | 15:05 | |
bwh | kejiahu: Well that seems like graceful feature, not like what was described before | 15:05 |
bwh | s/feature/failure/ | 15:05 |
bwh | I can't find the beginning of the discssion now, but you said you had to fix something up | 15:08 |
kejiahu | bwh, oh, thanks, my issue has been solved by Kinnison's suggestion. I was only replying to your particular question about adding the thing to kernel parameter | 15:12 |
kejiahu | pedroalvarez, regarding the distbuild, you mentioned I have to push definition somewhere to let all the workers work on the same thing. does this 'somewhere' necessarily to be the trove defined with the workers? or anywhere they can access? if the latter, how to define where should the workers look for it? | 15:15 |
pedroalvarez | kejiahu: first of all, note that you don't have to push anything it that already exists (e.g. building master of definitions.git) | 15:17 |
*** tiagogomes_ has joined #baserock | 15:19 | |
pedroalvarez | to change what torve the distbuild network uses for sources, you can change /ect/distbuild/distbuild.conf (TROVE_HOST and TROVE_ID) and then restart the distbuild-setup unit `systemctl restart distbuild-setup` | 15:20 |
kejiahu | pedroalvarez, thanks | 15:23 |
pedroalvarez | s/torve/trove/ | 15:24 |
tiagogomes_ | why extlinux.conf is only installed by default for x86? This impedes using system-version-manager on arm systems, unless you set BOOTLOADER_CONFIG_FORMAT | 15:32 |
radiofree | we use it on jetsons | 15:36 |
radiofree | tiagogomes_: http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/definitions.git/tree/clusters/jetson-upgrade.morph | 15:36 |
radiofree | not all versions of u-boot have sysboot built in (though i don't see any reason why it's not a default for everything now...) | 15:37 |
tiagogomes_ | radiofree, even without sysboot, you could use system-version-manager to set the version to run no? At least that's my pla | 15:38 |
tiagogomes_ | plan | 15:38 |
radiofree | you could yes, just change the default subvolume to the new one | 15:39 |
radiofree | this is going to cause problems if the update fails though... | 15:39 |
radiofree | did you look at using sysboot? | 15:39 |
radiofree | also how will you do kernel upgrades? system-version-manager knows about "BOOT_PARTITION", but i suppose if you're not going to use sysboot you'd need to have it generate a new boot.scr, or use symlinks | 15:42 |
tiagogomes_ | I didn't look at using sysboot | 15:43 |
tiagogomes_ | why do I need a new boot.src? | 15:44 |
edcragg | I wouldn't be surprised if sysboot isn't supported in this U-Boot | 15:44 |
radiofree | it is | 15:44 |
edcragg | radiofree: how do you know? | 15:44 |
radiofree | because a) i read through the source and b) the sysboot command worked | 15:44 |
radiofree | and c) it uses pxe boot which is in the same command | 15:45 |
radiofree | the sysboot command "worked" (i.e we know it's on there) but there was an error with the config file | 15:45 |
radiofree | i suggested multiple things, multiple times via multiple platforms to try and get it working | 15:46 |
radiofree | then lost the will to live | 15:46 |
edcragg | ah, ok | 15:46 |
radiofree | trying to get sysboot working should be a 10 minute job | 15:47 |
radiofree | + however it takes to reboot if something goes wrong | 15:47 |
radiofree | s/however/however long | 15:47 |
*** zoli__ has quit IRC | 15:48 | |
edcragg | in that case i think i missed the benefits / implications of using sysboot in the handover | 15:49 |
tiagogomes_ | radiofree, with sysboot, kernel and device tree can be on a btrfs partition? | 15:49 |
edcragg | think we still need an ext partition | 15:49 |
radiofree | no, system-version-manager will respect BOOT_PARTITION and update the extlinux.conf there | 15:49 |
radiofree | copy over the kernel + device tree as well | 15:50 |
*** petefoth has quit IRC | 15:50 | |
radiofree | you shouldn't have to change anything in system-version-manager if you get sysboot working | 15:50 |
radiofree | actually you will, your version of uboot doesn't understand "devicetree" | 15:52 |
edcragg | how do we get around that? | 15:52 |
radiofree | here's my extlinux.conf from my jetson (which is on mmcblk0p1 which is a ext4 partition) http://fpaste.org/193856/25570755/ | 15:52 |
radiofree | edcragg: s/devicetree/fdt/ | 15:53 |
* Kinnison notes that in the next firmware update that may change | 15:54 | |
radiofree | if that doesn't break extlinux on x86, you can submit a patch to the part of morph/system-version-manager that uses "devicetree" | 15:54 |
*** wschaller has joined #baserock | 15:55 | |
radiofree | Kinnison: updated u-boot? | 15:55 |
Kinnison | radiofree: who knows :( | 15:55 |
Kinnison | radiofree: HP are sadly very close-lipped about what they're up to | 15:55 |
Kinnison | it's due by the end of the month | 15:55 |
Kinnison | but we need to have moved onto other work by then | 15:55 |
tiagogomes_ | radiofree, so to be clear, if sysboot works the kernel and device tree can be in a btrfs partition. Only boot.src and extlinux.conf needs to be on ext2? | 15:56 |
radiofree | tiagogomes_: no, the kernel and fdt need to be on the ext4 partition as well | 15:56 |
radiofree | tiagogomes_: i mirrored the btrfs layout on the ext4 partition to make system-version-manager work without loads of changes | 15:57 |
radiofree | tiagogomes_: this is the layout of my ext4 boot partition http://fpaste.org/193860/14255710/ | 15:58 |
tiagogomes_ | ah, I see | 15:59 |
*** fay_ has quit IRC | 16:00 | |
tiagogomes_ | radiofree, but why boot.src needs to be updated for upgrades? | 16:00 |
radiofree | no, boot.scr would just call sysboot | 16:00 |
radiofree | hold on | 16:00 |
tiagogomes_ | I will expand: why boot.src needs to be updated for upgrades if we *don't* use sysboot | 16:01 |
Kinnison | boot.scr ought not to need updating if we use sysboot, and in theory *if* the u-boot honours symlinks it wouldn't need to be updated without sysboot | 16:01 |
radiofree | if you use symlinks you probably won't need to update boot.scr if you're not using sysboot | 16:02 |
Kinnison | indeed | 16:02 |
radiofree | but the process of recovering from a failed upgrade won't be as nice.. you wouldn't have a menu to select factory | 16:02 |
Kinnison | Our user has accepted that short-term they may have to re-schedule the hardware if an upgrade fails | 16:03 |
radiofree | tiagogomes_: something like http://fpaste.org/193864/14255715/ should work | 16:06 |
tiagogomes_ | why u-boot needs to honour symlinks? I was thinking when doing an upgrade, to just copy kernels and device trees to /boot if we detect a separate boot partition. The only symblink that I see is on "rootflags=subvol=systems/default/run", but that is passed to the kernel, not processed by u-boot | 16:06 |
* tiagogomes_ is starting to get confused of what approach to follow | 16:07 | |
*** franred has quit IRC | 16:07 | |
radiofree | tiagogomes_: what if you upgrade the kernel? | 16:07 |
radiofree | or device tree | 16:08 |
radiofree | tiagogomes_: http://fpaste.org/193865/42557165/ is better, sysboot -p.... | 16:08 |
radiofree | you create the boot.scr from the boot.script | 16:08 |
*** jonathanmaw has quit IRC | 16:08 | |
radiofree | also, replace ${baudrate} with the actual baudrate | 16:08 |
tiagogomes_ | radiofree, I would copy the new kernel and device trees to the ext boot partition from systems/default/run/boot | 16:09 |
tiagogomes_ | but probably I'm missing something | 16:09 |
radiofree | tiagogomes_: and overwrite the existing kernel? | 16:09 |
radiofree | if uImage -> myFirstKernel, and you copy over mySecondKernel and update the symlink uImage -> mySecondKernel it should be ok | 16:10 |
radiofree | or you update boot.scr to use mySecondKernel directly | 16:10 |
radiofree | or as part of your recovery procedure state that you have to go into the previous version, manually copy out the kernel and device tree and copy them to the ext partition as well... which just seems like more work | 16:11 |
*** zoli__ has joined #baserock | 16:13 | |
tiagogomes_ | ta radiofree | 16:14 |
*** fay_ has joined #baserock | 16:14 | |
radiofree | tiagogomes_: i'm pretty sure you don't need to modify system-version-manager at all though, even if you don't use boot.scr to sysboot | 16:17 |
radiofree | http://fpaste.org/193873/55722171/ | 16:17 |
radiofree | in your upgrade cluster make sure you set ROOT_DEVICE: "/dev/sda2" and BOOT_DEVICE: "/dev/sda1" | 16:18 |
*** zoli__ has quit IRC | 16:19 | |
radiofree | tiagogomes_: i just noticed system-version-manager will error if there's no /extlinux.conf or /extlinux/extlinux.conf found | 16:22 |
radiofree | in self._get_extlinux_path() | 16:22 |
tiagogomes_ | yes I know | 16:22 |
radiofree | probably better to change _rewrite_boot_menu to not do anything if _get_extlinux_path() returns false | 16:22 |
tiagogomes_ | BOOTLOADER_CONFIG_FORMAT: extlinux should have solved it | 16:22 |
radiofree | tiagogomes_: you'll probably have an extlinux.conf on /dev/sda2 | 16:23 |
radiofree | mount /dev/sda2 /mnt | 16:23 |
* tiagogomes_ checks | 16:23 | |
radiofree | if should be in /mnt/extlinux.conf | 16:23 |
tiagogomes_ | It is not | 16:24 |
tiagogomes_ | odd, I'll redeploy | 16:24 |
radiofree | tiagogomes_: but you have state/ and systems/ ? | 16:24 |
tiagogomes_ | I've | 16:25 |
tiagogomes_ | one thing at a time | 16:25 |
tiagogomes_ | I am going to give a try at sysboot | 16:26 |
radiofree | no i just find it odd that you don't have an extlinux.conf there if you have state/ and systems/ | 16:26 |
radiofree | yes try sysboot, will make life much easier | 16:26 |
tiagogomes_ | Retrieving file: /extlinux.conf | 16:30 |
tiagogomes_ | Error reading config file | 16:30 |
tiagogomes_ | Booting PXE | 16:30 |
tiagogomes_ | radiofree, ^^ | 16:31 |
radiofree | what about the "load" command | 16:31 |
radiofree | did you see "Read foo bytes" or something | 16:31 |
tiagogomes_ | 163 bytes read in 14 ms (10.7 KiB/s) | 16:31 |
tiagogomes_ | ## Executing script at 4004000000 | 16:31 |
tiagogomes_ | 441 bytes read in 28 ms (14.6 KiB/s) | 16:31 |
tiagogomes_ | Retrieving file: /extlinux.conf | 16:31 |
radiofree | ok so it's not that it can't find the file | 16:32 |
radiofree | what does your extlinux.conf look like? | 16:32 |
radiofree | and you're using sysboot -p? | 16:32 |
tiagogomes_ | radiofree, http://paste.baserock.org/icoxizotud | 16:35 |
tiagogomes_ | yes, sysboot -p | 16:35 |
radiofree | hmm, get rid of the load command now | 16:39 |
radiofree | (in boot.scr) | 16:39 |
tiagogomes_ | I din't have extlinux.conf because I set BOOTLOADER_CONFIG_FORMAT on the installer system, not the system to be installed, doh! | 16:40 |
* tiagogomes_ obeys | 16:40 | |
radiofree | it's odd because pxe boot uses a lot of the same code | 16:41 |
tiagogomes_ | I assume the whole line | 16:41 |
radiofree | yeah, remove the whole "load ...." command | 16:41 |
tiagogomes_ | radiofree, http://paste.baserock.org/odawuyeduh | 16:43 |
radiofree | tiagogomes_: it needs more investigating, and i don't have the source code for your u-boot here | 16:47 |
radiofree | probably best to park this for now | 16:47 |
radiofree | if your installer copies extlinux.conf to your ext4 partition, and copies the kernel + device tree to /systems/factory/kernel and dtb | 16:48 |
radiofree | then updates should work with http://fpaste.org/193873/55722171/ | 16:48 |
radiofree | tiagogomes_: one last thing to check | 16:49 |
radiofree | tiagogomes_: actually never mind, i need to check the source code | 16:50 |
tiagogomes_ | ok | 16:50 |
tiagogomes_ | radiofree, just a question, where to you create and fill the systems directory on /boot | 16:51 |
radiofree | /boot being your ext partition? | 16:52 |
tiagogomes_ | radiofree, not that :) In which repo and script you do that? | 16:53 |
radiofree | tiagogomes_: it just mirrors the layout of the btrfs partition, system-version-manager creates the folder on the ext parition and copies things http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/tbdiff.git/commit/?id=61f116bc5367e8ba26e8fd0f48aa71e644cb9b1e | 16:54 |
*** a1exhughe5 has quit IRC | 16:54 | |
radiofree | http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/tbdiff.git/tree/system-version-manager/system-version-manager#n237 | 16:54 |
radiofree | so if your boot.scr is using /systems/default/kernel, it'll always be the last one updated - http://git.baserock.org/cgi-bin/cgit.cgi/baserock/baserock/tbdiff.git/tree/system-version-manager/system-version-manager#n189 | 16:56 |
tiagogomes_ | radiofree, but you need to have a systems directory in /boot in the first deployment no? before doing an upgrade | 16:57 |
radiofree | no? | 17:01 |
radiofree | it copies the kernel and devicetree from boot i think, but nothing else | 17:02 |
*** CTtpollard has quit IRC | 17:03 | |
tiagogomes_ | radiofree, somehow, you need to have a boot.src which is is configured to read from /systems/default/kernel; and you need to have a kernel there as well | 17:16 |
tiagogomes_ | this even before of doing an upgrade | 17:16 |
radiofree | yes, do that in your install step | 17:18 |
radiofree | when you do the initially install, copy /systems/default/kernel from your btrfs partition, to /systems/default/kernel on the ext partition | 17:19 |
radiofree | same with the device tree | 17:19 |
jjardon | Hi, newbie python question; Im not very sure why cliapp is used for in morph, if its only to parse command line arguments, can not the argparse module be used instead? https://docs.python.org/2/library/argparse.html | 17:22 |
persia | cliapp and morph were both started by the same person. | 17:25 |
ssam2 | it does more than parse arguments, see `pydoc cliapp` | 17:25 |
*** Krin has quit IRC | 17:26 | |
ssam2 | it handles plugins, some common arguments for log handling, and the runcmd thing | 17:26 |
ssam2 | all of which we could reimplement fairly quickly if we wanted, but why bother? | 17:26 |
jjardon | python3 | 17:30 |
jjardon | only curious, really | 17:30 |
jjardon | ssam2: thanks for the info | 17:30 |
ssam2 | good point. Might be easier to port cliapp to python3 than to reimplement the bits we need, i'm not sure | 17:30 |
jjardon | ssam2: also cliapp is not packaged in Arch, so thats where all this curiosity begin ;) | 17:31 |
pedroalvarez | I forgot to lorry this for genivi :( http://paste.baserock.org/rehisevona | 17:39 |
jjardon | pedroalvarez: are we not prefixing the genivi modules? | 17:40 |
pedroalvarez | jjardon: you are a really good reviewer | 17:40 |
jjardon | pedroalvarez: +1 with that change ;) | 17:40 |
pedroalvarez | we failed to include some of them in the genivi prefix though | 17:41 |
*** mdizzle has quit IRC | 17:44 | |
*** edcragg has quit IRC | 17:50 | |
ssam2 | +1 | 17:55 |
pedroalvarez | yay | 17:55 |
*** bashrc has quit IRC | 17:57 | |
*** edcragg has joined #baserock | 17:58 | |
pedroalvarez | merged thanks! | 17:59 |
*** CTtpollard has joined #baserock | 18:00 | |
*** sambishop has quit IRC | 18:10 | |
*** wschaller has quit IRC | 18:10 | |
*** CTtpollard has quit IRC | 18:10 | |
*** CTtpollard has joined #baserock | 18:18 | |
*** CTtpollard has quit IRC | 18:22 | |
rdale_ | when i type 'make' in a chroot for a failed build i get this: http://paste.baserock.org/varagumaro | 18:27 |
rdale_ | so it looks like you need to set things up in /proc perhaps? | 18:27 |
persia | You probably want to mount /proc, /sys, and /tmp in the target directory before calling chroot() | 18:30 |
rdale_ | right - i'll go and see what morph actually does. but i'm much happier now i've got strace working and i can see what is going on | 18:31 |
pedroalvarez | I tried mounting them and it didn't work | 18:31 |
rdale_ | :( | 18:31 |
*** tiagogomes_ has quit IRC | 18:36 | |
*** ssam2 has quit IRC | 18:39 | |
*** edcragg has quit IRC | 18:56 | |
*** gfinney has quit IRC | 19:10 | |
*** rdale_ has quit IRC | 19:39 | |
*** gary_perkins has quit IRC | 19:46 | |
*** CTtpollard has joined #baserock | 19:48 | |
*** CTtpollard has quit IRC | 19:50 | |
*** edcragg has joined #baserock | 20:00 | |
*** zoli__ has joined #baserock | 20:18 | |
*** zoli__ has quit IRC | 20:34 | |
*** edcragg has quit IRC | 20:51 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!