Pc-sysconfig et al


So trying to poke around because of the “Wrong time after resume” topic, I started at Lumina source code, “grep -ir suspend *” to see what happens when you click suspend. That is calling pc-sysconfig with a few different args, ok what does man pc-sysconfig or pc-sysconfig --help tell me? “manpage not found”. Hmm. Go over to github and see if there is a source tree for pc-sysconfig. I couldn’t find one under trueos GIT repos.

Looks like a few other “pc-” over in /usr/local/bin don’t have man pages, some will work (pc-updatemanager gives you Usage).

So, basically, is source for pc-sysconfig available or is it “secret sauce” for the project? How about manpages for other “pc-” utils? Are they meant strictly as backends for other tools, perhaps to be retired at some point?

System is up to date with the last EDGE release.



There are multiple search fields at https://github.com/trueos one of which can lead to, for example:

From https://github.com/trueos/trueos-docs/issues/21#issuecomment-268047278:

… writing manpages for pc-updatemanager and other TrueOS command line utilities. These pages (when ready) will be referenced in their respective utilities’ handbooks and subsections, but will not be fully reproduced in the handbooks.

more recently known as UNSTABLE ;-)


Thanks. I should include “go search issues on github” in my list of things to do. I’ve found stuff online in TrueOS handbook about things like pc-sysconfig, so I “assumed” man pages would be there. Chicken/Egg, Horse/Cart ordering issues.
Now if one wanted to give a whack at man pages for pc-sysconfig, what git repo should one fork?

And I guess I should remove the Custom setting in sysadm and point it back at STABLE or UNSTABLE.


@mer I expect this tool to be depricated in the coming weeks. We can replace it with automatic mounting using devd. I am working out the logistics for integration.

New autofs mounting

Good enough. I was trying to “scratch the itch” by looking at code, if the tool is deprecated, I’m done scratching.


Thanks, and please include a GUI to temporarily disable automation. A preference in the mount tray, I guess.


@mer I have just been thinking maybe it made more sense to put automounting more into the hands of devd. If you can simplify pc-sysconfig I am all for it. I have been modifying this program locally. https://github.com/pkgdemon/automount. For further reading https://www.freebsd.org/doc/handbook/usb-disks.html


@grahamperrin Another thought maybe mounttray is still the notifier, and can control global, or per device automounting, shortcut to opening media?


@grahamperrin Also I have came up with a few methods locally to make it exclude trueos efi partitions from being shown as mountable devices by blacklisting the specific glabel. Would that make sense to do? Would it make sense to also blacklist any kind of additional persona devices from being automounted, or detected by mounttay, and automounter?


Thanks for asking, those sound OK to me. Neither too simple nor too complex a set of features.

Plain English, I’d probably call it Storage tray.

A future version might default to not listing slices/partitions that are not likely to contain user data – EF00 (EFI System Partition) and so on. Plus allowance for the user to prefer an ovverride of that default.

Management e.g. creating and deleting slices and file systems should remain in a discrete application; windowed (as legacy Disk Manager is).

Nothing more comes to mind at the moment. (I began proper testing of mount tray only a few days ago.)


Storage tray is a good name change I think. Or we could consider moving mounting notications to sysadm? Controlling devd automounting settings, autofs mounting, and fstab settings in a sysadm pane?


Envisaging a future de luxe approach, then rewinding some distance …

Storage is for files.

If all file system related tasks can be performed with a capable file manager (e.g. Insight), then there remains just one essential role that can/should be played by an icon in ever-present tray:

  • encourage graceful disconnection from media (drives on USB, SMB/CIFS file servers and so on).

The ideal icon for that will be eject:

That oblique answer :slight_smile: should help folks to think about the value and necessity of each type of notification.

For example: if files simply become available when I connect a drive, then I need not be notified. Certainly not with an on-screen dialogue. One of three things should follow:

  • I bring my preferred file manager to the front
  • the OS brings a file manager to the front
  • nothing.

The preference for nothing to happen should be controllable in a pane of SysAdm.


I really like the idea of changing to the eject icon. Should we just umount all detachable devices when that happens, or continue to present the list of mounted devices? Or should we list devices with right click, and umount all of /media with left click?


I suggest:

  • just one type of click
  • a menu of things that can be ejected
  • within that menu, an eject icon to the left of the (user-friendliest) name of each thing.

