# [SOLVED?]Diskless boot (pxe/nfs): / not being remounted rw

## the_mgt

<solution>The problem seems to be the baselayout, I upgraded to baselayout2 (with openrc) and everything works as intended, without any modification of executables or using a ramdisk! I am going to file a bug about the diskless howto</solution>

Original post:

Hello!

I am trying to get my media pc booting via pxe and using a nfs share as the root filesystem.

I followed this howto: http://www.gentoo.org/doc/en/diskless-howto.xml

This worked perfectly for the old system (kernel 2.6.15 and a gentoo with 2006 profile) which used to run from hd on the board of the mediacenter (EPIA ME6000II, pretty out of date, but it is ok for my needs). I copied kernel and system to the server, adapted them following the howto and BAM everything booted just fine, up to a running freevo. So far so good...    :Very Happy: 

Since I want to use newer versions, I used a new stage tarball and a recent 2.6.31 kernel, adapted it to match the old system stuff and booted again.

But, alas, I can't get localmount to remount / rw! This drives me nuts, the error is, that it can't write to /etc/mtab... Of course it cant! It is just about to remount the partition containing /etc/mtab rw... So why isn't "mount -n ..." used in this case? And why do these systems behave completely different with the same guide?!   :Evil or Very Mad: 

I'd like to come to a solution which does not involve hackish changes to rc scripts or anything like that...

So, any help and clues are appreciated, thank you for reading this!

<edit>Booting the old system with the 2.6.31 kernel results in / being remounted rw properly</edit>

Client configs:

linux # grep NFS .config

CONFIG_NFS_FS=y

CONFIG_NFS_V3=y

CONFIG_NFS_V3_ACL=y

# CONFIG_NFS_V4 is not set

CONFIG_ROOT_NFS=y

# CONFIG_NFSD is not set

CONFIG_NFS_ACL_SUPPORT=y

CONFIG_NFS_COMMON=y

cat /etc/fstab:

(In the guide it adds rsize and wsize, but that leads to another problem, so I omitted them)

10.42.0.1:/home/pxe/client       /       nfs             sync,hard,intr,rw,nolock  0 0 

shm                     /dev/shm        tmpfs           nodev,nosuid,noexec    0 0

tmpfs                   /tmp            tmpfs           rw,nosuid,noexec,nodev,size=128M,mode=1777      0 0

Server configs:

/var/tftp/pxelinux.cfg/default:

DEFAULT /client-2.6.31

APPEND ip=dhcp root=/dev/nfs nfsroot=10.42.0.1:/home/pxe/client

/etc/exports:

/home/pxe/client 10.42.0.5(rw,sync,no_root_squash,no_subtree_check)

----------

## TJNII

It looks like you fixed it, but let me throw some pointers in for future reference:

This is an extremely common problem.  I've set up a handfull of diskless boxen and run into this on all 3.

On one box this was caused by having the root entry in the fstab.  There is probably more to this, but the system works fine without the entry so I haven't investigated further.

On another box I copied the first diskless fs while the first system was up and that left the filesystem in an odd state.  Logging in, manually remounting the root filesystem, and starting services got it to a good state.  A clean shutdown and restart seemed to fix it, I haven't had any more problems.

The third machine had a baselayout problem.  You can hack around it by allowing the kernel to mount the filesystem rw at boot so the remount isn't necessary.

Hope this helps someone.

----------

## the_mgt

 *TJNII wrote:*   

> It looks like you fixed it, but let me throw some pointers in for future reference:

 

I wouldnt call it "fixed" or "solved", I avoided the problem (which i think is in the baselayout) by using another baselayout.

 *TJNII wrote:*   

> This is an extremely common problem.  I've set up a handfull of diskless boxen and run into this on all 3.
> 
> On one box this was caused by having the root entry in the fstab.  There is probably more to this, but the system works fine without the entry so I haven't investigated further.

 

Hm, that sounds interesting? Which baselayout was it?

 *TJNII wrote:*   

> On another box I copied the first diskless fs while the first system was up and that left the filesystem in an odd state.  Logging in, manually remounting the root filesystem, and starting services got it to a good state.  A clean shutdown and restart seemed to fix it, I haven't had any more problems.

 

And I assume you omitted the entry in fstab here as well and the systems were identical?

 *TJNII wrote:*   

