yashsingh1/xdaforums huggingface dataset:
[Chromebooks] nabil2000:
Using FydeOS 5.3.1 - Chromium OS v70

FydeOS 5.3.1 has the kernel also stored in /boot as

vmlinuz vmlinuz-4.14.67

I replaced vmlinuz by vmlinuz-4.14.96-... (my build)

removed the /lib/modules/4.14.67 & replaced it by

/lib/modules/4.14.96-...

also in /dev/sdb12 syslinux/

replace vmlinuz.A by vmlinuz-4.14.96-... (bzImage of my build)...

this yielded FydeOS v70 with Kernel 4.14.96

& Linux beta is available in the menu, also Android 7.1.1

I have not yet flashed the kernel blob to /dev/sdb2

about first to test if it will boot on Acer CB C720P...

icing on the cake would be if chromefied to eve v71, it still boots...

There is not enough space in /dev/sdb3 which is 2.7 GB for modules of 4.14.96 - so I cannot keep it protected/signed - had to increase it.

Chromefied with eve 71 / swtpm.tar

yields 4.14.96 kernel without crositini, but with Android 7.1.1 on non Chromebooks.

yields 4.14.67 kernel on Acer Chromebook C720P, with crostini, because kernel is hardwired on /dev/sdb2 - not /boot or /dev/sdb12 -

camera works on both

using chromebrew for extra Linux commands (replaces crostini smh)

now will retry again to flash kernel to /dev/sdb2 amending slightly the script used upstream... probably useless, as I have not figured out how Chrome OS synchronises the uses of the three kernels it uses

/boot

/syslinux vmlinuz.A in /dev/sdb12

blob /dev/sdb2

It seems to corrupt when the blob is flashed the wrong way, & cannot recover even if a backup image of /dev/sdb2 is restored... leading to an unbootable system even on non chromebooks...

I am sure [MENTION=2546018]googledevs[/MENTION] will not spill the beans on this with Google NDA's (security & all that BS).
[Chromebooks] nabil2000:
flashing /dev/sdb2 blob - 2nd attempt

To flash the /dev/sdb2 blob, I will do it from the Chrome OS chroot I built in another thread, this gives me access to more resources -

https://xdaforums.com/hardware-hacking/chromebooks/chromium-os-building-t3900245

using

$ vbutil_kernel --pack new_kern.bin \

--keyblock /usr/share/vboot/devkeys/kernel.keyblock \

--signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \

--version 1 \

--config config.txt \

--bootloader /lib64/bootstub/bootstub.efi \

--vmlinuz vmlinuz-4.14.96-09859-ga5c3f2f0428a

I assume config.txt is in fact .config

Let's see if this works finally?

Result -

(cr) bgrau@bgrau-MN9 ~ $ vbutil_kernel --pack new_kern.bin \

> --keyblock /usr/share/vboot/devkeys/kernel.keyblock \

> --signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \

> --version 1 \

> --config config.txt \

> --bootloader /lib64/bootstub/bootstub.efi \

> --vmlinuz vmlinuz-4.14.96-09859-ga5c3f2f0428a

Config file config.txt is too large (>= 4096 bytes)

ERROR: Error reading config file.

So, config.txt is not .config, & has to be smaller than 4K bytes...

any idea what config.txt is or contains? any kernel signing expert RFC?

testing with dummy.txt

echo blah > dummy.txt

$ vbutil_kernel --pack new_kern.bin \

--keyblock /usr/share/vboot/devkeys/kernel.keyblock \

--signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \

--version 1 \

--config dummy.txt \

--bootloader /lib64/bootstub/bootstub.efi \

--vmlinuz vmlinuz-4.14.96-09859-ga5c3f2f0428a

got new_kern.bin

$ vbutil_kernel --verify new_kern.bin --verbose

(cr) bgrau@bgrau-MN9 ~ $ vbutil_kernel --verify new_kern.bin --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: 0x6d0e00

Bootloader address: 0x7c9000

Bootloader size: 0x4000

Vmlinuz header address: 0x7cd000

Vmlinuz header size: 0x3e00

Flags : 0x0

Body verification succeeded.

Config:

blah

I am concerned that config.txt is important, but I have no idea how to generate it.

Did not work on Acer CB C720P - flashing the blob makes boot to blank screen, like ATB v72 & FydeOS 6.0

more analysis & cooking in next post...
[Chromebooks] nabil2000:
More cooking...

