@gjolly, I've taken a look at the 'Where problems could occur' section of the SRU template and I'm concerned about the risk of regression for users altering mount options for the root file system.
My concerns involve the root filesystem line alone. I think 'discard' is nice-to-have but not worth the risk of breaking users that alter the line via code. I'm not convinced we should change the error option from 'continue' to 'remount-ro' in an SRU either; first because it could break automation that users have to change the line and second it changes behavior for error handling that could break user assumptions of systems already in production should they deploy with a newly built image and they'll be unlikely to have image qualification tests that trigger an IO error. I recommend SRU'ing without the changes for the root filesystem. The change to the fstab line for the EFI file system pertains to a security improvement which I like to see. I think the risk is much lower that a user has automation changing mount options for this file system. The other risk is one of behavior. Will users have a non-root user accessing the EFI mountpoint and be broken by this change? Given the contents of the file system I don't believe it's unlikely most users would be accessing this directly. I believe the benefit from the change justifies the umask SRU. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1902103 Title: Ensure default fstab options are sane and consistent across all images To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-images/+bug/1902103/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
