New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 691486 link

Starred by 1 user
Status: Fixed
Owner:
yllin@chromium.org
Closed: Feb 2017
Cc:
█ pihsun@chromium.org
hungte@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

factory: Support partx for partition manipulation.

Project Member Reported by yllin@chromium.org, Feb 13 2017 
Chrome Version: (copy from chrome://version)
OS: (e.g. Win7, OSX 10.9.5, etc...)

What steps will reproduce the problem?


What is the expected result?

What happens instead?

The usages of cgpt and parted is scattered in the source.
Let's try to give an integrated class for all the usages.

Comment 1 Deleted

Comment 2 by yllin@chromium.org, Feb 15 2017 

I already had some CLs in local, an interface to query partition info.
It basically a wrapper to cgpt or partx (depends on which util exists in the envronment)
After doing some manual tests, I found that partx cannot read the GPT of the file, which generated from the function "ConvertChromeOSImageToMiniOmahaFormat" in py/umpire/commands/update.py (Looks like partx cannot recognize the label, so does parted, and parted can print more information(start,size,...) then error at reading label name.)
So, should we still need to change these cgpt usages in this file?
If the cgpt exists in the system, then no problem.
If it doesn't, it will fail since the interface will try to use partx to read partition offset and size.

Comment 3 by hungte@chromium.org, Feb 15 2017 

> partx cannot read the GPT of the file, which generated from the function "ConvertChromeOSImageToMiniOmahaFormat"

I don't understand. ConvertChromeOSImageToMiniOmahaFormat does not use label (is it?)

And, partx recognizes label as NAME in my test (both block file and image files are fine).

Comment 4 by yllin@chromium.org, Feb 16 2017 

> I don't understand. ConvertChromeOSImageToMiniOmahaFormat does not use label (is it?)
 Yes, it doesn't.

I put the file (generated from update_unittest.py) in attached.

> the output of `cgpt show -i 4 tmp.file` (`-i 4` is the given partition index in the unit tests)

       start        size    part  contents                                  
         210          16       4  Label: "KERN-B"                           
                                  Type: ChromeOS kernel                     
                                  UUID: C4DCA93D-6DDB-804C-BA65-E13E250BB37A
                                  Attr: priority=0 tries=0 successful=0     

the output of `partx -r -g -n 4 -o SIZE -b tmp.file`

partx: /tmp/tmp.file: failed to read partition table

> the output of `parted -l tmp.file` (print error at the last)

Model: ATA MTFDDAK1T0MBF-1A (scsi)
Disk /dev/sda: 1024GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name                  Flags
 1      1049kB  2097kB  1049kB                                     bios_grub
 2      2097kB  258MB   256MB   fat32        EFI System Partition  boot
 3      258MB   770MB   512MB   ext2                               boot
 4      770MB   1024GB  1023GB


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/dhcp--100--102--7--168--vg-swap_1: 68.6GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system     Flags
 1      0.00B  68.6GB  68.6GB  linux-swap(v1)


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/dhcp--100--102--7--168--vg-usr+local+google: 871GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End    Size   File system  Flags
 1      0.00B  871GB  871GB  ext4

> the output of
Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/dhcp--100--102--7--168--vg-root: 60.0GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  60.0GB  60.0GB  ext4


Error: /dev/mapper/sda4_crypt: unrecognised disk label                    


> the output of `parted tmp.file print all` (give some warning that the file is corrupted.

Warning: /usr/local/google/home/yllin/projs/cros/internal_repo/chroot/tmp/tmp.file contains GPT signatures, indicating that it has a GPT table.  However, it does not have a valid fake msdos partition table, as it should.  Perhaps it was
corrupted -- possibly by a program that doesn't understand GPT partition tables.  Or perhaps you deleted the GPT table, and are now using an msdos partition table.  Is this a GPT partition table?
parted: invalid token: all
Yes/No? yes                                                               
Model:  (file)
Disk /usr/local/google/home/yllin/projs/cros/internal_repo/chroot/tmp/tmp.file: 149kB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name    Flags
 1      17.4kB  82.9kB  65.5kB               STATE   msftdata
 2      82.9kB  91.1kB  8192B                KERN-A
 3      91.1kB  108kB   16.4kB               ROOT-A
 4      108kB   116kB   8192B                KERN-B
 5      116kB   132kB   16.4kB               ROOT-B
tmp.file
145 KB Download

Comment 5 by hungte@chromium.org, Feb 16 2017 

> I put the file (generated from update_unittest.py) in attached.

So the problem is in unittest, not in the code itself.
We are ok to use cgpt in unittest (see the discussion in original CL)

> the output of `parted -l tmp.file` (print error at the last)

Wrong usage. -l indicates parted to read all block devices on your machine, not the given file.

> However, it does not have a valid fake msdos partition table, as it should.

Can be solved by adding "cgpt boot -p tmp.file" when creating the file.

> partx: /tmp/tmp.file: failed to read partition table

I can run partx on a standard chromiumos image (partx chromiumos_test_image.bin) so there's probably something else wrong - either we didn't create the file using CGPT in a way that partx is happy, or partx has some limitation. Comparing strace shows that partx is trying to read wrong sector (#31) and found \0*512, while on chromiumos image it happily tries first GPT table sector (#2=1024).

Maybe revise how we create the unittest file by following chromiumos disk image creation script, or trace partx C to find out what goes wrong.

Comment 6 by yllin@chromium.org, Feb 16 2017 

> So the problem is in unittest, not in the code itself.
> We are ok to use cgpt in unittest (see the discussion in original CL)

Ok, I see.

> Wrong usage. -l indicates parted to read all block devices on your machine, not the given file.

Thanks for your hint!



Another question:

py/gooftool/common.py:
There are many cgpt usages here, such as GetCgptAttributes,SetCgptAttributes, or modify partition flags, some of them can't be done with partx. So, should we replace these cgpt queries to the queries to the new interface, and leave the modification usage as it was?

Comment 7 by hungte@chromium.org, Feb 16 2017 

I think we don't need to change gooftool since it's very chromeos specific that cgpt should be available.

Let's focus on programs outside gooftool.

Comment 8 by yllin@chromium.org, Feb 17 2017

Components: Factory
Add Factory to Components

Comment 9 by yllin@chromium.org, Feb 17 2017

Status: Started (was: Untriaged)

Comment 10 by hungte@chromium.org, Feb 17 2017 

BTW, I've searched partx source. The GPT probing in partx has a restriction

 .minsz          = 1024 * 1440 + 1,      /* ignore floppies */

So you should change unit test to be larger than the size and then you can use partx on it.

Comment 13 by yllin@chromium.org, Feb 24 2017

Status: Fixed (was: Started)
►

Sign in to add a comment