I think the config.txt for generating & signing the blob is created by just this command:

$ echo "console=tty1 debug root=/dev/sdb3 rw rootwait" > config.txt

or

$ echo "console=tty1 debug root=/dev/sda3 rw rootwait" > config.txt

info hacked from Google+

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

sadly G+ is closing - so copied the whole post for reference.

will try later...

an interesting hybrid I cooked is

1. using FydeOS 5.3.1

2. chromefy with eve 71 / swtpm.tar

3. replace FydeOS 5.3.1 kernel which is 4.14.67 by FydeOS 6.0 4.14.83 (adding modules in /lib/modules & replacing vmlinuz.A, & vmlinuz, adding vmlinuz-4.14.83 in /boot

this gives Android 7.1.1, camera, but no crostini - also surprisingly camera in MacBook Air...

I also flashed the /dev/sdb2 of FydeOS 6.0 (4.14.83) onto /dev/sdb2 of FydeOS 5.3.1 - that borks booting in Acer CB C720P -

current conclusion - Only up to & including kernel 4.14.67 can Acer CB C720P boot successfully, & provided it's the original FydeOS 5.3 / 5.3.1 blob,

with that one gets crostini, camera, Android 7.1.1

It seems Google has closed the door for Acer CB C720P through the blob above 4.14.67 - I have no idea how they did it, but it ain't booting, unless the blob is 4.14.67 not higher.

same can be done with kernel 4.14.96... but no crostini for both - for crostini in FydeOS 5.3.1 only 4.14.67 works/
[Chromebooks] nabil2000:
Using Kernel 4.14.67 (FydeOS 5.3.1) for sanity check blob flashing.

If the method I used to flash the blob is consistent, flashing FydeOS 5.3.1 Chromium OS v70 blob on itself will produce the same result, i.e. it will boot,

I will apply the flashing on it & see if this is true...

from Chromium OS building environment chroot apply:

$ vbutil_kernel --pack new_kern67.bin \

--keyblock /usr/share/vboot/devkeys/kernel.keyblock \

--signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \

--version 1 \

--config config.txt \

--bootloader /lib64/bootstub/bootstub.efi \

--vmlinuz vmlinuz-4.14.67

then flash it

$ sudo dd if=new_kern67.bin of=/dev/sdb2

check if it boots - after changing all instances to 4.14.67 in the correct places /dev/sdb12 syslinux/vmlinuz.A, & /boot/vmlinuz /boot/vmlinuz-4.14.67 -

probably will need to rerun

bash chromefy.sh /dev/sdb3 eve71 swtpm.tar (or caroline 71)

probably final note on this -

I think I'm giving up on trying to get a higher kernel than 4.14.67 (FydeOS 5.3.1) for Acer Chromebook C720P -

could not figure out how to get the kernel blob working,

even when I flash a built up blob of vmlinuz-4.14.67 using official instructions, it does not boot -

only dd'ing back the FydeOS /dev/sdb2 will it repair it -

there is an ingredient missing to successfully produce a working blob, but no docs available showing how...

so for me Acer Chromebook C720P is end of line at kernel 4.14.67 -

Google have crippled ability to successfully flash higher kernel blobs.

This makes efforts to build Chromium OS with latest kernels (4.14.83 & above) for Acer Chromebook C720P probably useless due to Google devs crippleware...
[Chromebooks] lfom:
I think the problem is the "config.txt", it seems that it is actually the command line used for the kernel to boot, similarly as the kernel line used in GRUB.

http://www.chromium.org/chromium-os/chromiumos-design-docs/disk-format#TOC-Quick-development

You may want to check the specific config.txt used for your device (peppy?):

I have an idea about how to verify this:

1. Get the kernel from KERNEL-A:

sudo dd if=/dev/sdb2 of=fydeos531.bin

2. Extract the command (config.txt):

vbutil_kernel --verify fydeos531.bin --verbose | \
tail -1 > fydeos531.cmdline

3. Get the stock configuration/info to compare later:

vbutil_kernel --verify fydeos531.bin --verbose

4. Now use vmlinuz.A from FydeOS 5.31 and the above command line and check if you get the same result:

vbutil_kernel --pack new_kern.bin \
--keyblock /usr/share/vboot/devkeys/kernel.keyblock \
--signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
--version 1 \
--config fydeos531.cmdline \
--bootloader /lib64/bootstub/bootstub.efi \
--vmlinuz vmlinuz.A

vbutil_kernel --verify new_kern.bin --verbose

If you get the exact same result, you should be able to flash new_kern.bin back to /dev/sdb2 and boot. But it seems you also forgot to do this first:

scp USER@SOMEWHERE:new_kern.bin /tmp
sudo dd if=/tmp/new_kern.bin of=/dev/sdb2

If it doesn't work, then you may want to simply repack the other kernels using fydeos531.cmdline and see if they boo:

vbutil_kernel --repack new_kern.bin \
--config fydeos531.cmdline \
--signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
--oldblob old_kern.bin

sudo dd if=new_kern.bin of=/dev/sdb2

If nothing works, then probably the keys are unique to each chroot/machine, and it won't work unless you build everything.
[Chromebooks] nabil2000:
command misunderstood...

scp USER@SOMEWHERE:new_kern.bin /tmp

sudo dd if=/tmp/new_kern.bin of=/dev/sdb2

I have no idea what to replace USER@SOMEWHERE: by - is this my Chromium OS google account I submitted as dev?

I did flash the resulting new_kern.bin to /dev/sdb2 - it makes it unusable on Acer C720P... I need to reflash the backup I made, which then makes the system repair itself...

As I am doing this on a scratch USB, I will try again & report, but first how do I use USER@SOMEWHERE:?
[Chromebooks] lfom:
Scratch that, scp is only needed if you built the kernel using another machine and you would then use scp to copy the file over ssh, my bad.
[Chromebooks] nabil2000:
Also why does the /dev/sdb2 of FydeOS 5.3.1 (4.14.67) works - but not the one of FydeOS 6.0 or ATB v72 which both are 4.14.83?

when I flash /dev/sdb2 with new_kern67.bin, it refuses to boot?...

there is something missing in building the blob, maybe getting the correct config.txt is the solution for Acer CB C720P - yet it worked for FydeOS 5.3.1 & ATB v69 without any intervention i.e. OTB.

My understanding of kernel blob is non existent.
[Chromebooks] lfom:
My bet is that 4.14.83 changed something that would make it not boot on C720P, either via GRUB or sda2. That's why I think you should first make sure you know how to use a known working vmlinuz, then try to build a newer kernel using the same CONFIG as. 67.
[Chromebooks] nabil2000:
I will try next - but I cannot build a lower kernel than 4.14.96 - using the config of FydeOS 5.3.1 is just a matter of extracting it from a running instance which I have.

As for vmlinuz, the issue is producing a working new_kern blob that when flashed boots Acer C720P, so far unsuccessful.

Of course, I can flash /dev/sdb2 from FydeOS 5.3.1 to FydeOS 6.0 & copying kernel 4.14.67 modules - & get a bootable result of Chromium OS v72 - but it leads to losing crostini, & having to settle with Android 7.1.1

this effort is about trying to get Android Pie 9 on Acer CB C720P...

RFC - Android Pie (9) can run with Kernel 3.18 in Android devices - so I don't get why it cannot run with kernel 4.14.67 from FydeOS? is that to do with handling virtual machines containers...

In the mean time, as best of both worlds, I can get this:

FydeOS 6.0 as base (Chromium OS v72)

in /dev/sdb3 /boot vmlinuz (4.14.67 from FydeOS 5.3.1)

in /dev/sdb12 sylinux/vmlinuz.A (4.14.83 from FydeOS 6.0)

flash /dev/sdb2 from Fydeos 5.3.1

chromefy with eve 71 / caroline 71

This gives a bootable USB with Kernel 4.14.67 & Android 7.1.1 & camera for Acer Chromebook C720P...

To make it work on another device like Acer Iconia W700 or Macbook Air mid 2011

I then need to

chromefy with eve 71 / swtpm.tar

This gives a bootable USB with Kernel 4.14.83 & Android 7.1.1 & camera for non Chromebooks as above...

(I leave /dev/sdb2 flashed as above from FydeOS 5.3.1)

/dev/sdb2 is not used in non Chromebooks.

Side note -

crostini works with both Kernel 4.14.83 & 4.14.67 - though it takes much longer to load the first time with 4.14.67 -

but

uname -a

in crostini penguin says kernel is 4.14.74 -

Linux penguin 4.14.74-07776-gac52e5f750c8 #1 SMP PREEMPT Thu Dec 6 17:36:39 PST 2018 x86_64 GNU/Linux

but it is possible to have a different kernel version in a virtual machine.
[Chromebooks] lfom:
1. If you just want to get Pie on C720P, did you try using nocturne recovery instead of eve? AFAIK only FydeOS 6.0 and nocturne have Pie in ARC.

2. Why you use swtpm.tar with the other devices instead of caroline recovery? Any special reason for that?

3. The crucial step needed is being able to get a vmlinuz and make it work when flashed to your /sdb2. So what are the results of a. and b. bellow, being vmlinuz.A the 4.14.67 vmlinuz?

a.

sudo dd if=/dev/sdb2 of=fydeos531.bin
vbutil_kernel --verify fydeos531.bin --verbose

b.

vbutil_kernel --verify fydeos531.bin --verbose | \
tail -1 > fydeos531.cmdline

vbutil_kernel --pack new_kern.bin \
--keyblock /usr/share/vboot/devkeys/kernel.keyblock \
--signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \
--version 1 \
--config fydeos531.cmdline \
--bootloader /lib64/bootstub/bootstub.efi \
--vmlinuz vmlinuz.A

vbutil_kernel --verify new_kern.bin --verbose

---------- Post added at 14:44 ---------- Previous post was at 14:41 ----------

Yes, AFAIK both ARC and crostini are virtual machines, much like Virtualbox devices, that's why you need a processor that support VT-x and a newer kernel.
[Chromebooks] nabil2000:
I'll try these things later, as I have to prep the usb for them - I am happy to keep the hybrid set up I described for Acer C720P for now - Pie is not a priority to me, Nougat is fine...

the dev version of Eve 73 has been leaked, & it supports Android Pie as well...

I can get Pie on non chromebooks with it or Nocturne - but Acer C720P with kernel 4.14.67 cannot allow Pie to run - & it cannot boot with kernel 4.14.83 -

I have a long experience in Virtual Machines since 2000 ;) qemu, connectix, vmware...
[Chromebooks] nabil2000:
blob works trials...

