nh2 · April 13, 2019 21:28
diff --git a/chromebook-samsung-linux-boot-discussion.txt b/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!