yashsingh1/xdaforums huggingface dataset:
[Chromebooks] nabil2000:
Failure TBC

$ vbutil_kernel --verify blob67-test.img --verbose

Key block:

Signature: ignored

Size: 0x4b8

Flags: 7 !DEV DEV !REC

Data key algorithm: 4 RSA2048 SHA256

Data key version: 1

Data key sha1sum: d6170aa480136f1f29cf339a5ab1b960585fa444

Preamble:

Size: 0xfb48

Header version: 2.2

Kernel version: 1

Body load address: 0x100000

Body size: 0x7a9400

Bootloader address: 0x8a2000

Bootloader size: 0x4000

Body verification succeeded.

Config:

console= loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=PARTUUID=%U/PARTNROFF=1 rootwait ro dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=0 dm="1 vroot none ro 1,0 5087232 verity payload=ROOT_DEV hashtree=HASH_DEV hashstart=5087232 alg=sha1 root_hexdigest=7b45dc47af17d4869598148973256b221a1 33c2c salt=ecac7c3af20fb070704c00595a2a8350465d3dd84dd73 aa246de0dd17e82f1e2" noinitrd cros_debug vt.global_cursor_default=0 kern_guid=%U add_efi_memmap boot=local noresume noswap i915.modeset=1 tpm_tis.force=1 tpm_tis.interrupts=0 nmi_watchdog=panic,lapic

--------------

$ vbutil_kernel --verify blob67-sdb2.img --verbose

Key block:

Signature: ignored

Size: 0xcb8

Flags: 11 !DEV DEV REC

Data key algorithm: 11 RSA8192 SHA512

Data key version: 1

Data key sha1sum: e78ce746a037837155388a1096212ded04fb86eb

Preamble:

Size: 0xf348

Header version: 2.2

Kernel version: 1

Body load address: 0x100000

Body size: 0x71d400

Bootloader address: 0x816000

Bootloader size: 0x4000

Body verification succeeded.

Config:

console= loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=PARTUUID=%U/PARTNROFF=1 rootwait ro dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=0 dm="1 vroot none ro 1,0 5087232 verity payload=ROOT_DEV hashtree=HASH_DEV hashstart=5087232 alg=sha1 root_hexdigest=7b45dc47af17d4869598148973256b221a133c2c salt=ecac7c3af20fb070704c00595a2a8350465d3dd84dd73aa246de0dd17e82f1e2" noinitrd cros_debug vt.global_cursor_default=0 kern_guid=%U add_efi_memmap boot=local noresume noswap i915.modeset=1 tpm_tis.force=1 tpm_tis.interrupts=0 nmi_watchdog=panic,lapic

Something missing... using the formula then flashing the result boots to a blank screen,

blob67-sdb2.img original backup

blob67-test.img after flashing backup

Conclusion - I do not know what is missing, so case closed - I cannot use this method to make a kernel blob & / or make it bootable...

suggestions welcome...
[Chromebooks] lfom:
1. I am pretty sure this part:

is related to the kernel signature, so it is not possible to simply copy it from one file to another (unless they are identical, of course). What happens if you don't use this part? Maybe it generates the configuration automatically? Or maybe it's described somewhere else, I don't remember reading anything about this part...

2. You can also change the firmware of your C720P, if it's available. Then maybe you can use GRUB or boot a kernel without being signed.
[Chromebooks] nabil2000:
This was an integrity/consistency/sanity check

1. I was using the same vmlinuz which is the one of FydeOS 5.3.1 vmlinuz-4.13.67 - the signature should be the same...

the process of building the blob is not consistent, that's what I discovered. I still do not know how to extract the kernel from a blob (if there is a command for it)...

but using the image of /dev/sdb2 (blob67-sdb2.img which boots vmlinuz-4.14.67) to extract config,

then using the resulting blob (new_kern67.bin) with that config generating vmlinuz-4.14.67.bin

then flashing vmlinuz-4.14.67.bin to /dev/sdb2

does not result in a bootable /dev/sdb2 -

I then used the new flashed /dev/sdb2 to generate with dd blob67-test.img to compare to original blob67-sdb2.img & posted the two results

$ vbutil_kernel --verify blob67-sdb2.img --verbose

$ vbutil_kernel --verify blob67-test.img --verbose

It's just forensic work comparison...

I do not consider it time wasted, as I learnt more about the interaction about the three kernel parts (yes they say there are three)

2. I would prefer to keep the original firmware intact.

There is something hidden in this process, & worse a disabling feature when one tries to amend the blob.