I think it will be more fruitful to start with the original blob of Acer Chromebook C720P to get config.txt - so I am logging this in

$ sudo dd if=/dev/sda2 of=C720P-sda2-blob.img

$ vbutil_kernel --verify C720P-sda2-blob.img --verbose

& the result is:

Key block:

Signature: ignored

Size: 0x4b8

Flags: 7 !DEV DEV !REC

Data key algorithm: 4 RSA2048 SHA256

Data key version: 3

Data key sha1sum: ef6c37d745bb9da235efc7bc8fae28ad8f0db574

Preamble:

Size: 0xfb48

Header version: 2.2

Kernel version: 1

Body load address: 0x100000

Body size: 0x454400

Bootloader address: 0x54d000

Bootloader size: 0x4000

Vmlinuz header address: 0x551000

Vmlinuz header size: 0x3400

Flags : 0x0

Body verification succeeded.

Config:

console= loglevel=7 init=/sbin/init cros_secure root=/dev/dm-0 rootwait ro dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=1 dm="1 vroot none ro 1,0 2539520 verity payload=PARTUUID=%U/PARTNROFF=1 hashtree=PARTUUID=%U/PARTNROFF=1 hashstart=2539520 alg=sha1 root_hexdigest=079b65ad8962c15cc20a962fe253d678e27485e0 salt=48257cf2686fef8d85c30df16d4c735bd7ba74da8fd7bcd8f15dcd1c78c8c7d3" noinitrd 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 iTCO_vendor_support.vendorsupport=3

