| *** gtristan has quit IRC | 04:44 | |
| *** gtristan has joined #baserock | 05:24 | |
| gtristan | can someone confirm for me... about extensions/writeexts.py... when we call 'extlinux --install ${real_root}'... are we using the freshly installed extlinux ? | 06:53 |
|---|---|---|
| gtristan | I can confirm we do not | 07:08 |
| *** rdale has joined #baserock | 07:50 | |
| pedroalvarez | If you are planning to upgrade syslinux there are horror histories that you might want to know.. | 08:05 |
| pedroalvarez | Stories* :) | 08:07 |
| pedroalvarez | Good morning | 08:07 |
| pedroalvarez | Although I think we were close.. | 08:11 |
| gtristan | pedroalvarez, good morning... | 08:12 |
| gtristan | oh dont worry... this is already a horror story | 08:12 |
| gtristan | I have been 2 days into this | 08:12 |
| pedroalvarez | Are you going to share the fun with us? | 08:24 |
| gtristan | I have been busy chatting with devs in #syslinux sorry | 08:26 |
| gtristan | pedroalvarez, ok fwiw, this is my chat on #syslinux: http://paste.baserock.org/puquxivori | 08:28 |
| *** edcragg has joined #baserock | 08:33 | |
| gtristan | pedroalvarez, ok... so here is my understanding so far, and experience with the problem | 08:34 |
| gtristan | first... I compiled the whole thing... and when running the gnome image in virtualbox... I get this error: | 08:34 |
| gtristan | int13_harddisk: function 42. Can't use 64bits lba | 08:35 |
| *** toscalix has joined #baserock | 08:35 | |
| *** CTtpollard has joined #baserock | 08:35 | |
| gtristan | This is debian testing, building with the same ybd setup I was using on the old Ubuntu 14.04 lts btw... I chose something more bleeding edge because it actually took a while to get things up and running with the older, more stable OS | 08:36 |
| gtristan | So, looking on the web, the 64bits lba issue is something that seems addressed in recent builds of virtualbox (recent as in... weeks ago there is an experimental fix for the years old bug) | 08:37 |
| gtristan | https://www.virtualbox.org/ticket/7415 <-- this bug | 08:37 |
| gtristan | Now, grepping around... I am thinking... what the hell is creating the LBA, and why is it 64bits ? | 08:37 |
| gtristan | I found some lines of code in syslinux which formats gpt and seemed to be related | 08:38 |
| *** ctbruce has joined #baserock | 08:39 | |
| gtristan | then discovered that... syslinux's extlinux binary should match the syslinux modules installed on the host | 08:39 |
| gtristan | syslinux devs recommend that they be of the "same build" even (ouch) | 08:39 |
| gtristan | So, I have a local ugly brute force patch which makes writeexts uses ${real_root}/some/btrfs/madness/root/sbin/extlinux binary instead... to use the binary which was compiled | 08:40 |
| gtristan | well... anyway... that patch works... but does not solve the problem | 08:42 |
| gtristan | syslinux guys are saying that nothing about syslinux should trigger 64bits lba for an image so small as 7GB | 08:43 |
| gtristan | so problem *should* be elsewhere (although I think that blindly invoking the extlinux from the build host is not going to work, either) | 08:44 |
| edcragg | gtristan: not sure if related at all, but i wrote some stuff in the rawdisk.write extension that flashes the sys/extlinux bootloader binary to the mbr, and i tested that in KVM at the time | 08:46 |
| gtristan | edcragg, rawdisk.write has some mention of extlinux in do_upgrade(), but I dont think I'm doing that when simply deploying a freshly built image to a file... am I hitting that code ? | 08:50 |
| gtristan | note that using the built syslinux (4.0.6) instead of the host syslinux (6.0.3)... *does* change the error in kvm | 08:53 |
| gtristan | instead of silently spinning at 100% cpu... | 08:53 |
| gtristan | I get the error: EDD: Error 0100 reading sector 36028797018963960 | 08:53 |
| gtristan | and then spin at 100% cpu in kvm | 08:53 |
| gtristan | so, *something* seems to be making this image seem extremely huge... somewhere | 08:54 |
| gtristan | oh, and on the old LTS ubuntu 14.04 system, my btrfs was too old | 08:54 |
| pedroalvarez | wow wow, this is a lot of fun... | 08:54 |
| pedroalvarez | I guess this is one of the problems of using baserock from random OSes | 08:55 |
| gtristan | so in the older system, I had to build images with patched writeexts.py so it removes the --features args to mkfs.btrfs | 08:55 |
| gtristan | pedroalvarez, perhaps | 08:56 |
| gtristan | pedroalvarez, or perhaps it's the kind of thing that is going to happen anyway, if you think you can just upgrade btrfs and syslinux, and build from a 'baserock vm' with too old syslinux | 08:57 |
| gtristan | and in any case, there needs to be a bootstrapping story - one cannot have a baserock vm be a hard requirement for building a baserock vm, right ? | 08:58 |
| gtristan | that's a bit circular | 08:58 |
| pedroalvarez | sure, you can still build it right, the problem is deploying | 08:59 |
| pedroalvarez | it's easy to bootstrap a rootfs that you can use later :) | 08:59 |
| gtristan | that seems to just be a missing link, we have all the tools there in the built system | 09:00 |
| gtristan | but we are not using them to create the image | 09:00 |
| pedroalvarez | not always I think | 09:00 |
| pedroalvarez | I'm not sure but I think that not every system deployed will have the tools that are needed to be deployed | 09:01 |
| edcragg | gtristan: if you deploy to a disk image, the partition table is MBR, and actually only if it's a partitioned image, so i guess you're probably not hitting that code | 09:01 |
| pedroalvarez | gtristan: so, some of these horror stories I mentioned were trying to deploy a system from a baserock vm with new syslinux | 09:02 |
| gtristan | pedroalvarez, right, but that is a matter of splitting up the artifacts... just because we are not deploying them in the target, does not mean we have not staged them somewhere and used them in the build | 09:02 |
| pedroalvarez | that is a good point | 09:03 |
| pedroalvarez | yeah, we have the power of building the tools, why not relying on our built tools when deploying? | 09:04 |
| pedroalvarez | hm.. | 09:04 |
| gtristan | on the other hand, this system builds a webkit that I cannot run, amazingly fast :) | 09:06 |
| *** bashrc has joined #baserock | 09:07 | |
| pedroalvarez | hahahah | 09:27 |
| * gtristan looks at 9fe18e52 | 09:31 | |
| gtristan | looking at the mkfs.btrfs lines, it shows that we are already disabling btrfs features which older syslinux cannot handle | 09:32 |
| gtristan | And now, I have debian testing... with even newer btrfs - perhaps I need to disable more features | 09:32 |
| gtristan | I notice that the error is different booting up if I comment out the --features lines and --nodesize line | 09:33 |
| gtristan | well, different... that is to say there is no 64bits lba error, only an SYSLINUX version line followed by nothing | 09:33 |
| pedroalvarez | I remember tiagogomes doing some progress on deploying using syslinux 6.03.. but I failed to find any of his work | 09:34 |
| gtristan | that should 'just work' assuming that A.) You upgrade syslinux in bsp strata and B.) You invoke extlinux as ${real_root}/systems/factory/run/sbin/extlinux | 09:35 |
| gtristan | the binaries themselves are very 'simple' stuff, by that I mean they dont load modules or anything, it's all math and sizes and such | 09:36 |
| edcragg | does the correct binary just need to be copied to the right place in deployment then? | 09:48 |
| *** jonathanmaw has joined #baserock | 09:50 | |
| *** tiagogomes has joined #baserock | 09:57 | |
| gtristan | edcragg, you mean for syslinux upgrade to work ? | 09:57 |
| gtristan | the thing about syslinux, is that it distributes modules required to boot... and it also has a tool (extlinux binary) which is used to install a bootloader | 09:58 |
| gtristan | the extlinux binary... and the modules installed at make install time, are supposed to *come from the same build* of syslinux | 09:59 |
| gtristan | people in #syslinux say that it may have 'worked' for slightly varying versions of 4.x, but will certainly not work for say, 4.x extlinux bootloader with 6.x modules | 10:00 |
| gtristan | when we boot a baserock image, we currently have the host extlinux install a boot loader which will encounter the syslinux modules that were built in the build system | 10:00 |
| *** VLetrmx_ is now known as VLetrmx | 10:02 | |
| *** ssam2 has joined #baserock | 10:04 | |
| *** ChanServ sets mode: +v ssam2 | 10:04 | |
| gtristan | Good news | 10:08 |
| gtristan | pedroalvarez, after all that fiddling, I find that using the built syslinux's extlinux, AND building a btrfs-progs v4.0 locally (matching the baserock version) - results in a bootable image again | 10:09 |
| pedroalvarez | heh | 10:09 |
| gtristan | pedroalvarez, which means, I think it's a safe bet to say that if we *did* use the built tooling for the image deployment, we would not have this problem | 10:09 |
| pedroalvarez | good news indeed/ | 10:09 |
| pedroalvarez | yeah.. | 10:10 |
| pedroalvarez | then some people will say: "Then you can't deploy an arm system from x86!!" | 10:11 |
| gtristan | Can you today ? | 10:11 |
| pedroalvarez | yes | 10:11 |
| gtristan | that's not what we demoed in korea though, which is a nice approach to that problem | 10:12 |
| gtristan | but indeed | 10:12 |
| gtristan | pedroalvarez, I think if the cross-environment really works, then it should not be a problem | 10:12 |
| gtristan | if you are cross compiling, that means you have built the host tooling for the target system which runs on the host | 10:13 |
| gtristan | that is the level of tools you want to use for the deployment, I think | 10:13 |
| richard_maw | pedroalvarez: aye, which is why I want to be able to specify a system to deploy from, so you can say "deploy this ARM system using tools from this x86 chroot" | 10:13 |
| pedroalvarez | gtristan: note that I said "deploy", not build | 10:14 |
| gtristan | pedroalvarez, yes I know... and when I say the "built tooling for the image deployment"... I am being a bit loose there | 10:15 |
| pedroalvarez | gtristan: oh right, I forgot your real suggestion | 10:16 |
| pedroalvarez | (monday morning, sorry) | 10:16 |
| radiofree | had an e-mail about the baserock-flashing-script in ubuntu | 10:23 |
| radiofree | it doesn't work because the version of fdisk there doesn't support GPT partition tables, could anyone with a bit of free time change the script over to use `parted` instead? | 10:23 |
| *** franred has joined #baserock | 10:39 | |
| ssam2 | if nobody has time, could you file an issue in storyboard.baserock.org or send a mail to the baserock-dev list radiofree ? | 10:45 |
| *** gtristan has quit IRC | 10:45 | |
| ssam2 | here's a thought for the day: http://blog.ezyang.com/2015/12/the-convergence-of-compilers-build-systems-and-package-managers/ | 10:49 |
| nowster | has someone put kimchi in the fridge? | 10:49 |
| franred | nowster, wrong window :) | 10:49 |
| franred | ? | 10:49 |
| nowster | oops! | 10:50 |
| nowster | at least it wasn't leaking (unlike the smell from the tupperware box) | 10:50 |
| franred | :D | 10:50 |
| *** locallycompact has joined #baserock | 10:55 | |
| *** franred has quit IRC | 11:04 | |
| *** gtristan has joined #baserock | 11:08 | |
| *** Lachlan1975 has joined #baserock | 11:13 | |
| *** gtristan has quit IRC | 11:14 | |
| *** franred has joined #baserock | 11:18 | |
| *** gtristan has joined #baserock | 11:37 | |
| *** franred has quit IRC | 11:38 | |
| *** franred has joined #baserock | 11:50 | |
| persia | radiofree: On fdisk: parted works, but also gdisk, if one wants less of an API change. | 12:20 |
| edcragg | that's true | 12:22 |
| edcragg | variously also called gfdisk | 12:23 |
| edcragg | really any sensibly recent fdisk should support GPT though | 12:24 |
| edcragg | if the jetson supports booting from an MBR partitioned disk, then that would be another easier option | 12:25 |
| persia | Does the jetson support EFI? | 12:29 |
| radiofree | persia: is gdisk sufficiently ubiquitous? | 12:36 |
| radiofree | i.e "apt-get install gdisk" will do it? | 12:36 |
| persia | radiofree: apt-get and yum work. I've been using gdisk for nearly 5 years. I don't know how common it is everywhere. | 12:37 |
| radiofree | it's on fedora by default (along with a version of fdisk that actually works with GTP...) | 12:38 |
| radiofree | well it still doesn't have the "g" command | 12:39 |
| radiofree | why am i using gpt anyway, does a dos partition layout work on a jetson? i don't see why not? | 12:39 |
| radiofree | jonathanmaw: you had some trouble with the flashing script on debian right? | 12:39 |
| radiofree | did changing "g" to "o" resolve it | 12:40 |
| jonathanmaw | radiofree: something like that. | 12:40 |
| *** Lachlan1975 has quit IRC | 13:12 | |
| *** tiagogomes has quit IRC | 13:59 | |
| *** tiagogomes_ has joined #baserock | 13:59 | |
| *** Lachlan1975 has joined #baserock | 14:18 | |
| *** trn has joined #baserock | 14:26 | |
| *** edcragg has quit IRC | 15:09 | |
| *** locallycompact has quit IRC | 15:09 | |
| *** locallycompact has joined #baserock | 15:10 | |
| *** edcragg has joined #baserock | 15:11 | |
| *** edcragg has quit IRC | 15:25 | |
| *** edcragg has joined #baserock | 15:25 | |
| *** flatmush has quit IRC | 15:51 | |
| *** fay__ has quit IRC | 16:16 | |
| *** ctbruce has quit IRC | 17:17 | |
| *** edcragg has quit IRC | 17:42 | |
| *** bashrc has quit IRC | 18:03 | |
| tiagogomes_ | github:jmacarthur/openjdk-binary :| | 18:09 |
| *** jonathanmaw has quit IRC | 18:13 | |
| *** locallycompact has quit IRC | 18:28 | |
| *** toscalix has quit IRC | 18:30 | |
| *** paulw has joined #baserock | 18:38 | |
| *** ssam2 has quit IRC | 19:04 | |
| *** Lachlan1975 has quit IRC | 19:40 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!