IRC logs for #baserock for Sunday, 2014-08-17

*** flatmush [] has joined #baserock00:02
*** flatmush [] has quit [Ping timeout: 246 seconds]00:06
*** flatmush [] has joined #baserock00:11
*** flatmush [] has quit [Ping timeout: 245 seconds]00:17
*** flatmush [] has joined #baserock01:21
*** flatmush [] has quit [Ping timeout: 260 seconds]01:27
*** flatmush [] has joined #baserock01:30
*** flatmush [] has quit [Ping timeout: 255 seconds]01:35
*** flatmush [] has joined #baserock01:43
*** flatmush [] has quit [Ping timeout: 255 seconds]01:48
*** flatmush [] has joined #baserock02:15
*** flatmush [] has quit [Ping timeout: 246 seconds]02:19
*** flatmush [] has joined #baserock02:22
*** flatmush [] has quit [Ping timeout: 240 seconds]02:28
*** flatmush [] has joined #baserock03:55
*** flatmush [] has quit [Ping timeout: 272 seconds]04:00
*** flatmush [] has joined #baserock04:35
*** flatmush [] has quit [Ping timeout: 246 seconds]04:41
*** flatmush [] has joined #baserock05:05
*** flatmush [] has quit [Ping timeout: 245 seconds]05:09
*** flatmush [] has joined #baserock05:10
*** flatmush [] has quit [Ping timeout: 272 seconds]05:19
*** flatmush [] has joined #baserock05:28
*** flatmush [] has quit [Ping timeout: 244 seconds]05:35
*** flatmush [] has joined #baserock05:37
*** flatmush [] has quit [Ping timeout: 240 seconds]05:45
*** flatmush [] has joined #baserock05:49
*** flatmush [] has quit [Ping timeout: 272 seconds]06:00
*** flatmush [] has joined #baserock06:08
*** flatmush [] has quit [Ping timeout: 255 seconds]06:30
*** flatmush [] has joined #baserock06:34
paulsherwoodis there a way to kill "A start job is running for dev-disk-by\x2dlabel-src.device" ?08:10
paulsherwoodah... it gives up on its own08:11
*** franred [] has joined #baserock10:07
*** franred [] has quit [Client Quit]10:11
paulsherwooddumb question - is one of our *rootfs artifacts usable as an img ?12:51
paulsherwoodor is there a way to create an img file from *rootfs other than morph deploy?12:52
persiaNo, and yes, but it's ugly13:01
straycatThe image needs to have some sort of file system, probably btrfs in our case and then possibly some bootloader stuff on top.13:01
persiaAlso needs to be configured: there's lots of stuff that gets deferred to deploy time that should run to make the software work.13:02
persia(from the chunks,and separate from the configuration extensions: the "integration scripts")13:02
paulsherwoodughh... it's 2014! :)13:18
KinnisonIt is.  Had you not noticed?13:22
persiaThis is not this way because it's old and nasty: this is this way to ease multiple deployments from the same rootfs artifact without the ugliness of configuration management-based solutions.13:22
paulsherwoodso, here's my catch 22 -13:22
paulsherwoodon jetson, i can use morph build to create rootfs, then use morph deploy to create img13:23
paulsherwoodbut i can't run nvidia flashing tool (it's x86)13:23
KinnisonHave an x86 VM, build on the jetson and transfer the artifact cache contents to your x86 vm and deploy from there13:24
persiaIs there no longer an ARM binary for that?  There used to be one.13:24
persia(assuming we're talking about the fastboot manipulation utility)13:24
straycatHrm? Doesn't the nvidia tool take a tarball?13:24
KinnisonOr, set your jetson up as a distbuild worker/controller pair and use distbuild from a VM on your x8613:24
persiastraycat: It can take a tarball *or* a filesystem image.13:25
persia(or it could, last I used it, years ago)13:25
paulsherwoodKinnison: the distbuild route is too complex for me, i'm afraid13:25
KinnisonI can understand that :-(13:25
paulsherwoodand so are netcat, and scp. i feel brainless today13:25
KinnisonIt's probably beyond me to describe on a Sunday too13:25
* persia wants a simple build-on-target command13:25
* Kinnison recommends a beer and a book, in a room with music13:26
Kinnisonthat usually renews braincells13:26
paulsherwoodi have music - my youngest is playing piano13:26
persiapaulsherwood: To be clear, do you want to run the new image on the jetson that built it, or another jetson?13:27
paulsherwoodis there some way i can upload an img to or some other internet space for the mo?13:27
persiaAlso, is the other jetson already running *some* baserock?13:27
persia(if the latter)13:27
paulsherwoodpersia: i can cause an out-of-box jetson to be brained as baserock, with the nvidia kernel:
paulsherwoodnow i would like to brain one with my own choice of baserock system, in the smallest number of steps possible13:29
persiaThen just use radiofree's work to do upgrades.13:29
paulsherwoodit must be me, but i honestly get confused by radiofree's instructions13:29
persiaAnd upgrade your target from whatever random state (that was baserock) to the one you want.13:29
paulsherwoodand i have never done a baserock upgrade, on any system. i know that makes me a wuss13:29
straycatOr deploy to tarball, scp tarball to x86 system, flash rootfs over, then extract kernel from tarball and flash that?13:30
paulsherwoodyou guys make it sound easy13:30
persiaIt's also safe to s/tarball/image/ in straycat's instructions13:30
persiapaulsherwood: So, as a first step, read upgrade-devel.morph, and run the command listed there, so you have experience with a local upgrade.  Once you know how to upgrade, just upgrade your target.13:31
persiaAside from the poor documentation, this is supposed to be easy: built on devel ,upgrade target for testing.  It's part of basic workflow for hardware-based solutions.13:32
persiaMind you, it requires a native devel environment, which is why I want a simple build-on-target command.13:34
persia(because two boards per engineer is unlikely to be available to OSVs for prerelease hardware)13:35
persia(note that doing this is complex: one needs to share an artifact cache, possibly via sshfs, and somehow cause morph to run in an environment that doesn't depend on features of the target system, etc.)13:36
* paulsherwood has never used scp, for example, and curses netcat every time he has to google how to use it13:40
KinnisonHave you used cp before?  if so, scp is pretty simple, just learn to prefix filenames with machine-name: to transfer across networks13:40
Kinnisone.g. scp somehost:/path/to/somefile mylocalcopy13:41
Kinnisonthe only really irritating limitation is you can't do scp somehost:/path/to/somefile anotherhost:/path/to/somewhere/13:41
persiaOr `scp somefile somehost:somefile` in the simple form13:41
paulsherwoodKinnison: tvm13:41
persiaKinnison: For that, you should use ftp.  Unfortunately, nobody has written a good command-line client for ftp.13:42
Kinnisonpaulsherwood: YOu might find to be of some use13:42
Kinnisonpersia: mmm, ftp is overused on the internet and underused on private networks13:42
persiaSadly.  It's because ftp+ssl is no undersupported in both clients and servers.13:42
persiaPlus nobody seems to understand using X.509 certificates13:43
KinnisonFTPs is barely supported anywhere13:43
* persia is unhappy about both these things, as ftp is really cool13:43
KinnisonTo be fair, I think even the people who specced them didn't really understand them13:43
persiaYes, but ignoring the implementation details, folk seem to create new key strategies in preference to using X.50913:43
* persia is somewhat annoyed at the proliferation of services that use ssh certs for authentication, when ssh certs can't be authenticated13:44
KinnisonI'm not fond of the "oracle of all truth" aspect which people who misunderstand/misuse x.509 often expect13:44
KinnisonI did the research once to sort out a way to have an x509 cert (with authentication/authority chains) convertible to an SSH key13:45
Kinnisonso you could have both worlds with one private key13:45
persiaI suspect the fact that the US Government restricted use of strong keys while promoting use for secure transactions (with weak keys) helped with both of our complaints.13:45
persiaYep.  You can even have that private key be a GPG secret key.13:45
persiaUnfortunately, client support for doing that is *awful*13:46
* persia thinks that it ought be the default13:46
paulsherwoodKinnison: do you know if i have supercowpowers to publish to
* Kinnison doubts you do13:46
Kinnisonlet me check13:46
persiapaulsherwood: What do you want to publish?13:46
paulsherwooda jetson img with docker, if i can get it to work13:47
persiaJust publish the definitions.13:47
Kinnisonpaulsherwood: actually you ought to have the rights, but if you want, you can upload it to your ~ on that box and I'll publish it for you13:47
* persia doesn't think it's interesting to publish images for consumption, because the desireable baserock target audience should be excited about *modifying* systems, rather than consuming them.13:48
paulsherwoodpersia: you're missing my point, slightly... it's currently non-trivial to get started on jetson13:48
Kinnisonpersia: Publishing an image to help people get started is well worth it IMO13:48
persiaYes, but it should be a *devel* image, no?13:48
paulsherwoodit will be a devel image with docker13:49
* persia would be very happy to see jetson devel images kept up to date on download.baserock.org13:49
persiaHow does docker help?13:49
persiaI'm not saying docker isn't cool, but I don't see why the jetson devel image should be different.13:49
paulsherwoodi'm not sure yet13:49
persiaSo, when you're confident, change *all* devel images to be docker, and publish those :)13:50
paulsherwoodmy current itch is jetson13:50
persiaSo let's define a jetson devel image that other devel images, and get it into the release morphology13:51
radiofreeIt's not non-trivial if you're familiar with u-boot/bootloaders/flashing etc..13:51
* persia fiddles with PalmDetect harder13:51
paulsherwoodthat's already there - we just haven't done a 'release' with the jetson devel so far13:51
paulsherwoodradiofree: s/familiar with/expert at/13:52
persiaOh, right, because we bundle stuff.13:52
persiaAre we still dependent on Codethink resources to do a release, or can we just do one if we have folk with supercowpowers about?13:53
KinnisonIn theory, the latter if they have resources to hand and the jetson stuff Paul is trying to release now13:53
KinnisonWhich would be nice13:53
persiaI'm happy to build a bunch of x86 artifacts to populate the cache if others are up for trying a release today.  I don't have arm hardware available to me at the moment.13:54
KinnisonI'm not sure what the state of things are, but I'd like to be certain things like the distbuild plugin are good before we do a release13:55
KinnisonI think it'd be nice to have a release beyond 14.20 where we're confident about distbuild13:55
persiaOh, right.  So really we need someone with a distbuild environment to do a release, and that's rare on weekends.13:56
KinnisonAye, in theory you can do it all on one system (the mason work has build, controller and worker all on one VM) but I don't personally know how to set that up13:56
paulsherwoodi can get to a jetson distbuild network13:56
persiaI can try to instantiate an x86 distbuild network on my private (in-laptop) cloud, but I don't know how slow that might run.13:57
persiaMy ML thread about governance hasn't garnered much response: do we need approval from anyone to do a release?13:58
paulsherwoodradiofree: sorry to bug you, but i'm trying and getting 'file does not exist'13:59
paulsherwoodpersia: weren't you the one saying releases are meaningless?14:00
persiapaulsherwood: I'd like them to be, yes, but I've been convinced by the number of times I've lost entire days to rebuilding that we need cache population to happen.14:00
persiaSo unless we have a distbuild network building definitions master when changes land, we need to coordinate cache population, which is a "release".14:01
straycatDoes the cd system not continually populate the cache?14:01
persiaI don't think the generated artifacts are particularly interesting, and I think that the conceptual model of "releasing" slows development and encourages user-unfreindly changes to land, but there are structural issues that need to be resolved to be release-free.14:02
persiastraycat: Is there a public CD system in place?14:02
paulsherwoodstraycat: i don't think we have a public cd system yet14:02
* persia has seen lots of code that might make that happen, but thought it was still in the "here's a toolkit from which you could build CD" stage.14:03
KinnisonI think we are14:03
KinnisonI think Mason is still a little bit lashed-together while technology decisions get made14:04
Kinnisonparticularly around the CI engine core.  I'm currently favouring buildbot when asked14:04
* persia is partial to zuul+gearman14:05
KinnisonI'd love for you to spend some time this week telling me about those14:05
Kinnisonbecause I've no experience of them14:06
persiaYou'll like zuul: it's python14:06
KinnisonWhat, not Lua?14:06
* Kinnison pouts14:06
ratmice__persia: hmm, i think there is a ton of value in publishing images for some use cases14:06
persiaratmice__: I'm of mixed minds.  I don't think there's value in publishing images for users of Baserock who are building random stuff or hacking baserock tooling.  I agree there's value in images that do things, but I think the folk who curate those images ought be somewhat separate from the folk doing tooling (although some folk may wear multiple hats).14:08
persiaFor that matter, I even think there's value in batching and releases for image creation (although having dailies for testing is handy), whereas I prefer CD for the core tooling.14:09
persiaI'm not sure any of the current reference images other than the devel systems for new users are particularly useful as curated targets though (I'd be delighted to be wrong)14:10
ratmice__persia: in our case bulding toolchains for bootstrapping a couple of related OS's it becomes impossible to make available a toolchain for every OS/os version someone might want to build/modify our source base from, so having a single image everyone can use to bootstrap from keeps everyone on the same page, and saves much time14:13
radiofreeTry giving it the full path to the img14:14
persiaratmice__: This makes perfect sense.  You are exactly of the class of users who I consider to be the set who would curate images that have a release schedule.14:15
radiofreeE.g /home/me/image/bar.IMG14:15
paulsherwoodradiofree: ok14:15
persiaratmice__: I'm just not sure that the same applies for many of the reference images in definitions.git master.14:16
persiaAnd I'm perhaps overly critical of releasing images in part because many of the folk who seem to be regulars on this channel seem to hack on morph with using-latest-morph so rarely (if ever) run the "released" images.14:17
ratmice__I suppose i'm somewhat confused, because new users have to start from somewhere, and the current mechanism for that is releasing images, need to read this more carefully to figure out what/how we are suggesting to replace that with :)14:25
paulsherwoodratmice__: i agree with you. sometimes, our discussion tends to lose track of the ground14:27
persiaMy thought is that for the tooling for system developers, there is ideally a development image built from the latest commit to definitions for every supported architecture (and possibly a minimal target image, if my dream of build-on-my-target even gets implemented~).14:27
persiaAnd there may also be a collected set of curated images that are collaboratively developed using the baserock tooling, which would be released together on some schedule that worked well for the various curators.14:28
paulsherwoodpersia: build-on-target is already happening? maybe not in a dreamy way, though :)14:28
persia(but this latter presumes the existence of a community of curators)14:29
persiapaulsherwood: Not quite what I want.  The current model involves having *two* target systems: one to build, and one to test (or maybe one with removable media).14:29
persiaI want to be able to run my devel system on whatever arch I want (probably ARM/x86 because I like laptops), and be able to cause my target (probably MIPS or PPC, because that's the sort of hardware I usually play with) to build a system and then deploy as upgrade into that system.14:31
paulsherwoodpersia: me too :)14:31
KinnisonSounds like defaulting to making single system controller+worker systems would be a good path to persia's goal14:31
persiaKinnison: Maybe.  I need pictures and architectural discussions to know if I agree.14:32
* Kinnison nods14:32
* Kinnison is only half-paying-attention to this discussion anyway, watching baby-snake care videos14:32
paulsherwoodwhat's the value of distbuild in that scenario? why not just build?14:32
persiaMy initial response is "not at all" because I read that as implying that I'm running some special system on my target to build.14:32
persiapaulsherwood: I think Kinnison is using "distbuild" as shorthand for "building on a system other than the devel system".14:33
* Kinnison is14:33
KinnisonAlso the current distbuild infra is as good as anything else we have for getting the workspace content to the target for building14:34
Kinnisonshared FSes are often too slow or awkward14:34
KinnisonOf course, it implies some kind of trove-like system which I know is becoming contentious14:34
persiaYes, but, troves, ...14:34
paulsherwooddocker :)14:34
Kinnisonpersia: I have some half-baked ideas about distbuild using the initiator to acquire git content14:35
persiaSo, there's two bits here that need network data:14:35
Kinnisonpersia: and using git bundles and/or archive tarballs across the link14:35
persia1) current state (for which I'd be happy with just git refs to accessible locations)14:35
persia2) tooling (remember, the target system may not have morph)14:35
persiaKinnison: I think we should stop supporting building random uncommitted stuff.14:36
KinnisonI'm not convinced we can get very far without morph (or some minial variant thereof) and supporting tooling (linux-user-chroot) etc.14:36
* persia believes this to be irresponsible and/or confusing, depending on the user's knowledge of git14:36
Kinnisonpersia: I think you'd be throwing away the chance of a fast change/build/test cycle if you forced user-driven commit/push at every change14:36
persiaMaybe.  When I'm hacking source for fun, I generally commit before build anyway.  Commits are cheap.14:37
KinnisonFor a lot of people, they worry about commits14:37
Kinnisonthe commit-often and rebase-at-some point methodology is not widely used IME, particularly outside of people already deeply invested in git workflows14:38
persiaSadly misled by the terminology.  A git "commit" doesn't mean the same thing as for a real VCS.14:38
* persia commits often and rebases continuously14:38
* Kinnison commits somewhat often and rebases usually before a push, regardless of intent to merge14:39
paulsherwoodi don't worry about commits. i just want there to be no possibility that morph and i disagree about what to build14:40
ratmice__fwiw, I do sometimes wish everything might work as some sort of large series of self contained filesystems which can be mounted like /opt rather than devel/release shenanigans, but its somewhat harder to maintain a consistent risk-free image :/14:40
persiapaulsherwood: I agree.  I believe that using commit to ensure shared understanding is sensible.  Morph does that today, but hides the details in ways that cause git visualisation tools to lose track.14:40
persia(although richard_maw's recent changes may have changed this: I haven't rebuild my gitk+tig system with them yet)14:41
persiaratmice__: It's a dependency issue: you'd need to have each piece know the complete set of other things for which it is integrated as it drops in place.14:41
* persia also wants this, but expects it to be enterprise-only, due to the massive infrastructural requirements14:42
ratmice__i do nutty things, branch per patch in a series, merge branch, and a scripts-to-merge-it branch, so committing can be rather involved14:43
persiaHrm?  If you have branch-per-patch, you have lots of git commits, although perhaps not a classic VCS "commit".14:43
persiaI actively don't believe users should have a classic VCS commit except at the end of their series of work.14:44
* persia is perhaps overly excited about git's failures as a VCS allowing for lots of useful hackery for unpublished branches14:44
ratmice__persia: the 'merge' branch contains the classic VCS commit, and each patch branch gets rebased/etc as patch series evoles...14:45
persiaUnderstood: I've seen discussion of this workflow recently in a few contexts, but all the changes you make are typicaly commited in the git sense regularly, and the cost of --amend is light, no?14:47
persia(Although I'm not sure precisely why I'm arguing for my workflow, when I really only care about whether morph exposes when it commits stuff, so users aren't surprised)14:49
ratmice__not exactly, part of it is ensuring that each patch in the series builds/tests appropriately by some per-commit continuous integration, a lot of the actual programming gets done in the merge branch, then I go to various satellites only to commit...14:50
persiaAh, that's a little different than the patch-per-branch workflow I saw discussed recently.14:51
persiaAs I understand it, distbuild currently does a commit (into a new branch) on morph build, and pushes that new branch to a shared location.14:52
persiaMy thought was that this should be exposed to users more clearly, rather than morph trying hard to restore state (including staging state) after the commit.14:53
persiaBut maybe you need that state for something?14:54
ratmice__fwiw I don't use this all the time, but have maintained some fairly intrusive patches for a long period of time14:54
persiaRight, but if you need the uncommitted git state at least sometimes, then it's probably worth continuing to support this.14:56
persiaWhereas if you don't need the state, then I'll continue arguing we shouldn't store it until I find someone that does :)14:57
ratmice__distbuild throws some uncertainty in my mind as to whether I ever want uncommited stuff to be available _to other people_, which is a resounding no :)15:00
persiaHmm..  I hadn't thought about that.15:03
persiaI want build-on-target because I don't want to have to run a trove at home to patch my router.15:03
persiaBut I can well imagine a team environment in an organisation where it's tempting to have a change including a comment about a coworker's stupidity that needs to be built, but never seen by that coworker (especially if one is wrong).15:04
paulsherwoodratmice__: i agree with you, again :)15:04
ratmice__it seems like the having 2 cache's a local one and a distbuild one is messing with my head and it'd be nice to get down to just one and a 'run distbuild locally' scenerio15:05
persiaThe issue there is really exposing that cache to the worker.15:09
persia(or paying the price in extra build time)15:09
persiaNote that the lack of effective gc on trove caches currently means one has to care (for resource allocation reasons), but ideally one shouldn't.15:11
ratmice__its not so much offending co-workers as much as testsite passes/coverage metadata which are trivially ignored in the local only scenerio but hogwash in a distributed scenerio (I understand it's technically offtopic for distbuild) but its a new separation to many developers, and i probably just need to track whats going on with mason more15:26
* persia has read that several times and remains confused.15:30
persiaDo you mean something like not wanting to have published branches that don't pass the verification suite?15:31
persia(especially when you fixed the issue 2 minutes later)15:31
ratmice__just not wanting every developers working branch to be listed together with the pass/fail % of coverage for the project as a whole until they publish, where that data is all keyed off of the build ID15:32
persiaAh, right.  That's probably a matter of having different CI reporting for development branches and the project.15:35
* persia hasn't been following the Mason work closely enough to know if this is currently enabled, but suspects that the per-branch nature of current Mason means that it is easiest to implement with current code by having separate CI environments per-developer (plus one for a merge target).15:36
ratmice__its probably important to note for the sake of verbosity i include coverage, because it requires special compiler flags, and thus affects the built stuff, which is irrelevent to whether and who the metadata is important to, anyhow if we could get a consistent workflow for all this i'd be a fairly happy camper :)16:09
persiaDepending on how it's done, profiling can also require that sort of thing.16:13
* persia suspects that the current cache key generation algorithm could be perplexed by these sorts of builds16:14
* paulsherwood must be doing something dumb...16:25
paulsherwoodflashing seems to proceed ok, but the board doesn't seem to boot16:25
* persia remembers spending a day or so trying to figure out nvidia's tegra tooling the first time16:26
persiapaulsherwood: When you boot, what happens?16:27
* persia wonders why the flash is being repartitioned16:27
persiaDid you let the magic smoke out?  The board should at least initialise.16:28
paulsherwoodno magic smoke. power led is on. fan is spinning. i can force recover it.16:28
* persia wonders if the firmware is actually reading the GPT and can load EFI, rather than using u-boot16:30
paulsherwoodi can boot using the nvidia bootloader. this is me trying to dumb-down radiofree's distbuild instructions, for a single jetson16:31
persiaAnd where are you in the instructions?  I presume you've already gotten the dev image running, and are now trying for a cluster morphology?16:33
paulsherwoodi had a devel image running, with the nvidia kernel. i now have a new jetson devel image, which i'm trying to put into the emmc16:35
paulsherwoodwith u-boot, btrfs16:35
persiaSo you've run `morph deploy`, and are on the "Flashing the distbuild images" section?16:36
paulsherwoodnot exactly.16:36
paulsherwoodah. that'll be it.16:37
persiaWhat did you try to do between `morph build` and ``?16:37
paulsherwoodmy deploy did not have all the magic set16:37
paulsherwoodthank you16:37
* persia vaguely wishes the deployment magic could go away in favour of ansible, but understands this would probably be bad for folk building highly-resource-constrained systems16:38
persiaSo I hope you've found a solution, but I'm guessing you had booted u-boot, and didn't chain-load linux, and didn't have a serial console connected.16:42
paulsherwoodyour guess is almost certainly correct16:49
paulsherwoodsadly my round-trip-time on this at the moment is approx 60 mins16:50
persiaPart of that is that your target doesn't have native EFI loaded, making it hard to work with.16:52
persiaBut I don't understand the other 50 minutes: what takes so long?16:53
paulsherwood30 mins to flash16:55
paulsherwood10 mins to migrate my redeployed image to my x86 vm16:55
persiaThat should go away once you finish bootstrapping and can migrate to an upgrade-based workflow.16:55
paulsherwoodand 20 mins futzing around16:55
radiofreeI do hope you're not trying to flash a board without a serial connection16:55
persiaradiofree: Why?16:56
paulsherwoodyes, i am trying that16:56
* persia has never used nvflash and a serial console at the same time, not much seeing the point16:56
paulsherwoodbut to be clear, it's the bootstrapping i want to crack16:56
radiofreeBecause you have no idea what's going on16:56
paulsherwoodradiofree: welcome to my world :)16:56
radiofreeIf u-boot has actually flashed.. If the kernel has loaded... If the kernel has panicked at some point16:57
paulsherwoodfootie's finished, i see :)16:57
persiapaulsherwood: So, the sane bootstrapper would just flash the image from twice.16:57
radiofreeYou have absolutely no way of knowing what's going on16:57
persiaradiofree: For those of us who don't hack the kernel much, and like to assume bootloader folk did it right, that's fine16:57
persia(yes, sadly, this isn't usually a very safe assumption, but for this I blame the reliance of bootloader folk on serial consoles, rather than the problem being with the user expecting the device to work without one)16:58
radiofreeCan't have this conversation ATM. On phone16:59
persiaNo worries.  The nice thing about IRC is that timing is flexible (especially if one has infinite backscroll)17:00
radiofreeI would just recommend using the serial when doing this type of stuff, just to make sure you know what's going on17:00
radiofreeAlso 30min to flash 3GB?17:01
paulsherwoodyup - virtualbox usb passthrough on mac seems very slow17:01
radiofreeWhat's the VM usb controller?? USB 1?17:01
persiaIt was probably performance validated for USB 1, and has since had more support added, but not new performance adjustments.17:02
paulsherwoodit claims USB 2.017:02
persiaIf it doesn't work this time, just flash the devel image, and upgrade it to your target image, so you don't have to do this again.17:05
persia(as a side effect, the upgrade workflow probably extends the life of the flash medium, because btrfs understands about wear leveling)17:06
paulsherwoodthat would be giving up :)17:06
* persia stops trying to channel Sancho Panza17:07
* paulsherwood surrenders for today...17:29
radiofreein terms of what you're currently trying to achieve - get baserock on there so you can then use baserock to upgrade it17:52
radiofreeit requires board specific stuff, this will be the same for all boards17:52
radiofreee.g for a wandboard it would be much more scary "use dd to flash this here, and that there.... then flash the image to this partition"17:53
radiofreeit requires a certain amount of knowledge, if you were handing out these boards for developers to use i would imagine you would want them to be pre-flashed17:54
radiofreeIMO for any board work, even after you've installed baserock, you'd always want a serial connection to it17:54
radiofreesay you upgraded the kernel, if it didn't "boot" you'd be clueless about where it went wrong17:55
radiofreeis it hanging waiting for the rootfs (which could mean maybe something's wrong in the new device tree), or is there a kernel panic before that?17:56
*** flatmush [] has quit [Ping timeout: 264 seconds]18:18
*** flatmush [] has joined #baserock18:19
*** flatmush [] has quit [Ping timeout: 245 seconds]18:32
*** flatmush [] has joined #baserock19:00
*** flatmush [] has quit [Ping timeout: 245 seconds]19:09
*** flatmush [] has joined #baserock19:15
*** flatmush [] has quit [Ping timeout: 240 seconds]19:26
*** flatmush [] has joined #baserock19:26
*** flatmush [] has quit [Ping timeout: 244 seconds]19:31
*** flatmush [] has joined #baserock19:40
*** flatmush [] has quit [Ping timeout: 255 seconds]19:51
*** flatmush [] has joined #baserock19:56
*** flatmush [] has quit [Ping timeout: 250 seconds]20:07
*** flatmush [] has joined #baserock20:17
*** flatmush [] has quit [Ping timeout: 245 seconds]20:22
persiaradiofree: So, for my other tegra devices, when it didn't boot, I generally just reflashed it with something else, and then it booted.  Only binary information, but this is sufficient for someone who isn't going to fix the kernel or bootloader.20:25
persia(it may also be worth noting that I would have had to drill a hole in the plastic to attach a serial cable, which is generally my experience with devices: I did roughly the same thing for i.MX51, although that involved a reinstall rather than a reflash (as there was XOR flash implementing multidevice kernel loading on that device))20:27
*** flatmush [] has joined #baserock20:34
*** flatmush [] has quit [Ping timeout: 255 seconds]20:38
*** flatmush [] has joined #baserock20:51
*** flatmush [] has quit [Ping timeout: 272 seconds]21:21
*** flatmush [] has joined #baserock21:29
*** flatmush [] has quit [Ping timeout: 260 seconds]21:34
*** flatmush [] has joined #baserock21:43
*** flatmush [] has quit [Ping timeout: 245 seconds]22:00
*** flatmush [] has joined #baserock22:02
*** flatmush [] has quit [Ping timeout: 260 seconds]22:37
*** flatmush [] has joined #baserock22:38

Generated by 2.15.3 by Marius Gedminas - find it at!