The config needs to be adapted to the UUID's of the USB stick with the target Chrome OS - for me the chromefied FydeOS 6.0 or chromefied ATB v72...

I will need to do some check & match with the original C720P SSD - same topology as target USB...

or maybe not...
[Chromebooks] lfom:
I think it is much more complicated because it enables the signatures check as well. If you can boot a Chromioum build, then it will be much easier, you also have access to the vmlinuz files, not to mention that if it works then you will be able to apply the same procedures in future builds.
[Chromebooks] nabil2000:
which blob config to use or how to use to boot Acer CB C720P?

Now that I have gathered all these config's which one to use to build a successful /dev/sdb2 blob to boot the Chromium OS releases not booting Acer C720P (from USB) -

Crudely & bluntly, I am tempted to use this one, as it has a usb clone of Acer C720P -

$ vbutil_kernel --verify C720P-usb-sdb2-blob.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: 0x3e7400

Bootloader address: 0x4e0000

Bootloader size: 0x4000

Vmlinuz header address: 0x4e4000

Vmlinuz header size: 0x3400

Flags : 0x0

Body verification succeeded.

Config:

console= loglevel=7 init=/sbin/init cros_secure oops=panic panic=-1 root=PARTUUID=%U/PARTNROFF=1 rootwait rw dm_verity.error_behavior=3 dm_verity.max_bios=-1 dm_verity.dev_wait=0 dm="1 vroot none ro 1,0 2506752 verity payload=ROOT_DEV hashtree=HASH_DEV hashstart=2506752 alg=sha1 root_hexdigest=bb988a39ae3c27f2c432d36c6a454f6adcc b9942 salt=c7d8352a11635f8174b95160d9c0b0b9fb7dd6048b3de 0c42e6e1025819bf256" noinitrd 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 iTCO_vendor_support.vendorsupport=3

