how to enable NFS mount in Chromium OS image

[Aaron]

Hi,

I would like to mount a NFS share on a x86-generic target. I understand I need to setup two things on target: 

1) build a kernel with NFS support (as documented in page http://www.chromium.org/network-based-development).

2) install nfs-utils to the image. 

For 2), I used "emerge-x86-generic nfs-utils" but got errors like "there are no builds to satisfy ">=net-libs/libnfsidmap-0.21-r1" for /build/x86-generic".

Anyone could help me on this?

Thanks,

Aaron

[Mike Frysinger]

On Tue, Jun 26, 2012 at 12:49 AM, Aaron <jin....@gmail.com> wrote:
> For 2), I used "emerge-x86-generic nfs-utils" but got errors like "there are
> no builds to satisfy ">=net-libs/libnfsidmap-0.21-r1" for
> /build/x86-generic".

do you need NFSv4 support ? if not, export USE=-nfsv4.

if you do, then use:
https://gerrit.chromium.org/gerrit/26106
-mike

[Aaron]

Hi Mike,

I don't need NFSv4. Thank you! :)

Aaron

[Aaron]

Hi Mike,

I have tried the following but couldn't find mount.nfs in the image.

USE=nfs ./build_packages --board=x86-generic --nowithfactory

export USE=-nfsv4

emerge-x86-generic nfs-utils

./build_image --board=x86-generic --noenable_rootfs_verification dev test

I could find mount.nfs in the directory /build/x86-generic/sbin but couldn't find it in the image created by build_image script.

Could you please give me more tips on this?  Thank you!

Aaron

On Tuesday, June 26, 2012 7:57:11 AM UTC-7, Mike Frysinger wrote:

[Mike Frysinger]

yes, installing a package with `emerge-$BOARD` does not install it into the target image.  for that, you have to add it to the relevant chromeos package.

i.e. edit src/third_party/chromiumos-overlay/chromeos-base/chromeos-dev/chromeos-dev-0.1.0.ebuild and add all the extra packages you want installed to that ebuild's RDEPEND.  then `emerge-$BOARD chromeos-dev` to force the binpkg to be regenerated.  then build_image like normal and you should end up with what you want.

we have the chromeos-bsp virtual for overlays to add their own custom packages to the final image, so if you were to make your own overlay (based on an existing one), you could add stuff to that ...

-mike

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

[Aaron]

[Aaron]

Hi Mike,

Thanks for your tips. The approach works. 

But when I booted the image from usb, the target entered "Yours system is repairing itself  ..." in repeated cycles. I reverted the ebuild change, the problem didn't go away. 

I am out of luck again. Any suggestions?

Aaron

--
Chromium OS discuss mailing list: chromium-os-discuss@chromium.org

--
Chromium OS discuss mailing list: chromium-os-discuss@chromium.org

[Aaron]

Hi Mike,

Thanks for your tips. The approach works. 

But when I booted the image from usb, the target entered "Yours system is repairing itself  ..." in repeated cycles. I reverted the ebuild change, the problem didn't go away. 

I am out of luck again. Any suggestions?

Aaron

On Tuesday, June 26, 2012 2:52:03 PM UTC-7, Mike Frysinger wrote:

--
Chromium OS discuss mailing list: chromium-os-discuss@chromium.org

View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

On Tuesday, June 26, 2012 2:52:03 PM UTC-7, Mike Frysinger wrote:

--
Chromium OS discuss mailing list: chromium-os-discuss@chromium.org

[Mike Frysinger]

sorry, no idea.  never seen that error before.

maybe make sure to use --noenable_rootfs_verification when running build_image ?

-mike

Chromium OS discuss mailing list: chromium-...@chromium.org

[Richard Barnette]

On Jun 27, 2012, at 11:26 AM, Aaron wrote:

> Hi Mike,
>
> Thanks for your tips. The approach works.
>
> But when I booted the image from usb, the target entered "Yours system is repairing itself ..." in repeated cycles. I reverted the ebuild change, the problem didn't go away.
>
> I am out of luck again. Any suggestions?
>

Aaron,

I don't know the root cause of your problem, but the message
appears when partition 1 can't be mounted during early system startup.
The "repair" amounts to 'mkfs.ext4' on the partition. If you're seeing this
problem repeatedly, it suggests that the 'mkfs' is failing. I don't know
why 'mkfs' would fail, though. My best guess would be that the boot
disk doesn't have a partition 1 at all…

For reference, see the sources in src/platform/init. See especially
the "chromeos_startup" and "clobber-state" scripts.

Good Luck!

> Chromium OS discuss mailing list: chromium-...@chromium.org

> Chromium OS discuss mailing list: chromium-...@chromium.org

> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en
>
>

> --
> Chromium OS discuss mailing list: chromium-...@chromium.org

> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en

-- jrb

[Aaron]

Hi,

Thanks all for the tips.

I did two tests and found the following:

1. Recreated the whole repo and built an dev image from scratch as per quick start guide. The image is booted with success.

2. Did the following in order to add NFS support for the image. The image failed to boot and entered self-repair mode.

USE=nfs ./build_packages --board=x86-generic --nowithfactory

export USE=-nfsv4

emerge-x86-generic nfs-utils

[edit chromeos-dev-0.1.0.ebuild and insert net-fs/nfs-utils to RDEPEND block]

emerge-x86-generic chromeos-dev

./build_image --board=x86-generic --noenable_rootfs_verification dev

3. Reverted the ebuild change in step 2 and did emerge --unmerge nfs-utils. The 3rd image failed to boot the same way. 

I was able to mount partition 1 in chroot on both failed images. 

Is there some thing else I am missing to check? My objective is to have a bootable usb image that can do NFS mount after boot as partially documented in http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/debugging-tips/host-file-access#TOC-NFS-Mount

Thanks a ton,

Aaron

> Chromium OS discuss mailing list: chromium-os-discuss@chromium.org

> Chromium OS discuss mailing list: chromium-os-discuss@chromium.org

> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en
>
>
> --

> Chromium OS discuss mailing list: chromium-os-discuss@chromium.org

[Aaron]

Hi,

I compared chromeos_startup files between a working image and failed image:

92c92
<     mount -n -t ext4 -o nodev,noexec,nosuid,commit=600 \
---
>     mount -n -t tmpfs -o nodev,noexec,nosuid,commit=600 \
102c102
<   elif ! mount -n -t ext4 -o nodev,noexec,nosuid,commit=600 \
---
>   elif ! mount -n -t tmpfs -o nodev,noexec,nosuid,commit=600 \

This explained why failed image entering self-repairing mode. Could this be a bug?

Thanks,

Aaron

On Monday, June 25, 2012 9:49:49 PM UTC-7, Aaron wrote:

[Richard Barnette]

On Jun 28, 2012, at 5:33 PM, Aaron wrote:

> Hi,
>
> I compared chromeos_startup files between a working image and failed image:
>
> 92c92
> < mount -n -t ext4 -o nodev,noexec,nosuid,commit=600 \
> ---
> > mount -n -t tmpfs -o nodev,noexec,nosuid,commit=600 \
> 102c102
> < elif ! mount -n -t ext4 -o nodev,noexec,nosuid,commit=600 \
> ---
> > elif ! mount -n -t tmpfs -o nodev,noexec,nosuid,commit=600 \
>
> This explained why failed image entering self-repairing mode. Could this be a bug?
>

It looks like something associated with the NFS support changes the
'ext4' to 'tmpfs'. I don't know where or how that happens.

Which of the two versions above is the working, and which the failing?
I'm guessing the 'tmpfs' variant works.

Thanks!

> Thanks,
> Aaron
>
>
> On Monday, June 25, 2012 9:49:49 PM UTC-7, Aaron wrote:
> Hi,
>
> I would like to mount a NFS share on a x86-generic target. I understand I need to setup two things on target:
>
> 1) build a kernel with NFS support (as documented in page http://www.chromium.org/network-based-development).
> 2) install nfs-utils to the image.
>
> For 2), I used "emerge-x86-generic nfs-utils" but got errors like "there are no builds to satisfy ">=net-libs/libnfsidmap-0.21-r1" for /build/x86-generic".
>
> Anyone could help me on this?
>
> Thanks,
> Aaron
>
>
>

> --
> Chromium OS discuss mailing list: chromium-...@chromium.org

[Richard Barnette]

On Jun 28, 2012, at 6:00 PM, Richard Barnette wrote:

> On Jun 28, 2012, at 5:33 PM, Aaron wrote:
>
>> Hi,
>>
>> I compared chromeos_startup files between a working image and failed image:
>>
>> 92c92
>> < mount -n -t ext4 -o nodev,noexec,nosuid,commit=600 \
>> ---
>>> mount -n -t tmpfs -o nodev,noexec,nosuid,commit=600 \
>> 102c102
>> < elif ! mount -n -t ext4 -o nodev,noexec,nosuid,commit=600 \
>> ---
>>> elif ! mount -n -t tmpfs -o nodev,noexec,nosuid,commit=600 \
>>
>> This explained why failed image entering self-repairing mode. Could this be a bug?
>>
> It looks like something associated with the NFS support changes the
> 'ext4' to 'tmpfs'. I don't know where or how that happens.
>
> Which of the two versions above is the working, and which the failing?
> I'm guessing the 'tmpfs' variant works.
>

OK. I found the code responsible for the change. It's in the chromeos-init
ebuild; that's the package responsible for chromeos_startup.

