0

I am trying to correctly identify which systemd configuration file must be updated to ensure the full user environment is mounted/accessible before the GUI/session is initiated.

This reference did not addess my needs.

/home is on the root disk, but all sub-directories are on the secondary disk at ${MOUNTPOINT)

(i.e. /home/user/Desktop 
     -> /DB001_F2/home/user.Desktop, etc.)

MOUNTPOINT="/DB001_F2"

The command

systemctl list-units | grep "${MOUNTPOINT}" | awk '{ print $1 }'

reports the unit as

DB001_F2.mount

Which file under /etc/systemd or /usr/lib/systemd must be updated such that the GDM will have the proper precondition to ensure that content on DB001_F2 will be available to correctly identify the path to the desired DESKTOP directory and its contents?

Currently, because the system has some timing issue (cause of which I do not know), the system was not able to access the actual physical desktop directory (not on the root disk) and is now showing the /home/user directory as the Desktop (and consequently showing all files at that level as desktop icons, and substituting the system default wallpaper instead of that previously defined thru the system control center applets for tweaking UbuntuMATE). It is now always booting to this state since the 'event' and don't know how to correct without doing a reinstall of the OS, which I want to avoid. Even comparing to backups, I am unable to identify which file is the file which cause a "toggle" to behave the way it is now behaving.

Presumably, the 'unit' would be the one where fstab contents are processed and must take effect for all partitions before proceeding. I event changed the last field in fstab to 0 (no fsck) without any beneficial effect.

Please assist.

Desktop: MATE 1.24.0
Distro: Ubuntu 20.04.2 LTS (Focal Fossa)
Kernel: 5.4.0-67-generic x86_64

Cross-reference to different approach to the same problem.

  • Wouldn't be enough to add your mountpoint unit in Wants/After option of you display-manager unit? Eg. add DB001_F2.mount into After line of your GUI unit with systemctl edit <gui_unit>. – Jiri B Mar 25 '21 at 21:22
  • As mentionned in the cross-reference, I attempted that, but that had no "corrective" impact. It may have preventive impact on a system which has not yet encountered the problem (noted for future distro installs) but it did not fix my problem. – Eric Marceau Mar 28 '21 at 21:25

1 Answers1

0

Full documentation for the solution to this problem is outlined in the answer to restated problem here .