Description of problem: Usually the first local user which is created on a new installed system has uid 1000 and gid 1000. This was possible for Fedora 28 and most previous releases. Now, if package openvswitch is installed, gid 1000 is already blocked by an account for a system service: hugetlbfs:x:1000:openvswitch I think it should be created as a system group. The error is in preinstall scriptlet. The following line getent group hugetlbfs >/dev/null || groupadd hugetlbfs should be changed to getent group hugetlbfs >/dev/null || groupadd -r hugetlbfs Version-Release number of selected component (if applicable): openvswitch-2.9.2-6.fc29.x86_64 How reproducible: Always Steps to Reproduce: 1. dnf install openvswitch 2. getent group hugetlbfs Actual results: Step 2: hugetlbfs:x:1000:openvswitch Expected results: Group with gid < 1000.
https://mail.openvswitch.org/pipermail/ovs-dev/2018-November/353662.html
Package openvswitch-2.10.0-3.fc29.x86_64 was build and released after comment #1, which has send a patch to upstream. But this package still contains the wrong code.
This will be resolved with Open vSwitch 2.11.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I had this bug In Fedora MATE 30 and hit this bug as well on a new installation on Fedora Mate 31 with openvswitch-2.12.0-1.fc31
This package was build and released several times since opening this bug report, but nobody has added " -r" to groupadd in the spec file.
Please Maintainers, can anyone tell me what is the problem why a VERY SIMPLE patch is not included? There is an open pull request since six months. Nobody cares! openvswitch was rebuild several times since then, but all builds still contains the same bug! openvswitch-2.13.0-1.fc32.x86_64 still contains the bug!
https://src.fedoraproject.org/rpms/openvswitch/pull-request/11
Anyone can help merging Pull Request from Edgar? Fedora 33 release images are going to be built soon, it 's a shame to carry that ug over to 33.
Merged - sorry for the delay.
(In reply to Aaron Conole from comment #10) > Merged - sorry for the delay. Thanks. Better late than never... So on Fedora 33 user accounts can start with uid and gid of 1000 again.
I have a fresh F33 installed. hugetlbfs is still on 1000 for me. Anyone know the manual steps for changing hugetlbfs's guid on an already running installation from 1000 down to the system guid range.
(In reply to Phil Wiggum from comment #12) > I have a fresh F33 installed. > hugetlbfs is still on 1000 for me. > > Anyone know the manual steps for changing hugetlbfs's guid on an already > running installation from 1000 down to the system guid range. According to my notes, the way to fix it is to start your computer from a live usb and edit the `/etc/group`file to have an entry like `hugetlbfs:x:975:openvswitch` Tings to keep in mind: - My current install (F33 Silverblue) doesn't have an entry for hugetlbfs so I may be missing something (I was on F31 Mate at the time). - You also want to fix the group id's of the user groups that you already have created. - I d suggest using a live usb to mount the files and change them rather than using the installation that the fixes will be applied on to avoid surprises. - After you make changes to new group ID' you will likely need to change group permissions on affected user files. - In my notes I instructed my self to do this right after installing Fedora, before booting the newly installed image for the first time. (My notes mention the path `/mnt/sysimage/etc/group`.) Since you have booted your installation there may be additional steps needed (or surprises lurking). - If I recall correctly the choice of 975 for group id was just an available number below 1000. You don't have to explicitly use that number, just something below 1000. Good Luck.
(In reply to Phil Wiggum from comment #12) > I have a fresh F33 installed. > hugetlbfs is still on 1000 for me. You should include repo "updates" during fresh Fedora installation. Then you don't get this error any more, because the package from updates doesn't contain the wrong instruction for group creation. > Anyone know the manual steps for changing hugetlbfs's guid on an already > running installation from 1000 down to the system guid range. The best would be to remove the package, remove the groups hugetlbfs and openvswitch, and install the package and all previously unstalled as dependeny again. openvswitch should not be running. dnf remove openvswitch groupdel hugetlbfs groupdel openvswitch dnf install openvswitch NetworkManager-ovs (NetworkManager-ovs was removed as dependency on my machine, too.) I'm not sure if there are any files owned by group hugetlbfs. If so, you need to change it manually (using chgrp). Don't edit /etc/group manually if there are commands for this case. Use groupadd, groupmod, groupdel to modify /etc/group. You don't need to boot a live system from usb, just be sure that there are no processes using this group (this is guaranteed by a live system, sure, because it hat it's own root filesystem).
This bug is fixed in Fedora 33 with updates, e.g. at least openvswitch-2.15.0-1.fc33.x86_64 . This bug is also fixed in Fedora 34.
Hi, Did everything described above in the 'rescue' option in the boot menu option. Good it's fixed in F34 Thanks!