Build using x32-generic (for non PAE platform) looking for stubs-64.h?

[D K]

Not sure if I make my first post (https://groups.google.com/a/chromium.org/d/topic/chromium-discuss/hoFe3tdqhrE/discussion) in the right group... I posted some background info there...

Looking for help to make a non PAE version of Chromium OS...

I have tried a few more things since my last post, but none seems to work. I think I have found __LP64__ was defined in ~/trunk/src/third_party/kernel/3.14/arch/ia64/Makefile Tried to remove that still no go. (also tried to make a sym link for stubs-64.h doesn't work either)

Any help would be appreciated...

Or please let me know the last version (currently: chromeos-chrome-38.0.2114.2_rc-r1) that works with non PAE (using BOARD=x32-generic). Thanks in advance

[Mike Frysinger]

it depends.  your summary is that you want to build for a non-PAE platform which i guess means you want to build for an old 32bit system ?  that is not what x32-generic is ... that target requires a 64bit kernel.  in which case you should be posting to this list, not Chromium.

short answer is what you've already found: you need to build for x86-generic, and then you need to disable PAE in the kernel config and rebuild the kernel.

had you actually wanted to build for x32, then chromium-discuss would be the place for it.  i've got CrOS building for x32, but Chromium itself doesn't work (runs into the errors you reported).

-mike

--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[D K]

Hi Mike

   You are right, I am trying to have it running on some older CPUs (like Pentium M) and I didn't know even x32-generic requires a 64bit kernel. hummm.

   So I should go back to x86-generic and try to figure out (or fix?) how to disable PAE?

   And any way to move a posting over to chromium-discuss? (BTW, I recall seeing a x86-embedded target, wonder what that is...)

   Thx.

[Mike Frysinger]

you want the x86-generic board. no other target is appropriate for what you want to do.
-mike

[D K]

OK... Would you happens to know what's the last version that actually works w/o PAE support? I have been trying to look for that info for sometime now... (and also need to figure out how to check out a specific version to compile, as well as how to generate a git tree using gitg...)

Thanks.

[Mike Frysinger]

afaik, PAE is merely a kernel option.  just disable it.

-mike

[D K]

Hummm. As I said I do notice Linux kernel 3.14 does support PAE disable.

But as I try to compile, it is chromeos-chrome-38.0.2114.2_rc-r1 causing me grief, correct me if I am wrong, that's not the Linux kernel, right?

D

[Mike Frysinger]

the kernel is called sys-kernel/chromeos-kernel-3_14.  what you're naming is the browser.

-mike

[D K]

OK, then I guess it was the browser (which is a main component, right?) failed to compile at this point.

I am also reading development docs, I found "If you want to build on a branch, pass the branch name to repo init (e.g: repo init -u <URL> [-g minilayout] -b 0.9.94.T)."

So, I have 2 questions...

1. For list of "branch", I am looking at https://chromium.googlesource.com/chromiumos/manifest.git/+refs which I know it is on alphabetical order (and not in date order). I think I might want to try those "release-RXX" one.

2. Say if I want to compile "release-R34-5500.B" I would do
repo init -u https://chromium.googlesource.com/chromiumos/manifest.git -b release-R34-5500.B

Am I correct? or I am way off?

Thanks.

D

[Mike Frysinger]

the errors you reported before about 64bit/stubs was because you were building for x32.  if you don't build for x32, you won't have those problems.

i don't think trying to build an older branch is a good idea.  just disable PAE in the kernel config.

-mike

On Sun, Aug 10, 2014 at 9:49 PM, Derek Kwan <derek....@gmail.com> wrote:

OK, then I guess it was the browser (which is a main component, right?) failed to compile at this point.

I am also reading development docs, I found "If you want to build on a branch, pass the branch name to repo init (e.g: repo init -u <URL> [-g minilayout] -b 0.9.94.T)."

So, I have 2 questions...

1. For list of "branch", I am looking at https://chromium.googlesource.com/chromiumos/manifest.git/+refs which I know it is on alphabetical order (and not in date order). I think I might want to try those "release-RXX" one.

2. Say if I want to compile "release-R34-5500.B" I would do
repo init -u https://chromium.googlesource.com/chromiumos/manifest.git -b release-R34-5500.B

Am I correct? or I am way off?

Thanks.

D

--

No trees were harmed in the sending of this message; however, a large number of electrons were terribly inconvenienced

[D K]

Because when I tried to set CONFIG_X86_PAE=n in ~/trunk/src/third_party/kernel/3.14/chromeos/config/i386/common.config doesn't seems to do anything (upon booting, it still shows require PAE)

I just run out of ideas what to try (or fix) at the moment.. any suggestions?

D

[Mike Frysinger]

you need to cros_workon the kernel and then rebuild it

$ cros_workon-x86-generic start chromeos-kernel-3_14

$ emerge-x86-generic chromeos-kernel-3_14

now when you do build_image, you'll get the kernel w/the changes you made locally

-mike

[D K]

ah ha!

so, let me recap...  

I will modify common.config first. then run the 2 command (new to me), then do build_image

Do I need to specify --nousepkg when running build_image? (which takes a very lllooooonnnggg time)

thanks, looking forward to try again (and hope it works this time)

[Mike Frysinger]

you don't need to pass --nousepkg to any command

-mike

[D K]

Followed your advice, still no go.

Modified the common.config, run the 2 command you suggested, the continue on the usual build_packages and build_image.

Booting the USB key still gives the message it need PAE.... :(

[D K]

OK, tried a few more things.. finally a little bit of break through.. But now I am getting this (and just keep rebooting) when boot from USB

early console in decompress_kernel

KASLR using RDISC... <---??

Decompressing Linux... Parsing ELF... Performing relocations... done.

Booting the kernel. <-- Good sign?

   Your system is repairing itself.  Please wait.  <-- repairing what?

[   20.494555] reboot: Restarting system

So I guess I have done something right taken out PAE, but break something else?

I changed these in common.config

CONFIG_HIGHMEM64G=n

CONFIG_X86_PAE=n

CONFIG_X86_PAT=n

[Mike Frysinger]

yes, it looks like you're past the PAE limitations.  the "Your system is repairing itself.  Please wait" message is coming from userspace.  there should be logs in the stateful partition if you mount the USB stick on your dev system.

-mike

[D K]

Unfortunately I was booting from USB stick.... I don't think it written any logs. :(

It boots fine on another PAE enabled system (first boot does goes to repair for 5 minutes!) After that it was running fine. So I take it back to the non PAE system, still no go.

Any hints where the log might be or what's failing? (or what's it it try to repair)

BTW, if I make change to the common.config and wants to compile again what command I should issue?

these two command doesn't seems to do me any good the second round.

$ cros_workon-x86-generic start chromeos-kernel-3_14

$ emerge-x86-generic chromeos-kernel-3_14

running build_packages/build_images doesn't seems to recompile the kernel based on my changes (in common.config)

I think I am getting close..

[Mike Frysinger]

recovery logs should be saved to the stateful partition on the USB stick.  i'm not too familiar with that though ... this issue has been covered a couple of times though, so you might want to search the archives of this list.

you only need to `cros_workon start` once.  every time you make a change to the source, you need to rebuild it with `emerge`.

but that only compiles the source.  you still need to generate a new image with `build_image`.

-mike

[D K]

Yea, I did searched the archives, I think you throw in your 2 cents too. It mention about mounting /dev/sdc and some commit 600 issue. But it yield no results and that guy seems to give up on it.

I will do a bit more searching and see if I can find out how to get to the 'stateful partition' and hope to pin point the problem...

As for the build. I will just run 'emerge' then 'build_image'? (skipping build_package? Well I guess because there are no change?)

And emerge is to "build kernel"?

Thanks!

[Mike Frysinger]

if you look at your USB stick, one of the partitions will be the stateful (i believe it's the first partition iirc).  try mounting that and see if there are useful logs in there.  if not, i'm afraid someone else (Richard or Hung-Te i suspect) will have to chime in with hints.

if you do build_packages+build_image, it should do the right thing automatically.  some people like to run emerge directly as it's a bit quicker to iterate (you've only changed one package, so only build that one by hand) before they re-run build_image.

when i say `emerge`, it's a shorthand for a variety of operations and depends on the context.  in this case, i'm referring to the exact `emerge-x86-generic chromeos-kernel-3_14` you said, but i'm too lazy to type out the whole thing.

-mike

[Hung-Te Lin]

From the description I assum you're booting a dev or test image (build_image), not recovery image right?

The self-repair occurs when it fails to mount some partitions - especially crypto home, if you forgot to support TPM correctly.

To get the logs, try to insert your USB stick to a Linux system (or anything that reads EXT4 fs),

mount the 1st partition and look for *.log files inside top folder, and the "unencrypted" folder.

I hope you can unencrypted/clober.log, which should tell you why it wants to repair.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

[D K]

@Mike

When I run "emerge-x86-generic chromeos-kernel-3_14" again after I made change to common.config, it gives me some message saying it was blocked (can't remember what was it exactly at the moment) and it doesn't seems to do anything

@Hung-Te

I am still a newbie.. :) I just followed the developer guide (http://www.chromium.org/chromium-os/developer-guide) to make my USB image. I assume mine was dev image.

I was able to find some information about the partition here -> http://www.chromium.org/chromium-os/chromiumos-design-docs/disk-format and my USB key shows

Disk /dev/sdb: 4127MB

Sector size (logical/physical): 512B/512B

Partition Table: gpt

Number  Start   End     Size    File system  Name        Flags

11      32.8kB  8421kB  8389kB               RWFW

 6      8421kB  8422kB  512B                 KERN-C

 7      8422kB  8422kB  512B                 ROOT-C

 9      8422kB  8423kB  512B                 reserved

10      8423kB  8423kB  512B                 reserved

 2      10.5MB  27.3MB  16.8MB               KERN-A

 4      27.3MB  44.0MB  16.8MB               KERN-B

 8      44.0MB  60.8MB  16.8MB  ext4         OEM         msftdata

12      128MB   145MB   16.8MB  fat16        EFI-SYSTEM  boot

 5      145MB   147MB   2097kB               ROOT-B

 3      147MB   1499MB  1353MB  ext2         ROOT-A

 1      1499MB  2573MB  1074MB               STATE       msftdata

What filesystem I should mount /dev/sdb1 as? I tried "mount -t ext4 /dev/sdb1 /mnt/test" doesn't work. A side note, is TPM a requirement? Can it be disable?

[Hung-Te Lin]

You should mount /dev/sd1 ("STATE"). The filesystem is ext4. If that does not work, it's probably already damaged and repair failed to create a new fs.

In the meantime, I'd recommend (1) disable auto-mounts on your Linux desktop (2) re-image the USB stick (cros flash, or image_to_usb).

We've seen disk partition corruption caused by Ubuntu automount, or user ejecting USB stick before data being flushed.

[D K]

(I changed the subject to better fit the current issue)

I have done a bit more researching and testing... 

On a PAE enabled system, the USB key boots fine. If the stateful partition was corrupted, it takes will rebuild it without problems.

On a non-PAE system, on first boot, it will corrupt the stateful partition. Even when the message was saying repairing itself and reboot, it doesn't seems to really fixing it. (I unplugged the USB key when it went back to the BIOS screen and examined it. The first partition is still corrupted.)

So, for some reasons, on non-PAE system, during the initial boot process, it messed up the stateful partition. And the repair didn't really reformat it like it should...

All seems to be done via "chromeos_startup"...