but I strongly doubt it will be that simple...

before that I need to find out that the formula to build a blob image is consistent by trying it out with same config for a given blob - I will try this with a FydeOS 5.3.1 test usb.

this one:

$ vbutil_kernel --verify blob67-fydeos-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

Vmlinuz header address: 0x81a000

Vmlinuz header size: 0x3400

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 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

using

vmlinuz-4.14.67 of FydeOS 5.3.1 & the config of blob67-fydeos-sdb2.img,

& from resulting newkern-vmlinuz-4.14.67 flash it on /dev/sdb2 & see if it boots Acer CB C720P...

if it does - that means the method to make the blob is consistent, otherwise... :( forget it...
[Chromebooks] lfom:
But you said:

You know what blobs boot your C720P, my suggestion is that now you try to build your own blob using the respective vmlinuz kernel. Once you get it working, build a newer kernel with the exact same CONFIG as the one that works, then create the blob the way you know it works and test. This way you will able to update the kernel to a newer version. Wasn't it the main purpose of the thread?
[Chromebooks] nabil2000:
Data for blobs config's that solve booting Acer CB C720P

The purpose of the thread was Acer CB C720P booting to a blank screen - I got steered to blobs when i realised that original chromebooks boot using /dev/sda2 or for usb /dev/sdb2...

there are a few significant entries that change from blob to blob - & finding out how to generate these entries I still have no clue how it is done...

also the size of /dev/sdb2 is 16MB in most cases, but ATB v72 increased it to 64MB - it does not matter as we flash a partitioned image derived from the kernels which uses config for settings...

So this is the formulae we worked out so far -

vbutil_kernel --pack new_kern67.bin \

--keyblock /usr/share/vboot/devkeys/kernel.keyblock \

--signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \

--version 1 \

--config config.txt \

--bootloader /lib64/bootstub/bootstub.efi \

--vmlinuz vmlinuz-4.14.67

vbutil_kernel --pack new_kern83.bin \

--keyblock /usr/share/vboot/devkeys/kernel.keyblock \

--signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \

--version 1 \

--config config.txt \

--bootloader /lib64/bootstub/bootstub.efi \

--vmlinuz vmlinuz-4.14.83

I need to find out how to put the correct data in config.txt based on comparing the separate config's collected so far.

So the challenge is to generate these data.
[Chromebooks] nabil2000:
Blob test run for consistency on FydeOS 5.3.1

Blob test run for consistency on FydeOS 5.3.1 Chromium OS v70 -

I will use the chroot Chromium OS environment built in the instructions I gathered in this thread -

https://xdaforums.com/hardware-hacking/chromebooks/chromium-os-building-t3900245

the Chromium OS chroot requires a lot of memory resources, I can't run if productively from within Acer CB C720P (only 2GB memory)

so will run it from the best I got - Acer Iconia hybrid tablet (4GB memory).

The command issued will be - with the labelling I used -

vbutil_kernel --pack new_kern67.bin \

--keyblock /usr/share/vboot/devkeys/kernel.keyblock \

--signprivate /usr/share/vboot/devkeys/kernel_data_key.vbprivk \

--version 1 \

--config config.txt \

--bootloader /lib64/bootstub/bootstub.efi \

--vmlinuz vmlinuz-4.14.67

config.txt will contain this data _only_:

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

then sudo dd if=new_kern67.bin of=/dev/sdb2

reboot /dev/sdb usb & see if it boots OK - if it does not, no point carrying on as the method will not work.