Re: Re: instable X after upgrade to buster - X? firefox? liberoffice? screensaver? lxde?
Have it running for some days now without screensaver gimmick. Appears to be quite stable now. --
Re: Re: inconsistent Clipit cut paste with firefox, konsole, claws
That's what I do any time I set up a new debian box: $ cat /etc/vim/vimrc.local " restore classic console mouse handling " [wr] 2019-12-20 set mouse= set ttymouse= Just didn't remember it by heart when I wrote the mail. But I knew it was there, just had to look it up. I don't know why it got lost in the upgrade. regards Wolfgang
Re: Re: instable X after upgrade to buster - X? firefox? liberoffice? screensaver? lxde?
> You told us that you upgraded to Buster by accident: yes what I did: - btrfs subvol snap - apt-get upgrade - cat /etc/debian_version 10.2 - "OOPS" - google "debian versions" - btrfs subvol snap - apt-get dist-upgrade - Wolfgang
Re: inconsistent Clipit cut paste with firefox, konsole, claws
tried parcellite instead of clipit as clipboard manager. looks good so far. still trouble with vi, but I think that's teh old never ending story. --
Re: Re: instable X after upgrade to buster - X? firefox? liberoffice? screensaver? lxde?
> You told us that you upgraded to Buster by accident: yes what I did: - btrfs subvol snap - apt-get upgrade - cat /etc/debian_version 10.2 - "OOPS" - google "debian versions" - btrfs subvol snap - apt-get dist-upgrade - btw: does this message get sorted to the correct thread? should I add the header In-reply-to: How can I do this in claws?
inconsistent Clipit cut with firefox, konsole, claws
Hello, after upgrade from stretch to buster, my cut does not work as before any more. I run lxde, with clipboard manager Clipit 1.4.5 "using primary" and "syncing clipboards" is activated (not sure about the english labels, since I run german locale) Firefox: I cannot copy web adresses anymore by just selecting them, as I did before the update. I can however copy adresses by using ctl+C I can copy normal text from a webpage by just selecting it Konsole (18.04.0): sometimes I can copy text by just selecting it, sometimes I can't. claws mail: can't use bare X mouse clipboard any more, just CTL+C / CTL+V Is there any point where I can finetune this behaviour? Or at least understand it? Could I use another clipboard manager within lxde? - regards Wolfgang
Re: instable X after upgrade to buster - X? firefox? liberoffice? screensaver? lxde?
Is xscreensaver the culprit? Bugs reported here are similiar, but not exact the same https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891578 https://dirkmittler.homeip.net/blog/archives/5226 deinstalled xscreensaver, just resumed from black screen and had neither slow firefox nor x-crashes after openOffice-restore. will watch and report Wolfgang --
instable X after upgrade to buster - X? firefox? liberoffice? screensaver? lxde?
Hello, together, after trapped into upgrade from stretch to buster, I get (1) x server crashes after closing multiple libreOffice windows (2) inacceptable response times after resuming from screen saver Details for (1) After crash, libreOffice restores open documents and opens them all as stacked windows. I repeatedly click on the "minimize" button to clean up my desktop, and when I klick on the empty desktop after the last office window is gone, X server session terminates immediately and drops to login screen. I reproduced this three times. I could NOT reproduce it by clicking on the empty desktop without libreoffice restore cycle before Details for (2) After resuming from screen saver, response times to mouse and keyboard event increases to several seconds. It's even hard to work on a "Konsole" Killing firefox (using system console) and maybe some other medium to large applications alleviates the symptom. Restarting firefox in the same session immediately slows down again. I experienced similiar behaviour with lotus notes & wine. After reboot, performance is normal again. Feels like bad old WIN$ :-((( I have a similiar behaviour with firefox 68 on my old laptop running Windows7. So it might be related to firefox? Top shows Xorg using ~ 103 % CPU (on a AMD 4300 quad core) Mem is 16 GB and still ample free. == I don't know whether this problems are related. I also can't pin it down to some specific package. So I'll ask the list before filing a bug. May workstation was set up with KDE in jessie. Upgraded to stretch in early 2019 Forgot to set apt sources to release, so I ran into buster last week without having planned so. Anyway, seamless upgrade between releases ist a debian promise, right? currently using lxdm and lxde I struggled with the known bug of X not starting after upgrade. During fixing, I tried different display manager and desktops (Gnome, KDE) dual screen VGA compatible controller: NVIDIA Corporation G92 [GeForce 9800 GT] (rev a2) lsmod: I think current driver is nouveau. dpkg: xserver-xorg-video-nouveau1:1.0.16-1 Anybody else with similiar experience? Wolfgang
Lost in debian backport patch workflow
Hello, dear debian-Pros, can somebody point me to information how to figure out, understand and partially revert the patching process that finally leads to my currently running kernel: # uname -a Linux cruncher 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt4-3~bpo70+1 (2015-02-12) x86_64 GNU/Linux in order to apply a recent patch for a single kernel module (aufs) ist it - 3.16.0 - 3.16.7 - or maybe containing some patches from later kernel versions? Im trying to setup a cluster with some diskless clients, using aufs-layered nfsroot , exporting those by nfs. I ended up with this kernel (which is current wheezy stable backport) by solving trobule with dracut, idmapd nd dhcp-client, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778580 Now I have still some issues related to aufs layered file system , which is a kernel module. Following the kind support of aufs author J. R. Okajima, I'd try to switch to recent aufs version. I tried to reverse aufs patches from the kernel tree as applied from the version 3.16.0 and reapply patches from aufs 3.16...current. Building aufs module fails. From private conversation with the aufs author: Note that - there are three versions related to your case. + plain linux-3.16.0 + plain linux-3.16.7 + debianized 3.16.7-ckt4-3~bpo70+1 they are all different from each other. - all aufs releases are for vanilla kernels. i.e. linux-3.16.0 instead of 3.16.7. in many cases, aufs3.xx is appliable for linux-3.xx.yy. but sometimes the function signature is changed in yy versions. in this case, I will release aufs3.xx.yy. - although I don't look close, aufs3.16 seems to be appliable to 3.16.7. actually I succeeded it on debian 3.16.7-ckt2-1. So the changes made between debian 3.16.7-ckt2-1 and ckt4-3~bpo70+1 is the cause your compiler error. The error include/linux/kernel.h:834:27: error: =E2=80=98struct dentry=E2=80=99 has n= o member=20 named =E2=80=98d_alias=E2=80=99 is caused by the change in mainline v3.19. 679829c 2014-12-16 move d_rcu from overlapping d_child to overlapping d_alias And the commit is backported to v3.18.1 in linux-stable. I guess debian people has backported the commit into their ckt4-3~bpo70+1 (or ckt3) too. () The ideal solution will be - check what was changed by debian, ie. diff v3.16.7 3.16.7-ckt4-3 (usually it is a simple backport) - how can aufs follow it (usually it will be a simple backport too) - and test. () J. R. Okajima So, my problem boils down to this line: - check what was changed by debian, ie. diff v3.16.7 3.16.7-ckt4-3 How can I reconstruct these different kernel trees? Any help is greatly appreciated :-) Wolfgang Rosner -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201503031141.49539.wros...@tirnet.de
idmapd fails in dracut - nfsroot over nfsv4 with wrong UID
Hello, debianics, it sounds like an age old problem solved quite a lot of times, but I still can't get it to work. I try to set up a diskless cluster in beowulf style with nfsroot. Base is debian wheezy. short story: when I boot into nfsv4 root, I find weird file ownership drwxr-xr-x 2 4294967294 4294967294 4096 Feb 15 13:00 bin drwxr-xr-x 3 4294967294 4294967294 4096 Feb 15 15:15 boot drwxr-xr-x 17 root root 3240 Feb 15 15:38 dev drwxr-xr-x 115 4294967294 4294967294 4096 Feb 15 14:27 etc drwxr-xr-x 2 4294967294 4294967294 4096 Dec 24 13:41 home indicating that idmap demon is not working as it should. The only workaraound to get rid of the problem is to mount nfsroot as nfsv3 instad of nfsv4 - see here : http://www.linuxquestions.org/questions/linux-networking-3/does-pxe-booting-nfs-root-supports-nfsv4-925154/#post4583418 and here http://serverfault.com/questions/379486/netboot-debian-wheezy-from-nfs-v4 The symptoms are well known and reported repeatedly. However, I checked following underlying causes - none was reflecting my Situation: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724514 http://layer-acht.org/fai-irc/fai.log.20120613 https://kernel.googlesource.com/pub/scm/boot/dracut/dracut/+/3eca0cc846e89675949abb11e9606f3222a2e266%5E%5E!/ https://bugzilla.redhat.com/show_bug.cgi?format=multipleid=537969 https://bugzilla.redhat.com/show_bug.cgi?id=922031#c5 I updated dracut to 040-207-g7252cde from testing - same picture - I have to use dracut instead of initramfs, since my cluser uses bonded Ethernet links which I could not get working with standard initfs. The plan is to layer common ro installation and nodewise rw-dirs using aufs and exporting them individually per node. Server has dnsmasq, (providing DHCP, DNS and TFTP) and nfs-kernel-server. My first setup started from a HD install. After switching from readonly to writable aufs, everything stalled and I blamed aufs as dmesg recommended... http://sourceforge.net/p/aufs/mailman/message/33392409/ I got rid of this problem by switching the server back form testing 3.16 kernel to standard 3.2 from wheezy. Don't ask me why... This way II messed up this HD based installation, so I decided to try a new clean one based on the debootstrap tool following this pointer https://help.ubuntu.com/community/Installation/OnNFSDrive - same picture - following https://dracut.wiki.kernel.org/index.php/Main_Page I tried both the deprecated command syntax root=/dev/nfs nfsroot= and the recommended one: root=nfs4:[server-ip:]root-dir[:nfs-options] rd.nfs.domain=NFSv4 domain name basically no difference I tried to start rpc.idmapd and stad manually from the console, which is possible either from a nfsv3 root or by copying the nobody-owned system into ramdisk and chown them to root. Then I can see error messages like rpc.statd: Failed to create /var/lib/nfs/state.new: Read-only file system I configured dracut manually to include this path - no help. When I get everything right to fire up idmapd manually, I can mount my nfsv4 export with proper UID. So, name resolution should be OK. I even could manage a manual switch_root (over ssh login...), but did not yield a decent running system this way (there is more stuff done during init I'm afraid, like /proc, /dev, /sys). But it tells me that server and network issues are OK. It's a initram problem. I can capture long logs of the init process. As far as my understanding goes, dracut tries to kill both statd and idmapd at 99-nfsroot-cleanup. I think it shuold not do so anayway, but it even looks like it cannot get a PID for idmapd, so I suppose it could not even succeed in getting it up and running properly before. Basically I think the problem is located somewhere between the integration of dracut, nfsv4/idmapd and debian packaging scheme. see also http://marc.info/?l=linux-nfsm=121621383812750w=2 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737554 I hoped that systemd might help out, but could not get it properly installed into the debootstrap base, see here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=668001 Do I just miss some silly detail? Or is debian dracut nfsv4-root simply no valid setup yet? I can provide MBytes of logs and screenshots, and with wireshark, we may be easily multiplying this figure Anybody out there to collaborate in a solution? yours Wolfgang Rosner -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201502151824.08378.wros...@tirnet.de