Here are the evil bits:
if use nfs; then
# With USE=nfs we remove the iptables rules to allow mounting
# of the root device.
rm "${D}/etc/init/iptables.conf" || die
rm "${D}/etc/init/ip6tables.conf" || die
# If nfs mounted use a tmpfs stateful partition like factory
sed -i 's/ext4/tmpfs/' "${D}/sbin/chromeos_startup" || die
fi

In short: the changes to chromeos_startup are there when you
built with 'USE=nfs'. If you don't want the changes made, don't
use that setting. The 'nfs' USE flag isn't checked in any other ebuild,
so I expect dropping the flag should have no other side effects.

I still don't fully understand your failure; it would help if I knew which
version of chromeos_startup is the working version, and which the
failing.

[Aaron]

The one with ext4 is working. 

>> Chromium OS discuss mailing list: chromium-os-discuss@chromium.org

>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en
>
> -- jrb
>
>
>
> --

> Chromium OS discuss mailing list: chromium-os-discuss@chromium.org

[Aaron]

Hi Richard,

Thanks for looking into this. 

Just to be clear, I am copying image to USB stick with nfs-utils package included using image_to_usb.sh script so that I could boot OS from USB and do NFS mount. Ext4 version of chromes_startup makes sense to me because the partition is on the USB, right?

I probably shouldn't add USE=nfs to do that. I'll try it out tomorrow.

Aaron

[Aaron]

Hi,

I got NFS mount working from a USB image by not using USE=nfs (except chromeos-kernel ebuild). Thanks for the help!

Another question - is Chromium OS able to do NFS boot on x86-generic platforms? The documentation on http://www.chromium.org/network-based-development points out the following:

...

Chromium OS Approach

(ARM only, for now).

...

Just would like to be sure if I could head on to that path to setup NFS boot.

Thanks,

Aaron

[Huang Jin]

> OK.  Did you test booting a kernel built without USE=nfs?  I do expect
> the kernel needs some sort of change of options, but I can't find anything
> in the source to indicate that the kernel ebuild uses the 'nfs' USE flag.

I built chromeos-kernel with USE=nfs and nfs-utils with USE=-nfsv4 to make it work.

[Richard Barnette]

(trying to re-send to the alias one more time; Mail.app is refusing to send
from my selected account…)

On Jun 29, 2012, at 11:37 AM, Aaron wrote:

> Hi,
>
> I got NFS mount working from a USB image by not using USE=nfs (except chromeos-kernel ebuild). Thanks for the help!
>

OK. Did you test booting a kernel built without USE=nfs? I do expect
the kernel needs some sort of change of options, but I can't find anything
in the source to indicate that the kernel ebuild uses the 'nfs' USE flag.

> Another question - is Chromium OS able to do NFS boot on x86-generic platforms? The documentation on http://www.chromium.org/network-based-development points out the following:
> ...
>
> Chromium OS Approach
>
> (ARM only, for now).
> ...
>
> Just would like to be sure if I could head on to that path to setup NFS boot.
>

My reading of the 'ARM only' statement is that it has to do with
getting firmware configured to boot over NFS. If you know how
to configure an x86-based linux system to boot over NFS, you
shouldn't have *too* much trouble. The only code in the
Chromium OS source base affected by an NFS root should be
the kernel code. None of the user-land code should be affected.

> >> Chromium OS discuss mailing list: chromium-...@chromium.org

> >> View archives, change email options, or unsubscribe:
> >> http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en
> >
> > -- jrb
> >
> >
> >
> > --

> > Chromium OS discuss mailing list: chromium-...@chromium.org

> > View archives, change email options, or unsubscribe:
> > http://groups.google.com/a/chromium.org/group/chromium-os-discuss?hl=en
>
> -- jrb
>
>
>

-- jrb

[Richard Barnette]

Right. What I'm interested in is whether you tried a kernel without USE=nfs and
then saw it fail.

I can't find anything in the source that says the kernel should be different with
USE=nfs, but there are aspects of this problem that still baffle me.

My objective here is to figure out changes that will make these problems
harder to find in future. I think part of the problem is that the code conflates
a single USE flag for 'NFS mounted root', 'NFS mounted stateful', and
'NFS support enabled'. I want to find the associated kernel code to figure
out how much these these things are actually related...

Thanks!

-- jrb

[Aaron]

 
Right.  What I'm interested in is whether you tried a kernel without USE=nfs and
then saw it fail.

I did try a kernel without USE=nfs and found the mount NFS share failed. 

 

 I think part of the problem is that the code conflates
a single USE flag for 'NFS mounted root', 'NFS mounted stateful', and
'NFS support enabled'.  I want to find the associated kernel code to figure
out how much these these things are actually related...

Agreed. 

Thanks!

Aaron