Re: [gentoo-user] acct-user/man usermod: user 'man' does not exist in /etc/passwd
On Thursday, 11 April 2024 16:08:54 BST Dale wrote: > I don't recall editing this file ever. From my understanding, commands > are used to manage that file. I can't say for sure but it's doubtful I > edited that file. > > I can easily do a emerge -ek world if you think it would be wise to do > so. I guess that would reset ownership of files as it reinstalls. > Thoughts? > > Thanks. > > Dale > > :-) :-) I can't really advise what to do, it depends on your level of concern about this discrepancy with the 'man' account. The question to mull over is what could a rogue 'man' account have changed since your last full emerge @world? If you upgraded your profile from 17.1 to 23.0 recently you would have re- emerged @world, so all packages would have been reinstalled. If you run find to print recently changed files since the profile upgrade, you'll have some pointers for packages to emerge again. Or, with the 'man' account safely back in its box you can change passwds/keys and re-emerge the whole @world once more. If you are totally worried to the point of not being able to trust your system, then you'll need to reformat and start with a fresh stage3 download and fresh sources. Do not blindly copy all your configuration files from the backups, but diff them to make sure only changes you approve make it into the new system. This can be a lot of work, which you may not be inclined to embark on and could potentially be an overkill. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Getting WiFi to work
On Thursday, 11 April 2024 16:18:51 BST Michael wrote: > On Thursday, 11 April 2024 16:15:52 BST Peter Humphrey wrote: > > On Thursday, 11 April 2024 16:08:35 BST Michael wrote: > > > On Thursday, 11 April 2024 13:49:18 BST Peter Humphrey wrote: > > --->8 > > > > > > I decided to establish a firm, clean system to fall back to after > > > > messing > > > > about with the various wifi packages, so I built a fresh system > > > > building > > > > on the merged-usr stage-3. I was surprised to find that kde-plasma/ > > > > powerdevil now insists on installing Network Manager unless I set > > > > USE=- > > > > wireless against it. > > > > > > > > Why has this happened? Can't the poor power devil cope with any other > > > > way > > > > of running WiFi? > > > > > > The USE="wireless" flag on powerdevil is needed to save energy when the > > > bluetooth/wireless chip is idle. This function could be useful with > > > laptops running on battery. > > > > > > If you set USE="-networkmanager" in make.conf and USE="-wireless" for > > > the > > > powerdevil package you won't be bothered by this again. > > > > I already had USE="-networkmanager" in make.conf. > > > > This is not a laptop and it has no battery. Nowhere on the system is there > > any hint to the contrary, so I still think this has not been thought > > through. The logic should have included alternatives to Network Manager. > > Yes, I agree wholeheartedly. However, these decisions are taken upstream, > where there is a tendency of convergence to monoculture. Sorry, but I disagree with that last. The ebuild could have contained suitable logic, and it still could. -- Regards, Peter.
Re: [gentoo-user] Getting WiFi to work
On Thursday, 11 April 2024 16:15:52 BST Peter Humphrey wrote: > On Thursday, 11 April 2024 16:08:35 BST Michael wrote: > > On Thursday, 11 April 2024 13:49:18 BST Peter Humphrey wrote: > --->8 > > > > I decided to establish a firm, clean system to fall back to after > > > messing > > > about with the various wifi packages, so I built a fresh system building > > > on the merged-usr stage-3. I was surprised to find that kde-plasma/ > > > powerdevil now insists on installing Network Manager unless I set USE=- > > > wireless against it. > > > > > > Why has this happened? Can't the poor power devil cope with any other > > > way > > > of running WiFi? > > > > The USE="wireless" flag on powerdevil is needed to save energy when the > > bluetooth/wireless chip is idle. This function could be useful with > > laptops running on battery. > > > > If you set USE="-networkmanager" in make.conf and USE="-wireless" for the > > powerdevil package you won't be bothered by this again. > > I already had USE="-networkmanager" in make.conf. > > This is not a laptop and it has no battery. Nowhere on the system is there > any hint to the contrary, so I still think this has not been thought > through. The logic should have included alternatives to Network Manager. Yes, I agree wholeheartedly. However, these decisions are taken upstream, where there is a tendency of convergence to monoculture. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Getting WiFi to work
On Tuesday, 9 April 2024 15:56:28 BST Wojciech Kuzyszyn wrote: > I have never managed to get WiFi working with iwlwifi, but iwd works > great for me. Give it a try! I will - thanks! -- Regards, Peter.
Re: [gentoo-user] Getting WiFi to work
On Thursday, 11 April 2024 16:08:35 BST Michael wrote: > On Thursday, 11 April 2024 13:49:18 BST Peter Humphrey wrote: --->8 > > I decided to establish a firm, clean system to fall back to after messing > > about with the various wifi packages, so I built a fresh system building > > on the merged-usr stage-3. I was surprised to find that kde-plasma/ > > powerdevil now insists on installing Network Manager unless I set USE=- > > wireless against it. > > > > Why has this happened? Can't the poor power devil cope with any other way > > of running WiFi? > > The USE="wireless" flag on powerdevil is needed to save energy when the > bluetooth/wireless chip is idle. This function could be useful with laptops > running on battery. > > If you set USE="-networkmanager" in make.conf and USE="-wireless" for the > powerdevil package you won't be bothered by this again. I already had USE="-networkmanager" in make.conf. This is not a laptop and it has no battery. Nowhere on the system is there any hint to the contrary, so I still think this has not been thought through. The logic should have included alternatives to Network Manager. -- Regards, Peter.
Re: [gentoo-user] Getting WiFi to work
On Thursday, 11 April 2024 13:49:18 BST Peter Humphrey wrote: > On Tuesday, 9 April 2024 14:44:05 BST Paul Sopka wrote: > > On 09.04.24 15:23, Peter Humphrey wrote: > > > Hello list, > > > > > > I want to move my Intel i5 NUC box to a place where Ethernet is not > > > available, nor like to become so. That means I have to get WiFi working, > > > but I've had no success so far. The wiki pages are many, confusing and > > > contradictory, so I'd like the panel's advice on the way to proceed. > > > > > > The first thing I tried was the traditional wpa_supplicant, which seemed > > > to go well - except that I couldn't get the link out of the DOWN state. > > > > > > Then I tried NetworkManager, and failed with that too. > > > > > > This is the hardware: > > > # lspci -v -s 00:14.3 > > > 00:14.3 Network controller: Intel Corporation Raptor Lake PCH CNVi WiFi > > > (rev 01) > > > --->8 > > > > > > Kernel driver in use: iwlwifi > > > Kernel modules: iwlwifi > > > > > > And this is dmesg: > > > > > > $ dmesg | grep -i wifi > > > [1.622343] Intel(R) Wireless WiFi driver for Linux > > > [1.622432] iwlwifi :00:14.3: enabling device ( -> 0002) > > > [1.625069] iwlwifi :00:14.3: Detected crf-id 0x400410, cnv-id > > > 0x80400 wfpm id 0x8020 > > > [1.625121] iwlwifi :00:14.3: PCI dev 51f1/0094, rev=0x370, > > > rfid=0x2010d000 > > > [1.625313] Loading firmware: iwlwifi-so-a0-gf-a0-86.ucode > > > [1.626644] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: > > > 0.0.2.41 > > > [1.626902] iwlwifi :00:14.3: loaded firmware version > > > 86.fb5c9aeb.0 > > > so- a0-gf-a0-86.ucode op_mode iwlmvm > > > [1.643426] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6E AX211 > > > 160MHz, REV=0x370 > > > [1.651382] iwlwifi :00:14.3: WRT: Invalid buffer destination > > > [1.809375] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x20 > > > [1.809385] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f > > > [1.809394] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90 > > > [1.809401] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x0 > > > [1.809403] Loading firmware: iwlwifi-so-a0-gf-a0.pnvm > > > [1.810724] iwlwifi :00:14.3: loaded PNVM version e28bb9d7 > > > [1.810817] iwlwifi :00:14.3: RFIm is deactivated, reason = 4 > > > [1.825831] iwlwifi :00:14.3: Detected RF GF, rfid=0x2010d000 > > > [1.897387] iwlwifi :00:14.3: base HW address: f4:6d:3f:2a:33:3e > > > > > > Would net-wireless/iwd get me a bit further? > > > > > > Meanwhile, I'll keep on exploring with the results of sys-apps/hw-probe. > > > > Hey Peter > > > > This might be the wrong firmware being loaded. > > > > Are you building your the iwlwifi driver not as a module but directly > > into the kernel? > > > > Are you including your firmware into the kernel? > > > > If you do the above, try loading the driver as a module. Also enable > > both DVM and MVM Firmware support. > > > > Then emerge sys-kernel/linux-firmware without USE=savedconfig. > > > > Finally reboot and check wther it works. If it works, check which > > firmware is loaded in your dmesg. > > I decided to establish a firm, clean system to fall back to after messing > about with the various wifi packages, so I built a fresh system building on > the merged-usr stage-3. I was surprised to find that kde-plasma/powerdevil > now insists on installing Network Manager unless I set USE=-wireless > against it. > > Why has this happened? Can't the poor power devil cope with any other way of > running WiFi? The USE="wireless" flag on powerdevil is needed to save energy when the bluetooth/wireless chip is idle. This function could be useful with laptops running on battery. If you set USE="-networkmanager" in make.conf and USE="-wireless" for the powerdevil package you won't be bothered by this again. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] acct-user/man usermod: user 'man' does not exist in /etc/passwd
Michael wrote: > On Thursday, 11 April 2024 12:58:17 BST Dale wrote: >> Michael wrote: >>> On Thursday, 11 April 2024 10:22:59 BST Dale wrote: I fixed it by commenting out the entry in the passwd file. It then created a new entry. I guess it was set wrong at some point. Just looks like emerge would be able to update it tho. Joost showing my setting was different gave me the clue that my current entry was wrong. I was kinda chicken to comment it out or remove it before then. ;-) Dale :-) :-) >>> It begs the question who/what could have changed the root group membership >>> to include the system account 'man'. This is highly irregular. Have you >>> looked at your backups to find out when /etc/group was changed last time? >>> Also emerge.log to find the last time acct-user/man was installed >>> successfully before this error started occurring. >> Well, this has been failing for a while. It's just that with the >> profile change, I wanted to re-emerge all packages. I'm sure this one >> hasn't really changed or anything but still, I wanted a clean start. >> >> My OS backup updates each week. So, backups is far to up to date to >> know. It's what I use to build the binary packages in. I also >> sometimes experiment as well when some package is giving me grief. I >> mostly just use the -k option on my main OS. >> >> I looked in /usr/share/man, I guess that is where most if not all man >> pages are, and they all appear to be owned by root and group is root. >> Should they be owned by man? If possible, can you post the owner and >> group for yours? I can change mine. I tested a few man pages, they all >> post fine but I'm usually root anyway. Works for user dale to tho. >> >> Thanks. >> >> Dale >> >> :-) :-) > The /usr/share/man directory and man pages within it are owned by root:root; > e.g. > > # ls -al /usr/share/man/man8/agetty.8.bz2 > -rw-r--r-- 1 root root 7307 Apr 4 10:46 /usr/share/man/man8/agetty.8.bz2 > > The problem in your case was the system account 'man' had been added to group > 'root'. This creates a privilege escalation and as such it is suspicious. > Had you done this by accident and now you corrected it, then hopefully you do > not need to be unduly worried. Had someone else done this ... then this > should be setting off alarm bells. I don't recall editing this file ever. From my understanding, commands are used to manage that file. I can't say for sure but it's doubtful I edited that file. I can easily do a emerge -ek world if you think it would be wise to do so. I guess that would reset ownership of files as it reinstalls. Thoughts? Thanks. Dale :-) :-)
Re: [gentoo-user] acct-user/man usermod: user 'man' does not exist in /etc/passwd
On Thursday, 11 April 2024 12:58:17 BST Dale wrote: > Michael wrote: > > On Thursday, 11 April 2024 10:22:59 BST Dale wrote: > >> I fixed it by commenting out the entry in the passwd file. It then > >> created a new entry. I guess it was set wrong at some point. Just > >> looks like emerge would be able to update it tho. Joost showing my > >> setting was different gave me the clue that my current entry was wrong. > >> I was kinda chicken to comment it out or remove it before then. ;-) > >> > >> Dale > >> > >> :-) :-) > > > > It begs the question who/what could have changed the root group membership > > to include the system account 'man'. This is highly irregular. Have you > > looked at your backups to find out when /etc/group was changed last time? > > Also emerge.log to find the last time acct-user/man was installed > > successfully before this error started occurring. > > Well, this has been failing for a while. It's just that with the > profile change, I wanted to re-emerge all packages. I'm sure this one > hasn't really changed or anything but still, I wanted a clean start. > > My OS backup updates each week. So, backups is far to up to date to > know. It's what I use to build the binary packages in. I also > sometimes experiment as well when some package is giving me grief. I > mostly just use the -k option on my main OS. > > I looked in /usr/share/man, I guess that is where most if not all man > pages are, and they all appear to be owned by root and group is root. > Should they be owned by man? If possible, can you post the owner and > group for yours? I can change mine. I tested a few man pages, they all > post fine but I'm usually root anyway. Works for user dale to tho. > > Thanks. > > Dale > > :-) :-) The /usr/share/man directory and man pages within it are owned by root:root; e.g. # ls -al /usr/share/man/man8/agetty.8.bz2 -rw-r--r-- 1 root root 7307 Apr 4 10:46 /usr/share/man/man8/agetty.8.bz2 The problem in your case was the system account 'man' had been added to group 'root'. This creates a privilege escalation and as such it is suspicious. Had you done this by accident and now you corrected it, then hopefully you do not need to be unduly worried. Had someone else done this ... then this should be setting off alarm bells. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Getting WiFi to work
On Tuesday, 9 April 2024 14:44:05 BST Paul Sopka wrote: > On 09.04.24 15:23, Peter Humphrey wrote: > > Hello list, > > > > I want to move my Intel i5 NUC box to a place where Ethernet is not > > available, nor like to become so. That means I have to get WiFi working, > > but I've had no success so far. The wiki pages are many, confusing and > > contradictory, so I'd like the panel's advice on the way to proceed. > > > > The first thing I tried was the traditional wpa_supplicant, which seemed > > to go well - except that I couldn't get the link out of the DOWN state. > > > > Then I tried NetworkManager, and failed with that too. > > > > This is the hardware: > > # lspci -v -s 00:14.3 > > 00:14.3 Network controller: Intel Corporation Raptor Lake PCH CNVi WiFi > > (rev 01) > > --->8 > > > > Kernel driver in use: iwlwifi > > Kernel modules: iwlwifi > > > > And this is dmesg: > > > > $ dmesg | grep -i wifi > > [1.622343] Intel(R) Wireless WiFi driver for Linux > > [1.622432] iwlwifi :00:14.3: enabling device ( -> 0002) > > [1.625069] iwlwifi :00:14.3: Detected crf-id 0x400410, cnv-id > > 0x80400 wfpm id 0x8020 > > [1.625121] iwlwifi :00:14.3: PCI dev 51f1/0094, rev=0x370, > > rfid=0x2010d000 > > [1.625313] Loading firmware: iwlwifi-so-a0-gf-a0-86.ucode > > [1.626644] iwlwifi :00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: > > 0.0.2.41 > > [1.626902] iwlwifi :00:14.3: loaded firmware version 86.fb5c9aeb.0 > > so- a0-gf-a0-86.ucode op_mode iwlmvm > > [1.643426] iwlwifi :00:14.3: Detected Intel(R) Wi-Fi 6E AX211 > > 160MHz, REV=0x370 > > [1.651382] iwlwifi :00:14.3: WRT: Invalid buffer destination > > [1.809375] iwlwifi :00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x20 > > [1.809385] iwlwifi :00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f > > [1.809394] iwlwifi :00:14.3: WFPM_AUTH_KEY_0: 0x90 > > [1.809401] iwlwifi :00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x0 > > [1.809403] Loading firmware: iwlwifi-so-a0-gf-a0.pnvm > > [1.810724] iwlwifi :00:14.3: loaded PNVM version e28bb9d7 > > [1.810817] iwlwifi :00:14.3: RFIm is deactivated, reason = 4 > > [1.825831] iwlwifi :00:14.3: Detected RF GF, rfid=0x2010d000 > > [1.897387] iwlwifi :00:14.3: base HW address: f4:6d:3f:2a:33:3e > > > > Would net-wireless/iwd get me a bit further? > > > > Meanwhile, I'll keep on exploring with the results of sys-apps/hw-probe. > > Hey Peter > > This might be the wrong firmware being loaded. > > Are you building your the iwlwifi driver not as a module but directly > into the kernel? > > Are you including your firmware into the kernel? > > If you do the above, try loading the driver as a module. Also enable > both DVM and MVM Firmware support. > > Then emerge sys-kernel/linux-firmware without USE=savedconfig. > > Finally reboot and check wther it works. If it works, check which > firmware is loaded in your dmesg. I decided to establish a firm, clean system to fall back to after messing about with the various wifi packages, so I built a fresh system building on the merged-usr stage-3. I was surprised to find that kde-plasma/powerdevil now insists on installing Network Manager unless I set USE=-wireless against it. Why has this happened? Can't the poor power devil cope with any other way of running WiFi? -- Regards, Peter.
Re: [gentoo-user] acct-user/man usermod: user 'man' does not exist in /etc/passwd
Michael wrote: > On Thursday, 11 April 2024 10:22:59 BST Dale wrote: > >> I fixed it by commenting out the entry in the passwd file. It then >> created a new entry. I guess it was set wrong at some point. Just >> looks like emerge would be able to update it tho. Joost showing my >> setting was different gave me the clue that my current entry was wrong. >> I was kinda chicken to comment it out or remove it before then. ;-) >> >> Dale >> >> :-) :-) > It begs the question who/what could have changed the root group membership to > include the system account 'man'. This is highly irregular. Have you looked > at your backups to find out when /etc/group was changed last time? Also > emerge.log to find the last time acct-user/man was installed successfully > before this error started occurring. Well, this has been failing for a while. It's just that with the profile change, I wanted to re-emerge all packages. I'm sure this one hasn't really changed or anything but still, I wanted a clean start. My OS backup updates each week. So, backups is far to up to date to know. It's what I use to build the binary packages in. I also sometimes experiment as well when some package is giving me grief. I mostly just use the -k option on my main OS. I looked in /usr/share/man, I guess that is where most if not all man pages are, and they all appear to be owned by root and group is root. Should they be owned by man? If possible, can you post the owner and group for yours? I can change mine. I tested a few man pages, they all post fine but I'm usually root anyway. Works for user dale to tho. Thanks. Dale :-) :-)
Re: [gentoo-user] How to find out all openrc dependencies?
On Thursday, 11 April 2024 10:48:15 BST J. Roeleveld wrote: > On Thursday, 11 April 2024 11:35:10 CEST Michael wrote: > > On Thursday, 11 April 2024 06:19:57 BST J. Roeleveld wrote: > > > Hi all, > > > > > > For a while I've been seeing the following ERROR-messages when booting 1 > > > of > > > my systems: > > > > > > * ERROR: cannot start multipathd as localmount would not start > > > > > > * ERROR: cannot start zfs-import as localmount would not start > > > > > > This isn't a big concern as these services will start correctly later: > > > > > > INIT: Entering runlevel: 3 > > > > > > * Starting multipathd ... > > > [ ok ] > > > * Importing ZFS pool(s) ... > > > [ ok ] > > > > > > But I am trying to find the cause of these errors as they are preventing > > > parallel-start from actually working correctly. > > > > > > When I check with "rc-depend", I don't see an obious cause: > > > > > > # /lib/rc/bin/rc-depend multipathd > > > sysfs devfs udev udev-trigger modules fsck root localmount multipathd > > > > > > # /lib/rc/bin/rc-depend localmount > > > sysfs devfs udev udev-trigger modules fsck root localmount > > > > > > # /lib/rc/bin/rc-depend zfs-import > > > multipath sysfs devfs udev udev-trigger modules fsck root localmount > > > multipathd zfs-import > > > > > > # /lib/rc/bin/rc-depend multipath > > > multipath > > > > > > From how I read these, it should be able to start "localmount" properly > > > before even trying to start "multipathd" and "zfs-import" > > > There is also no technical dependency for "localmount" (the root > > > filesystem > > > is not on ZFS on this system) > > > > > > Any help/suggestions on how to find the cause would be appreciated. > > > > > > -- > > > Joost > > > > Check if hwclock is in the boot runlevel: > > > > rc-update -s -v | grep hwclock > > What does "hwclock" got to do with this? > It has no dependency with multipathd, zfs-import, localmount or anything > else that is showing an error. > > -- > Joost Our systems are certainly different, but I noticed this dependency on my localmount which is missing on yours: # /lib/rc/bin/rc-depend localmount sysfs devfs udev udev-trigger hwclock modules fsck root dmcrypt localmount ^^^ Have you compared your system services which has this problem, with other systems of yours which can startup properly? signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] How to find out all openrc dependencies?
On Thursday, 11 April 2024 11:35:10 CEST Michael wrote: > On Thursday, 11 April 2024 06:19:57 BST J. Roeleveld wrote: > > Hi all, > > > > For a while I've been seeing the following ERROR-messages when booting 1 > > of > > my systems: > > > > * ERROR: cannot start multipathd as localmount would not start > > > > * ERROR: cannot start zfs-import as localmount would not start > > > > This isn't a big concern as these services will start correctly later: > > > > INIT: Entering runlevel: 3 > > > > * Starting multipathd ... > > [ ok ] > > * Importing ZFS pool(s) ... > > [ ok ] > > > > But I am trying to find the cause of these errors as they are preventing > > parallel-start from actually working correctly. > > > > When I check with "rc-depend", I don't see an obious cause: > > > > # /lib/rc/bin/rc-depend multipathd > > sysfs devfs udev udev-trigger modules fsck root localmount multipathd > > > > # /lib/rc/bin/rc-depend localmount > > sysfs devfs udev udev-trigger modules fsck root localmount > > > > # /lib/rc/bin/rc-depend zfs-import > > multipath sysfs devfs udev udev-trigger modules fsck root localmount > > multipathd zfs-import > > > > # /lib/rc/bin/rc-depend multipath > > multipath > > > > From how I read these, it should be able to start "localmount" properly > > before even trying to start "multipathd" and "zfs-import" > > There is also no technical dependency for "localmount" (the root > > filesystem > > is not on ZFS on this system) > > > > Any help/suggestions on how to find the cause would be appreciated. > > > > -- > > Joost > > Check if hwclock is in the boot runlevel: > > rc-update -s -v | grep hwclock What does "hwclock" got to do with this? It has no dependency with multipathd, zfs-import, localmount or anything else that is showing an error. -- Joost
Re: [gentoo-user] How to find out all openrc dependencies?
On Thursday, 11 April 2024 06:19:57 BST J. Roeleveld wrote: > Hi all, > > For a while I've been seeing the following ERROR-messages when booting 1 of > my systems: > > * ERROR: cannot start multipathd as localmount would not start > * ERROR: cannot start zfs-import as localmount would not start > > This isn't a big concern as these services will start correctly later: > > INIT: Entering runlevel: 3 > * Starting multipathd ... > [ ok ] > * Importing ZFS pool(s) ... > [ ok ] > > But I am trying to find the cause of these errors as they are preventing > parallel-start from actually working correctly. > > When I check with "rc-depend", I don't see an obious cause: > > # /lib/rc/bin/rc-depend multipathd > sysfs devfs udev udev-trigger modules fsck root localmount multipathd > > # /lib/rc/bin/rc-depend localmount > sysfs devfs udev udev-trigger modules fsck root localmount > > # /lib/rc/bin/rc-depend zfs-import > multipath sysfs devfs udev udev-trigger modules fsck root localmount > multipathd zfs-import > > # /lib/rc/bin/rc-depend multipath > multipath > > From how I read these, it should be able to start "localmount" properly > before even trying to start "multipathd" and "zfs-import" > There is also no technical dependency for "localmount" (the root filesystem > is not on ZFS on this system) > > Any help/suggestions on how to find the cause would be appreciated. > > -- > Joost Check if hwclock is in the boot runlevel: rc-update -s -v | grep hwclock signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] acct-user/man usermod: user 'man' does not exist in /etc/passwd
On Thursday, 11 April 2024 10:22:59 BST Dale wrote: > I fixed it by commenting out the entry in the passwd file. It then > created a new entry. I guess it was set wrong at some point. Just > looks like emerge would be able to update it tho. Joost showing my > setting was different gave me the clue that my current entry was wrong. > I was kinda chicken to comment it out or remove it before then. ;-) > > Dale > > :-) :-) It begs the question who/what could have changed the root group membership to include the system account 'man'. This is highly irregular. Have you looked at your backups to find out when /etc/group was changed last time? Also emerge.log to find the last time acct-user/man was installed successfully before this error started occurring. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] acct-user/man usermod: user 'man' does not exist in /etc/passwd
Michael wrote: > On Thursday, 11 April 2024 02:23:22 BST Dale wrote: >> Howdy, >> >> This failed once before but I didn't worry about it. However, since the >> profile update, it still fails. I'd like to figure out how to fix it. >> I tried doing a emerge -C and then emerging it again. No help. This is >> the output. It's not to long, whole thing. :-D > > Completed installing acct-user/man-1-r3 into >> /var/tmp/portage/acct-user/man-1-r3/image > OK, so far so good. :-) > > >> * Final size of build directory: 0 KiB >> * Final size of installed tree: 4 KiB >> >> ./ >> ./usr/ >> ./usr/lib/ >> ./usr/lib/sysusers.d/ >> ./usr/lib/sysusers.d/acct-user-man.conf >> > Done. >> * checking 1 files for package collisions >> > Merging acct-user/man-1-r3 to / >> error writing passwd entry: Invalid argument >> * User man already exists >> --- /usr/ >> --- /usr/lib/ >> --- /usr/lib/sysusers.d/ >> > /usr/lib/sysusers.d/acct-user-man.conf >> * Removing user man from group(s): root > What?! Group 'root' should only have user 'root' as its member: > > # grep root:x /etc/group > root:x:0:root > > >> * To retain the user's group membership in the local system >> * config, override with ACCT_USER_MAN_GROUPS or >> * ACCT_USER_MAN_GROUPS_ADD in make.conf. >> * Documentation reference: >> * >> https://wiki.gentoo.org/wiki/Practical_guide_to_the_GLEP_81_migration#Overri >> de_user_groups * Updating user man >> usermod: user 'man' does not exist in /etc/passwd > This is not right, unless you removed 'man' manually? > > # grep man /etc/passwd > man:x:13:15:System user; man:/dev/null:/sbin/nologin > > >> usermod: failed to unlock /etc/gshadow >> * usermod: user 'man' does not exist in /etc/passwd >> * usermod: failed to unlock /etc/gshadow > # stat /etc/passwd > File: /etc/passwd > Size: 1636 Blocks: 4 IO Block: 4096 regular file > Device: 259,2 Inode: 18587 Links: 1 > Access: (0644/-rw-r--r--) Uid: (0/root) Gid: (0/root) > > # stat /etc/shadow > File: /etc/shadow > Size: 815 Blocks: 2 IO Block: 4096 regular file > Device: 259,2 Inode: 18602 Links: 1 > Access: (0640/-rw-r-) Uid: (0/root) Gid: (0/root) > > # stat /etc/gshadow > File: /etc/gshadow > Size: 636 Blocks: 2 IO Block: 4096 regular file > Device: 259,2 Inode: 18562 Links: 1 > Access: (0400/-r) Uid: (0/root) Gid: (0/root) > > Check what yours look like, then try to correct them. It would be a good > idea > to fsck the partition too and check smartctl, in case you have fs corruption. I fixed it by commenting out the entry in the passwd file. It then created a new entry. I guess it was set wrong at some point. Just looks like emerge would be able to update it tho. Joost showing my setting was different gave me the clue that my current entry was wrong. I was kinda chicken to comment it out or remove it before then. ;-) Dale :-) :-)
Re: [gentoo-user] acct-user/man usermod: user 'man' does not exist in /etc/passwd
On Thursday, 11 April 2024 10:16:52 CEST Dale wrote: > J. Roeleveld wrote: > > On Thursday, 11 April 2024 03:23:22 CEST Dale wrote: > >> Howdy, > >> > >> This failed once before but I didn't worry about it. However, since the > >> profile update, it still fails. I'd like to figure out how to fix it. > >> I tried doing a emerge -C and then emerging it again. No help. This is > >> the output. It's not to long, whole thing. :-D > >> > >>>>> Failed to install acct-user/man-1-r3, Log file: > >>>>> '/var/log/portage/acct-user:man-1-r3:20240411-011746.log' > >>>>> > >>>>> Jobs: 0 of 1 complete, 1 failed Load avg: 2.12, > > > > > > > >> * FAILED postinst: 1 > >> * > >> * The following package has failed to build, install, or execute > >> postinst: > >> * > >> * (acct-user/man-1-r3:0/0::gentoo, ebuild scheduled for merge), Log > >> file: > >> * '/var/log/portage/acct-user:man-1-r3:20240411-011746.log' > >> * > >> > >> * GNU info directory index is up-to-date. > >> > >> (chroot) root@fireball / # > >> > >> > >> > >> Any ideas? It did install once long ago when the group and user thing > >> started. > >> > >> Ideas?? > > > > First idea, if "man" exists, check if it matches current systems. > > > > This is on a system less then 1 month old: > > > > $ id man > > uid=13(man) gid=15(man) groups=15(man) > > > > -- > > Joost > > Mine says: > > > root@fireball / # id man > uid=14357(man) gid=0(root) groups=0(root),15(man) > root@fireball / # > > > It doesn't match yours but it has something there. I'm surprised that > doing a emerge -C and then emerging it again didn't fix it but I guess > it adds something to those files but doesn't remove it when > uninstalled. So, I did some editing. The old line, I commented it > out. Then it emerged and added the new line. > > > man:x:13:15:System user; man:/dev/null:/sbin/nologin > #man:!:14357:0:9:7::: > > > With it set like that, it emerges. This is what the output of your > command looks like now. > > > root@fireball / # id man > uid=13(man) gid=15(man) groups=15(man) > root@fireball / # > > > Now it matches yours. > > Is this a bug or something? I don't tend to mess with that file > myself. :/ > > Dale > > :-) :-) You might have some files owned by an unknown user on your system now (especially man-pages?) Looking back at the original error message, it did complain about "man" being part of the "root" group. doing a usermod to remove that group would have worked as well. -- Joost
Re: [gentoo-user] acct-user/man usermod: user 'man' does not exist in /etc/passwd
J. Roeleveld wrote: > On Thursday, 11 April 2024 03:23:22 CEST Dale wrote: >> Howdy, >> >> This failed once before but I didn't worry about it. However, since the >> profile update, it still fails. I'd like to figure out how to fix it. >> I tried doing a emerge -C and then emerging it again. No help. This is >> the output. It's not to long, whole thing. :-D >> >>>>> Failed to install acct-user/man-1-r3, Log file: >>>>> '/var/log/portage/acct-user:man-1-r3:20240411-011746.log' >>>>> >>>>> Jobs: 0 of 1 complete, 1 failed Load avg: 2.12, > > >> * FAILED postinst: 1 >> * >> * The following package has failed to build, install, or execute postinst: >> * >> * (acct-user/man-1-r3:0/0::gentoo, ebuild scheduled for merge), Log file: >> * '/var/log/portage/acct-user:man-1-r3:20240411-011746.log' >> * >> >> * GNU info directory index is up-to-date. >> (chroot) root@fireball / # >> >> >> >> Any ideas? It did install once long ago when the group and user thing >> started. >> >> Ideas?? > First idea, if "man" exists, check if it matches current systems. > > This is on a system less then 1 month old: > > $ id man > uid=13(man) gid=15(man) groups=15(man) > > -- > Joost Mine says: root@fireball / # id man uid=14357(man) gid=0(root) groups=0(root),15(man) root@fireball / # It doesn't match yours but it has something there. I'm surprised that doing a emerge -C and then emerging it again didn't fix it but I guess it adds something to those files but doesn't remove it when uninstalled. So, I did some editing. The old line, I commented it out. Then it emerged and added the new line. man:x:13:15:System user; man:/dev/null:/sbin/nologin #man:!:14357:0:9:7::: With it set like that, it emerges. This is what the output of your command looks like now. root@fireball / # id man uid=13(man) gid=15(man) groups=15(man) root@fireball / # Now it matches yours. Is this a bug or something? I don't tend to mess with that file myself. :/ Dale :-) :-)
Re: [gentoo-user] acct-user/man usermod: user 'man' does not exist in /etc/passwd
On Thursday, 11 April 2024 02:23:22 BST Dale wrote: > Howdy, > > This failed once before but I didn't worry about it. However, since the > profile update, it still fails. I'd like to figure out how to fix it. > I tried doing a emerge -C and then emerging it again. No help. This is > the output. It's not to long, whole thing. :-D > >>> Completed installing acct-user/man-1-r3 into > > /var/tmp/portage/acct-user/man-1-r3/image OK, so far so good. :-) > * Final size of build directory: 0 KiB > * Final size of installed tree: 4 KiB > > ./ > ./usr/ > ./usr/lib/ > ./usr/lib/sysusers.d/ > ./usr/lib/sysusers.d/acct-user-man.conf > > >>> Done. > > * checking 1 files for package collisions > > >>> Merging acct-user/man-1-r3 to / > > error writing passwd entry: Invalid argument > * User man already exists > --- /usr/ > --- /usr/lib/ > --- /usr/lib/sysusers.d/ > > >>> /usr/lib/sysusers.d/acct-user-man.conf > > * Removing user man from group(s): root What?! Group 'root' should only have user 'root' as its member: # grep root:x /etc/group root:x:0:root > * To retain the user's group membership in the local system > * config, override with ACCT_USER_MAN_GROUPS or > * ACCT_USER_MAN_GROUPS_ADD in make.conf. > * Documentation reference: > * > https://wiki.gentoo.org/wiki/Practical_guide_to_the_GLEP_81_migration#Overri > de_user_groups * Updating user man > usermod: user 'man' does not exist in /etc/passwd This is not right, unless you removed 'man' manually? # grep man /etc/passwd man:x:13:15:System user; man:/dev/null:/sbin/nologin > usermod: failed to unlock /etc/gshadow > * usermod: user 'man' does not exist in /etc/passwd > * usermod: failed to unlock /etc/gshadow # stat /etc/passwd File: /etc/passwd Size: 1636Blocks: 4 IO Block: 4096 regular file Device: 259,2 Inode: 18587 Links: 1 Access: (0644/-rw-r--r--) Uid: (0/root) Gid: (0/root) # stat /etc/shadow File: /etc/shadow Size: 815 Blocks: 2 IO Block: 4096 regular file Device: 259,2 Inode: 18602 Links: 1 Access: (0640/-rw-r-) Uid: (0/root) Gid: (0/root) # stat /etc/gshadow File: /etc/gshadow Size: 636 Blocks: 2 IO Block: 4096 regular file Device: 259,2 Inode: 18562 Links: 1 Access: (0400/-r) Uid: (0/root) Gid: (0/root) Check what yours look like, then try to correct them. It would be a good idea to fsck the partition too and check smartctl, in case you have fs corruption. signature.asc Description: This is a digitally signed message part.