As exhibit, if I try to reflash the original backed up /dev/sdb2 partition blob67-sdb2.img, the system stops booting altogether, it gets borked
[Chromebooks] lfom:
If it's really a integrity/signature check, then even simply changing the file name would case a problem as the resulting hash would be different. This part needs to be crated somehow, otherwise you cannot boot a new built kernel, only when you build the whole system... From what I have read, this should work on Chromebook devices as long as it's in dev mode, you have enabled USB boot and you are using an external disk.
[Chromebooks] nabil2000:
My C720P is in dev mode, & I have enabled USB boot and I'm using an external disk :)

It boots from the /dev/sdb2 of the external USB disk /dev/sdb as I have found out, they call it the kernel blob.

It is very sensitive to changing /dev/sdb2 - it only boots when it is the original from FydeOS kernel 4.14.67 (5.3.1)

So I concur - it has to be built from scratch as Chromium OS, it cannot be done separately, i.e. the blob is linked to the full build.

So I am back to when I said I need to build the whole Chromium OS from scratch like arnoldthebat & FydeOS do.

But! if the Chromium OS has disabled the ability to boot the blob for real Chromebooks, then there is nothing I can do -

both ATB v72 & FydeOS 6.0 use blobs (of kernel 4.14.83) that will not boot C720P, it is a Google devs implemented crippleware...

Only solution might be to use a firmware that will allow booting from software grub, not boot from /dev/sdb2.
[Chromebooks] nabil2000:
Comments, conjecture, crippleware - & goodbye.

I believe Google googledevs are closing pathways to use Chromebooks for non official updates...

that use of kernel blobs is rather recent, maybe from Chrome OS v72 in fact.

Some hacks are being closed down this way, making /dev/sdb3 protected, & forcing system firmware to boot from /dev/sdb2 only for Chromebooks...

I am not really interested in fascistic corporation taking an open system, & closing it to make a profit, so I will no longer look into this, this is EOL for me.

It was fun while is lasted, like the Hackintosh adventure...

PS.

Qualifier - I could be tempted to try firmware mods that make Acer CB C720P more like a normal laptop, that might be the answer to avoid crippleware blob booting.
[Chromebooks] lfom:
[MENTION=258618]nabil2000[/MENTION]

I am sorry that it didn't work, I found more info online about building a kernel for a Chromebook device that could be helpful:

https://plus.google.com/+OlofJohansson/posts/34PYU79eUqP

https://pomozok.wordpress.com/2014/10/11/building-chromeos-kernel-without-chroot/

https://www.peterdavehello.org/2015/04/build-chromium-os-from-source-notes/

I finally found a way to properly generate the config files for building a kernel based on a single config:

How to regenerate and validate splitconfigs from single config

cd /path/to/kernel
cp <single config> chromeos/config/<arch>/<flavour>.flavour.config
chromeos/scripts/kernelconfig oldconfig
chromeos/scripts/prepareconfig <flavour>
make ARCH=${ARCH} oldconfig
diff .config <single config>

http://dev.chromium.org/chromium-os/how-tos-and-troubleshooting/kernel-configuration

But there is one thing that I couldn't do yet and you may help: FydeOS builds don't have /proc/config.gz nor configs.ko module, so how could you get the config for FydeOS 5.31? I tried to use the same configs.ko from ATBv72 as it has the same kernel as FydeOS 6.0 but it seems that it generates the config for ATBv72 instead... If you could answer this it'd woudl be great.

Thanks for all the info so far!
[Chromebooks] nabil2000:
config.gz -

I answered this upstream ;) look out for the formula :)
[Chromebooks] lfom:
Above is what you said that you have used to get the config from FydeOS, the problem is that FydeOS does *not* have configs.ko (at least not v6.0) so how was it possible? Maybe you have done it from chroot and then it is actually the config of the chroot kernel? Or did you use a configs.ko module from another distro?

EDIT: I have just booted ATBv72 again, which has a configs.ko module, and the generated config is the same as base.config.fydeos you provided. So actually we don't have any config for a FydeOS kernel. :(
[Chromebooks] nabil2000:
The config's I extracted separately from chromefied ATB R72 & FydeOS 5.3.1 (R70) - they were different, with variations in modules settings.

Maybe FydeOS proper does not allow this .

As for my own challenge (booting Acer CB with R72)- I think I solved it,

I will put details in the Acer CB C720P thread -

https://xdaforums.com/showpost.php?p=79103843&postcount=176

but it is a cooking operation, not kernel building.
[Chromebooks] lfom:
Yep, I stand corrected. FydeOS v5.31 does have a configs.ko module, while v6.0 doesn't. As my last contribution to this thread, you can actually get the config from the kernel or the module files using a script from the kernel source tree (it is available online too), the only requirement is that the kernel was built with "CONFIG_IKCONFIG=y" (config.gz is not saved to /proc if the module exists, loading the module during runtime saves the file to /proc):

