Setting up "netbooting" on the OSD...

[pfft2001]

OK - that's a good thing, but I still can't proceed with netbooting until someone answers my questions about the filesystems (rootfs and "extended area").

There's a rootfs on my site (may our may not work ) as cramfs or tar.... You're on your own here, though I'd be inclined to try out the method in the wiki. There seems to be no mention of PXE, so maybe U-Boot just loads up the uImage and there's no extra complication?

I know this must sound like I keep hitting the same note, but I'd like someone to confirm that it is OK to just tar up both the rootfs and the extended area (as separate tar files) and use that to populate the directories on the server (the ones that are listed in /etc/exports).

Also, the instructions on the Wiki ("NetBooting the OSD") seem to be stuck in Torfu land - i.e., where there is only one NFS mount to do (namely, the rootfs).  It doesn't give the details for how to set it (the extended area) up for Arizona.  Now, in looking around, I found this text on the page for "Workstation setup":

Now, edit /etc/exports and add this line (replacing network-acl as specified above):
 /srv/neuros-osd-rootfs network-acl(ro,sync,no_root_squash,subtree_check)

Arizona requires an additional export mounted rw:
 /srv/neuros-osd-rootfs/nfs-debug-extended-area network-acl(rw,sync,no_root_squash,subtree_check)

But that doesn't tell me what the corresponding uBoot environment variable is.  I.e., the NetBooting page tells us to:

setenv nfs_root /path/to/neuros-bsp/rootfs/fs

(where by "/path/to/neuros-bsp/rootfs/fs", they really mean "/srv/neuros-osd-rootfs")

But what is the corresponding environment variable for the "extended area" in Arizona/OSDng?

P.S.  I looked in my environment variables (dumped out the output of "printenv" to a file), looking for the string "extend".  It wasn't there.  I think it should be - you'd think there'd be some variable in there already for the extended area.

[heyrick]

I think the question would be... has anybody else actually done this?

Perhaps the answer is to just try it, see what happens.

At supermarket now, gotta go.


Best wishes,

Rick.

[greyback]

I know this must sound like I keep hitting the same note, but I'd like someone to confirm that it is OK to just tar up both the rootfs and the extended area (as separate tar files) and use that to populate the directories on the server (the ones that are listed in /etc/exports).

I can confirm this - tho you don't need separate tarballs, one will do.

To extract the tarball, you'll need to use sudo, as the device nodes must be written as root.

Also, the instructions on the Wiki ("NetBooting the OSD") seem to be stuck in Torfu land - i.e., where there is only one NFS mount to do (namely, the rootfs).  It doesn't give the details for how to set it (the extended area) up for Arizona.  Now, in looking around, I found this text on the page for "Workstation setup":

Now, edit /etc/exports and add this line (replacing network-acl as specified above):
 /srv/neuros-osd-rootfs network-acl(ro,sync,no_root_squash,subtree_check)

Arizona requires an additional export mounted rw:
 /srv/neuros-osd-rootfs/nfs-debug-extended-area network-acl(rw,sync,no_root_squash,subtree_check)

But that doesn't tell me what the corresponding uBoot environment variable is.
<snip>
But what is the corresponding environment variable for the "extended area" in Arizona/OSDng?

Following the guide, the extended area is a folder inside the usual rootfs. In the exports file, you tell NFS to share /srv/neuros-osd-rootfs as read-only, and /srv/neuros-osd-rootfs/nfs-debug-extended-area as read-write.

The OSD will NFS mount /srv/neuros-osd-rootfs on boot. The read-write folder within it will just work! No Arizona-only info is needed in uBoot. So you just need to tell uBoot the location of /srv/neuros-osd-rootfs as usual:

Code:

setenv nfs_root /srv/neuros-osd-rootfs

and you should be good to go (along with IP addresses and tftp stuff, as you know).
-G

[pfft2001]

I know this must sound like I keep hitting the same note, but I'd like someone to confirm that it is OK to just tar up both the rootfs and the extended area (as separate tar files) and use that to populate the directories on the server (the ones that are listed in /etc/exports).

I can confirm this - tho you don't need separate tarballs, one will do.

To extract the tarball, you'll need to use sudo, as the device nodes must be written as root.

OK - that makes sense.  So, just to double check, I can do the tar-ing on a running OSD - get all the files into a big tar file, then untar that on the server.  Right?

The OSD will NFS mount /srv/neuros-osd-rootfs on boot. The read-write folder within it will just work! No Arizona-only info is needed in uBoot. So you just need to tell uBoot the location of /srv/neuros-osd-rootfs as usual:

Code:

setenv nfs_root /srv/neuros-osd-rootfs

and you should be good to go (along with IP addresses and tftp stuff, as you know).
-G

OK - that makes sense.  I didn't know that NFS worked that way - that a single NFS mount could be read-only for some of the files and read-write for others.  I.e., that you can have a single NFS mount "connected" to more than one line in /etc/exports.  Interesting...

[greyback]

So, just to double check, I can do the tar-ing on a running OSD - get all the files into a big tar file, then untar that on the server.  Right?

Hmmm, that could work. I've never done it that way though, I've always built a firmware, generated a rootfs, then "copied" it to somewhere using tar so OSD can use it via NFS.

While OSD is running, there'll be a few additional files and some of the mount points will be active. I'm not sure how good a tarball of this will be for future NFS use. It's worth a try though.
-G

[heyrick]

While OSD is running, there'll be a few additional files and some of the mount points will be active. I'm not sure how good a tarball of this will be for future NFS use. It's worth a try though.

It might also be an idea not to follow symbolic links, for a lot of stuff points to a lot of other stuff (case in point, /media ), but then this could equally affect all the library dupes that point to the one copy, or pretty much everything in /bin that points to busybox... Mmm...


Best wishes,

Rick.