Desktop EFI install - tweaking Boot

English Install/Boot/Login
#1

I have built a fresh 13.2 / KDE system with boot via EFI bios.

System boots OK, with the following exceptions

  1. I have a crypto file that is defined in /etc/fatab. I would rather it not mount on boot, so I added the noauto option in /etc/fstab
  2. I have several nfs mounts defined but the nfs server(another PC on my network) is not always online. I added the soft option to /etc/fstab for each.

Here is a snippet of my /etc/fstab

/dev/mapper/cr_srv2  /home/carl/srvc2     ext4       loop,noauto,nofail    0 0
192.168.10.39:/home/carl    /nfs_shares/PVE-LinuxSRV5/Carl_home    nfs    soft 0 0 
192.168.10.39:/    /nfs_shares/PVE-LinuxSRV5/Root_BE\040CAREFUL    nfs    soft,ro 0 0 
192.168.10.39:/backup    /nfs_shares/PVE-LinuxSRV5/backup    nfs    soft 0 0 
192.168.10.39:/home    /nfs_shares/PVE-LinuxSRV5/home    nfs    soft 0 0

After modifying /etc/fstab, I ran mkinitrd (as root) and it installed in /boot

But the noauto and soft options don’t seem to be effective on the next system reboot.
The system is still looking for the crypto key during boot, and the nfs startup process is still hanging for the default 5min 30 sec timeout.

Might this be a systemd issue?

Is there additional magic (in addition to mkinitrd) to updating what should go on during boot?

Thanks

#2

You will also need to add a “noauto” option to the corresponding entry in “/etc/crypttab”.

  1. I have several nfs mounts defined but the nfs server(another PC on my network) is not always online. I added the soft option to /etc/fstab for each.

I can’t comment on the “soft” option. In those circumstances, I prefer to use automount (the “autofs” service).

#3

Ah so, thanks for the /etc/cryptab.

I’ll read up on autofs

#4

I found this item in the archives
https://forums.opensuse.org/showthread.php/429064-How-to-mount-NFS-server-with-autofs
Is this still a good setup procedure?

#5

It looks okay. The server setup is similar to what I used, except that I made it available to “*” (any host). I’m relying on my router firewall to keep out external access.

For client, in my experience, most of NFS client setup is done by default. So I only needed to setup my definitions in the “auto.*” configuration files, then start “rpcbind” and “autofs” services.

#6

FYI, I found the following to be VERY HELPFUL and clear

https://www.suse.com/documentation/sles-12/book_sle_admin/data/cha_autofs.html

I realize it is for SUSE, not openSUSE, but at the moment at least this piece is in synch.
The write-up made it much clearer what the various config( /etc/auto.wxyz) files were doing.

I am now connected!

#7

Yes, that looks pretty good.

I first used autofs with solaris (I think it had a different name). Back then, the linux automounter didn’t have very good reputation. The solaris one worked well. So when I wanted NFS with opensuse, I decided it was time to check whether the linux automount was doing better. Thus far it has worked pretty well.

Without automount, you can get into a situation where you have a network of several computer each of which has to be booted first >:(

#8

I agree.
Although this is a desktop, I tried running the Network via Network Manager, since Network Manager when running on a laptop seems to gracefully boot when it can’t reach nfs mounts. But that in fact does not seem to be the case.
Now that I have autofs working, I wish I had made the shift a while ago.

I prefer nfs (and autofs) over Samba (which seems to generally work very well now in 13.x) as I have encound=tered some applications which will not browse to Samba folders/files but are OK with nfs shares.

#9

“soft” is unrelated to mounting. It means system will stop access to mounted NFS filesystem after timeout if server does not respond. Opposite is “hard” where system will retry access to non-responsive server indefinitely. What did you intend to achieve with this option?