> The third machine had a baselayout problem.  You can hack around it by allowing the kernel to mount the filesystem rw at boot so the remount isn't necessary.

 

I considered doing that, but I wanted to know why it fails on the localmount. I did not want to use hackish approaches. (Well, changing the baselayout is kind of a hack, at least it is chicken style: avoiding the problem instead of fixing it...)

You might want to contribute to https://bugs.gentoo.org/show_bug.cgi?id=308977

Still, what I fail to comprehend: Remounting / from a hard drive should lead to a similiar failure, if "mount -n ..." isn't use!

----------

## TJNII

 *the_mgt wrote:*   

> I wouldnt call it "fixed" or "solved", I avoided the problem (which i think is in the baselayout) by using another baselayout.

 

I would consider that a fix. If current baselayout is buggy, then upgrading gets the bugfixes.

 *the_mgt wrote:*   

> Hm, that sounds interesting? Which baselayout was it?

 

baselayout-1.12.13

 *the_mgt wrote:*   

> And I assume you omitted the entry in fstab here as well and the systems were identical?

   With the exception of changing minor things like the hostname, the filesystemswere exactly identical.

 *the_mgt wrote:*   

> Still, what I fail to comprehend: Remounting / from a hard drive should lead to a similiar failure, if "mount -n ..." isn't use!

 

I'm not really sure what you're trying to ask here.  However, I have found that localmount will mount filesystems if /etc/mtab is read only.  Baselayout must be smart enough to check and append the needed option.

----------

## the_mgt

Ok, so it seems I am not the only one with problems in that baselayout

 *TJNII wrote:*   

> 
> 
>  *the_mgt wrote:*   Still, what I fail to comprehend: Remounting / from a hard drive should lead to a similiar failure, if "mount -n ..." isn't use! 
> 
> I'm not really sure what you're trying to ask here.  However, I have found that localmount will mount filesystems if /etc/mtab is read only.  Baselayout must be smart enough to check and append the needed option.

 

Yes, exactly. Thats what the "-n" option does: Do not write to /etc/mtab. Since this works beautifully for hard drives, it should not work differently for nfs shares. (And it does not work differently with older or newer baselayouts)

----------

## bjoernfan

Sorry for using an old thread and everything, but after struggeling with this for two days and finally finding such a stupid (it feels kind of stupid to me, anyways) solution to my problem, I feel it would help a lot if the docs were updated.

 *TJNII wrote:*   

> On one box this was caused by having the root entry in the fstab.  There is probably more to this, but the system works fine without the entry so I haven't investigated further.
> 
> ...
> 
> Hope this helps someone.

 

This is what got me.

I'm using Gentoo on my workstation, and I've got a laptop here with a broken harddrive I want to netboot with root from a NFS share. The laptop is using an old backup of its Debian Squeeze install.

When I had the fstab entry for / (sync,rw and more) it booted but / was mounted readonly, and almost every initscript complained about it.

The solution was to *remove* this line from fstab. It made me cringe when I saw that it actually worked. I have no idea why this works. It feels so non-intuitive to not have a line for / in fstab. Especially since all the docs I found about pxebooting told me I should have this line. 

Could the docs be updated to reflect this?

Note: If / is mounted read-only, try removing the root entry from /etc/fstab

(Sorry for the harshness, I hope my rude mood is understandable.)

----------

## the_mgt

 *bjoernfan wrote:*   

> The solution was to *remove* this line from fstab. It made me cringe when I saw that it actually worked. I have no idea why this works. It feels so non-intuitive to not have a line for / in fstab. Especially since all the docs I found about pxebooting told me I should have this line. 
> 
> Could the docs be updated to reflect this?
> 
> Note: If / is mounted read-only, try removing the root entry from /etc/fstab
> ...

 

I totally understand your frustration and I dont mind the thread necrophilia.

I have been quite frustrated too, especially after filing a bug report which was instantly closed.

https://bugs.gentoo.org/show_bug.cgi?id=308977 I reopened the bug, but instead of fixing the docs which they once wrote up, they asked me to fix it, when I didnt know of any solution for baselayout-1...

Could you please write your solution to this bug report, please? They are not interested in reading this forum post... And tell them which exact version of baselayout-1 you used. For me, removing of / from fstab did not work, when I tried to set it all up. Thank you very much!

----------

