I'm trying to customize the firstboot process in CentOS 5 and have come across a few issues that are driving me nuts. I'm sure they are all upstream issues, but I don't have a RHEL 5 system to verify them. I had these customizations working in CentOS 4, but things that used to work then don't work now.
The main problem is that you can't validate user input. This problem can be easily seen in the firstboot "Create User" module. If you are in this screen, deliberately enter mismatched passwords. You will get a warning that the passwords do not match, but when you click OK to dismiss the warning you are taken to the next screen. In CentOS 4, firstboot would stay at the current screen until all user input had been validated. If you look at the underlying Python code, when you returned "None" from the apply method it would not exit the module in CentOS 4, but it does in CentOS 5.
I also can't get the firstboot Display module to load. It ships with "skipme = True", but setting it to false or removing that line altogether does not show the module. It appears to me that there a lots of issues with firstboot in CentOS 5. Actually, in my environment (~40 desktops), CentOS 5 has been far less stable than CentOS 4 (mostly Gnome issues with Terminal windows crashing and window "flickering"). I've reported some of these issues before on this list. My servers seem to be rock stable, though.
Anyway, for now I will have to live with these issues. Can I report these issues in the Red Hat bugzilla database or do I need to be a RHN subscriber to report bugs against RHEL5? I suspect (but have not verified) that these issues have been addressed in Fedora already.
Alfred
Yesterday I wrote:
I'm trying to customize the firstboot process in CentOS 5 and have come across a few issues that are driving me nuts. I'm sure they are all upstream issues, but I don't have a RHEL 5 system to verify them. I had these customizations working in CentOS 4, but things that used to work then don't work now.
The main problem is that you can't validate user input. This problem can be easily seen in the firstboot "Create User" module. If you are in this screen, deliberately enter mismatched passwords. You will get a warning that the passwords do not match, but when you click OK to dismiss the warning you are taken to the next screen. In CentOS 4, firstboot would stay at the current screen until all user input had been validated. If you look at the underlying Python code, when you returned "None" from the apply method it would not exit the module in CentOS 4, but it does in CentOS 5.
I also can't get the firstboot Display module to load. It ships with "skipme = True", but setting it to false or removing that line altogether does not show the module. It appears to me that there a lots of issues with firstboot in CentOS 5. Actually, in my environment (~40 desktops), CentOS 5 has been far less stable than CentOS 4 (mostly Gnome issues with Terminal windows crashing and window "flickering"). I've reported some of these issues before on this list. My servers seem to be rock stable, though.
Anyway, for now I will have to live with these issues. Can I report these issues in the Red Hat bugzilla database or do I need to be a RHN subscriber to report bugs against RHEL5? I suspect (but have not verified) that these issues have been addressed in Fedora already.
Has anyone seen these issues? Is anybody using firstboot (or care about it)? If there is there a better forum where I can go for firstboot questions, please let me know. Ideally, I would like the upstream provider to acknowledge this issue and include a fix in the next update release, but how can I best make that happen?
Alfred
Alfred von Campe wrote:
Has anyone seen these issues? Is anybody using firstboot (or care about it)? If there is there a better forum where I can go for firstboot questions, please let me know. Ideally, I would like the upstream provider to acknowledge this issue and include a fix in the next update release, but how can I best make that happen?
The easy way to do this would be to open an issue report at bugs.centos.org/ and someone can work with you to verify the bug exists. if it does then we can push it upstream. They are quite accepting of issues that come via some sort of a verification process ( they even have a direct link to the centos issue tracker! )
The easy way to do this would be to open an issue report at bugs.centos.org/ and someone can work with you to verify the bug exists.
Done: http://bugs.centos.org/view.php?id=3200
Thanks, Alfred
-
Alfred von Campe -
Karanbir Singh