Arch Linux ARM does not boot from Internal Hard Drive / Internal Flash Memory - (veyron [RK3288] - Asus Flip C100PA "minnie", Asus c201 "speedy")

[mstn]

Hi! Thanks for this script.

I tested on my Asus Flip C100PA.

Install on SDCARD works.

Install on INTERNAL Memory works without errors, but, when I reboot and CTRL-D to start from disk, I get "Chrome OS is missing or damaged". OS verification is OFF. Booting from SDCARD still works.

It looks like OS verification is still ON. Hence it could be a problem related with this particular model more than with your script.

If I find how to solve it, I'll post here.

[altreact]

Interesting...
Sorry for the inconvenience.

Try this while you are running arch off of your sdcard:

wget https://raw.githubusercontent.com/altreact/archbk-utils/master/archbk-bu.sh && sudo sh archbk-bu.sh mmcblk0

Then reboot, and press Ctrl + D

Please let me know if that works for you

[mstn]

Thanks for your reply.

I had to install rsync by hand before running the script.

But I cannot boot with Ctrl + D.

I got this warning (EDIT: when I ran the script)

The backup GPT table is corrupt, but the primary appears OK, so that will be used.

[mstn]

I found this https://archlinuxarm.org/forum/viewtopic.php?f=44&t=11232

It looks like the same problem.

[mstn]

After some trials and errors, I found how to install arch on the internal memory. As far I understood (but I am not an expert!), partitions on the internal memory must be different from partitions on the sdcard. This should be the reason why the machine complains with "Chrome OS is missing or damaged" when it does not find the expected format.

1. Follow the instructions at this section of the installation process for Debian on C201. I read that C201 internal hardware is de facto the same as that of C100pa.
2. When you run vbutil_kernel you must replace vmlinuz.signed with vmlinux.kpart and
   kernel.keyblock and kernel_data_key.vbprivk with those for veyron (they can be found here).

If you do not run vbutil_kernel, the system will boot, but it will terminate with kernel panic. The logs says something like

mmcblk0p3 couldn't mount features incompatibilities

Meaning that the boot loader is using the wrong kernel flags (not sure, please correct me if I am wrong).

I have not tested it yet, but it boots and I can login.

[altreact]

Sorry for the late reply. Life showed up, and I've been busy being responsible and such.

Awesome detective work!

To be clear, you followed the instruction at
https://wiki.debian.org/InstallingDebianOn/Asus/C201#Installing_to_internal_memory_from_SD_card
and as a result, you were a me to boot arch Linux arm from internal flash?

[mstn]

Yes, I followed the instructions in that section. I changed only the name of the kernel and I used kernel.keyblock and kernel_data_key.vbprivk for veyron minnie that you can find at the link I provided.

I tested the new installation. Arch is booting from the internal memory. I was able to install i3wm with Xorg. I still have some problems, but I do not think they are related to the installation process. For example, sounds do not work and (randomly) the ui is sluggish.

[tacito95]

Hey, did you follow the exact commands in that Debian tutorial?
I'm trying to do it but I'm getting errors in the partition related commands.
For example, the first line
cgpt add -i 3 -s 32 /dev/mmcblk0
Returns:
WARNING: Primary GPT header is being ignored
Which commands did you use? Also, I'm doing these from the chromeOS shell, or I should do from the alarm in the SD slot?

[urjaman]

Firstly, yeah you should do this when running from the SD.

I figured out a way to do this relatively cleanly, so I'll explain a few notes:
primary gpt header being ignored seems to be harmless, though I would prefer it to be fixed, the backup one works then.

The default archlinuxarm kpart does work for booting from the eMMC, as long as the root partition is the next partition after the kernel partition (in the numbering order).
(this is the PARTNROFF=1 part of /proc/cmdline, the PARTUUID in there is filled in by the boot loader, so it will match the partition the kernel was loaded from).

So in reference to the InstallingDebianOn guide that was linked above, firstly it doesnt move ROOT-B out of the way so expanding the STATE partition wouldnt work as-written.
I ended up shrinking/moving out of the way ROOT-B and the STATE partitions (instead of ROOT-A and ROOT-B) and put ROOT-A where the guide would put STATE, then skipped modifying the kernel,
and just wrote /boot/vmlinux.kpart into /dev/mmcblk0p2 with dd.

And then did the priorities as he listed.

This is the fdisk printout of the partition table for this system:

Device           Start      End  Sectors  Size Type
/dev/mmcblk0p1  282656   282687       32   16K Microsoft basic data
/dev/mmcblk0p2   20480    53247    32768   16M ChromeOS kernel
/dev/mmcblk0p3  282688 30752767 30470080 14.5G ChromeOS root fs
/dev/mmcblk0p4   53248    86015    32768   16M ChromeOS kernel
/dev/mmcblk0p5  282624   282655       32   16K ChromeOS root fs
/dev/mmcblk0p6   16448    16448        1  512B ChromeOS kernel
/dev/mmcblk0p7   16449    16449        1  512B ChromeOS root fs
/dev/mmcblk0p8   86016   118783    32768   16M Microsoft basic data
/dev/mmcblk0p9   16450    16450        1  512B ChromeOS reserved
/dev/mmcblk0p10  16451    16451        1  512B ChromeOS reserved
/dev/mmcblk0p11     64    16447    16384    8M unknown
/dev/mmcblk0p12 249856   282623    32768   16M EFI System

[altreact]

Unfortunately, I will be swamped for at least the next three months with work, so I don't have time to thoroughly go through the Debian documentation, to collaborate with you guys, and to incorporate a solution anytime soon.

Pull requests and/or fork are welcomed and encouraged.

When my schedule clears up a bit, I can devote more time to this issue. For now, help me in helping you, by contributing solutions in the form of usable code.
Forks and pull requests are welcomed, and even encouraged.

[urjaman]

I'm not in a hurry to test this again, sorry, but I'll try to write an untested set of commands (that are simpler than the mess my bash history on the SD is, since i messed it up at first etc) that you can use as a basis to get the idea.

# unmount all partitions on mmcblk0*, if your system automounts things.
# shrink & move ROOT-B (mmcblk0p5)
cgpt add -i 5 -b 282624 -s 32 /dev/mmcblk0
# shrink & move STATE (mmcblk0p1)
cgpt add -i 1 -b 282656 -s 32 /dev/mmcblk0
# move & enlarge ROOT-A (mmcblk0p3)
cgpt add -i 3 -b 282688 -s 30470080 /dev/mmcblk0
# make a new filesystem on ROOT-A
mkfs -t ext4 /dev/mmcblk0p3
# make mountpoints
mkdir /tmp/{old,new}root
# mounts for a clean copy
mount --bind / /tmp/oldroot
mount /dev/mmcblk0p3 /tmp/newroot
# copy system and unmount target
cd /tmp/oldroot
cp -a * ../newroot
umount /tmp/newroot
# install kernel to KERN-A (mmcblk0p2)
dd if=/boot/vmlinux.kpart of=/dev/mmcblk0p2
# set mmcblk0p2 to the high priority and successful
cgpt add -i 2 -P 10 -S 1 /dev/mmcblk0
# set mmcblk0p4 to low priority so it is not used
cgpt add -i 4 -P 0 -S 0 /dev/mmcblk0

[tacito95]

I just followed your exact instructions, but did a powerwash on the chromeOS first, to make sure the partitions were defaulted. Worked flawlessly, thank you so much.
Everything works, except for audio, but that was still the case for the SD card install.
I'm using the xf86-video-fbturbo driver and my UI is working perfectly (I'm using MATE).

EDIT: Managed to get audio to work:

sudo pacman -S alsa-utils pulseaudio
alsamixer

Press F6 and select the rockchip sound card
Press 'm' to unmute the following:

‘Left Speaker Mixer Left DAC1 Switch’
‘Left Speaker Mixer Right DAC1 Switch’
‘Right Speaker Mixer Left DAC1 Switch’
‘Right Speaker Mixer Right DAC1 Switch’
‘Right Headphone Mixer Left DAC1 Switch’
‘Right Headphone Mixer Right DAC1 Switch’
‘Left Headphone Mixer Left DAC1 Switch’
‘Left Headphone Mixer Right DAC1 Switch’

[dt-rush]

I also had the same issue. I was disappointed to find out that the C100P tutorial linked around threads of people trying to get arch on their C201 is actually only for an arch-on-USB install, which sucks. This thread finally gave me an on-internal-disk install.

What I did:

I never ran arch-bu.sh, to be clear. I made a recovery medium first, and powerwashed my C201P (I'm not sure what P is for, maybe since I'm in Montreal and it has french keys on the keyboard? Anyway it seems the internals are identical).

I then created the USB using this repo's main method of running make-arch_drv.sh from within the crosh root shell. I then rebooted with the USB in and hit CTRL+U to boot from it. It booted fine and I logged into the root shell. I then connected to wifi using wifi-menu.

I had to run pacman -S cgpt, since cgpt wasn't already in the disk image.

Here's what my internal disk partition table looked like at boot of the USB system:

The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/mmcblk0: 14.7 GiB, 15762194432 bytes, 30785536 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 1964A4A9-ADFC-0C42-9377-025C358480C7

Device            Start      End  Sectors  Size Type
/dev/mmcblk0p1  8704000 30781439 22077440 10.5G Microsoft basic data
/dev/mmcblk0p2    20480    53247    32768   16M ChromeOS kernel
/dev/mmcblk0p3  4509696  8703999  4194304    2G ChromeOS root fs
/dev/mmcblk0p4    53248    86015    32768   16M ChromeOS kernel
/dev/mmcblk0p5   315392  4509695  4194304    2G ChromeOS root fs
/dev/mmcblk0p6    16448    16448        1  512B ChromeOS kernel
/dev/mmcblk0p7    16449    16449        1  512B ChromeOS root fs
/dev/mmcblk0p8    86016   118783    32768   16M Microsoft basic data
/dev/mmcblk0p9    16450    16450        1  512B ChromeOS reserved
/dev/mmcblk0p10   16451    16451        1  512B ChromeOS reserved
/dev/mmcblk0p11      64    16447    16384    8M unknown
/dev/mmcblk0p12  249856   315391    65536   32M EFI System

Partition table entries are not in disk order.

I then ran urjaman's commands slightly modified for the specifics of my partition table:

(let me just say that the fact that the partitions are not shown in the order they appear on disk made these steps slightly more annoying since I had to look at the start and end sectors to reason about what was sitting where, instead of just looking at them laid out in order by fdisk -l)

• I resized mmcblk0p1 (STATE), which was actually after mmcblk0p3 (ROOT-A) on my system, to the very end of its range, so it occupied 32 sectors basically at the end of the disk. This freed up a ton of space, around 10.5 GB, for mmcblk0p3 (ROOT-A) to grow into. (You could say I shrank it "to the right").

• I then resized mmcblk0p5 (ROOT-B), which was just before mmcblk0p3 (ROOT-A), so that it took up only 32 sectors, freeing up space "to the left" of mmcblk0p3 (ROOT-A).

• I finally set mmcblk0p3 to begin just after mmcblk0p5 and end just before the start of mmcblk0p1. I had to use a calculator to find out how many sectors this should be in the cgpt add command.

My partition table then looked as follows (output of fdisk -l /dev/mmcblk0):

The primary GPT table is corrupt, but the backup appears OK, so that will be used.
Disk /dev/mmcblk0: 14.7 GiB, 15762194432 bytes, 30785536 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A7ACB032-0B54-E54E-BF21-B5D16E1E59CC

Device             Start      End  Sectors  Size Type
/dev/mmcblk0p1  30781406 30781437       32   16K Microsoft basic data
/dev/mmcblk0p2     20480    53247    32768   16M ChromeOS kernel
/dev/mmcblk0p3    315424 30781405 30465982 14.5G ChromeOS root fs
/dev/mmcblk0p4     53248    86015    32768   16M ChromeOS kernel
/dev/mmcblk0p5    315392   315423       32   16K ChromeOS root fs
/dev/mmcblk0p6     16448    16448        1  512B ChromeOS kernel
/dev/mmcblk0p7     16449    16449        1  512B ChromeOS root fs
/dev/mmcblk0p8     86016   118783    32768   16M Microsoft basic data
/dev/mmcblk0p9     16450    16450        1  512B ChromeOS reserved
/dev/mmcblk0p10    16451    16451        1  512B ChromeOS reserved
/dev/mmcblk0p11       64    16447    16384    8M unknown
/dev/mmcblk0p12   249856   315391    65536   32M EFI System

Partition table entries are not in disk order.

I then ran the rest of their commands the same: formatted ROOT-A as ext4 using mkfs, mounted to the oldroot (the root of the USB live system) using --bind and ROOT-A, copied the contents of oldroot to newroot, unmounted newroot, and ran the dd command to overwrite the kernel partition. On boot, without the USB plugged in, everything went well.

Although I do still hear a beep, I know I could probably change this by restoring chromeOS and running a command to flash some flags into the firmware or something... I don't really feel like doing this all again. So I'll just live with pressing CTRL+D or just learn to love the beep.

I hope this thread helps someone else in future!

[dt-rush]

So, my initial install had issues running accelerated graphics and had no audio. Given that, I decided to powerwash.

1. Why I powerwashed

I read in the useful-if-not-arch-specific "Installing Debian on ASUS C201" that I would need some files from the Chrome OS install. I also read the hint in the "OpenGL ES" section that I'd need some libraries for accelerated graphics.

With the above in mind, I decided to powerwash again using my recovery medium, so I could grab the files.

2. What I did once I was back in Chrome OS

2.1. side note: disable beep on boot screen

When I booted in, I made sure to "enable debugging features", to get a root account and allow firmware writing. I wanted to disable the annoying beep on boot up. The instructions here worked fine.

2.2. grabbing libraries and conf files only found in Chrome OS

2.2.i.
I grabbed the contents of /usr/share/share/alsa/ucm/

2.2.ii.
I grabbed the following from /usr/lib/:

libmali*
libEGL*
libGLES*

... and I stored them onto the arch install USB so I can put them back into their system locations during install.

3. After I installed

(to install I followed my exact same steps as posted in my comment above)

After having got the base arch system installed (during which I copied the drivers / config files above into their proper places), there are a few things I did to configure basic quality of life:

3.1. install X and a graphics driver and allow normal users to run it startx

# pacman -S xorg xorg-xinit xf86-video-fbturbo
# echo "needs_root_rights = yes" > /etc/X11/Xwrapper.config

3.2. fixed no audio

I ran pacman -S alsa-utils alsa-lib pulseaudio. Then I followed the advice of the "Debian on ASUS C100P" page:

UCM profiles from Chromium OS are on a way to be included in Debian. In meantime copy /usr/share/alsa/ucm/ directory contents from Chromium OS. I enabled these UCM files by adding /usr/bin/alsaucm -c ROCKCHIP-I2S set _verb HiFi to /etc/rc.local.

To have sound with pulseaudio, add to /etc/pulse/default.pa the following line :

load-module module-alsa-sink device=sysdefault

I also followed the recommendation of this page and ran:

# amixer -c 0 sset 'Right Speaker Mixer Right DAC' unmute 
# amixer -c 0 sset 'Right Speaker Mixer Left DAC' unmute 
# sudo alsactl store

(if you read the link, you'll notice they had a typo in probably copy-pasting 'Right' two times, they didn't unmute the left DAC. My commands above are the correct ones.)

I have no idea which of the above was necessary and which was incidental, and I don't feel like testing.

I also have no idea how the internals of the audio system work on this machine, all I know is that once I did the above, and opened alsamixer to unmute the main 'Speaker' item, I could hear sweet music coming out of my speakers. Headphones work too. I would strongly advise anyone reading this to not mess around with any of the other settings as it seems quite possible to fry the speakers from the general rumours I've heard spoken in various threads.

---

I then went on to set up a normal user, give them sudo, import all my dot files and configs, install fonts, install a window manager (i3gaps ftw) and all that good stuff. But this isn't really relevant to the issue of just getting a basic arch system working on this machine.

[paulwratt]

When I booted in, I made sure to "enable debugging features", to get a root account and allow firmware writing. I wanted to disable the annoying beep on boot up. The instructions here worked fine.

There server at here still exists, but the site has changed, The page is available (with comments):
http://web.archive.org/web/20170711043202/https://johnlewis.ie/neutering-the-developer-mode-screen-on-your-chromebook/