Bug#712953: sysvinit: System Restarts Instead of Powering Off
On 09/03/2019 2:41 am, Ben Hutchings wrote: Control: tag -1 moreinfo On Fri, 21 Jun 2013 09:13:19 +0100 "Alan Chandler" < a...@chandlerfamily.org.uk> wrote: Package: sysvinit Version: 2.88dsf-41 Severity: normal Dear Maintainer, When I attempt to power off the machine (either logging out of gnome3, or via shutdown now typed in at a terminal) the system goes through the shutdown sequence (it does seem to pause after telling all processes to terminate and then reports that some processes are still running). It finally reports it is about to power off. But the computer then restarts and reboots. If I load up Debian Wheezy and shut that down, the computer powers off properly. Sorry this report took so long to get assigned properly. Is this still happening in a current Debian version? Ben. This was 6 years ago. I don't have the problem now. -- Alan Chandler http://www.chandlerfamily.org.uk
Processed: Re: sysvinit: System Restarts Instead of Powering Off
Processing control commands: > tag -1 moreinfo Bug #712953 [src:linux] sysvinit: System Restarts Instead of Powering Off Added tag(s) moreinfo. -- 712953: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712953 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#712953: sysvinit: System Restarts Instead of Powering Off
Control: tag -1 moreinfo On Fri, 21 Jun 2013 09:13:19 +0100 "Alan Chandler" < a...@chandlerfamily.org.uk> wrote: > Package: sysvinit > Version: 2.88dsf-41 > Severity: normal > > Dear Maintainer, > > When I attempt to power off the machine (either logging out of gnome3, or via > shutdown now typed in at a terminal) > the system goes through the shutdown sequence (it does seem to pause after > telling all processes to terminate and > then reports that some processes are still running). It finally reports it is > about to power off. > > But the computer then restarts and reboots. > > If I load up Debian Wheezy and shut that down, the computer powers off > properly. Sorry this report took so long to get assigned properly. Is this still happening in a current Debian version? Ben. -- Ben Hutchings Knowledge is power. France is bacon. signature.asc Description: This is a digitally signed message part
Bug#908216: btrfs blocked for more than 120 seconds
On Wed, Mar 06, 2019 at 07:55:45AM -0600, Russell Mosemann wrote: >The four most problematic servers were hanging nearly every day. They each >have a dedicated hard drive and are running 4.19.0-0.bpo.2-amd64. I >installed btrfs-progs 4.20.1 on each and recreated the file system on the >hard drive. There have been no issues since then, but it is too early to >tell. There are hardly any references or files on the drives. It might >take up to a month to know if there is an issue. > Thanks for reformatting with newer -progs; this eliminates the most difficult/impossible to reproduce factor. Which of the five rounds of tests from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908216#202 have you started with? It should be possible to accelerate triggering the bug by using the network to send additional VM images from each server to the test subject once a day. eg: if four servers send VM images to a fifth server then ideally (optimistically!) the bug would be triggered 80% faster, and if everything is still all clear after a month then you'd have at least 220 reflinked historical backups and five sparse copies of large VM images. Thank you for your work on making this bug reproducible. This not only accelerates its resolution (reproducible case in core functionality needs to be forwarded upstream), but also provides valuable data to inform our wiki's upcoming btrfs on buster (linux-4.19) recommendations. Cheers, Nicholas signature.asc Description: PGP signature
Bug#924051: nfs-common: Krb5 NFSv4 Realmd AD nfsidmap files owned by nobody group 4294967294
Package: nfs-common Version: 1:1.3.4-2.1 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Debian box joined to AD with Realmd. Mounted nfsv4 with kerberos auth. UID/GID match on client and server. File permissions honored by displayed incorrected. * What exactly did you do (or not do) that was effective (or ineffective)? The following was observed in /var/log/syslog on the client: nss_getpwnam: name 'us...@xx.xx.edu@XX.XX.EDU' domain 'XX.XX.EDU': resulting localname '(null)' uid and gid appear to not map properly from nfsidmap in a nfsv4 with sec=krb5. UID and GID are mapping properly on CentOS server and CentOS client. Ubuntu nfs client file permissions are honored, but display in `ls -lan` command are incorrect. --- $ cat /var/log/syslog |grep nfsidmap Mar 8 16:38:34 ubuntuclient nfsidmap[24736]: key: 0x24a1c64d type: uid value: us...@xx.xx.edu@XX.XX.EDU timeout 600 Mar 8 16:38:34 client nfsidmap[24736]: nfs4_name_to_uid: calling nsswitch->name_to_uid Mar 8 16:38:34 client nfsidmap[24736]: nss_getpwnam: name 'us...@xx.xx.edu@XX.XX.EDU' domain 'XX.XX.EDU': resulting localname '(null)' Mar 8 16:38:34 client nfsidmap[24736]: nss_getpwnam: name 'us...@xx.xx.edu@XX.XX.EDU' does not map into domain 'XX.XX.EDU' Mar 8 16:38:34 client nfsidmap[24736]: nfs4_name_to_uid: nsswitch->name_to_uid returned -22 Mar 8 16:38:34 client nfsidmap[24736]: nfs4_name_to_uid: final return value is -22 Mar 8 16:38:34 client nfsidmap[24736]: nfs4_name_to_uid: calling nsswitch->name_to_uid $ $ mount -v -t nfs4 -o sec=krb5 SP19SRV.XX.XX.EDU:/export /mnt $ su userX $ ls -la /mnt total 4 drwxr-xr-x 5 nobody 4294967294 50 Feb 28 18:04 . drwxr-xr-x 24 root root 4096 Mar 7 22:34 .. drwxr-xr-x 2 nobody 4294967294 125 Mar 8 16:27 userX $ Problem: nfsmapid isn't showing proper file permissions on the ubuntu nfsv4 client with sec=krb Client: --- mount -v -t nfs4 -o sec=krb5 SP19SRV.XX.XX.EDU:/export /mnt --- $ ls -la total 4 drwxr-xr-x 5 nobody 4294967294 50 Feb 28 18:04 . drwxr-xr-x 24 root root 4096 Mar 7 20:58 .. drwxr-xr-x 2 nobody 4294967294 112 Mar 7 14:30 username usern...@xx.xx.edu@ubuntuclient:/mnt --- $ cat /etc/idmapd.conf [General] Verbosity = 9 Pipefs-Directory = /run/rpc_pipefs # set your own domain here, if it differs from FQDN minus hostname Domain = XX.XXX.EDU [Mapping] Nobody-User = nobody Nobody-Group = nogroup --- $ cat /etc/default/nfs-common STATDOPTS= NEED_GSSD="yes" NEED_IDMAPD="yes" # I've tried commenting out NEED_IDMAPD as well. # I manually created the following file with ktutil to just have nfs lines. RPCGSSDARGS="-k /etc/nfs.keytab" # I've tried with and without the above line (this was shown from redhat documentaiton) --- My nfs server is a Centos 7. Both machines were joined to active directory with sssd. NFSv4 with krb security works on my centos server and client. The nfs server mount works on the ubuntu client and file permissions are honored. But, the ls -la command is showing the incorrect file permissions. uid and gid's appear to be in sync from sssd. Note in /etc/sssd/sssd.conf ldap_id_mapping = False though I don't think that should matter since ids are the same on both client and server from the ldap attributes in AD. Centos 7 servers /var/log/messages with idmapd.conf verbosity: Mar 8 16:38:32 sp19srv rpc.idmapd[1224]: Server : (group) id "65534" -> name "nfsnob...@xx.xx.edu" Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfsdcb: authbuf=gss/krb5 authtype=user Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: calling nsswitch->uid_to_name Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: nsswitch->uid_to_name returned 0 Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: final return value is 0 Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: Server : (user) id "3872" -> name "us...@xx.xx.edu@XX.XX.EDU" Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfsdcb: authbuf=gss/krb5 authtype=group Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_gid_to_name: calling nsswitch->gid_to_name Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_gid_to_name: nsswitch->gid_to_name returned 0 Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_gid_to_name: final return value is 0 Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: Server : (group) id "110" -> name "some group g...@xx.xx.edu@XX.XX.EDU" Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfsdcb: authbuf=gss/krb5 authtype=user Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: calling nsswitch->uid_to_name Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: nsswitch->uid_to_name returned 0 Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_uid_to_name: final return value is 0 Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: Server : (user) id "0" -> name "r...@xx.xx.edu" Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfsdcb: authbuf=gss/krb5 authtype=group Mar 8 16:38:34 sp19srv rpc.idmapd[1224]: nfs4_gid_to_name: calling
Bug#923173: Fwd: Bug#923173: Acknowledgement (linux-image-4.9.0-8-amd64: Kernel Panic, HALT when detach-ing bcache)
I tested this for a few older kernels: linux-image-4.9.0-8-amd64: kernel panic linux-image-4.9.0-7-amd64: kernel panic linux-image-4.9.0-6-amd64: works fine linux-image-4.9.0-5-amd64: not tested linux-image-4.9.0-4-amd64: works fine
