nh2/chromebook-samsung-linux-boot-discussion.txt

## chromebook-samsung-linux-boot-discussion.txt
→ nh2 joined  •  Channel mode: +cgnrt
02:41 <nh2> I think I found a bug in ChromiumOS's custom Linux kernel patches. How do I find the exact git commit of the kernel that my Chromebook is running?
03:30 <nh2> also, why is the `Version Lookup` box on https://cros-omahaproxy.appspot.com returning (in red bold text):
03:30 <nh2> <html> <head> <title>500 Internal Server Error</title> </head> <body> <h1>500 Internal Server Error</h1> The server has either erred or is incapable of performing the requested operation.<br /><br /> </body> </html>
05:50 → CEnnis91 joined  ⇐ flyback quit  ↔ seventh popped in  ↔ bashfulshell, sibis and phh nipped out
Tuesday, March 19th, 2019
00:20
<+amstan> nh2: hey
00:20 <nh2> amstan: hey
00:21
<+amstan> depends what linux version your chromebook is running
00:21 <nh2> amstan: that is what I want to find out; it says 3.8.11 in `uname -a`
00:21
<+amstan> 3.8 is what i was looking for
00:22
<+amstan> so this is where you want to look: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-3.8
00:22
<+amstan> that's "master", essentially what's going to be in canary tomorrow
00:23 <nh2> amstan: how do I find out which exact commit my Chromebook is running right now?
00:23
<+amstan> depends what chromeos version you're on
00:23
<+amstan> dev/beta/stable
00:23
<+amstan> but more importantly the number
00:23
<+amstan> probably one of R72, 73, 74
00:24
<+amstan> then you look in https://chromium.googlesource.com/chromiumos/third_party/kernel/+refs
00:24
<+amstan> for a branch labeled: "release-R$yournumber-*-chromeos-3.8"
00:25
<+amstan> but realistically... last commit in 3.8 "master" was oct
00:25
<+amstan> so there won't be a difference
00:26
<+amstan> since i think they all branched after that
00:26 <nh2> amstan: is there no complete mapping of Chrome OS version to git commit (e.g. a direct lookup table)?
00:27
<+amstan> there is, those branches
00:27 <nh2> but branches can change over time
00:27 <nh2> e.g. I have 58.0.3028.140 in the "About" window
00:27
<+amstan> but your laptop's version could change too
00:28
<+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
<+amstan> generally those branches don't change much after the branch point, it's more for bugfixes or stability things
00:28
<+amstan> think of it like a feature freeze
00:29 <nh2> amstan: so there is no unambiguous way to find out precisely what code is running? That seems odd
00:29
<+amstan> anyway, if you have R58 (that's super old btw)
00:29
<+amstan> you're probably running https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/release-R58-9334.B-chromeos-3.8
00:33
<+amstan> anyway, so what's this bug you speak of
00:33
<+amstan> perhaps we could merge it in :)
00:34 <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 <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 <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
<+amstan> nh2: are you sure that's a cherry-pick? we usually label cherry-picks pretty well
00:36
<+amstan> and it would say that's been reviewed on gerrit, etc
00:36
<+amstan> i'm baffled
00:37
<+amstan> here we go: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/313465
00:38
<+amstan> I'm really not sure where 554086d85e71f30abe46fc014fea31929a7c6a8a and 8142b215501f8b291a108a202b3a053a265b03dd are
00:38
<+amstan> in our tree, like which branch
00:38
<+amstan> but the gerrit link i pasted looks like a real cherry-pick that landed in the 3.8 branch
00:39 <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
<+amstan> yeah, so you're talking about https://chromium.googlesource.com/chromiumos/third_party/kernel/+/554086d85e71f30abe46fc014fea31929a7c6a8a right?
00:40
<+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
<+amstan> oh, i see
00:41
<+amstan> alright, so it's a matter of cherry-picking 8142b21 (the fix)
00:42
<+amstan> since the breakage 554086d8, landed in 3.8 as https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/313465
00: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
<+amstan> but in later kernels both 554086d8(breakage) 8142b21 (fix) landed
00:42
<+amstan> cool
00:42 <nh2> yes
00:43
<+amstan> so.. assuming i send a cl, and it gets merged
00:44
<+amstan> will you even be able to run it?
00:44
<+amstan> if you have R58 i assume you're running an EOL device? do you still get updates?
00:44 <nh2> amstan: I found it on an EOL device, trying to give it new life with crouton
00:45
<+amstan> the issue is that you'll never get the kernel update, even if i do fix it
00:45
<+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
<+amstan> even if i merge the fix in that R58 branch, we don't have R58 builders anymore
00:46 <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 <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
<+amstan> this is an intel machine, right?
00:49
<+amstan> there's no seabios?
00:49
<+amstan> yeah... chrubuntu probably did seabios
00:50
<+amstan> with seabios you don't really need any more handholding, it's just like installing linux on a windows laptop
00:50 → flyback joined (~flyback@2601:540:8201:c3ce::e162)
00:51 <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
<+amstan> weird, maybe i didn't know that chrubuntu does magic
00:52
<+amstan> so without seabios, there's still another way to boot other distros
00:52
<+amstan> it involves packaging the kernel into a partition
00:52
<+amstan> we do this a lot of arm systems
00:53 <nh2> amstan: is there some docs for that somewhere that I could read?
00:53
<+amstan> here's how you can partition the drive: https://archlinuxarm.org/platforms/armv8/rockchip/asus-chromebook-flip-c101pa
00:53
<+amstan> some instructions on how to build the kpart: https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-gru/PKGBUILD#L97
00:54
<+amstan> but not sure how much of that second link is arm specific
00:54
<+amstan> those are for arch
00:54
<+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
<+amstan> but it's a lot less readable
00:54 <nh2> amstan: another thing I found quite odd is that the 500C runs i686 even though its processor is 64-bit
00:55
<+amstan> probably 32 bit userspace
00:55
<+amstan> the kernel's still 64 bit?
00:55
<+amstan> we do that on arm still
00:55
<+amstan> though i think we do 64 bit userspace on x86 now always
00:55 <nh2> amstan: the i686 is in the `uname -a` output, and the bug I found applies only to 32-bit kernels
00:56
<+amstan> ah
00:57
<+amstan> well that does explain a lot then, why nobody else noticed
00:57
<+amstan> i don't think we do that often anymore
00:58 <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
<+amstan> no
01:00
<+amstan> in the arch instructions
01:01
<+amstan> you'll see the line: "crossystem dev_boot_usb=1 dev_boot_signed_only=0"
01:01
<+amstan> that enables you to press ctrl+U on the white bootloader screen
01:01
<+amstan> and it'll read a flash drive
01:01
<+amstan> but the catch is, the flashdrive needs to be formatted with chromeos partitions
01:01
<+amstan> so you already need the kpart magic that i talked about
01:02
<+amstan> the arch instructions essentially tell you how to make such a removable drive
01:02
<+amstan> is the chrubuntu repo still up somewhere?
01:02
<+amstan> you're probably best reviving some of those scripts
01:02
<+amstan> anything doing "cgpt ..."
01:03
<+amstan> nh2: you don't happen to be on this list? https://mrchromebox.tech/#devices
01:03 <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
<+amstan> you only need 2 partitions
01:04
<+amstan> there's a kernel type partition that the bootloader looks for
01:04
<+amstan> and the rootfs for it
01:05
<+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
<+amstan> and a bunch of extra misc things that aren't important
01:05 <nh2> amstan: unfortunately I'm not on that list, I have the XE500C21 and that list only has XE500C12
01:14
<+amstan> nh2: https://wiki.archlinux.org/index.php/Talk:Chrome_OS_devices#removed_old_content
01:14
<+amstan> looks like they removed it
01:14
<+amstan> because everyone relies on seabios i guess
01:15 <nh2> amstan: oh, nice find
01:15
<+amstan> it might not go into the kpart packaging though
01:15
<+amstan> cgpt is useful even when you're not doing that, like just shuffling partitions around
01:16 <nh2> amstan: I also shortly looked into putting Coreboot on
01:16 <nh2> it but found only this: https://mail.coreboot.org/pipermail/flashrom/2016-October/014857.html
01:16 <nh2> that didn't look too promising
01:16
<+amstan> oh!
01:16
<+amstan> well
01:17
<+amstan> i just realized it wouldn't work
01:17
<+amstan> but you could always take whatever's on your computer right now, keep using the same kernel, just replace the userspace
01:17
<+amstan> but that's not what you want
01:17
<+amstan> but eventually you could replace the kernel too, once you get familiar with the vbutil_kernel tool
01:18
<+amstan> pretty much just do https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-gru/PKGBUILD#L97
01:19 <nh2> amstan: another question that might solve it: Can the Chromebook kernel kexec() other kernels?
01:19
<+amstan> i don't know, it's possible the config option is disabled
01:20 <nh2> amstan: can I easily look at the kernel config I'm running on somehow?
01:20
<+amstan> modprobe configs, gcat /proc/config.gz or something like that
01:24
<+amstan> you know... you could try running an amd64-generic build of chromiumos
01:24
<+amstan> if it's packages the chromeos way it should boot
01:25 <nh2> amstan: I get `# CONFIG_KEXEC is not set` when grepping for kexec in the /proc/config.gz
01:25
<+amstan> welp
01:25 <nh2> amstan: where can I find the amd64-generic build?
01:25
<+amstan> there's not really any official binaries you can download
01:27 <nh2> are there some instructions with which I could build it from a checkout?
01:27
<+amstan> https://chromium.googlesource.com/chromiumos/docs/+/master/developer_guide.md
01:27 ⇐ eballetbo[m] quit (eballetbom@gateway/shell/matrix.org/x-nmntxgtssytilkty) Remote host closed the connection
01:27 <nh2> ah I see, in the board selection
01:28 ⇐ sielicki quit (sielickima@gateway/shell/matrix.org/x-rybhxtmdvadzozzz) Remote host closed the connection
01:28
<+amstan> with that, in theory you can patch the kernel the way you like it, build another R58
01:28
<+amstan> and just boot that
01:28
<+amstan> assuming the board wasn't deleted
01:28
<+amstan> but at the repo init step you can tell it to use the R58 branch
01:28
<+amstan> and you'll definatelly still have your board
01:28 <nh2> right, as long as I'm able to enable kexec in the kernel config I should be good
01:29
<+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
<+amstan> or kexec, heh
01:34 <nh2> yes, both of these seem like ways forward
01:34 <nh2> amstan: thanks a lot for your help!
	→ nh2 joined • Channel mode: +cgnrt
	02:41 <nh2> I think I found a bug in ChromiumOS's custom Linux kernel patches. How do I find the exact git commit of the kernel that my Chromebook is running?
	03:30 <nh2> also, why is the `Version Lookup` box on https://cros-omahaproxy.appspot.com returning (in red bold text):
	03:30 <nh2> <html> <head> <title>500 Internal Server Error</title> </head> <body> <h1>500 Internal Server Error</h1> The server has either erred or is incapable of performing the requested operation.<br /><br /> </body> </html>
	05:50 → CEnnis91 joined ⇐ flyback quit ↔ seventh popped in ↔ bashfulshell, sibis and phh nipped out
	Tuesday, March 19th, 2019
	00:20
	<+amstan> nh2: hey
	00:20 <nh2> amstan: hey
	00:21
	<+amstan> depends what linux version your chromebook is running
	00:21 <nh2> amstan: that is what I want to find out; it says 3.8.11 in `uname -a`
	00:21
	<+amstan> 3.8 is what i was looking for
	00:22
	<+amstan> so this is where you want to look: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/chromeos-3.8
	00:22
	<+amstan> that's "master", essentially what's going to be in canary tomorrow
	00:23 <nh2> amstan: how do I find out which exact commit my Chromebook is running right now?
	00:23
	<+amstan> depends what chromeos version you're on
	00:23
	<+amstan> dev/beta/stable
	00:23
	<+amstan> but more importantly the number
	00:23
	<+amstan> probably one of R72, 73, 74
	00:24
	<+amstan> then you look in https://chromium.googlesource.com/chromiumos/third_party/kernel/+refs
	00:24
	<+amstan> for a branch labeled: "release-R$yournumber-*-chromeos-3.8"
	00:25
	<+amstan> but realistically... last commit in 3.8 "master" was oct
	00:25
	<+amstan> so there won't be a difference
	00:26
	<+amstan> since i think they all branched after that
	00:26 <nh2> amstan: is there no complete mapping of Chrome OS version to git commit (e.g. a direct lookup table)?
	00:27
	<+amstan> there is, those branches
	00:27 <nh2> but branches can change over time
	00:27 <nh2> e.g. I have 58.0.3028.140 in the "About" window
	00:27
	<+amstan> but your laptop's version could change too
	00:28
	<+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
	<+amstan> generally those branches don't change much after the branch point, it's more for bugfixes or stability things
	00:28
	<+amstan> think of it like a feature freeze
	00:29 <nh2> amstan: so there is no unambiguous way to find out precisely what code is running? That seems odd
	00:29
	<+amstan> anyway, if you have R58 (that's super old btw)
	00:29
	<+amstan> you're probably running https://chromium.googlesource.com/chromiumos/third_party/kernel/+/refs/heads/release-R58-9334.B-chromeos-3.8
	00:33
	<+amstan> anyway, so what's this bug you speak of
	00:33
	<+amstan> perhaps we could merge it in :)
	00:34 <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 <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 <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
	<+amstan> nh2: are you sure that's a cherry-pick? we usually label cherry-picks pretty well
	00:36
	<+amstan> and it would say that's been reviewed on gerrit, etc
	00:36
	<+amstan> i'm baffled
	00:37
	<+amstan> here we go: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/313465
	00:38
	<+amstan> I'm really not sure where 554086d85e71f30abe46fc014fea31929a7c6a8a and 8142b215501f8b291a108a202b3a053a265b03dd are
	00:38
	<+amstan> in our tree, like which branch
	00:38
	<+amstan> but the gerrit link i pasted looks like a real cherry-pick that landed in the 3.8 branch
	00:39 <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
	<+amstan> yeah, so you're talking about https://chromium.googlesource.com/chromiumos/third_party/kernel/+/554086d85e71f30abe46fc014fea31929a7c6a8a right?
	00:40
	<+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
	<+amstan> oh, i see
	00:41
	<+amstan> alright, so it's a matter of cherry-picking 8142b21 (the fix)
	00:42
	<+amstan> since the breakage 554086d8, landed in 3.8 as https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/313465
	00: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
	<+amstan> but in later kernels both 554086d8(breakage) 8142b21 (fix) landed
	00:42
	<+amstan> cool
	00:42 <nh2> yes
	00:43
	<+amstan> so.. assuming i send a cl, and it gets merged
	00:44
	<+amstan> will you even be able to run it?
	00:44
	<+amstan> if you have R58 i assume you're running an EOL device? do you still get updates?
	00:44 <nh2> amstan: I found it on an EOL device, trying to give it new life with crouton
	00:45
	<+amstan> the issue is that you'll never get the kernel update, even if i do fix it
	00:45
	<+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
	<+amstan> even if i merge the fix in that R58 branch, we don't have R58 builders anymore
	00:46 <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 <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
	<+amstan> this is an intel machine, right?
	00:49
	<+amstan> there's no seabios?
	00:49
	<+amstan> yeah... chrubuntu probably did seabios
	00:50
	<+amstan> with seabios you don't really need any more handholding, it's just like installing linux on a windows laptop
	00:50 → flyback joined (~flyback@2601:540:8201:c3ce::e162)
	00:51 <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
	<+amstan> weird, maybe i didn't know that chrubuntu does magic
	00:52
	<+amstan> so without seabios, there's still another way to boot other distros
	00:52
	<+amstan> it involves packaging the kernel into a partition
	00:52
	<+amstan> we do this a lot of arm systems
	00:53 <nh2> amstan: is there some docs for that somewhere that I could read?
	00:53
	<+amstan> here's how you can partition the drive: https://archlinuxarm.org/platforms/armv8/rockchip/asus-chromebook-flip-c101pa
	00:53
	<+amstan> some instructions on how to build the kpart: https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-gru/PKGBUILD#L97
	00:54
	<+amstan> but not sure how much of that second link is arm specific
	00:54
	<+amstan> those are for arch
	00:54
	<+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
	<+amstan> but it's a lot less readable
	00:54 <nh2> amstan: another thing I found quite odd is that the 500C runs i686 even though its processor is 64-bit
	00:55
	<+amstan> probably 32 bit userspace
	00:55
	<+amstan> the kernel's still 64 bit?
	00:55
	<+amstan> we do that on arm still
	00:55
	<+amstan> though i think we do 64 bit userspace on x86 now always
	00:55 <nh2> amstan: the i686 is in the `uname -a` output, and the bug I found applies only to 32-bit kernels
	00:56
	<+amstan> ah
	00:57
	<+amstan> well that does explain a lot then, why nobody else noticed
	00:57
	<+amstan> i don't think we do that often anymore
	00:58 <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
	<+amstan> no
	01:00
	<+amstan> in the arch instructions
	01:01
	<+amstan> you'll see the line: "crossystem dev_boot_usb=1 dev_boot_signed_only=0"
	01:01
	<+amstan> that enables you to press ctrl+U on the white bootloader screen
	01:01
	<+amstan> and it'll read a flash drive
	01:01
	<+amstan> but the catch is, the flashdrive needs to be formatted with chromeos partitions
	01:01
	<+amstan> so you already need the kpart magic that i talked about
	01:02
	<+amstan> the arch instructions essentially tell you how to make such a removable drive
	01:02
	<+amstan> is the chrubuntu repo still up somewhere?
	01:02
	<+amstan> you're probably best reviving some of those scripts
	01:02
	<+amstan> anything doing "cgpt ..."
	01:03
	<+amstan> nh2: you don't happen to be on this list? https://mrchromebox.tech/#devices
	01:03 <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
	<+amstan> you only need 2 partitions
	01:04
	<+amstan> there's a kernel type partition that the bootloader looks for
	01:04
	<+amstan> and the rootfs for it
	01:05
	<+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
	<+amstan> and a bunch of extra misc things that aren't important
	01:05 <nh2> amstan: unfortunately I'm not on that list, I have the XE500C21 and that list only has XE500C12
	01:14
	<+amstan> nh2: https://wiki.archlinux.org/index.php/Talk:Chrome_OS_devices#removed_old_content
	01:14
	<+amstan> looks like they removed it
	01:14
	<+amstan> because everyone relies on seabios i guess
	01:15 <nh2> amstan: oh, nice find
	01:15
	<+amstan> it might not go into the kpart packaging though
	01:15
	<+amstan> cgpt is useful even when you're not doing that, like just shuffling partitions around
	01:16 <nh2> amstan: I also shortly looked into putting Coreboot on
	01:16 <nh2> it but found only this: https://mail.coreboot.org/pipermail/flashrom/2016-October/014857.html
	01:16 <nh2> that didn't look too promising
	01:16
	<+amstan> oh!
	01:16
	<+amstan> well
	01:17
	<+amstan> i just realized it wouldn't work
	01:17
	<+amstan> but you could always take whatever's on your computer right now, keep using the same kernel, just replace the userspace
	01:17
	<+amstan> but that's not what you want
	01:17
	<+amstan> but eventually you could replace the kernel too, once you get familiar with the vbutil_kernel tool
	01:18
	<+amstan> pretty much just do https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-gru/PKGBUILD#L97
	01:19 <nh2> amstan: another question that might solve it: Can the Chromebook kernel kexec() other kernels?
	01:19
	<+amstan> i don't know, it's possible the config option is disabled
	01:20 <nh2> amstan: can I easily look at the kernel config I'm running on somehow?
	01:20
	<+amstan> modprobe configs, gcat /proc/config.gz or something like that
	01:24
	<+amstan> you know... you could try running an amd64-generic build of chromiumos
	01:24
	<+amstan> if it's packages the chromeos way it should boot
	01:25 <nh2> amstan: I get `# CONFIG_KEXEC is not set` when grepping for kexec in the /proc/config.gz
	01:25
	<+amstan> welp
	01:25 <nh2> amstan: where can I find the amd64-generic build?
	01:25
	<+amstan> there's not really any official binaries you can download
	01:27 <nh2> are there some instructions with which I could build it from a checkout?
	01:27
	<+amstan> https://chromium.googlesource.com/chromiumos/docs/+/master/developer_guide.md
	01:27 ⇐ eballetbo[m] quit (eballetbom@gateway/shell/matrix.org/x-nmntxgtssytilkty) Remote host closed the connection
	01:27 <nh2> ah I see, in the board selection
	01:28 ⇐ sielicki quit (sielickima@gateway/shell/matrix.org/x-rybhxtmdvadzozzz) Remote host closed the connection
	01:28
	<+amstan> with that, in theory you can patch the kernel the way you like it, build another R58
	01:28
	<+amstan> and just boot that
	01:28
	<+amstan> assuming the board wasn't deleted
	01:28
	<+amstan> but at the repo init step you can tell it to use the R58 branch
	01:28
	<+amstan> and you'll definatelly still have your board
	01:28 <nh2> right, as long as I'm able to enable kexec in the kernel config I should be good
	01:29
	<+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
	<+amstan> or kexec, heh
	01:34 <nh2> yes, both of these seem like ways forward
	01:34 <nh2> amstan: thanks a lot for your help!