| Walkerdine | Okay I'm building it finally | 00:11 |
|---|---|---|
| Walkerdine | I'll also include to rename the morphologies so that when the build comes up it doesn | 00:16 |
| Walkerdine | say its building a x86_64 system | 00:16 |
| Walkerdine | I panicked for a second then remembered when I was playing around with the morph I saw the names didnt match with the build | 00:17 |
| *** lachlanmackenzie has quit IRC | 03:31 | |
| *** lachlanmackenzie has joined #baserock | 03:31 | |
| *** Walkerdine has quit IRC | 03:32 | |
| *** Walkerdine has joined #baserock | 03:34 | |
| *** perryl has joined #baserock | 05:33 | |
| *** zoli__ has joined #baserock | 05:47 | |
| *** zoli__ has quit IRC | 06:17 | |
| *** rdale has quit IRC | 06:23 | |
| *** zoli__ has joined #baserock | 06:23 | |
| Walkerdine | Ha my build ran out of space | 06:46 |
| Walkerdine | guess I should have used the SSD | 06:46 |
| *** zoli__ has quit IRC | 06:51 | |
| paulsherwood | ack | 06:53 |
| Walkerdine | oh well | 06:56 |
| Walkerdine | Ill have to try again tomorrow | 07:00 |
| paulsherwood | gnite! sleep now! :) | 07:01 |
| *** zoli__ has joined #baserock | 07:08 | |
| *** toscalix has joined #baserock | 07:53 | |
| *** mdunford has joined #baserock | 08:09 | |
| *** jonathanmaw has joined #baserock | 08:15 | |
| toscalix | good morning | 08:18 |
| tiagogomes_ | good morning toscalix | 08:24 |
| *** petefoth has quit IRC | 08:30 | |
| *** tiagogomes__ has joined #baserock | 08:42 | |
| *** nowster has quit IRC | 08:42 | |
| *** CTtpollard has quit IRC | 08:42 | |
| *** tiagogomes_ has quit IRC | 08:42 | |
| *** gary_perkins has quit IRC | 08:42 | |
| *** mdunford has quit IRC | 08:42 | |
| *** jonathanmaw has quit IRC | 08:42 | |
| *** mdunford has joined #baserock | 08:43 | |
| *** nowster has joined #baserock | 08:43 | |
| *** jonathanmaw has joined #baserock | 08:43 | |
| *** gary_perkins has joined #baserock | 08:43 | |
| *** CTtpollard has joined #baserock | 08:43 | |
| *** franred has joined #baserock | 08:52 | |
| wdutch | firehose question: if chunk x depends on y and x is being watched by firehose and requires a new version of y, will firehose update y? | 08:53 |
| *** flatmush has joined #baserock | 08:54 | |
| Kinnison | Currently, I doubt it | 08:56 |
| Kinnison | But configuration could likely be constructed to permit that | 08:56 |
| Kinnison | the firehose codebase is currently very much prototypical | 08:57 |
| wdutch | firehose does very little of what I thought :/ this will give CIAT orchestration a lot of work to do | 08:59 |
| Kinnison | CIAT orchestration can assume firehose will do things it can't currently do | 09:00 |
| Kinnison | and we can pick and choose our initial software set | 09:00 |
| Kinnison | that's fine | 09:00 |
| Kinnison | Over time, things can improve | 09:00 |
| wdutch | okay | 09:00 |
| Kinnison | don't compensate for missing but intended features | 09:00 |
| *** Zara has joined #baserock | 09:08 | |
| *** fay_ has joined #baserock | 09:16 | |
| *** pdar has joined #baserock | 09:18 | |
| tlsa | stratum level build deps will make auto updating of just the actual deps impossible for firehose. It would need to update every chunk in the build dep statum | 09:19 |
| Kinnison | indeed | 09:21 |
| Kinnison | To some extent that's a + and to some extent a - | 09:22 |
| *** lachlan75 has joined #baserock | 09:22 | |
| *** pdar has quit IRC | 09:22 | |
| *** benbrown_ has joined #baserock | 09:22 | |
| *** lachlan75 has quit IRC | 09:25 | |
| *** pdar has joined #baserock | 09:25 | |
| *** toscalix has quit IRC | 09:27 | |
| *** flatmush has quit IRC | 09:57 | |
| *** tiagogomes__ has quit IRC | 09:57 | |
| *** tiagogomes__ has joined #baserock | 09:57 | |
| *** flatmush has joined #baserock | 09:58 | |
| wdutch | new CIAT diagram: http://i.imgur.com/1FfWvKa.png | 10:03 |
| *** mdunford has quit IRC | 10:06 | |
| *** toscalix__ has joined #baserock | 10:10 | |
| *** toscalix__ is now known as toscalix | 10:10 | |
| *** mdunford has joined #baserock | 10:26 | |
| wdutch | new new diagram, http://i.imgur.com/y2ezdZ8.png | 10:34 |
| wdutch | I think that is now what Kinnison is describing | 10:35 |
| tlsa | looks good to me | 10:38 |
| Kinnison | looks pretty good. there's a definitoins and we need to ensure the test framework publishes test results to the 'fileserver' block, otherwise that looks good for the basic scheme we're aiming at as a starter-for-ten | 10:39 |
| wdutch | oops | 10:40 |
| *** rdale has joined #baserock | 10:44 | |
| toscalix | wdutch: I will add it to the wiki | 10:51 |
| Kinnison | Do we have a space on the baserock wiki for the CIAT work we're doing? | 10:51 |
| toscalix | no | 10:52 |
| toscalix | I don-t think so | 10:52 |
| Kinnison | Perhaps we should | 10:52 |
| toscalix | hummmmm...... I think that when we come to a positive result, yes | 10:52 |
| toscalix | specially if we will have a test environment for others to try | 10:53 |
| toscalix | otherwise it is just a "use case" | 10:53 |
| Kinnison | Well, hopefully that'll be by the end of next week | 10:53 |
| toscalix | which we should document once it is a success | 10:53 |
| * Kinnison isn't against displaying use-cases | 10:53 | |
| paulsherwood | in general i think it's better to encourage people to put stuff on the wiki early, so it doesn't get lost/forgotten | 10:54 |
| toscalix | I love use cases | 10:54 |
| * Kinnison concurs with paulsherwood | 10:54 | |
| toscalix | can we say that the technology we are using is baserock? | 10:55 |
| toscalix | or is the next generation of baserock? | 10:55 |
| paulsherwood | baserock is an 'umbrella' | 10:55 |
| toscalix | * lack info at this point | 10:55 |
| * toscalix lack info | 10:55 | |
| Kinnison | yeah, baserock is a project in which there's lots of technology | 10:55 |
| Kinnison | we'll be basing our solution, for now, on the baserock-style definitions model | 10:56 |
| toscalix | I think the more public we go, the better | 10:56 |
| toscalix | in general | 10:56 |
| paulsherwood | iiuc what's beeing done is using some existing baserock tooling, improving some other baserock tooling, and integrating some non-baserock tooling | 10:56 |
| Kinnison | yep | 10:56 |
| Kinnison | all in a fungible way | 10:56 |
| * Kinnison is all for modularity this week | 10:56 | |
| paulsherwood | in other news, on #automotive i seem to be completely failing to explain why keeping all the things in git is necessary | 10:56 |
| paulsherwood | and it's sapping my will to type :) | 10:57 |
| Kinnison | Oh dear | 10:57 |
| toscalix | so, instead of documenting CIAT internally and then adding it on baserock once it is done, we will go for documenting it directly on baserock. Am I correct? | 10:58 |
| Kinnison | I'd prefer that | 10:58 |
| paulsherwood | toscalix: that would be lovely | 10:58 |
| paulsherwood | especially since i'm trying to establish a workable approach for CIAT at GENIVI, AGL and other places | 10:59 |
| paulsherwood | so being able to point to documentation/discussion/code would be a big help | 10:59 |
| paulsherwood | but fwiw the upshot on #automotive is that some folks there consider that tarballs are better, and there's an outstanding action to discuss mirroring with yocto upstream to establish what the community recommends | 11:00 |
| toscalix | The only thing I need then is a wiki account so I can start | 11:00 |
| paulsherwood | i think i'm the wrong person to to lead the discussion with yocto upstream | 11:01 |
| paulsherwood | (mainly but not entirely because i can't face learning bitbake in enough detail to have the right level of conversation) | 11:01 |
| toscalix | I cannot help much there. For me it would be a high learning curve too at this point | 11:03 |
| * Kinnison sadly only knows enough about bitbake to not want to touch it again | 11:04 | |
| paulsherwood | lol | 11:04 |
| * Kinnison knows this is not a good attitude to have | 11:04 | |
| Kinnison | but then again, I know enough about nettles to not want to touch them again too | 11:04 |
| * paulsherwood sympathises | 11:04 | |
| toscalix | Would CIAT fit in the Distbuild section of this page as root page? http://wiki.baserock.org/guides/ | 11:06 |
| toscalix | nop, the Workflow section could be better.... | 11:07 |
| * toscalix unsure | 11:07 | |
| paulsherwood | toscalix: i suggest start a new wiki.baserock.org/ciat page, don't add it to guides until there's something for users to do with it? | 11:08 |
| *** petefoth has joined #baserock | 11:55 | |
| wdutch | the easiest way to have Trove trigger orchestration requires buildbot, would this be a problem? | 12:14 |
| paulsherwood | what are the alternatives? | 12:17 |
| wdutch | have it ping something living where orchestration lives which then uses buildbot to send it to the localhost, or find out what buildbot actually sends over the network and create it from a script | 12:18 |
| paulsherwood | i haven't used buildbot, but others like it i know. | 12:18 |
| wdutch | I think we have settled on buildbot for some components, my worry is that it might not to be good to need it on the same box hosting Trove | 12:19 |
| paulsherwood | ack | 12:19 |
| * wdutch won't worry about it for now | 12:21 | |
| *** tiagogomes__ has quit IRC | 12:30 | |
| *** tiagogomes_ has joined #baserock | 12:42 | |
| Kinnison | wdutch: Find out how to ping over http | 13:02 |
| Kinnison | wdutch: it's the *only* way you'll get a notification out of trove | 13:03 |
| wdutch | I thought about having something like flask in orchestration | 13:06 |
| paulsherwood | not bottle? | 13:07 |
| wdutch | whichever, I didn't give that bit much thought | 13:07 |
| wdutch | yet | 13:07 |
| paulsherwood | :) | 13:07 |
| toscalix | paulsherwood: ok, I will create a new page | 13:16 |
| *** tlsa has quit IRC | 13:19 | |
| *** tlsa_ has joined #baserock | 13:20 | |
| *** tlsa_ is now known as tlsa | 13:25 | |
| toscalix | paulsherwood: it looks like, a month ago, you already created that page. I work on it | 13:29 |
| toscalix | on the wiki I mean | 13:29 |
| paulsherwood | :-) | 13:30 |
| paulsherwood | i'd forgotten... i started there, then sent the outline to genivi and agl for review | 13:30 |
| paulsherwood | it's missing my picture | 13:30 |
| toscalix | in one month we have moved forward | 13:31 |
| *** Walkerdine_ has joined #baserock | 13:31 | |
| paulsherwood | :) | 13:34 |
| toscalix | paulsherwood: did you know about this? http://kernelci.org | 13:41 |
| toscalix | Kevin Hilman will be talking about it at ELCE | 13:41 |
| paulsherwood | i had heard of it, don't know much about it | 13:42 |
| rjek | That looks very similar in concept to what Simtec did for the ARM kernel | 13:43 |
| toscalix | Kevin is now in charge of the Linaro Stable Kernel build-test-release | 13:44 |
| rjek | It stopped some time ago though: http://armlinux.simtec.co.uk/kautobuild/stats.html | 13:44 |
| toscalix | he used to be in my group | 13:45 |
| toscalix | several of the simtec guys moved to linaro | 13:46 |
| toscalix | like Nicolas or Deepak | 13:46 |
| toscalix | ah, Ben Dooks..... | 13:47 |
| toscalix | :-) | 13:47 |
| rjek | I can tell you with total confidence that neither Nicolas or Deepak are ex-Simtec. | 13:47 |
| * paulsherwood concurs | 13:48 | |
| toscalix | rjek: http://armlinux.simtec.co.uk/whoswho.html | 13:48 |
| rjek | Mainly because I've never heard of them :) | 13:48 |
| toscalix | there is where I got it. | 13:48 |
| rjek | toscalix: ARMLinux != Simtec : | 13:48 |
| rjek | :) | 13:48 |
| toscalix | rjek: ok | 13:48 |
| * rjek , bjdooks, nowster, Kinnison, and Vincent Sanders are ex-Simtec. | 13:49 | |
| rjek | But Simtec did provide quite a bit of infrastructure for the ARMLinux project. | 13:49 |
| * wdutch chuckles at the pictures of ben and vince | 13:50 | |
| toscalix | understood | 13:50 |
| rjek | wdutch: I can find older ones if you want | 13:50 |
| rjek | wdutch: Enjoy this state-of-the-art-for-the-time digital photograph of Dave Walker, Vince, and Ben http://eh.org/cgi-bin/pics.cgi?smiles.jpg | 13:52 |
| wdutch | those pictures are unflattering enough | 13:52 |
| *** toscalix has quit IRC | 14:14 | |
| *** toscalix__ has joined #baserock | 14:15 | |
| Walkerdine_ | My goal for today is to find out how to partition the SSD | 14:21 |
| paulsherwood | infrastructure/extensions/simple-network.configure requires cliapp, so ybd can't deploy it | 14:26 |
| *** tiagogomes_ has quit IRC | 14:32 | |
| *** tiagogomes_ has joined #baserock | 14:35 | |
| Kinnison | I thought simple-network had been superceded by systemd-networkd stuff | 14:43 |
| paulsherwood | maybe it was in definitions. not in infrastructure it seems | 14:44 |
| paulsherwood | i'm only trying it because deifnitions doesn't seem to have any examples of 'subsystem' | 14:44 |
| paulsherwood | some of the cluster files look extremely weird to me | 14:45 |
| paulsherwood | (fwiw) | 14:45 |
| *** Walkerdine_ has quit IRC | 14:48 | |
| *** rdale has quit IRC | 14:56 | |
| * paulsherwood can't believe that distcc requires all this ... http://paste.baserock.org/lulacekufa | 15:03 | |
| rjek | lol rpm | 15:04 |
| rjek | paulsherwood: But no, I don't believe it either | 15:04 |
| *** rdale has joined #baserock | 15:05 | |
| paulsherwood | rjek: have you used distcc? | 15:05 |
| rjek | In the past, yes | 15:06 |
| radiofree | yes i think that's just poor dependency management | 15:06 |
| rjek | rjek ▶ platypus ▶ SSH ▶ ~ ▶ $ ▶ apt-cache show distcc | 15:06 |
| rjek | Package: distcc | 15:06 |
| rjek | Version: 3.1-5 | 15:06 |
| rjek | Installed-Size: 477 | 15:06 |
| rjek | Maintainer: Daniel Hartwig <mandyke@gmail.com> | 15:06 |
| rjek | Architecture: amd64 | 15:06 |
| rjek | Depends: libavahi-client3 (>= 0.6.16), libavahi-common3 (>= 0.6.16), libc6 (>= 2.8), libpopt0 (>= 1.14), adduser (>= 3.52), debconf (>= 0.5) | debconf-2.0, netbase (>= 4.09), lsb-base (>= 3.2-13) | 15:06 |
| radiofree | mesa-libGL-10.6.3-1.20150729.fc22.armv7hl.rpm ... | 15:06 |
| radiofree | cairo?! | 15:06 |
| radiofree | mesa?! | 15:06 |
| paulsherwood | so imagine my scenario... n scaleway instances all running ybd and/or distcc | 15:06 |
| rjek | libavahi-client3 depends on dbus, but that's the only other semi-surprising dependancy in wheezy | 15:07 |
| paulsherwood | cand distcc clients serve multiple requests at once? requesters? | 15:07 |
| radiofree | paulsherwood: that seems like a lot of effort for something that probably won't end up being much faster than a chroot on a moonshot | 15:07 |
| rjek | I believe it's quite flexible, yes | 15:07 |
| * wdutch uses buildbot to open Guess over http :) | 15:08 | |
| paulsherwood | radiofree: i agree it may not stack up, but i'm interested to try it to see what the numbers work out at | 15:08 |
| rjek | I would expect the Moonshut to be faster: the ArmadaXP's Ferocean core is a little faster than a Cortex-A9 and the X-Gene's core a little slower than an Cortex-A53. | 15:08 |
| rjek | Mootshut? Moonshot. | 15:08 |
| rjek | Also the X-Gene has twice the cores and sixteen times the RAM | 15:09 |
| rjek | paulsherwood: I may sound trolly, but try using Debian on the Scaleway instead? | 15:09 |
| paulsherwood | but also i'm thinking generically.... iirc radiofree you suggested distcc - i'm thinking of trying it on scaleway just cos lots of instances are very cheap | 15:09 |
| radiofree | yes i think distcc would be excellent to integrate | 15:09 |
| radiofree | distcc and n moonshot nodes! | 15:10 |
| rjek | +1 | 15:10 |
| paulsherwood | rjek: instead of the fedora? i did. there's a compiler bug won't build our stage1-gcc | 15:10 |
| rjek | paulsherwood: Erk? | 15:10 |
| rjek | Did you file a bug? :) | 15:10 |
| paulsherwood | radiofree: ack. i'd get it working on scaleway first, then move the approach to moonshot and aws :) | 15:10 |
| Kinnison | distcc introduces a lot of latency into the compile pipeline, so you need larger parallel build jobs to really take advantage of it | 15:11 |
| rjek | Also remember that with distcc all pre-processing happens on one box | 15:11 |
| rjek | Which may be a bottleneck too | 15:11 |
| paulsherwood | rjek: who do i file the bug against? | 15:11 |
| radiofree | Kinnison: i originally thought it would be good to integrate into distbuild when you reached a chunck that was blocking | 15:11 |
| radiofree | these tended to be pretty big things, qt-base etc... | 15:12 |
| rjek | paulsherwood: Probably Debian? What is the nature of the bug? | 15:12 |
| radiofree | i'd have 5 jetsons all waiting on qt-base | 15:12 |
| paulsherwood | rjek, Kinnison - yup. but if the concepr proves sound, it may be useful and applicable for other configurations | 15:12 |
| Kinnison | radiofree: Mmm | 15:12 |
| Kinnison | paulsherwood: oh it's certainly worth a play | 15:13 |
| paulsherwood | i'm thinking that i could (say) have an AWS host or x86 laptop farming arm compiles to lots of (say) scaleway boxes, or jetsons | 15:13 |
| Kinnison | paulsherwood: NetSurf uses a 3-way distcc cluster for our armv7hf builds | 15:13 |
| radiofree | it would still be large for those large things, but when you can build gcc in 10 minutes on a mustang it's not as crucial to me as it once was | 15:13 |
| radiofree | s/large for those/good for those/ | 15:13 |
| paulsherwood | Kinnison: please expand on 3-way distcc cluster? | 15:14 |
| paulsherwood | (what hw, and what's 3-way)? | 15:14 |
| rjek | Raspberry Pis | 15:14 |
| rjek | Three of them | 15:15 |
| Kinnison | 15:43 < kyllikki> we have a cubietruck 3+rpi2+rpi2 giving a distcc -j9 on two parallel build slots | 15:15 |
| paulsherwood | rilly? | 15:15 |
| rjek | NetSurf's not written in C++ like Qt, so doesn't need to be sent into the future to be compiled by Skynet. | 15:15 |
| Kinnison | rjek: 2 raspis not 3 | 15:15 |
| rjek | Oh right | 15:15 |
| * paulsherwood wonders how long to build the genivi demo platform on that puppy :) | 15:15 | |
| rjek | Cubie too | 15:15 |
| rjek | I think it takes a few minutes to build NetSurf | 15:15 |
| Kinnison | paulsherwood: about two hundred billion years | 15:15 |
| radiofree | qtwebkit... | 15:16 |
| paulsherwood | lol | 15:16 |
| Kinnison | 15:43 < kyllikki> twenty minutes for all six builds from stone cold cleared ccache | 15:16 |
| Kinnison | for NetSurf | 15:16 |
| Kinnison | But, as rjek says, NetSurf in written in a sane language, rather than C++ | 15:16 |
| paulsherwood | ack | 15:16 |
| paulsherwood | can a distcc client handle jobs from multiple sources? | 15:17 |
| jmacs | Pretty sure ours did when we had a cluster | 15:18 |
| Kinnison | a distcc server can handle requests from more than one place, yes | 15:18 |
| rjek | paulsherwood: Yes. | 15:18 |
| Kinnison | But remember, it's entirely up to you to secure the cluster | 15:18 |
| paulsherwood | ack | 15:18 |
| Kinnison | Also remember that you need to distribute compilers appropriately | 15:18 |
| Kinnison | which for a Baserock build would be very hard | 15:19 |
| rjek | Yeah, each system needs to have the same and right compiler on it | 15:19 |
| paulsherwood | for 3 quid a moth i may not spend too much time on security. i'd only be playing | 15:19 |
| rjek | Which you could perhaps do by sharing via NFS | 15:19 |
| rjek | paulsherwood: You can provide a server with a list of IP addresses to accept jobs from IIRC | 15:19 |
| rjek | paulsherwood: Do Scaleway give you a VLAN for private communications between all your own systems? | 15:20 |
| radiofree | couldn't you just do that via nfs? | 15:20 |
| radiofree | oh rjek said that | 15:20 |
| rjek | Yeah, if you set all your systems up to share a single /bin /sbin /usr it might even work :) | 15:21 |
| radiofree | just share the build area over nfs and chroot into it? | 15:21 |
| radiofree | the distcc server works in a chroot | 15:21 |
| rjek | For each build you did you'd need to share it over NFS, chroot, and launch a distcc | 15:22 |
| rjek | Rather than the workers being persistent beings. | 15:22 |
| rjek | Which may or may not be a problem. | 15:22 |
| paulsherwood | there's a private ip and public for each mc | 15:23 |
| rjek | MC? | 15:23 |
| paulsherwood | server | 15:23 |
| rjek | What does the private IP "go to" ? A virtual network with all a specific customers servers on? | 15:24 |
| radiofree | maybe you could just tell each node to construct the same build area from a shared cache and chroot into that | 15:24 |
| paulsherwood | unclear | 15:24 |
| radiofree | does distbuild work like that? | 15:24 |
| rjek | If so, you can just run distcc only on that network interface and tell it to allow the whole network | 15:24 |
| rjek | But it does seem that getting a consistent and correct environments between all your nodes will be the tricky bit | 15:29 |
| paulsherwood | i think that's already handled by the sandboxing if we could get distcc to understand that | 15:33 |
| radiofree | well i *believe* distbuild informs a node to "construct this build area from this cache" and then builds it on the node in that, you'd essentially have to tell each node to "build the same build area from the same cache and launch a distcc server inside it" | 15:35 |
| radiofree | there's going to be some overhead to distributing the build area anyway | 15:35 |
| paulsherwood | ack | 15:36 |
| *** fay_ has quit IRC | 15:39 | |
| *** Walkerdine__ has joined #baserock | 15:52 | |
| Walkerdine__ | I don't think I'm going to be able to figure out how to use the SSD instead of the eMMC :/ | 16:26 |
| *** jonathanmaw has quit IRC | 16:27 | |
| SotK | Walkerdine__: how far have you got? | 16:36 |
| Walkerdine__ | Well I have everything set up to build but I couldn't get it to build without using the SSD becasue the eMMC doesnt have enough space | 16:38 |
| Walkerdine__ | I was told that I could partition the SSD manually but I'm not sure how I should partition it | 16:39 |
| *** toscalix__ has quit IRC | 16:40 | |
| SotK | When I was messing with a Jetson I just formatted the whole thing as one ext3 (or maybe btrfs) partition IIRC | 16:41 |
| SotK | s/whole thing/whole SSD/ | 16:41 |
| rjek | then root=/dev/sda in your boot config? | 16:42 |
| SotK | I just added it to my fstab to mount on /src I think | 16:43 |
| Walkerdine__ | So root would be on the SSD and the boot would still be eMMC? | 16:43 |
| paulsherwood | yup | 16:43 |
| rjek | Aha | 16:44 |
| Walkerdine__ | And the commands are just normal fdisk commands? | 16:45 |
| Walkerdine__ | So I can create one partition(ext3? or 4? does it matter?) out of my SSD create a src and set up the workspace like normal and all I have to change is the ROOT in jetson-upgrade.morph | 16:48 |
| *** toscalix__ has joined #baserock | 16:48 | |
| rjek | I would recommend ext4 or XFS as they both support TRIM in order to maximise the lifetime of your SSD | 16:48 |
| rjek | (make sure they are mounted with the option 'discard') | 16:48 |
| Walkerdine__ | What does that do | 16:48 |
| Walkerdine__ | discard | 16:49 |
| rjek | Walkerdine__: When the file system is done with a block on the underlying device, it causes it to send a TRIM ATA command which tells the SSD's controller that part of the flash is no longer used. | 16:49 |
| rjek | So it can do better wear-leveling | 16:49 |
| Walkerdine__ | okay I'll make sure to do that | 16:50 |
| * SotK doesn't know how ROOT_DEVICE works off the top of his head | 16:51 | |
| SotK | looks like the device specified as ROOT_DEVICE gets an entry added to the fstab at deploy time expecting it to be btrfs | 16:54 |
| *** zoli__ has quit IRC | 16:54 | |
| Walkerdine__ | ooooo so that would change how I partition the drive | 16:55 |
| SotK | you can probably just leave ROOT_DEVICE in the cluster as the eMMC and mount the SSD somewhere and work in there if you like | 16:55 |
| radiofree | SotK: i use the ssd for my root device | 16:56 |
| radiofree | however had to manually create the partition table on the SSD | 16:56 |
| radiofree | so 50G for /dev/sda1 (BTRFS) rest for /dev/sda2 (ext4) which will be /src | 16:57 |
| radiofree | actually this will probably work | 16:58 |
| * radiofree thinks about it a bit more | 16:58 | |
| radiofree | ... | 16:59 |
| radiofree | right got it | 16:59 |
| Walkerdine__ | radiofree: yeah i ran out of room when I tried to build jus using the emmc | 16:59 |
| radiofree | Walkerdine__: that's more down to your lack of /src | 17:00 |
| radiofree | you can format the ssd as an ext4 partition and mount that as /src | 17:00 |
| radiofree | i believe the guide mentions that | 17:00 |
| radiofree | however, if you did want to put the whole thing on the ssd | 17:00 |
| radiofree | 1) create partition table on ssd, /dev/sda1 (btrfs) /dev/sda2 (ext2) | 17:00 |
| radiofree | s/ext2/ext4 | 17:00 |
| radiofree | sda2 should be bigger | 17:00 |
| radiofree | 2) mount a jetson devel image `mount devel-system-armv7lhf-jetson.img /mnt` | 17:01 |
| radiofree | 3) copy everything to /dev/sda1 `cp -r /mnt/* /where/your/ssd/sda1/is/mounted` | 17:01 |
| radiofree | 4) plug into jetson | 17:01 |
| radiofree | there are multiple ways to do the next bit (e.g mount it as usb device), but i'll go with the easiest | 17:02 |
| radiofree | 5) boot into the devel system already on the jetson, and mount /dev/mmcblk0p1 `mount /dev/mmbclk0p1 /mnt` | 17:02 |
| radiofree | 6) edit extlinux.conf to point at /dev/sda1 instead of /dev/mmcblk0p2 (any time there is a root=/dev/mmbclk0p2, replace with root=/dev/sda1) | 17:02 |
| radiofree | now it'll boot into the ssd instead of emmc, from there on in you can just set ROOT_DEVICE to /dev/sda1 in your cluster | 17:03 |
| radiofree | it's what i do anyway | 17:03 |
| radiofree | but as i said before, i only do that because i deploy quite a lot of upgrades for testing etc... so i needed the rootfs to be much bigger than 10G | 17:04 |
| radiofree | i can't remember if the version of u-boot we're using supports sata, if it did you probably could create an image with a partition table and just flash the whole thing to a ssd | 17:06 |
| radiofree | u-boot will check emmc -> sdcard -> ssd (maybe a more recent version will do it) | 17:06 |
| * radiofree doesn't have access to a jetson atm so can't check | 17:07 | |
| Walkerdine__ | I'm also going to be deploying quite a lot of upgrades. I'm going to try this when I get home | 17:07 |
| *** rdale has quit IRC | 17:13 | |
| Walkerdine__ | Oh I see what you're talking about with the ext4 partion in the guide | 17:14 |
| *** Walkerdine__ has quit IRC | 17:24 | |
| *** Walkerdine__ has joined #baserock | 17:26 | |
| *** zoli__ has joined #baserock | 17:55 | |
| *** toscalix__ has quit IRC | 18:00 | |
| *** Walkerdine_ has joined #baserock | 18:26 | |
| *** Walkerdine__ has quit IRC | 18:27 | |
| *** Walkerdine_ has quit IRC | 18:33 | |
| *** Walkerdine_ has joined #baserock | 18:39 | |
| *** Walkerdine_ has quit IRC | 18:52 | |
| *** zoli__ has quit IRC | 19:01 | |
| *** Walkerdine_ has joined #baserock | 19:26 | |
| *** Walkerdine_ has quit IRC | 20:21 | |
| *** Walkerdine_ has joined #baserock | 20:41 | |
| *** Walkerdine_ has quit IRC | 21:27 | |
| *** Walkerdine_ has joined #baserock | 21:51 | |
| *** toscalix__ has joined #baserock | 22:56 | |
| *** Walkerdine_ has quit IRC | 22:58 | |
| *** toscalix__ has quit IRC | 23:28 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
