February 2024 Milwaukee Linux Users Group (MLUG) - Meeting Invitation

[Roger M. Jenson]

Join us online for the February 2024 Milwaukee Linux Users Group online
meeting by clicking on the following link.

https://meet.jit.si/LegitimateLettersMultiplyStraight

Best Regards,
Roger M. Jenson

[Tom]

Just set up a new Fedora 39 machine.

 

Got me a timing issue: something isn't loaded by the time my mounts start and the machine fails to boot. I'm surprised that it doesn't just take of this. How rude.

 

The kicker is that it's not just the off-box (NFS) mounts that cause it to fail. I'm also attempting to mount an mdadm RAID and that also causes it to fail. WAIT... That's not quite true. I now have a second problem. See Problem 2 below.

 

Problem 1: the machine won't boot and drops to maintenance mode unless all external mounts are set to noauto. Once up and running, I can start a console, su to root or use sudo, and mount them all, with no problems.

 

Note: the first time I manually mount /data/thecus1, it reports:

Created symlink /run/systemd/remotefs.target.wants/rpc-stat-d.service -> /usr/lib/systemd/system/rpc-statd.service.

 

This mount's entry on fstab has the fs type as "nfs" and so do some of the others, but I've always had to use "nfs4" to mount my TrueNAS volumes on a Fedora/Redhat/CentOS machine. Everything else off-box is given as "nfs".

 

A copy of my messy fstab file is at the end of this message. The tabs didn't translate, so it's hard to read. Sorry.

 

Problem 2: I mounted /dev/md127 successfully when testing, then put /dev/md127 in my fstab file. This prevented boot. Why? Because /dev/md127 magically changed to /dev/md0 between boots. So I changed it to an automatic mount at boot of /dev/md0 and presto! it boots nicely.

 

So I guess problem 2 is: Why did the name of the RAID array change on me? Will it change again? Of course, I do see that it has a UUID for what is now md0 -- is my best play here to mount id by its UUID? Since when do mdadm logical drives change names? That's perverse. I don't ever remember an MD device changing numbering between boots.

 

Thanks in advance for any insights.

 

-T

 

# /etc/fstab

# local array

/dev/md0 /raid xfs defaults 0 0

 

172.20.0.7:/data/archive /data/archive nfs noauto,defaults 0 0

172.20.0.7:/usr/local/shared /usr/local/shared nfs noauto,defaults 0 0

 

# Drobo NAS

172.20.0.96:/mnt/DroboFS/Shares/Drobo1_1 /data/drobo5n nfs noauto,rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=172.20.0.96,mountvers=3,local_lock=none

 

# Iomega NAS

iomega-nas1:/mnt/soho_storage/samba/shares/public /data/iomnas1/public nfs rw,noauto,mountaddr=172.20.0.97,mountvers=3,mountport=981,mountproto=udp,local_lock=none,addr=172.20.0.97) 0 0

iomega-nas1:/mnt/soho_storage/samba/shares/Backups /data/iomnas1/backups nfs rw,noauto,local_lock=none,addr=172.20.0.97) 0 0

 

172.20.0.12:/raid/Media /data/media nfs noauto,defaults 0 0

172.20.0.12:/raid/Media/TV /data/media/TV nfs noauto,defaults 0 0

 

# Gibson

172.20.0.11:/mnt/p0/ds0 /data/gibson/ds0 nfs4 noauto,defaults 0 0

172.20.0.11:/mnt/p1/ds1 /data/gibson/ds1 nfs4 noauto,defaults 0 0

172.20.0.11:/mnt/p2/d2 /data/gibson/d2 nfs4 noauto,defaults 0 0

 

# Thecus NAS

 

 

 

---

335. A free society is a place where it's safe to be unpopular. --Adlai Stevenson

---

Tom Peters • a50@MHzHam@gmail.com • N9QQB (amateur radio) --... ...-- / -.. . / -. ----. --.- --.- -...
"HEY YOU" (loud shouting) • Second Tops (Set Dancing) • FIND ME ON FACEBOOK
43° 7' 17.2" N by 88° 6' 28.9" W • Elevation 815' • Grid Square EN53wc
Sr. Systems Administrator • Open-source Dude • Musician • Registered Linux User 385531

---

Admiration: Our polite recognition of another's resemblance to ourselves.

[James Meyer]

For those nfs shares you probably want the _netdev option.   That should force the system to skip those devices until the network is ready.

Another option is to remove them from /etc/fstab and use systemd .mount units.  

While I am no fan of systemd..the mount units are nice, once you get past the super annoying naming convention.

--
Homepage: http://www.milwaukeelug.org/home
This forum online: https://groups.google.com/forum/#!forum/MilwaukeeLUG
---
You received this message because you are subscribed to the Google Groups "Milwaukee Linux User's Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to MilwaukeeLUG...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/MilwaukeeLUG/5701.-303960930.1707864704%40gmail.com.

[Tom]

Thanks JM, either one sounds like it would address the issue. Where does one put the _netdev option? Ah, I see it.

 

Lots of people hate systemd, obviously you're not  alone there. I have learned to get along with it, but I don't do a lot with it, other than starting and stopping services. I should learn how to do mounts via systemd. But not today.  

 

I see some folks doing stuff like this:

whatdevice wheremount  nfs   _netdev,x-systemd.requires=network-online.target,x-systemd.after=network-online.target, ...

 

I did that for one of these mounts and it worked, no more hang at boot. But that doesn't turn out to be necessary. Just specifying _netdev worked for another mount.

 

Trying that for some of the others... .. and it works. The extra x-systemd targeting doesn't seem to be needed. Just marking it as _netdev seems to be enough.

 

Thanks!

 

P.S. Roger Jenson: I guess I will be changing the mount over to use the UUID instead.

To view this discussion on the web visit https://groups.google.com/d/msgid/MilwaukeeLUG/CADvTYkwzU7hghf6bSgsctbKpg1Gyh4HE5QOakXm87QqyP_%2Bxjg%40mail.gmail.com.