sudo ~/kernel/scripts/extract-ikconfig vmlinuz > new.config

or

sudo ~/kernel/scripts/extract-ikconfig configs.ko > new.config

Ref: https://superuser.com/questions/287371/obtain-kernel-config-from-currently-running-linux-system
[Chromebooks] nabil2000:
If ATB v72 has configs.ko, you can copy it over to FydeOS 6.0 as they have the same kernel 4.14.83
[Chromebooks] lfom:
Yes, I tried that... But it yields the config for ATBv72 and not FydeOS, as the module contains the config itself, it does not "extract" it from the current system, so it will result in the same config regardless of which system it was installed...

Thanks again for all the info! Regards
[Chromebooks] nabil2000:
I asked in Telegram for FydeOS to release their kernel source code, it fell on deaf ears.
[Chromebooks] nabil2000:
cyan blob used to boot Acer CB C720P on top of ATB R55

I noticed the config is also used in efi/boot/grub.cfg

so comparing with the one used in ATB R69 which is not booting Acer CB C720P

$ vbutil_kernel --verify kernel-blob-sdb2-cyan.img --verbose

Key block:

Signature: ignored

Size: 0xcb8

Flags: 11 !DEV DEV REC

Data key algorithm: 11 RSA8192 SHA512

Data key version: 1

Data key sha1sum: aaba460dce4d56c06819359450a447047767b0ab

Preamble:

Size: 0xf348

Header version: 2.2

Kernel version: 1

Body load address: 0x100000

Body size: 0x831600

Bootloader address: 0x92a000

Bootloader size: 0x4000

Vmlinuz header address: 0x92e000

Vmlinuz header size: 0x3600

Flags : 0x0

Body verification succeeded.

Config:

console= loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=PARTUUID=%U/PARTNROFF=1 rootwait ro dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=0 noinitrd panic=60 cros_recovery kern_b_hash=9b837f1693ee4734667d63a52b2e2899ffa811e2 vt.global_cursor_default=0 kern_guid=%U add_efi_memmap boot=local noresume noswap i915.modeset=1 tpm_tis.force=1 tpm_tis.interrupts=0 nmi_watchdog=panic,lapic iwlwifi.remove_when_gone=1 disablevmx=off

content of efi/boot/grub.cfg - (signed bit)

menuentry "verified image A" {

linux /syslinux/vmlinuz.A init=/sbin/init boot=local rootwait ro noresume noswap loglevel=7 noinitrd console=tty2 quiet dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=0 i915.modeset=1 cros_efi cros_debug root=/dev/dm-0 dm="1 vroot none ro 1,0 4096000 verity payload=ROOT_DEV hashtree=HASH_DEV hashstart=4096000 alg=sha1 root_hexdigest=8f9b4e702c43034115885f739a44b9d5b13af366 salt=36f7736717c1cb22e793cfc616ceaad7401a631383264d6844e06cbb1c97523e"

}

It could be that replacing the data from the config into this signed section of grub.cfg would solve the booting...

*** cannot be done, irrelevant ***

2 ways of booting

ctrl-L

ctrl-U

ctrl-U is the one to use for ATB R69 (does not boot C720P)

ctrl-L is the one to use for ATB R55 (works boots C720P)

though I have not figured out why the difference...

now exploring adding the boot folder in root / (for ATB v69)

adding the /boot folder in / did not work either

$ ls /boot

efi syslinux vmlinuz vmlinuz-3.18.0-18747-gdea8d908bd77

though it allows for last option usb booting in efi enabled non-chromebooks...

If I could make it boot using ctrl-L instead of ctrl-U maybe - still unable to find out how...
[Chromebooks] nabil2000:
fooling with firmware - mrchromebox

I knew of https://mrchromebox.tech/#fwscript -

but so far resisted using changing/flashing chromebook firmware -

Soon Acer Chromebook C720P (codename peppy) will no longer be covered by Google updates -

so soon will be the time to flash firmware to "transform" it into a normal PC -

at which if successful, no need for all the acrobatics to get it to boot...

I might start on this very soon...

- side note -

For Asus Chromebit CS10 Chromebook Stick using Arm - there is no control-L (no seabios for arm)

so for instance Arch Linux can be installed to USB, and uses control-U to boot...

no googledevs leaked the secret of the differential between ctrl-L & ctrl-U & the way to flip from one to the other...
[Chromebooks] nabil2000:
Acer Iconia W700 with cyan (or any of strago, Braswell)

