ROOT-A Filesystem encrypted ?

[Ravishankar S]

Is the root-a ext2 file system encrypted ? I am not able to mount it to check its contents.

I have downloaded it from here:

https://storage.cloud.google.com/chromeos-image-archive/arm64-generic-full/R92-13931.0.0-rc1/index.html

file full_dev_part_ROOT.bin

full_dev_part_ROOT.bin: Linux rev 1.0 ext2 filesystem data, UUID=00000000-0000-0000-0000-000000000000, volume name "ROOT-A" (large files)

rreddy78@jetson-nano:~/Downloads$ sudo losetup /dev/loop1 full_dev_part_ROOT.bin

sudo mount -t ext2 /dev/loop1 roota

mount: /home/rreddy78/Downloads/roota: wrong fs type, bad option, bad superblock on /dev/loop1, missing codepage or helper program, or other error.

Even the kernel image seems encrypted 

full_dev_part_KERN.bin

rreddy78@jetson-nano:~/Downloads$ file full_dev_part_KERN.bin

full_dev_part_KERN.bin: data

Thanks and Regards

Ravishankar

[Mike Frysinger]

the rootfs isn't encrypted.  just mount it read-only.

the kernel isn't encrypted.  it's just in a format most tools don't recognize.

we don't encrypt any of these things as it doesn't make sense.

-mike

--
--
Chromium OS Discussion mailing list: chromium-...@chromium.org
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-os-discuss

[Ravishankar S]

I have copied the kernel to the STATE partition and have loaded it 

=> ls virtio 0:1

<DIR>       4096 .

<DIR>       4096 ..

<DIR>      16384 lost+found

<DIR>       4096 dev_image

<DIR>       4096 var_overlay

           65536 vmlinuz_hd.vblock

        67108864 Image

=> load virtio 0:1 0x40200000 Image 

67108864 bytes read in 46 ms (1.4 GiB/s)

=> booti 0x40200000

Bad Linux ARM64 Image magic!

So I am not able to load the kernel image also. The Image file is same as full_dev_part_KERN.bin 

Thanks and Regards

[Ravishankar S]

Thanks. Can you tell me to which address i have to load the kernel to ? I can try to create a uImage for the u-boot boot loader and try booting.

I am now able to boot u-boot in qemu and I am at the prompt

=> virtio part  

Partition Map for VirtIO device 0  --   Partition Type: EFI

Part Start LBA End LBA Name

Attributes

Type GUID

Partition GUID

  1 0x004ae000 0x00cae06c "STATE"

attrs: 0x0000000000000000

type: 0fc63daf-8483-4772-8e79-3d69d8477de4

guid: 1bb49ec2-2479-6540-b64f-882c7ab275c5

According to this post:

https://stackoverflow.com/questions/14800515/unknown-arm-linux-kernel-image-format

"ARM Linux kernels are usually self-loading plain binaries, generated from the original ELF by extracting the code+rdata sections from it and appending the "piggy" loader. They're loaded by the bootloader at some place in the memory and just run from there. The piggy loader unpacks/copies the main payload to the final address and jumps to it."

Hope it holds true in this case also.

Thanks and Regards

Ravishankar

On Wednesday, May 5, 2021 at 11:26:02 AM UTC+5:30 Mike Frysinger wrote:

[Simon Glass]

Hi Ravishankar,

On Wed, 5 May 2021 at 09:33, Ravishankar S <ravishan...@gmail.com> wrote:

Thanks. Can you tell me to which address i have to load the kernel to ? I can try to create a uImage for the u-boot boot loader and try booting.

I am now able to boot u-boot in qemu and I am at the prompt

Upstream U-Boot has a boot script (in chromebook_coral) which locates and boots the kernel. It might be easier to copy that.

Regards,

Simon

[Ravishankar S]

Thanks. I didnt find any script in the folders. But I located one in the docs

https://u-boot.readthedocs.io/en/latest/chromium/run_vboot.html

Under  the heading "U-Boot without Chromium OS verified boot". Hope this is the one you are referring to.  I am translating it for the current usecase.

This script looks like working though the kernel partition format (https://www.chromium.org/chromium-os/chromiumos-design-docs/disk-format) 

for booting as described in heading  "Kernel partition format". 

Would be helpful if I can get any hints on whether offsets are valid for the current usecase.

[Simon Glass]

Hi Ravishankar,

On Fri, 7 May 2021 at 00:06, Ravishankar S <ravishan...@gmail.com> wrote:
>
> Would request google to make the arm64 build vm bootable. Its certainly not possible for normal users like me.

I think vapier@ mentioned that this build is being turned down. Is that right?

Regards,
Simon

>
> Thanks

[Ravishankar S]

Would request google to make the arm64 build vm bootable. Its certainly not possible for normal users like me.

Thanks

On Thursday, May 6, 2021 at 9:34:54 PM UTC+5:30 Ravishankar S wrote:

[Simon Glass]

Hi Ravishankar,

OK, well I'm sorry but I don't know enough about this. Mike may weigh
in with his thoughts.

Regards,
Simon

On Fri, 7 May 2021 at 11:06, Ravishankar S <ravishan...@gmail.com> wrote:
>
> Hello Simon,
>
> No. Not exactly.
>
> You refer to this statement : "use the test image. we intend on deleting the qemu image since it's no longer relevant." ?
>
> For the amd64 build both qemu_image.bin and test_image.bin exist. For the arm64 build only test_image.bin exists.
>
> Mike meant that only test_image is relevant in future for both vm and test purposes if I understood correctly.
>
> Thanks and Regards,
> Ravishankar

[Ravishankar S]

Hello  Simon,

No. Not exactly.

You refer to this statement : "use the test image.  we intend on deleting the qemu image since it's no longer relevant." ?

For the amd64 build both qemu_image.bin and test_image.bin exist. For the arm64 build only test_image.bin exists.

Mike meant that only test_image is relevant in future for both vm and test purposes if I understood correctly.

Thanks and Regards,

Ravishankar