Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
IRC discussion on #chromium-os on picked kernel bug and how to put newer kernels on the Samsung 500C like ChrUbuntu
→ 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!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.