Little new project before I fold -

using original kernel & ROOT-A partition (not chromefy) -

getting a stable graphics driver for Acer Iconia W700 using cyan (kernel 3.18) -

with auron paine (kernel 3.14) it 's perfect, but no crostini -

I will need to identify the .ko file needed, & most probably compile kernel 3.18 for this... any help welcome...

Ref. - https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices
[Chromebooks] nabil2000:
another kernel building to get graphics stability on Acer Iconia W700

All the releases like cyan for chromebooks using kernel 3.18 make the graphics of Acer Iconia W700 unstable.

The only way so far for me to stabilise graphics is to hook up the hybrid tablet to an external HDMI monitor, so not a portable solution.

What I like about Cyan & others such as relm, Celes, Terra, Ultima, Edgar, Buddy, Setzer, Wizpig, Banon... on base board strago with platform Braswell

is that they support Android crostini with kernel 3.18 - & Android can be rooted...

They work well with Macbook Air mid-2011 even the graphics, & BT, but no WiFi, though some WiFi realtek dongles are supported.

As I said Auron_Paine is good for Acer W700, but no crostini, as Google does not support crostini for kernels lower than 3.18, & its kernel is 3.14.

So here I am again attempting to get the missing kernel module for graphics used by Acer iconia W700 which is an Intel Core i3 i3-2375M machine with an HD 3000 Intel graphics processor.

I now finished cloning in the Chrome OS 3.18 kernel, & will soon build it after I single out the graphics driver module I need, but I will do a first test run using FydeOS 5.3.1 .config in the hope that they included the graphics driver as module.

cloning command:

$ git clone https://chromium.googlesource.com/chromiumos/third_party/kernel -b chromeos-3.18

Cloning into 'kernel'...

remote: Sending approximately 2.16 GiB ...

remote: Counting objects: 24677, done

remote: Finding sources: 100% (8/8)

remote: Total 7253650 (delta 5947953), reused 7253645 (delta 5947953)

Receiving objects: 100% (7253650/7253650), 2.16 GiB | 3.92 MiB/s, done.

Resolving deltas: 100% (5947953/5947953), done.

Checking out files: 100% (52018/52018), done.
[Chromebooks] nabil2000:
Brought to a halt because of inability to progress further

A few things about original Chrome OS method with vanilla ROOT-A partition & vmlinuz.A

1. Cannot modify ROOT-A & STATE partitions in size as protected.

2. not enough space in ROOT-A means no space for modules coupled with an updated kernel.

3. It is not just a matter of putting in .ko files separately generated building the kernel into the lib/modules/kernel-3.18-xxxx directory, as they won't load.

> 3. is a real downer & I am unable to find a way around it.

If one knows how to proceed from this I would really appreciate it - the following folder is where this is happening

$ ls p3/lib/modules

3.18.0-18747-gdea8d908bd77

When I compile and try to install modules it attempts to create in /lib/modules this directory

/lib/modules/3.18.0-19103-ge89049c9df69

I tried to remove 3.18.0-18747-gdea8d908bd77 & replace it with /lib/modules/3.18.0-19103-ge89049c9df69 after replacing vmlinuz.A by bzImage in p12/syslinux

still not enough space...

the two are linked & both two must be changed at the same time when updating kernel:

p3/syslinux/vmlinuz.A (replaced by compiled bzImage)

/lib/modules/3.18.xx-xx

it is not as easy as just putting in .ko modules drivers files in

/lib/modules/3.18.0-18747-gdea8d908bd77/kernel

$ ls /lib/modules/3.18.0-18747-gdea8d908bd77/kernel

arch crypto drivers fs kernel lib net sound

I think this sums up the analysis...

So only way around this is to actually build a Chromium OS from scratch, & so generate all the above files & folders in one synced go -

Google devs have made it this way, modifying tinkering trying to update the kernel on a genuine chromebook is not possible.

If I am wrong on this, I invite hackers/coders to correct me & offer a solution on how to inject new drivers in a vanilla Chrome OS.
[Chromebooks] lfom:
Did you run "depmod -a" after copying the new modules to the /lib/modules folder? If yes, and it didn't work, you can try to add the modules to the kernel itself (use module=y instead of module=m), or disabling the ones you know that your device doesn't use, maybe you will get enough space to replace the stock kernel modules folder...
[Chromebooks] nabil2000:
hacking chrome os kernel...

It does not boot with the new compiled kernel -

yes I tried what you suggested, & it is very time consuming...

also did sudo depmod -a of course...

