[yocto] nfs-boot problem

[Matthias.Heise at atlas-elektronik.com]

> -----Ursprüngliche Nachricht-----
> Von: Anders Darander [mailto:anders at chargestorm.se]
> Gesendet: Mittwoch, 10. Dezember 2014 12:17
> An: Heise, Matthias
> Cc: jimr at spectralogic.com; yocto at yoctoproject.org
> Betreff: Re: [yocto] nfs-boot problem
> 
> * Matthias.Heise at atlas-elektronik.com <Matthias.Heise at atlas-
> elektronik.com> [141210 11:48]:
> > > -----Ursprüngliche Nachricht-----
> > > Von: Anders Darander [mailto:anders at chargestorm.se]
> > > Gesendet: Mittwoch, 10. Dezember 2014 11:24
> > > An: Heise, Matthias
> > > Cc: jimr at spectralogic.com; yocto at yoctoproject.org
> > > Betreff: Re: [yocto] nfs-boot problem
> 
> > > * Matthias.Heise at atlas-elektronik.com <Matthias.Heise at atlas-
> > > elektronik.com> [141210 09:35]:
> > > > As to the rootfs, this folder
> > > > fsl-community-bsp/build/tmp/work/wandboard_quad-poky-linux-
> > > gnueabi/cor
> > > > e-image-minimal/1.0-r0/rootfs seems to be exactly the structure
> > > > that is packed into the
> > > > image.tar.bz2 so I thought it is a good idea to directly use it as
> > > > nfs share. Is there some reason not to do so ?
> 
> > > Well, there're quite few. For instance file and directory ownership,
> > > permissions etc.
> 
> > Yes, I can see that
> 
> > >If you're not using devtmpfs, and thus would like static  device
> > >nodes, they wouldn't be created in the build directory.
> 
> > This is a little beyond my horizon, if you don't mind, could you
> > please explain this a little, I may be lacking some knowledge here...
> > sorry
> 
> Well, nowadays most people are letting the kernel create the device nodes
> itself (possibly with some extra help from udev/mdev). Though, on really tiny
> systems you might still want to manually create all device nodes statically
> during image create time. In that special case, the device node names will be
> available in the build directory .../rootfs, but they will be regular files, not
> device nodes.

Ah, ok , thank you.

> 
> If you don't know about this, it's quite likely you don't have to bother with
> this at the moment.
> 

Ok ;-)


> > > Thus, you really should be using the tarball when you want to run an
> nfsroot.
> 
> > Tried again but again it didn't work, do you have an idea what could be
> wrong ?
> 
> What steps have you taken?
> 
> How have you unpacked and exported the rootfs?
> 
> If you have export e.g. /export/rootfs, it's usually enough (for a simple image
> at least) to run `sudo tar xf ....rootfs.tar.bz2`.
> 

I did unpack and copy to correct location but didn't know I'd have to re-run "exportfs" after changing the directory (I just switched a link from the other working-but-not-advisable-rootfs to the unpacked tar.bz2 ). After doing so it works, thank you !
I only have some permission issues left, don't know if they are important :

INIT: version 2.88 booting
Starting udev
udevd[171]: starting version 182
bootlogd: cannot allocate pseudo tty: No such file or directory
Populating dev cache
mv: can't preserve ownership of '/etc/udev/cache.data': Operation not permitted
INIT: Entering runlevel: 5
Configuring network interfaces... ifup skipped for nfsroot interface eth0
run-parts: /etc/network/if-pre-up.d/nfsroot exited with code 1
Starting OpenBSD Secure Shell server: sshd
  generating ssh RSA key...
  generating ssh ECDSA key...
  generating ssh DSA key...
  generating ssh ED25519 key...
done.
Starting rpcbind daemon...done.
creating NFS state directory: chown: sm: Operation not permitted
chown: sm.bak: Operation not permitted
chown: statd: Operation not permitted
chown: /var/lib/nfs: Operation not permitted
done
starting statd: done
Starting syslogd/klogd: done

Poky (Yocto Project Reference Distro) 1.7 wandboard-quad /dev/ttymxc0

wandboard-quad login:

> Cheers,
> Anders
> --
> Anders Darander
> ChargeStorm AB / eStorm AB

Thank you,
regards,
Mat