Permanent fstab entries (and possibly more)

[KaruroChori]

fstab is currently not safe for reinstall (as in, gets wiped) but adding a mount should not be too much of an issue I guess. You can also use the usb overlay (see install.md when finished).

Originally posted by @consp in #45 (comment)

Find the best way to keep some local configuration persistent when upgrading the image, like for /etc/fstab. Ideally an option to decide if patches should be applied post-upgrade, or if the user wants a clean install.

[KaruroChori]

Instances of default configuration vs patched local one to be addressed (for some a partial solution might have been already implemented):

• users/groups
• fstab entries
• printer.cfg. It is nice to have defaults but the calibration on the local machine should not be overwritten.
• wifi/lan configuration. It is nice to provide a hotspot mode as default, but local changes should be not overwritten if present.

[xblax]

IMHO that is all already solved, if you carefully read the the Install docs :)

You just put a klipper_mod/etc/fstab file on your USB drive and every time you update/install the mod that overrides the default one.

The files that are preserved within the mod itself (automatically), that is only really intended for more for some special cases (they are listed in the install docs). Network settings are already included.

I don't see a purpose for a Hotspot mode, just makes things to complicated. WiFi can be configured as needed before the install already.

[KaruroChori]

IMHO that is all already solved, if you carefully read the the Install docs :)

I have, I just consider this approach functional but not ideal.
For example, when I update a debian based system, if config files are to be overwritten, a choice is given, and there is a chance to open a resolution shell to check the status.
And in general config files are structured in such a way that often the base configuration and the user configuration are split, so that these events are less frequent.

Manually patching the installation, requiring the user to manually retrieve files from the printer to save them is not exactly ergonomic.

I don't see a purpose for a Hotspot mode, just makes things to complicated.

Was it not the default behaviour of the original firmware?

[consp]

Was it not the default behaviour of the original firmware?

Not that I know of. Can't find it in the manual either.

[KaruroChori]

I still have no access to the hardware, and I just saw that option once before nuking the original image, never tested it. I was able to track it down on this video:
https://youtu.be/WO2FZ2MBw7I?t=528

Regardless, I am not suggesting we should replicate 1:1 the user experience provided by the original firmware, but some people might be using it since it is there.

[consp]

Ah, yea it's there (no you know how often I've used the stock firmware).

KlipperScreen does not support it. IWD does, and if a user really wants it I guess they can use the overlay to make it happen? Config files are persistent.

[KaruroChori]

Since the most promising UI proposal for this project would not support it regardless, I think you are right.

At the very least, this is a regression over the original firmware, so I would simply add a line or two making it explicit in the docs, and add a basic configuration file for reference.

[xblax]

For example, when I update a debian based system, if config files are to be overwritten, a choice is given, and there is a chance to open a resolution shell to check the status.

For some files, like the printer.cfg it probably makes sense to add them to the automatic persistence mechanism - because calibration data is different for each printer and locally generated. Maybe that mechanism could be extended to allow explicitly marking of additional files/folder to be preserved.

But in general I consider a printer with embedded Linux to be a different use case than a Linux desktop. I think it should rather be considered like a Docker container or automatically deployed server that can be deleted an reliably rebuilt from scratch if needed.

Re-building the system in a structured and automated way is the cleaner approach and easier to maintain - I think that should be encouraged rather than adding complex ways to preserve local changes, because that would probably never meet everyone requirements.

The klipper_mod dir is just the most simple method to have a clear separation between custom configs and the base system. It would also make sense to manage local configs in Git or to have an Ansible playbook (if someone runs a printer farm).

[KaruroChori]

Ok, I get your point.

So your suggested workflow would be something like:

• Do not make local changes on the actual printer. Consider the fs as immutable, except from few selected files or folder.
• Keep your modified files to be copied over in the klipper_mod folder, and reuse it across firmware revisions (as long as they do not conflict with important changes in the mainline versions. At that point there is some manual patching to perform.)

Ideally, by building my own klipper_mod folder I get my custom distribution.