> -----Ursprüngliche Nachricht----- > Von: Anders Darander [mailto:and...@chargestorm.se] > Gesendet: Mittwoch, 10. Dezember 2014 12:17 > An: Heise, Matthias > Cc: j...@spectralogic.com; yocto@yoctoproject.org > Betreff: Re: [yocto] nfs-boot problem > > * matthias.he...@atlas-elektronik.com <Matthias.Heise@atlas- > elektronik.com> [141210 11:48]: > > > -----Ursprüngliche Nachricht----- > > > Von: Anders Darander [mailto:and...@chargestorm.se] > > > Gesendet: Mittwoch, 10. Dezember 2014 11:24 > > > An: Heise, Matthias > > > Cc: j...@spectralogic.com; yocto@yoctoproject.org > > > Betreff: Re: [yocto] nfs-boot problem > > > > * matthias.he...@atlas-elektronik.com <Matthias.Heise@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 -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto