March 19, 2019 
< | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | >
March 19, 2019 [00:20:43] <amstan> nh2: hey[00:20:54] <nh2> amstan: hey[00:21:07] <amstan> depends what linux version your chromebook is running[00:21:47] <nh2> amstan: that is what I want to find out; it says 3.8.11 in `uname -a`[00:21:58] <amstan> 3.8 is what i was looking for[00:22:28] <amstan> so this is where you want to look: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-3.8[00:22:44] <amstan> that's "master", essentially what's going to be in canary tomorrow[00:23:00] <nh2> amstan: how do I find out which exact commit my Chromebook is running right now?[00:23:13] <amstan> depends what chromeos version you're on[00:23:24] <amstan> dev/beta/stable[00:23:28] <amstan> but more importantly the number[00:23:43] <amstan> probably one of R72, 73, 74[00:23:59] <amstan> then you look in https://chromium.googlesource.com/chromiumos/third_party/kernel/+refs[00:24:28] <amstan> for a branch labeled: "release-R$yournumber-*-chromeos-3.8"[00:25:46] <amstan> but realistically... last commit in 3.8 "master" was oct[00:25:53] <amstan> so there won't be a difference[00:26:03] <amstan> since i think they all branched after that[00:26:38] <nh2> amstan: is there no complete mapping of Chrome OS version to git commit (e.g. a direct lookup table)?[00:27:13] <amstan> there is, those branches[00:27:31] <nh2> but branches can change over time[00:27:45] <nh2> e.g. I have 58.0.3028.140 in the "About" window[00:27:55] <amstan> but your laptop's version could change too[00:28:23] <amstan> let's say you're on stable, R73, and tomorrow another specter vulterability comes, you'll get an update to another R73 that has a fix for it[00:28:54] <amstan> generally those branches don't change much after the branch point, it's more for bugfixes or stability things[00:28:58] <amstan> think of it like a feature freeze[00:29:37] <nh2> amstan: so there is no unambiguous way to find out precisely what code is running? That seems odd[00:29:40] <amstan> anyway, if you have R58 (that's super old btw)[00:29:48] <amstan> you're probably running https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/release-R58-9334.B-chromeos-3.8[00:33:00] <amstan> anyway, so what's this bug you speak of[00:33:15] <amstan> perhaps we could merge it in :)[00:34:05] <nh2> amstan: an incorrect cherry-pick of an upstream kernel fix (I figured it out last night): https://github.com/systemd/systemd/issues/11974#issuecomment-473754055[00:34:54] <nh2> nonexistent system calls returned their own number as return value, insteadof ENOSYS, which lead to software being unable to detect whether syscalls are available or not[00:35:46] <nh2> it was fixed in ChromiumOS's 3.18 kernel, so there will be only something to do if < 3.18 kernels are still maintained in any way[00:35:59] <amstan> nh2: are you sure that's a cherry-pick? we usually label cherry-picks pretty well[00:36:09] <amstan> and it would say that's been reviewed on gerrit, etc[00:36:51] <amstan> i'm baffled[00:37:22] <amstan> here we go: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/313465[00:38:04] <amstan> I'm really not sure where 554086d85e71f30abe46fc014fea31929a7c6a8a and 8142b215501f8b291a108a202b3a053a265b03dd are[00:38:18] <amstan> in our tree, like which branch[00:38:41] <amstan> but the gerrit link i pasted looks like a real cherry-pick that landed in the 3.8 branch[00:39:45] <nh2> amstan: in the link above I provide a bullet point list with details of each branch involved; the problematic commit is on each linked page, very much at the top[00:40:08] <amstan> yeah, so you're talking about https://chromium.googlesource.com/chromiumos/third_party/kernel/+/554086d85e71f30abe46fc014fea31929a7c6a8a right?[00:40:41] <amstan> what i'm saying is that i don't know what branch that is for us, i don't think it's an ancestor of the 3.8 branch[00:41:13] <amstan> oh, i see[00:41:56] <amstan> alright, so it's a matter of cherry-picking 8142b21 (the fix)[00:42:26] <amstan> since the breakage 554086d8, landed in 3.8 as https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/313465[00:42:42] <nh2> amstan: that is correct, on https://patchwork.ozlabs.org/patch/372692/#821784 they discussed that one mustn't be picked without the other[00:42:46] <amstan> but in later kernels both 554086d8(breakage) 8142b21 (fix) landed[00:42:57] <amstan> cool[00:42:59] <nh2> yes[00:43:53] <amstan> so.. assuming i send a cl, and it gets merged[00:44:01] <amstan> will you even be able to run it?[00:44:16] <amstan> if you have R58 i assume you're running an EOL device? do you still get updates?[00:44:54] <nh2> amstan: I found it on an EOL device, trying to give it new life with crouton[00:45:10] <amstan> the issue is that you'll never get the kernel update, even if i do fix it[00:45:38] <amstan> you'll forever be stuck at https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/release-R58-9334.B-chromeos-3.8[00:45:56] <amstan> even if i merge the fix in that R58 branch, we don't have R58 builders anymore[00:46:43] <nh2> that makes sense, I investigated it only because I suspected that it might be a bug that exists in newer versions as well, but found that with >= 3.18 it must be fixed[00:48:46] <nh2> I'm still looking into how to give this Samsung 500C a new life given that it's EOL'd; crouton is clearly not a solution as running a 3.8 kernel isn't safe, but it doesn't seem to support Coreboot and I am not sure if there's a modern way (I've used ChrUbuntu before) to boot a normal Linux distro[00:49:25] <amstan> this is an intel machine, right?[00:49:29] <amstan> there's no seabios?[00:49:45] <amstan> yeah... chrubuntu probably did seabios[00:50:11] <amstan> with seabios you don't really need any more handholding, it's just like installing linux on a windows laptop[00:50:45] *** flyback <flyback!~flyback@2601:540:8201:c3ce::e162> has joined #chromium-os[00:51:27] <nh2> amstan: from what I have researched, there's no seabios for it -- https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/samsung-series-5-chromebook says that it runs on H2C[00:51:57] <amstan> weird, maybe i didn't know that chrubuntu does magic[00:52:07] <amstan> so without seabios, there's still another way to boot other distros[00:52:20] <amstan> it involves packaging the kernel into a partition[00:52:28] <amstan> we do this a lot of arm systems[00:53:33] <nh2> amstan: is there some docs for that somewhere that I could read?[00:53:36] <amstan> here's how you can partition the drive: https://archlinuxarm.org/platforms/armv8/rockchip/asus-chromebook-flip-c101pa[00:53:47] <amstan> some instructions on how to build the kpart: https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-gru/PKGBUILD#L97[00:54:00] <amstan> but not sure how much of that second link is arm specific[00:54:34] <amstan> those are for arch[00:54:41] <amstan> here's our file that does the same thing: https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/master/eclass/cros-kernel2.eclass[00:54:45] <amstan> but it's a lot less readable[00:54:54] <nh2> amstan: another thing I found quite odd is that the 500C runs i686 even though its processor is 64-bit[00:55:08] <amstan> probably 32 bit userspace[00:55:13] <amstan> the kernel's still 64 bit?[00:55:19] <amstan> we do that on arm still[00:55:29] <amstan> though i think we do 64 bit userspace on x86 now always[00:55:55] <nh2> amstan: the i686 is in the `uname -a` output, and the bug I found applies only to 32-bit kernels[00:56:00] <amstan> ah[00:57:17] <amstan> well that does explain a lot then, why nobody else noticed[00:57:27] <amstan> i don't think we do that often anymore[00:58:13] <nh2> amstan: should I be able to boot a normal Linux live USB stick if I've done all the developer mode stuff?[01:00:40] <amstan> no[01:00:58] <amstan> in the arch instructions[01:01:02] <amstan> you'll see the line: "crossystem dev_boot_usb=1 dev_boot_signed_only=0"[01:01:23] <amstan> that enables you to press ctrl+U on the white bootloader screen[01:01:26] <amstan> and it'll read a flash drive[01:01:39] <amstan> but the catch is, the flashdrive needs to be formatted with chromeos partitions[01:01:47] <amstan> so you already need the kpart magic that i talked about[01:02:02] <amstan> the arch instructions essentially tell you how to make such a removable drive[01:02:37] <amstan> is the chrubuntu repo still up somewhere?[01:02:46] <amstan> you're probably best reviving some of those scripts[01:02:58] <amstan> anything doing "cgpt ..."[01:03:44] <amstan> nh2: you don't happen to be on this list? https://mrchromebox.tech/#devices[01:03:58] <nh2> amstan: right, I suspected that. There's quite an amount of partitions on the the 500C, so I'd have to figure out which one is the right one, and to prepare stuff in the way that the device likes it as you say[01:04:08] <amstan> you only need 2 partitions[01:04:35] <amstan> there's a kernel type partition that the bootloader looks for[01:04:38] <amstan> and the rootfs for it[01:05:19] <amstan> the hd on a chromebook has a lot because theres 3 sets of each, a big stateful partition (where your encrypted data actually is)[01:05:27] <amstan> and a bunch of extra misc things that aren't important[01:05:40] <nh2> amstan: unfortunately I'm not on that list, I have the XE500C21 and that list only has XE500C12[01:14:32] <amstan> nh2: https://wiki.archlinux.org/index.php/Talk:Chrome_OS_devices#removed_old_content[01:14:37] <amstan> looks like they removed it[01:14:47] <amstan> because everyone relies on seabios i guess[01:15:25] <nh2> amstan: oh, nice find[01:15:39] <amstan> it might not go into the kpart packaging though[01:15:59] <amstan> cgpt is useful even when you're not doing that, like just shuffling partitions around[01:16:18] <nh2> amstan: I also shortly looked into putting Coreboot on[01:16:24] <nh2> it but found only this: https://mail.coreboot.org/pipermail/flashrom/2016-October/014857.html[01:16:35] <nh2> that didn't look too promising[01:16:54] <amstan> oh![01:16:56] <amstan> well[01:17:04] <amstan> i just realized it wouldn't work[01:17:32] <amstan> but you could always take whatever's on your computer right now, keep using the same kernel, just replace the userspace[01:17:36] <amstan> but that's not what you want[01:17:57] <amstan> but eventually you could replace the kernel too, once you get familiar with the vbutil_kernel tool[01:18:34] <amstan> pretty much just do https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-gru/PKGBUILD#L97[01:19:33] <nh2> amstan: another question that might solve it: Can the Chromebook kernel kexec() other kernels?[01:19:49] <amstan> i don't know, it's possible the config option is disabled[01:20:30] <nh2> amstan: can I easily look at the kernel config I'm running on somehow?[01:20:53] <amstan> modprobe configs, gcat /proc/config.gz or something like that[01:24:26] <amstan> you know... you could try running an amd64-generic build of chromiumos[01:24:42] <amstan> if it's packages the chromeos way it should boot[01:25:19] <nh2> amstan: I get `# CONFIG_KEXEC is not set` when grepping for kexec in the /proc/config.gz[01:25:25] <amstan> welp[01:25:29] <nh2> amstan: where can I find the amd64-generic build?[01:25:51] <amstan> there's not really any official binaries you can download[01:27:00] <nh2> are there some instructions with which I could build it from a checkout?[01:27:18] <amstan> https://chromium.googlesource.com/chromiumos/docs/+/master/developer_guide.md[01:27:40] *** eballetbo[m] <eballetbo[m]!eballetbom@gateway/shell/matrix.org/x-nmntxgtssytilkty> has quit IRC (Remote host closed the connection)[01:28:03] *** sielicki <sielicki!sielickima@gateway/shell/matrix.org/x-rybhxtmdvadzozzz> has quit IRC (Remote host closed the connection)[01:28:04] <amstan> with that, in theory you can patch the kernel the way you like it, build another R58[01:28:04] <amstan> and just boot that[01:28:04] <nh2> ah I see, in the board selection[01:28:14] <amstan> assuming the board wasn't deleted[01:28:26] <amstan> but at the repo init step you can tell it to use the R58 branch[01:28:32] <amstan> and you'll definatelly still have your board[01:28:54] <nh2> right, as long as I'm able to enable kexec in the kernel config I should be good[01:29:31] <amstan> but the long term plan is still for you to learn how to use vbutil-kernel, then with a simple bash script you could convince your distro to package the kernel the way the bootloader likes it[01:29:51] <amstan> or kexec, heh[01:34:23] <nh2> yes, both of these seem like ways forward[01:34:30] <nh2> amstan: thanks a lot for your help![01:35:30] *** eballetbo[m] <eballetbo[m]!eballetbom@gateway/shell/matrix.org/x-voblldsszkxeoxrz> has joined #chromium-os[01:49:27] *** sielicki <sielicki!sielickima@gateway/shell/matrix.org/x-zffszauyixvsxpit> has joined #chromium-os[01:49:40] *** dgrogan <dgrogan!uid7844@gateway/web/irccloud.com/x-iybhhivdoisebvbz> has joined #chromium-os[01:51:40] *** flyback <flyback!~flyback@2601:540:8201:c3ce::e162> has quit IRC (Remote host closed the connection)[01:54:24] *** flyback <flyback!~flyback@2601:540:8201:c3ce::e162> has joined #chromium-os[03:11:23] *** NightMonkey <NightMonkey!~NightMonk@pdpc/supporter/professional/nightmonkey> has quit IRC (Quit: ZNC - http://znc.in)[03:13:22] *** NightMonkey <NightMonkey!~NightMonk@pdpc/supporter/professional/nightmonkey> has joined #chromium-os[03:42:18] *** bashfulshell <bashfulshell!uid190567@gateway/web/irccloud.com/x-anigousokbgefhme> has quit IRC (Quit: Connection closed for inactivity)[16:23:17] *** trisk <trisk!~trisk@2601:196:4700:3f0b:225:31ff:fe02:7a11> has quit IRC (Quit: WeeChat 2.0.1)[16:33:52] *** armax00 <armax00!~armax00@pdpc/supporter/student/armax00> has quit IRC (Remote host closed the connection)[17:01:12] *** trisk <trisk!~trisk@2601:196:4700:3f0b:225:31ff:fe02:7a11> has joined #chromium-os