resizing GPT on C201PA chromebook makes it unbootable

Hi,

I'm struggling with Kali on Asus C201PA chromebook, when installed and booted from an SD card (128GB). Essentially everything seems to be working fine, including wifi, but once I try to use all space on the SD card (add another partition), it gets unbootable :-(

Initially, the disk layout (of the SD card) looks like this:

Code:

root@kali:~# cgpt show -d /dev/mmcblk1 start size part contents 0 1 PMBR 1 1 Pri GPT header Sig: [EFI PART] Rev: 0x00010000 Size: 92 Header CRC: 0x6850405e My LBA: 1 Alternate LBA: 14335999 First LBA: 34 Last LBA: 14335966 Disk UUID: FDE085FB-90B4-1840-A7EE-5F7190417010 Entries LBA: 2 Number of entries: 128 Size of entry: 128 Entries CRC: 0x90fd8609 2 32 Pri GPT table 8192 32768 1 Label: "kernel" Type: ChromeOS kernel UUID: 47D2424D-92CD-8E46-906D-E7D1CD097AB2 Attr: priority=10 tries=5 successful=1 40960 14295007 2 Label: "Root" Type: Linux data UUID: 1C0BF3F9-081D-FA46-952B-88FA53349DE4 243269599 32 Sec GPT table 8192 32768 1 Label: "kernel" Type: ChromeOS kernel UUID: 47D2424D-92CD-8E46-906D-E7D1CD097AB2 Attr: priority=10 tries=5 successful=1 40960 14295007 2 Label: "Root" Type: Linux data UUID: 1C0BF3F9-081D-FA46-952B-88FA53349DE4 243269631 1 Sec GPT header Sig: [EFI PART] Rev: 0x00010000 Size: 92 Header CRC: 0x41551530 My LBA: 243269631 Alternate LBA: 1 First LBA: 34 Last LBA: 14335966 Disk UUID: FDE085FB-90B4-1840-A7EE-5F7190417010 Entries LBA: 243269599 Number of entries: 128 Size of entry: 128 Entries CRC: 0x90fd8609

I'm not a GPT expert, but following the various tutorials I do this:

Code:

root@kali:~# parted /dev/mmcblk1 GNU Parted 3.2 Using /dev/mmcblk1 Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Warning: Not all of the space available to /dev/mmcblk1 appears to be used, you can fix the GPT to use all of the space (an extra 228933632 blocks) or continue with the current setting? Fix/Ignore? Fix Model: SD SD128 (sd/mmc) Disk /dev/mmcblk1: 125GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 4194kB 21.0MB 16.8MB kernel 2 21.0MB 7340MB 7319MB ext4 Root msftdata (parted) q

At this point, the SD card is unbootable, i.e. if I try to reboot the chromebook, it will refuse to boot from it (using the Ctrl-U). The GPT looks like this:

Code:

root@kali:~# cgpt show -d /dev/mmcblk1 start size part contents 0 1 PMBR 1 1 Pri GPT header Sig: [EFI PART] Rev: 0x00010000 Size: 92 Header CRC: 0xc87dd7d7 My LBA: 1 Alternate LBA: 243269631 First LBA: 34 Last LBA: 243269598 Disk UUID: FDE085FB-90B4-1840-A7EE-5F7190417010 Entries LBA: 2 Number of entries: 128 Size of entry: 128 Entries CRC: 0xab1299a2 2 32 Pri GPT table 8192 32768 1 Label: "kernel" Type: ChromeOS kernel UUID: 47D2424D-92CD-8E46-906D-E7D1CD097AB2 Attr: priority=0 tries=0 successful=0 40960 14295007 2 Label: "Root" Type: Linux data UUID: 1C0BF3F9-081D-FA46-952B-88FA53349DE4 243269599 32 Sec GPT table 8192 32768 1 Label: "kernel" Type: ChromeOS kernel UUID: 47D2424D-92CD-8E46-906D-E7D1CD097AB2 Attr: priority=0 tries=0 successful=0 40960 14295007 2 Label: "Root" Type: Linux data UUID: 1C0BF3F9-081D-FA46-952B-88FA53349DE4 243269631 1 Sec GPT header Sig: [EFI PART] Rev: 0x00010000 Size: 92 Header CRC: 0xa6577a55 My LBA: 243269631 Alternate LBA: 1 First LBA: 34 Last LBA: 243269598 Disk UUID: FDE085FB-90B4-1840-A7EE-5F7190417010 Entries LBA: 243269599 Number of entries: 128 Size of entry: 128 Entries CRC: 0xab1299a2

I've tried to fix this using 'gpt repair' but that does not change a thing :-(

TomasV, have you had any luck solving your problem? I am having the same problem only with a 32GB SD card. I cannot re-size the root partition without screwing up the card so it will not boot. I would appreciate it if you can share any help if you've made progress.

stevo

Quote:

Originally Posted by Stevo898

TomasV, have you had any luck solving your problem? I am having the same problem only with a 32GB SD card. I cannot re-size the root partition without screwing up the card so it will not boot. I would appreciate it if you can share any help if you've made progress.
stevo

I got the answer! Actually I found the info somewhere in these forums a while back (maybe here). I have repeated this procedure a few times now with variously sized drives, so I pretty much know it off by heart. All you should need to do, after resizing the rootfs, is re-add the kernel's cgpt attributes for the Chromebook's BIOS to pick up, and then you should be good to go.

For example:

In the first part of the first post above, TomasV's kernel attributes initially look like this:

Code:

Attr: priority=10 tries=5 successful=1

Whereas, after resizing the disk layout, the attributes have been lost! They now look like this:

Code:

Attr: priority=0 tries=0 successful=0

So, to get the kernel booting again, we need to re-add these attributes.

We do this in cgpt, either in Chrome OS or in another Linux instance.

The magic incantation:

Code:

cgpt add -i 1 -S 1 -T 5 -P 10 -l kernel /dev/mmcblk1

That's it! Reboot, and cross your fingers.

Now Ctrl+U should boot straight into Kali, and the dreaded beep of fail should soon be a long-distant memory.

Some background info on the above command string:

'cgpt add' tells cgpt we are about to to modify (or add) a partition.
'-i 1' tells cgpt we are modifying partition number one.
'-S 1' tells cgpt to set the "successful" flag - indicating that this kernel has previously booted successfully. This can be either 0 or 1.
'-T 5' tells cgpt to set the "tries" flag - governing the number of times to try to boot the kernel before giving up. This can be from 0-15.
'-P 10' tells cgpt to set the kernel's boot priority. If it's set to 0 the kernel will never boot! This can be from 0-15.
'-l kernel' tells cgpt to set the label of the partition to "kernel". IIRC this isn't actually needed, but YMMV.
'/dev/mmcblk1' tells cgpt we are working on /dev/mmcblk1. Self explanatory.

Usually Chrome OS has (at least) two or three kernel/rootfs pairs between which it alternates in order to deliver seamless updates. This is apparently why the extended attributes are required.

NB: On a system with enough internal capacity, it is possible to keep two (or more) operating systems on the internal memory, and specify which one to reboot into by setting its priority the highest.

HTH!