To the left of each thing, so that if there’s more than one thing: there’ll be a tidy, straight column of two or more eject icons.

More contentiously:

  • refrain from detailed device-specific icons.

An optical disc icon is meaningful only if there truly is an optical drive, and so on.

There’s the temptation to distinguish, with icons, between local and remote storage but it could be interesting to see how an Eject feature appears at its cleanest.

If a thing can not be ejected then a traditional modal dialogue will be ideal. De luxe might offer to open a terminal window with a suitably filtered list of open files.


@grahamperrin Let me know what you think of this idea…

When media is detected show an eject icon.
Maybe close the tray, and present nothing at all when media is not detected?
When left, or right clicking the eject icon show the list of devices.
Display media labels as we display them now.
To the left of each media label show a tiny eject icon in place of the large media icon. This would make the eject icon, media label, browse, or initialize buttons display on a single line.

To the right of each media label replace mount with:

“Browse” Which would only appear, and open the default file manager in the case of readable filesystems

“Initialize” Which would only appear, and open disk manager in the case of non optical, unmountable media.

Remove the autorun checkboxes.


Yes and no. Yes to a neat, tidy fit.

No because (kicking the ball around here) an eject menu is simply not the place for any action that is not eject.

Storage aside, for a few minutes …

Consider the power menu, status bar and United States flag at the display manager screen (Ken, please note that I’m not singling out PCDM for unfair attention – I recall your recent reflective writing about the design history). DPI is unrelated to power; it’s not a status bar, but its position causes it to appear as such; the US status does not match my UK preferences; and so on. Essentially:

  • if there is (or might be, in the future) uncertainty about what range of purposes a thing will serve, then simply use a written word or phrase to label that thing (avoid icons that will be ambiguous or misfitting).

Back to the Eject menu concept

I might eject a storage device, or click eject to disconnect from a file server.

Eject a checkbox? Nah. No such thing.

You’re right, Joe, autorun preferences can be kept away from an eject menu. Offer them in SysAdm, I guess.


@grahamperrin I like where this brainstorming is going. We could look for mounted media in /net, or /media from autofs. When media is detected show the eject icon. As you say click the icon, and have a second mini eject button (icon) next to each media label. Each one per line.

Now how do we expose the mounted media to show the user where it is so they can open it? Do we simply have icons in lumina-fm next to home for /media, and /net?


@grahamperrin Maybe the media label could be clickable, and that opens Lumina-fm to the correct location? I kind of see your point though about the eject button not doing anything but eject.


Given the suggested feature cull, I’m surprised that no-one has cried “POLA” …

I might guess why you’d like that – and (yes) when I wander away from the computer and think about enhancements to mount tray (or whatever it might be called), I do think of handy features that might be retained or added.

Mind wandering, I mistakenly think of the tray in isolation.

Of course it’s not a cull, not even when (above) “nothing” is an option.


Allow a handful of things, including The File Manager and SysAdm, to reign supreme! Make 'em great.

Ensure timely, concise orientation for each user of a system (this overlaps with a separate topic).

Food for thought

as seen in post 4 under Can’t browse network mounts.

If I recall correctly, remote:/ is (in Dolphin) a predefined place, a holder for three classes of remote place. I haven’t toyed with those places in a working environment but at a glance, they make sense.

In the screenshot below:

  • the /media/ place was made by me
  • a sidebar predefined Devices heading, which I ignore.

(The 100 MiB hard drive is not a drive, it’s probably the EFI slice of the internal drive. And that list of devices seems to omit devices such as the USB flash drive that’s currently present (with no mounted file system), so I’ll continue to ignore the heading.)


@grahamperrin I was thinking /net would be our answer for remote. Rather than rely on a 3rd party technology like gvfs we could just extend the functionality of what was included in FreeBSD. Show discovered devices, support authentication, and so on.

Ok I have another idea. Expose the mounted media on the desktop as a either an optical media icon, or USB storage icon depending on which is mounted. Add the ability to right click the icon to unmount from the desktop. Then remove the mounttray / eject button idea altogether? I was trying to come up with something simple to replace mounttray now while pursuing lumina-fm enhancements, and redesign down the road.

Maybe then we could also use sysadm for the messaging. As you previously suggested for something else perhaps show up with red alert when media was detached improperly?