I am trying another hacking trick, but I doubt it will work - rename kernel folder as what is expected from the new compiled bzImage, & replace relevant .ko files & others by ones built - I will generate the modules from a chromefied FydeOS 5.3.1 installation then use them over... maybe it will trick it into booting?
[Chromebooks] lfom:
I am not sure about what you plan to do, but I think that modules built for another kernel, even if the same version like 4.14.67 and 4.14.83 won't work... I am doing a lot of tests myself with the chromeos-4.14 and chromeos-4.19 that I built and unfortunately the 4.19 breaks ARC as well as crostini. But I could use my own built chromeos-4..14 with a chromefied installation using FydeOS 5.31, so there is hope (it is possible to use crouton instead of crostini, maybe it's even a better option).
[Chromebooks] nabil2000:
hacking Chrome OS kernel...

Maybe I did not express it well - I am not planning to use modules from 4.14.xx

I will just use a Chrome OS environment where space is not constrained to build the modules of 3.18.0-19103-ge89049c9df69

& I just did from Chromefied FydeOS 5.3.1

$ sudo make modules_install

arch/x86/Makefile:114: stack-protector enabled but compiler support broken

CHK include/config/kernel.release

INSTALL arch/x86/kernel/test_nx.ko

INSTALL crypto/af_alg.ko

INSTALL crypto/algif_hash.ko

INSTALL crypto/algif_skcipher.ko

...

INSTALL sound/usb/snd-usb-audio.ko

INSTALL sound/usb/snd-usbmidi-lib.ko

INSTALL /lib/firmware/e100/d101m_ucode.bin

INSTALL /lib/firmware/e100/d101s_ucode.bin

INSTALL /lib/firmware/e100/d102e_ucode.bin

INSTALL /lib/firmware/tigon/tg3.bin

INSTALL /lib/firmware/tigon/tg3_tso.bin

INSTALL /lib/firmware/tigon/tg3_tso5.bin

DEPMOD 3.18.0-19103-ge89049c9df69

so I got

ls /lib/modules

3.18.0-19103-ge89049c9df69 4.14.67
[Chromebooks] nabil2000:
observations via files sizes -

/lib/modules/3.18.0-18747-gdea8d908bd77

Original kernel modules folder size is 17 MB

/lib/modules/3.18.0-19103-ge89049c9df69

New compiled module folder size is 243 MB

No wonder it would not fit in the ROOT-A P3 partition.

I checked the .ko modules most are much bigger in the compiled 3.18.0-19103-ge89049c9df69

I don't know why that is...

In any event my trick of changing names & using bzImage did not work... It will not boot.

This is beyond me.
[Chromebooks] nabil2000:
just a quick note -

merging ATB v72 & FydeOS 6.0 modules works with no problems because the /lib/modules/4.14.83 is same for both releases - so you get the best of both :)
[Chromebooks] lfom:
Yes, if the kernel version is exactly the same (main.major.minor) and the compiler used is the same, it should work.

My problem is that I could get the battery/charger working only with kernel chromeos-4.19, but then it breaks ARC++ and Crostini. My bet is that the system libraries are not fully compatible the the newer kernel (not even FydeOS v6.0 with chromeos-4.19 works for ARC++, if I recall it correctly) so the container isn't started properly.

By the other hand, using my custom chromeos-4.14 works fine with ARC++, but then the standard Linux Terminal won't startup. I've found it is actually a common problem, even among Chromebook devices, and there is an easy workaround using crosh:

vsh termina
lxc exec penguin -- /bin/login -f [i]username[/i]

Where "username" is the login used minus "@gmail.com". The normal command to open the Linux term would be "vsh termina penguin", but it fails with an error message like "ERROR: vsh.cc(214) could not connect, service is not available". Maybe it helps you too.
[Chromebooks] nabil2000:
Yes, I had to deal with starting penguin manually at one stage...

I am very stubborn when it comes to trying to get something work, but what is defeating me is the lack of documentation, & clarity from Google devs.

With Linux distros proper, which are straight open source, problems get fixed eventually, no secrets ;) - but Google took an open source software & made part of it closed, sad.

Also making Chromium OS not booting Chromebooks since version 72 is mean from Google devs.

I am still resisting the urge to flash C720P firmware to make it into a normal PC, because I want to learn more about how to make Chrome OS kernel operate... but I will end up flashing just to see what it will do...

Anyways I must try & stop chasing unicorns, but it's just a hobby, like solving puzzles, lack of progress & shooting in the dark makes it frustrating though :) ;)
[Chromebooks] nabil2000:
more trials - testing

check

Upgrade Linux Kernel on Chromebook

https://blog.serverbooter.com/post/upgrade-linux-kernel-on-chromebook/

*dead end*