Re: kmail2 and TLS problem
My KMail2 had a problem as well. Had not worked in ages. Claws is really a drag. GMail used TLS? On Wed, Sep 12, 2018, 10:54 AM Hans wrote: > Hi foilks, > after last update of debian/testing I got into a problem with TLS. > > I can not get access to the mail servers running TLS. Also in the settings > menu of kmail, I can not scan the server. Message: Server not reachable. > > However, the server is reachable, as kmail-trinity is working fine. > > This mail was sent via kmail-trinity. > > As I do not know, if this is a bug or a local problem on my system: > > Does anybody got into the same problem with actual kamil2 + debian/testing? > > Thank you very much for any feedback! > > Best regards > > Hans > >
Re: Nvidia drivers
On Fri, Jul 6, 2018, 5:57 AM Matthew Crews wrote: > On 07/05/2018 06:03 PM, Mark Allums wrote: > > On 7/5/18 5:42 PM, Francisco Mariano-Neto wrote: > >> Hey all, > >> > >> I'm running kernel 4.15 with nvidia-driver 390.48-3 with no > >> problems. However, recently my kernel was automatically upgraded to 4.16 > >> and it broke the nvidia driver. > >> > >> Running 'dkms autoinstall --all' does not help, it complains > >> about not finding kernel headers (which are installed) and quits. > >> > >> Any ideas on how I can rebuild the kernel module for the new > >> kernel version? > >> > >> Thanks > >> Francisco > >> > > This requires a workaround, a kernel parameter at boot. > > > > GRUB_CMDLINE_LINUX_DEFAULT="slab_common.usercopy_fallback=y" > > > > Edit the config file like this, > > > > $sudo gedit /etc/default/grub > > > > Then run $sudo update-grub. > > > > As an aside, thank you for posting this fix. Although my drivers were > not broken, I did have a problem where xorg would not start correctly > with the 4.16 kernel and nvidia drivers 390.48 (both from Stretch > backports). That GRUB command seemed to resolve it my issue. > > Cheers. > > I have 304xx working fine dkms with 4.16. of course these are now > deprecated. If only nouveau would work. I prefer it..
Re: Ntp not working
On Fri, Jun 22, 2018, 3:45 PM Mike wrote: > On Thu, Jun 21, 2018 at 10:04:24AM +0300, David Baron wrote: > > On Wed, Jun 20, 2018, 5:33 PM Mike wrote: > > > > > > > > OK, so your NTP servers are: > > > > > > pool 0.debian.pool.ntp.org iburst > > > pool 1.debian.pool.ntp.org iburst > > > pool 2.debian.pool.ntp.org iburst > > > pool 3.debian.pool.ntp.org iburst > > > > > > > > > Most likely you are blocking UDP/123. However, if you fail to resolve > > > the IP when you ping it, you have a DNS issue. > > > > > > Mike. > > > > > > > 123 udp allowed both ways. > > The destination is resolved do dns ok. > > Ping still fails, unreachable,sendmsg operation not permitted. > > > > The npt config is correct and the servers should be reachable. This > points to some kind of networking issue at your end. > > That ping error is a little curious. It does sounds like a permissions > issue. One needs to be root to send the ICMP messages that ping uses. > Ping gets around this issue by having setuid set on /usr/bin/ping, so > that anyone who can run it runs it effectively as root. I've never > tried it but I suspect that if you remove setuid from /usr/bin/ping > you'd probably see the above error. Having said that, I did a quick > seearch with a well-known Internet search engine and it the results > suggested that iptables could also cause the above error. > > Anyway, speculation aside, the error (and I've ran ping many, many times > and never seen that error before) does suggest that something isn't > right on your box and it's not the NTPd config. I'd start by looking at > your iptables config. I'd be fairly sure something is blocking UDP/123, > whereever it is. > > Mike. I just Port forwarded on the router. May!! be working. >
Re: Ntp not working
On Wed, Jun 20, 2018, 5:33 PM Mike wrote: > On Wed, Jun 20, 2018 at 04:50:34PM +0300, David Baron wrote: > > Attached ntp.conf > > Attached service.text > > > > OK, so your NTP servers are: > > pool 0.debian.pool.ntp.org iburst > pool 1.debian.pool.ntp.org iburst > pool 2.debian.pool.ntp.org iburst > pool 3.debian.pool.ntp.org iburst > > What happens if you do: > > ping 0.debian.pool.ntp.org > > ? > > Most likely you are blocking UDP/123. However, if you fail to resolve > the IP when you ping it, you have a DNS issue. > > Mike. > 123 udp allowed both ways. The destination is resolved do dns ok. Ping still fails, unreachable,sendmsg operation not permitted. >
Re: Ntp not working
Attached ntp.conf Attached service.text On Wed, Jun 20, 2018, 12:44 PM Mike wrote: > On Wed, Jun 20, 2018 at 12:22:38PM +0300, David Baron wrote: > > > Hello, > > > > > > > Cannot find valid servers. I have the conf and hosts files from the > > > > distro.(Sid) > > > > > > Can you show the config file because not all have machine running SID > > > or show ntpq -p ? > > > > > > > Fix? > > > > > > Ntpq -p yields "Connection refused" > > > > > > Can you provide the npt.conf please? > > ntp -p will yield connection refused if ntpd is not running. > > There should be some lines begining "pool" or "server" in ntp.conf. Can > you ping them? If so, do you have a firewall that might be blocking > UDP/123? > > Mike. > service.txt Description: Binary data ntp.conf Description: Binary data
Re: Ntp not working
On Wed, Jun 20, 2018, 12:01 PM Alexandre GRIVEAUX wrote: > Hello, > > > Cannot find valid servers. I have the conf and hosts files from the > > distro.(Sid) > > Can you show the config file because not all have machine running SID > or show ntpq -p ? > > > Fix? > > > > Ntpq -p yields "Connection refused"
Ntp not working
Cannot find valid servers. I have the conf and hosts files from the distro.(Sid) Fix?
Nouveau instead of 304xx
Tired it. Certainly looks better. But will quickly hang up if I start a second session!
More on Nvidia 304xxx
Can I continue using it if I update xorg? I use dkms. Status of nouvaux with kde and Firefox? Had been problems before. Can I try it by getting rid of the modprob.d blacklist?
Nvdia 304xxx
What is happening with this? I would gladly use nouveau but it has had problems with Firefox and kde.
Re: making more room in root partition for distribution upgrade
Yep. I ended up buying a second disk and moving everything around. The installation is awful. On Mon, May 21, 2018, 3:13 PM Pascal Hambourg wrote: > Le 21/05/2018 à 10:26, Curt a écrit : > > > > Verily in the installer I chose automatic partitioning because of my > > partitioning phobia many moons ago and was allotted a 9G '/' and a 1.4T > > 'home' (as well as swap the size of my ego) > (...) > > (A recent thread seemed to imply that the installer's automagical > > partitioner for LVM leaves little or no empty room for growth, thus > > vitiating somewhat the very raison d'être of LVM at its root.) > > Bottom line : do not use guided partitioning. > > If you do not know what partition sizes you need, use LVM. Create > volumes with minimal suitable sizes (you are not going to fill /home > with 90% of the disk capacity at once, are you ?). This will leave > plenty of free space. When you see that one volume begins to be filled, > extend it. Simple and easy. > >
Re: Kmail - slow or no erasing of mails when deleting fast
My Debian testing version is inoperative. Can no longer connect to Gmail. Message preview box is black. A long time now. Latest upgrade is no better. Since the main and left panes of system setup is also black, problem may be kde. On Tue, Apr 24, 2018, 8:59 AM Hans wrote: > Hi Marc, > thanks for your reply. > > Well , > > > > Question, what version of KMail are you using (Help:About KMail)? > > > > The version I am running here is 5.7.3, which is debian/testing and 32-bit. > However, I have to tell, that I am watching this behaviour since a lng > time, almost since the change to akonadi. At least for 3-4 years. > > I lived that long timer with this issue, but in the version I am using, > things > got worse. Now the "greyed out" mails are also, when marking them all and > then > move into the trash in one step. > > I'm using version 5.5.2 and while some things are a bit slow, this > version > > is much better than those before it. I've also seen "greyed out" e-mails > > which were artifacts of the folder not being updated properly, and as you > > point out, they go away when you force a folder refresh. Assuming you are > > using a current version, I'd post a bug report on the KDE site: > > > > https://www.kde.org/applications/internet/kmail/ > > > > If you are running an "old" version, your report will be ignored as work > is > > only done on new versions. > > > Hmm, I think this behaviour was ignored since a long time. I dunno, I > believe > I mentioned it some years ago in the forum, too, but nothing changed since. > > And I am not sure, if that can be fixed at all. Because: Who is to blame? > (Sorry, if "blame" might be the wrong word, my English..., better say > "ask"?) > > > Good luck, > > Mark > > Best regards > > Hans > > > >
Re: troubleshooting Kmail
Kmail has been broken for weeks. No action, just excuses. Might simply have to abandon it after all these years. On Sat, Feb 17, 2018, 11:42 PM wrote: > On Saturday, February 17, 2018 3:59:53 PM EST ernst doubt wrote: > > I sent a similar message to debian-kde this morning, but it appears > there's > > not much activity there, so I figured I'd also try here. > > > > I've been a debian GNU/linux user (I like KDE for my desktop, though I > > generally keep openbox (and gnome) available as "fallbacks") for quite > some > > time now (decades at least) and am in general a very happy user. I've > been > > using both thunderbird and claws-mail as IMAP clients for some time, but > > recently (a few months ago) I set up Kmail (and I like it very much, as > > integration with gnupg was relatively painless). I am again using it as > an > > IMAP client (with this gmail address). I have two computers, both running > > debian 9 stretch. On one of them (the laptop), Kmail is functioning > > properly, but on the desktop machine which I'm writing from now, incoming > > email has not been appearing since the end of January. I don't see any > > obvious menu entries which would give me access to log files in order to > > try to troubleshoot the problem, so I'm looking for any advice as to how > I > > might go about correcting the issue so this instance of Kmail can again > > receive email (it's possible that the problem is as simple as an > > incorrectly entered password though I've just attempted to reenter it > with > > no improvement in mail fetching behavior). I'm not currently subscribed > to > > this list, so CCing me is perfectly fine (though I'll monitor the web > > archives for responses on which I may not be CCed). > > > >thanks so much in advance for any clues anyone may have to share with > me, > > ~c > > Ernst, > > Things that come to mind... > The way IMAP works is e-mail is delivered to the mail server > (google/gmail, is > what I think you said). Your client (kmail, thunderbird, etc) reads an > email > message from the server. Then, depending on configuration, the message is > saved > or deleted? So, check your configuration to be sure that the IMAP server > is > configured to leave mail on the server after being read. > Also, have you checked that the version of kmail is the same on both > computers? > > Mark > > Have you ckecked the version of each instance of kmail? > >
Re: Out of root partition space
Isn't the Debian I installed wonderful! I ended up putting in an additional drive and repartitioning to solve this. On Tue, Dec 26, 2017, 8:34 AM john doe wrote: > On 12/26/2017 5:04 AM, Doug wrote: > > > > On 12/25/2017 08:44 PM, Sarah Johnson wrote: > >> Hi, > >> I ran out of root partition disk space and can't install or remove any > >> more packages or even login gui window manager anymore > >> > >> i spent few good hours researching for solutions and found that i can > >> resize root and home partitions using resize2fs and lvresize tools but > >> they are not even installed on my system > >> > >> so is it safe to resize debian root and other partitions using windows > >> machine partitioning tool ? > >> knowing that my debian installation is on a USB stick > >> > >> Thanks > >> -- > >> Sarah Johnson > > Why not download GParted--the version that runs off a CD, and burn > > it--and use that? At least it's Linux, and has a lot of capability, like > > changing partition sizes, making new ones, moving existing ones, etc. > > > > Rescue mode seems a good choise to start with. > I wouldn't use windows for that unless you have some spare time! :) > Maybe backing up your home partition might be a good idea. > > -- > John Doe > >
Re: Embarrassing security bug in systemd
On יום רביעי, 6 בדצמבר 2017 22:52:17 IST Urs Thuermann wrote: > Yesterday, my 10 years old son logged into my laptop running Debian > jessie using his account, and curiously asked if he is allowed to try > the /sbin/reboot command. Knowing I have a Linux system as opposed to > some crappy Win machine, I replied "sure, go ahead and try". Seconds > later I was completely shocked when the machine actually rebooted... > > Of course, my son doesn't have any special privileges, no entry in > /etc/sudoers, etc. But then I see > > $ ls -l /sbin/reboot > lrwxrwxrwx 1 root root 14 Apr 8 2017 /sbin/reboot -> /bin/systemctl > $ ls -l /bin/systemctl > -rwxr-xr-x 1 root root 538904 Apr 8 2017 /bin/systemctl > $ dpkg -S /bin/systemctl > systemd: /bin/systemctl > > The /bin/systemctl binary is not suid root, so I assume[1] it > communicates to systemd which then reboots the machine without > checking what user the request comes from. > > I wonder how can such a severe bug make it into a Debian stable > distribution? And is this just an insane default setting on Debian's > side or is it yet another instance of brain-dead systemd behavior? > > Searching the man pages I couldn't find a way to fix this. How can > that be stopped? > > [1] Of course, this is not docuemented in systemctl(1) as usual with > systemd. Also, according to the man page, systemctl must be > called with a "COMMAND" argument which /sbin/reboot doesn't do. > Obviously, systemctl looks at the name it was called and somehow > uses that as command. The admin shall guess about this. > > > urs I find I need to use "sudo" to shutdown or reboot. That is using those (pseudo?) commands. Maybe their scripts check before going to sysemctl
Re: Handhelds that conviently run Debian
I have had Debian up on my Xiamo smartphone. I believe it uses the existing kernel. Had a xwindows as well but did not like the interface. In the end, question was what to do with it.
Re: How to use zram ?
On יום חמישי, 28 בספטמבר 2017 12:27:01 IDT Pierre Couderc wrote: > On 09/28/2017 11:56 AM, to...@tuxteam.de wrote: > > On Thu, Sep 28, 2017 at 11:47:56AM +0200, Pierre Couderc wrote: > >> I have found no howto for zram under debian, nor even the word > >> "zram" in the archives of this list ! > >> > >> I have tried to use zramctl but it refuses with : > >> > >> root@nous:~# zramctl --find --size 1024M > >> zramctl: no free zram device found > >> > >> I suppose I should init something somewere, but what ? > >> > >> On the contrary ubuntu has a dedicated zram-config to make the job. > >> > >> Thanks for any help. > > > > I didn't even know what it is -- but the zram(8) man page and a little > > guesswork at least leads in some direction. > > > > I assume you'd want to load the zram kernel module (sudo modprobe zram, > > I'd guess) to be in in the fun. > > > > There's some doc about the Linux kernel module itself (just follow the > > link in the above man page). > > > > Let us know how it works out and... make a backup first! > > Thank you very much. I have not found "the zram(8) man page "... But It > seems to work : > > root@nous:~# modprobe zram num_devices=2 > root@nous:~# zramctl --find --size 1024M > /dev/zram0 > root@nous:~# zramctl --find --size 1024M > /dev/zram1 > root@nous:~# free -th >totalusedfree shared buff/cache > available > Mem: 3.8G 73M3.6G5.5M 146M3.5G > Swap:0B 0B 0B > Total: 3.8G 73M3.6G > root@nous:~# mkswap /dev/zram0 > Setting up swapspace version 1, size = 1024 MiB (1073737728 bytes) > no label, UUID=66e3aa01-a4b8-4308-b317-608c6a072810 > root@nous:~# free -th >totalusedfree shared buff/cache > available > Mem: 3.8G 73M3.6G5.5M 146M3.5G > Swap:0B 0B 0B > Total: 3.8G 73M3.6G > root@nous:~# swapon /dev/zram0 > root@nous:~# free -th >totalusedfree shared buff/cache > available > Mem: 3.8G 73M3.6G5.5M 147M3.5G > Swap: 1.0G 0B1.0G > Total: 4.8G 73M4.6G > root@nous:~# mkswap /dev/zram1 > Setting up swapspace version 1, size = 1024 MiB (1073737728 bytes) > no label, UUID=69b8070b-3b8d-4234-a773-a59812e54552 > root@nous:~# swapon /dev/zram1 > root@nous:~# free -th >totalusedfree shared buff/cache > available > Mem: 3.8G 74M3.6G5.5M 147M3.5G > Swap: 2.0G 0B2.0G > Total: 5.8G 74M5.6G > root@nous:~# > > Now I suppose I shouls put that in a systemd script... > > Thank you very much. > > PC Did all this. All my free -th results looked the same. Could it be it was already there? Assuming there is an advantage to this, how does one get it going on startup. I HAD a sysinit script for it at one time, before the new days of systend.
Re: Nvidia legacy driver install..
On יום שלישי, 4 ביולי 2017 16:27:21 IDT Mark Fletcher wrote: > On Mon, Jul 03, 2017 at 09:17:00AM -0700, tony mollica wrote: > > On another note, > > > > just checking to see if anyone has used the nvidia driver (304 series) > > install and if there were any problems that arose or needed to be resolved > > either before or after the installation? > > I had to do this for the first time with the upgrade to stretch, > apparently my circa-2009 nvidia geforce card is now "legacy". > > I did think the upgrade process was compromised a bit by this, but I > got it working in the end. > > The upgrade news said "Don't install the new driver if you have an old > card." Well thanks, but what am I supposed to do instead??? > > During the upgrade, it pointed out that my card was not supported by the > new driver, and that I needed the legacy driver (previous question > answered). Always, loads of run. I actually do like Nouveau but it does not play well with Firefox, et. al, and KDE. If this has been fixed, someone please inform me. Failing that, I use the 304xx legacy driver. Installs without a hitch. xorg.conf is deprecated. Live without it. I need to blacklist Nouveau in /etc/modprobe.d -- installation provides an nvidia-blacklists-nouveau.conf to put there. Voile!
Re: kmail gmail integration
On יום חמישי, 29 ביוני 2017 22:38:27 IDT T. P. Van Dae wrote: > I’m trying to transition myself back to Linux (been a long time though… > sorry!) and am working on phasing myself off of Windows. Is it possible to > integrate gmail (currently using 2-step verification) with kmail? Google > says “enable less secure apps”, but it’s a NO with 2 STEP ON. Is there or > will there be a work around for this or is “DISABLE” 2 Step Verification > the answer? One can get Google/gmail to generated a single-app 16-character password. Cut and paste that into kmail. Then it will work.
Canon Selphie CP740
This is a USB printer and there is a Gutenberg driver for it. How does one get it working?
Re: Debian natively on Android device
On יום חמישי, 2 בפברואר 2017 8:33:56 IST Carl Fink wrote: > On Thu, Feb 02, 2017 at 01:09:39PM +, Rodolfo Medina wrote: > > Deloptes, thanks for your indications about Sailfish project and Jolla > > phones, they are very interesting, but what I was looking for is the > > possibility of running Debian on those devices, not other OSs. So Ubuntu > > pre-installed is not either what I wish. As far as I understand, the > > capability for Debian - and other Linux distros - to install on > > smartphones and tablets could improve, and probably will, more and more > > in the next months and years. Some people have already experienced > > Ubuntu, and maybe Debian, on some `WinPads'. But, as far as I > > understand, this was possible because those WinPads have, at start, like > > normal computers, the possibility of choosing to boot from usb pendrive - > > or at least from SDcard. So the main problem in trying the installation > > on other - Android - devices is probably this, that they don't have that > > possibility. Right? Or instead they do have it in some way? > > Android devices almost always have provision for "reflashing" with a new > operating system. If you root it (gain the ability to operate as superuser) > you can install an arbitrary OS. There are Free Software ROMs out there, > like LineageOS (http://lineageos.org/), and in principle there's no reason > somoene couldn't create a Debian distro for Android, but it would be an > enormous job and nobody has actually done so (that I know about). Debian distro for Android (that runs under android in its own chroot or equivelant) -- several on Play. Read the recent XDA-Developers article. The poster wanted to replace Android with something better -- Debian. Ubuntu (Debian-based) has done all the work if one has a compatable device.
Re: Debian natively on Android device
On יום חמישי, 2 בפברואר 2017 13:09:39 IST Rodolfo Medina wrote: > Rodolfo Medina writes: > > Rodolfo Medina writes: > >> I'm interested in the problem of running Debian on an Android device > > > > [...] > > Thanks to all who kindly replied, it did help. Now I can see everything a > bit more clearly. I'll try to summarize what seems important to me about > the issue. > > Deloptes, thanks for your indications about Sailfish project and Jolla > phones, they are very interesting, but what I was looking for is the > possibility of running Debian on those devices, not other OSs. So Ubuntu > pre-installed is not either what I wish. As far as I understand, the > capability for Debian - and other Linux distros - to install on smartphones > and tablets could improve, and probably will, more and more in the next > months and years. Some people have already experienced Ubuntu, and maybe > Debian, on some `WinPads'. But, as far as I understand, this was possible > because those WinPads have, at start, like normal computers, the > possibility of choosing to boot from usb pendrive - or at least from > SDcard. So the main problem in trying the installation on other - Android > - devices is probably this, that they don't have that possibility. Right? > Or instead they do have it in some way? > Good. If you just want to run the distro, any hardware with support in the kernel will do it. If you want a phone, then Ubuntu and Jolla have already done that work. Need support for the hardware, of course.
Re: linux-image-4.9.0-1-amd64 + nvidia-legacy-304xx-driver + xserver-xorg-video-nouveau
On יום ראשון, 15 בינואר 2017 19:44:36 IST Felix Miata wrote: > Jimmy Johnson composed on 2017-01-15 13:43 (UTC-0800): > > The 965 is only using "ro", the 4.8 and 4.9 kernel are installed but not > > working. The 4.7.0-1 kernel works swell, if the newer kernel's are not > > working later on I will do something else, like import another kernel > > that will be updated. > > ro has no remaining effect long before starting Xorg or sddm are attempted. > From the man page: > > ro [KNL] Mount root device read-only on boot > > > The ATI is basically working with the 4.8.0-2 kernel and with the 4.9 > > kernel if I assist it by pressing key's on the keyboard or it dies and > > it's just using "ro". > > Is Plymouth both required and installed on your systems? If installed and > not required for your configuration, try disabling it, or removing it > entirely. > > The Nvidia has to use "ro nomodeset nouveau.modeset=0" and is working > > swell with the 4.8.0-2 kernel but dies with the 4.9 kernel. > > It seems as though you are equating the FOSS Xorg driver named modesetting > with kernel modesetting (KMS). They are not the same thing. > > The proprietary NVidia Xorg driver, unless something has changed lately that > I'm unaware of, requires that KMS be disabled (exclusively via kernel > cmdline???, such as nomodeset or *.modeset=0) in order for it to function. > AFIAK, as I've never tried using it, AMD's proprietary drivers require the > same. > > Disabling KMS via kernel cmdline disables these FOSS Xorg drivers: > > Intel > AMD/ATI/Radeon > Nouveau > I used to use the nomodeset. I also tested for it and brute-force switched between Nouveau and Nvidia legacy based on it. I have not had nomodeset since that "trick" (copying one or other Xorg.conf) became deprecated and I did a new 64-bit install. With no appends on kernel command line, Xorg works with either driver until I try to use KDE, Kwin, compositing. Then Nouveau will hang up, Nvidia legacy 304 will have missing window decorations.
Nvidia Legacy 304xx
Is this being kicked off Debian? Dist-upgrade will remove it for a while now, lists it as installed but not needed, as well. upgrade holds back most all xorg stuff. Problems with kde plasma with both 304xx (works partially) and nouveau (hangs). What would I do now? (I would prefer nouveau because it is "ours" but needs to work :-) )
Re: plasma not starting
On יום שבת, 22 באוקטובר 2016 18:51:45 IDT Sven Joachim wrote: > On 2016-10-22 11:30 -0400, Christopher Judd wrote: > > Hi, > > > > I'm running testing amd64. After upgrading about a week ago, plasma > > will > > > > not start, I get the error message "Plasma is unable to start as it could > > not use OpenGL2", or something similar. I have an nvidia card with the > > nvidia- legacy-304xx driver installed. LXDE runs fine. Does anyone know > > what the issue is here, or how I can debug this? Please cc me, as I'm > > not currently subscribed to the list. Thanks. > > Apparently OpenGL is broken in the 304.132 Nvidia drivers[1,2]. > > Cheers, >Sven > > > 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=840342 > 2. https://devtalk.nvidia.com/default/topic/968892/ 1. Do not start compositing on plasma start. Edit ./config/kwinrc to make sure of this, restart plasmashell. Will run at least. 2. Downgrade the legacy-304xx stuff the Jessie-backports. These apparently do work!
Re: Nvida Legacy 304 Catastrophe
On יום שני, 10 באוקטובר 2016 11:25:42 IDT Brad Rogers wrote: > On Mon, 10 Oct 2016 12:17:58 +0300 > David Baron wrote: > > Hello David, > > >Since I uninstalled the 304, maybe send me your documentation. > > Embarrassing 'egg on face' moment coming up: I *was* misreading the > documentation. The file I mentioned has a section detailing what > supported by which drivers. It's in the legacy 304 section that your > chipset is listed. I didn't check carefully enough first time round. > > My apologies if I got your hopes up. Tried it before getting this. Simply did not work Going back to nouveau hung up very quickly So reinstalled sid legacy-304xx. Compiled this time (not for -rt but this is known). My kdm splash screen resolution bollixed up. Had to redo all my desktops. Big pain. Have to resize all my fonts as well. Otherwise, after a day wasted, working again.
Re: Nvida Legacy 304 Catastrophe
On יום שני, 10 באוקטובר 2016 9:07:33 IDT Brad Rogers wrote: > On Mon, 10 Oct 2016 10:07:49 +0300 > David Baron wrote: > > Hello David, > > >01:00.0 VGA compatible controller: NVIDIA Corporation NV44 [GeForce > >6200 TurboCache] (rev a1) > > If that's the card you're using, why are you using the 304 legacy > version of the nVidia drivers? That card is supported by the latest > driver. At least that's my understanding from the relevant read.me > in/usr/share/doc/nvidia-drivers. > > I'm using that driver myself, albeit with a different card, hence my > having the read.me installed. ~$ nvidia-detect Detected NVIDIA GPUs: 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation NV44 [GeForce 6200 TurboCache] [10de:0161] (rev a1) Checking card: NVIDIA Corporation NV44 [GeForce 6200 TurboCache] (rev a1) Your card is only supported up to the 304 legacy drivers series. It is recommended to install the nvidia-legacy-304xx-driver package Along with other documentation I have seen. Would love to use the latest and greatest rather than legacy excuses. Since I uninstalled the 304, maybe send me your documentation.
Re: kernel 4.7.0 and nvidia
On יום ראשון, 9 באוקטובר 2016 17:54:35 IDT Boyan Penkov wrote: > Hey folks, > > OK, here was the procedure (as a reminder, I’m on stretch, testing): > > — boot into 4.6, verify everything works, purge both 4.7 kernel and 4.7 > headers, purge all nvidia-* (and nvidia-dkms was indeed installed) > > — purge xserver-xorg-video-nvidia > > — install xserver-xorg-xideo-nvidia and nvidia-driver (which pulls in > nvidia-dmks as a dependency, among others) > > — I’m still booted into 4.6, so watch the install script build nvidia-dmks > package for 4.6 only. > > — reboot (into the only kernel I have: 4.6), verify all is ok > > — install 4.7 and 4.7 headers. I observed that the install script and > post-install hook did not rebuild nvidia-dkms for 4.7 > > — reboot into 4.7 and everything works. > > So, to wrap up: I’m happy for now, but I clearly don’t understand something > about how nvidia-dmks built for 4.6 also functions on 4.7 Did we get lucky > here, or do we need a bug filed to get the post-install script to check > what kernels are there and build the kms accordingly? > > Thanks for your individual help off-list as well. > > Cheers! > -- > Boyan Penkov > www.boyanpenkov.com > > > On Oct 6, 2016, at 1:34 PM, Pascal Obry wrote: > > > > Le jeudi 06 octobre 2016 à 08:55 +0200, gianluca a écrit : > >> Are the opensource nouveau drivers so bad, so you need closed-source > >> blob??? If so, that's your choice. But do not ask why something is > >> not working as execpted if you upgrade something on the kernel-side. > > > > You may also say this without being harsh. > > > > A possibility (and that's my case) is that I'm using NVIDIA proprietary > > driver as I need OpenCL support and AFAIK there is no OpenCL support > > with the Nouveau driver. > > > > Anyway on my side I'm also on the 4.7 kernel (Debian/sid) and have no > > problem with the dkms nvidia package. > > > > Cheers, With legacy-304xx, did not build for the 4.6 and what was built for 4.7 did not work! Impossible to go back to testing which did work :-( These packages are off Debian, it seems.
Re: Nvida Legacy 304 Catastrophe
On יום ראשון, 9 באוקטובר 2016 13:03:24 IDT Felix Miata wrote: > David Baron composed on 2016-10-09 13:17 (UTC+0300): > > These packages upgraded (though they seem no longer on Debian!). The > > upgrades would not play with opengl2 so plasma would no longer run. > > Downgrading to testing, due to partial removal from the repos, proved > > impossible. No more means to file bugs, either! > > > > So I uninstalled them, went back to Nouveaux (which I might even prefer). > > Plasmashell is unstable, crashes and restarts, and multiple session will > > not work. Could live the a single-session if that be stable. > > > > There had been problems with firefox in nouveaux last year. > > > > What to do about all this? > > Show us output from 'lspci | grep VGA' > > If output includes 6150SE, try adding nouveau.config=NvMSI=0 to > kernel cmdline. 01:00.0 VGA compatible controller: NVIDIA Corporation NV44 [GeForce 6200 TurboCache] (rev a1) so no 6150SE. Note that one of the "new problems" is that when I attempt to run a second KDE plasma session, the system hangs with NMI watchdog warnings. > > Show us output from 'inxi -Fz' Do not have an inxi > > Show us /var/log/Xorg.0.log attached. > Ensure all traces of NVidia driver are purged, including > /etc/X11/xorg.conf which for most people with most gfxchips using > FOSS drivers has not been necessary for several Debian generations. No xorg.conf, as said, no longer needed or relevant. > With proprietary NVidia driver never having been installed, lsmod > output should resemble the following with legacy geforce gfxcard: > > button 12944 1 nouveau > drm 249998 5 ttm,drm_kms_helper,nouveau > drm_kms_helper 49210 1 nouveau > i2c_algo_bit 12751 1 nouveau > i2c_core 46012 5 No 'core' entry. > drm,i2c_i801,drm_kms_helper,i2c_algo_bit,nouveau mxm_wmi > 12515 1 nouveau > nouveau 1122508 2 > ttm77862 1 nouveau > video 18096 1 nouveau > wmi17339 2 mxm_wmi,nouveau > > Ensure kernel cmdline does not include nomodeset. > Nomodeset. Once used this for a boot=time which between nvidia and nouveau. I had to test that to swap in and out xorg.conf versions but might wish to now attempt such magic by swapping in and out the nouveau blacklist file. If I had working nvidia drivers. > Ensure nothing to do with nouveau is blacklisted. > Removed several copies of that file. > If a thorough nvidia purge is insufficient, you might try purging > xserver-xorg-video-nouveau. In Debian Testing and Unstable, this > should cause use of Xorg's built-in modesetting driver. See: > http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Debian-Abandon-Int > el-DDX [19.794] X.Org X Server 1.18.4 Release Date: 2016-07-19 [19.794] X Protocol Version 11, Revision 0 [19.794] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian [19.794] Current Operating System: Linux dovidhalevi 4.7.0-1-amd64 #1 SMP Debian 4.7.6-1 (2016-10-07) x86_64 [19.794] Kernel command line: BOOT_IMAGE=Linux-4.7.0-1 ro root=UUID=d14ae79d-fd96-43d5-83b0-0bbbdd831196 quiet [19.795] Build Date: 06 September 2016 01:32:44PM [19.795] xorg-server 2:1.18.4-2 (https://www.debian.org/support) [19.795] Current version of pixman: 0.34.0 [19.795] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [19.795] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [19.795] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Oct 10 09:45:23 2016 [19.916] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [20.071] (==) No Layout section. Using the first Screen section. [20.071] (==) No screen section available. Using defaults. [20.071] (**) |-->Screen "Default Screen Section" (0) [20.071] (**) | |-->Monitor "" [20.094] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [20.094] (==) Automatically adding devices [20.094] (==) Automatically enabling devices [20.094] (==) Automatically adding GPU devices [20.094] (==) Max clients allowed: 256, resource mask: 0x1f [20.253] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [20.253] Entry deleted from font path. [20.271] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/
Nvida Legacy 304 Catastrophe
These packages upgraded (though they seem no longer on Debian!). The upgrades would not play with opengl2 so plasma would no longer run. Downgrading to testing, due to partial removal from the repos, proved impossible. No more means to file bugs, either! So I uninstalled them, went back to Nouveaux (which I might even prefer). Plasmashell is unstable, crashes and restarts, and multiple session will not work. Could live the a single-session if that be stable. There had been problems with firefox in nouveaux last year. What to do about all this?
Re: [ A little off topic] Best e-mail client for Android
K9 and the forks and family are oldies and goodies. They are showing their age, but still, one cannot go wrong with them. GMail and Inbox are resource hogs (along with most gapps). Microsoft's Outlook (not the Windows Outlook or Express!) is a decent lightweight contender and integrates calendar and contacts functions as well. This program is an acquisition. Its calendar functions will be incorporating those of another of their acquisitions, Sunrise calendar, which was one of the best. (Note that it plays very well with GMail accounts but it never read my own IMAP server through which I ran my pop3 accounts. I run the old pop3 stuff through GMail now so this works out just fine. Do not need the GMail app to do this--set it up on the site.)
Re: New Weather Protocol?
ALL my weather applets are working today. Surprise! Including yr.no, yahoo and owm. What was going on, folks ? :-)
Re: New Weather Protocol?
On Sunday 10 April 2016 19:06:46 Andrew McGlashan wrote: > On 10/04/2016 5:51 PM, David Baron wrote: > > Non of my weather widgets work any longer. OK, Yahoo changed their API, > > but > > the updated widget still does not work. Neither does open weathermap? > > > > So ... is there something new I must enable in the firewall?? > > Does this help? > > http://wttr.in/tlv > This site displays fine, great ascii art like I used to enjoy. Had animated games doing stuff like this. However, does not answer the question, why connect and transfer of information to plasma widgets of Yahoo weather and openweathermap seems blocked. Apparently (maybe I am wrong, 'tis something else) these are not using straightup http protocols any longer.
New Weather Protocol?
Non of my weather widgets work any longer. OK, Yahoo changed their API, but the updated widget still does not work. Neither does open weathermap? So ... is there something new I must enable in the firewall??
Re: replacement for old /etc/mtab that lists only real filesystems like ext4 or fat
On Thursday 11 February 2016 22:25:31 Jan Gregor wrote: > Hello, > > I used /etc/mtab to list mounted filesystems with their mount options. > Unfortunatelly /etc/mtab no longer exists in debian jessie, it is just > symlink to /proc/mounts that lists 31 filesystems and I want to see just 2 > > :-) classic filesystems like ext4, fat, btrfs only. > > Thanks, > Jan A small utility, if it does not already exist, to do this would be nice. Meanwhile cat /proc/mounts | grep ... may get what we want :-)
Re: (Repeat) Incessant Random Eth Disconnect/Reconnect
On Saturday 30 January 2016 19:31:51 David Baron wrote: > > Hi. > > > > On Fri, Jan 29, 2016 at 10:30:26AM +0200, David Baron wrote: > > > Note: The reported dmesg sequence is on start up, not on expiry problem. > > > > > > ~$ sudo ethtool eth0 > > > > > Settings for eth0: > > > > > > > Link partner advertised auto-negotiation: Yes > > > > > > > > > ~$ sudo ethtool eth1 > > > > > Settings for eth1: > > > > > > > Attempts to set values get "cannot advertise ..." > > > > This is to be expected. You cannot force speed or duplex on a NIC unless > > you turn auto-negotiation off first. > > > > So start with "ethtool -s eth0 autoneg off" first. > > > > And you *did* try using a different cable, do you? > > > > Reco > > Cable was tried. > I have set autoneg off, see what happens. > How do I make such a setting persistant? Update: Problem still occurs.
Re: (Repeat) Incessant Random Eth Disconnect/Reconnect
> Hi. > > On Fri, Jan 29, 2016 at 10:30:26AM +0200, David Baron wrote: > > Note: The reported dmesg sequence is on start up, not on expiry problem. > > > > ~$ sudo ethtool eth0 > > > Settings for eth0: > > > > Link partner advertised auto-negotiation: Yes > > > > > ~$ sudo ethtool eth1 > > > Settings for eth1: > > > > Attempts to set values get "cannot advertise ..." > > This is to be expected. You cannot force speed or duplex on a NIC unless > you turn auto-negotiation off first. > > So start with "ethtool -s eth0 autoneg off" first. > > And you *did* try using a different cable, do you? > > Reco Cable was tried. I have set autoneg off, see what happens. How do I make such a setting persistant?
Re: (Repeat) Incessant Random Eth Disconnect/Reconnect
On Thursday 28 January 2016 15:41:50 Dan Ritter wrote: > On Thu, Jan 28, 2016 at 08:58:37PM +0200, David Baron wrote: > > Here is dmesg | grep eth. I had only one set like this so may not be > > relevant since the disconnect/reconnect happens repeated. > > > > h > > [0.854438] r8169 :02:00.0 eth0: RTL8168c/8111c at > > 0xc9634000, 00:e0:4c:68:00:c5, XID 1c4000c0 IRQ 27 > > [0.854445] r8169 :02:00.0 eth0: jumbo features [frames: 6128 > > bytes, tx checksumming: ko] > > [0.855148] r8169 :03:00.0 eth1: RTL8168c/8111c at > > 0xc9636000, 00:e0:4c:68:00:c6, XID 1c4000c0 IRQ 28 > > [0.855155] r8169 :03:00.0 eth1: jumbo features [frames: 6128 > > bytes, tx checksumming: ko] > > [ 26.942601] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > > [ 26.953369] r8169 :02:00.0 eth0: link down > > [ 26.953372] r8169 :02:00.0 eth0: link down > > [ 26.953485] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready > > [ 26.957431] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready > > [ 26.969361] r8169 :03:00.0 eth1: link down > > [ 26.969435] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready > > [ 28.612791] r8169 :02:00.0 eth0: link up > > [ 28.612809] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready > > > > There is no eth1 active. IPv6 the problem? > > No, IPv6 is just reporting on what it tries to do after it notes > that the link is bouncing. > > According to your dmesg, you have two ethernet ports and both > are being configured. eth1 never comes up, but eth0 bounces. > > First check: mii-tool or ethtool to investigate and/or set > properties such as duplex, 10/100/1000 speed, and jumbo frame > size. I recommend setting it to 1000 full duplex no jumbo > frames, i.e. frame size of 1500 bytes or so. > > What do they report? > > -dsr- Note: The reported dmesg sequence is on start up, not on expiry problem. ~$ sudo ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Link partner advertised pause frame use: Transmit-only Link partner advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x0033 (51) drv probe ifdown ifup Link detected: yes ~$ sudo ethtool eth1 Settings for eth1: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Speed: 10Mb/s Duplex: Half Port: MII PHYAD: 0 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: g Current message level: 0x0033 (51) drv probe ifdown ifup Link detected: no Attempts to set values get "cannot advertise ..." The two ports are on-board, one in use. Maybe I can hide eth1 in BIOS setup.
(Repeat) Incessant Random Eth Disconnect/Reconnect
Royal pain in the ... What do I do about this? Running on up-to-date 64-bit Sid box, running through netgear router. (Saw something about network manager/netcfg conflict but I do not have netcfg.)
Re: (Repeat) Incessant Random Eth Disconnect/Reconnect
On Thursday 28 January 2016 18:34:36 Lisi Reisz wrote: > On Thursday 28 January 2016 18:08:50 David Baron wrote: > > Royal pain in the ... > > What do I do about this? > > > > Running on up-to-date 64-bit Sid box, running through netgear router. > > > > (Saw something about network manager/netcfg conflict but I do not have > > netcfg.) > > I have come across this when a Netgear router was on its last legs. But I > also met it when my local telephone exchange was undergoing maintenance. > > Lisi Netgear is brand new. Also occurred with the older one. I doubt the phone company (ADSL provider) is the problem and they most likely would not admit to it if they were :-)
Re: (Repeat) Incessant Random Eth Disconnect/Reconnect
On Thursday 28 January 2016 13:13:42 you wrote: > On Thu, Jan 28, 2016 at 08:08:50PM +0200, David Baron wrote: > > Royal pain in the ... > > What do I do about this? > > > > Running on up-to-date 64-bit Sid box, running through netgear router. > > > > (Saw something about network manager/netcfg conflict but I do not have > > netcfg.) > > 1. Get more information. > - dmesg output? > - hardware info about the NIC? > - ethtool or mii-tool info? > - /proc/interrupts investigation > > 2. Change variables one at a time, noting any changed behavior > - can you swap the cable? > - can you test a different NIC, or a different computer > entirely? > - can you connect the same NIC to something other than the > netgear? > > -dsr- Thanks for you reply. I tried the cables. Have no other HW NIC machine available. Here is dmesg | grep eth. I had only one set like this so may not be relevant since the disconnect/reconnect happens repeated. h [0.854438] r8169 :02:00.0 eth0: RTL8168c/8111c at 0xc9634000, 00:e0:4c:68:00:c5, XID 1c4000c0 IRQ 27 [0.854445] r8169 :02:00.0 eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko] [0.855148] r8169 :03:00.0 eth1: RTL8168c/8111c at 0xc9636000, 00:e0:4c:68:00:c6, XID 1c4000c0 IRQ 28 [0.855155] r8169 :03:00.0 eth1: jumbo features [frames: 6128 bytes, tx checksumming: ko] [ 26.942601] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 26.953369] r8169 :02:00.0 eth0: link down [ 26.953372] r8169 :02:00.0 eth0: link down [ 26.953485] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 26.957431] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready [ 26.969361] r8169 :03:00.0 eth1: link down [ 26.969435] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready [ 28.612791] r8169 :02:00.0 eth0: link up [ 28.612809] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready There is no eth1 active. IPv6 the problem?
libqt5egldeviceintegration5
Is this obsolete or deprecated? Many held libqt5 packages upgrades want to remove this.
(Repeat) Incessant Random Eth Disconnect/Reconnect
Royal pain in the ... What do I do about this? (Saw something about network manager/netcfg conflict but I do not have netcfg.)
Re: sexist content in the package openclipart2-png
My two cents (not worth very much nowadays, I am afraid): I have not looked at the collections but like others, there simply have to be some girlie stuff, scantily clad beauties, ripped men, etc. I suppose these have place in clipart collections, someone might make use of them and not necessarily in harmful ways. I would like to see all the sexist and sexy stuff de-emphasized. I am more concerned about the ad-pictures that will adorn our technical sites (and I have complained about some of it). I am also concerned about the prevalence of foul language in a professional forum. I think we can do better.
Re: Dovecot Problems?
On Wednesday 30 December 2015 22:56:06 David Baron wrote: > On Wednesday 30 December 2015 21:31:09 Jochen Spieker wrote: > > David Baron: > > > I can no longer log on to my IMAP server from my Android. I can do so > > > from > > > kmail but even the URL is translated to localhost. Using k-9 mail on the > > > android. > > > > Is kmail running in the same host as Dovecot? That's the only way I can > > think of that kmail is working with localhost as the IMAP server (or a > > *very* broken entry in /etc/hosts). > > > > > I have dovecot listening to *,:: (both ivp4 and ivp6) > > > I have tried with and without ssl,tls, neither works > > > > > > I am not sure when it stopped working, dovecot upgrades or new router. > > > The > > > desktop ufw is set to allow all out and 143 in for all the combinations. > > > > If you only allow 143, IMAP over SSL will not work. It uses 993. > > > > > The router's port forwarding is set up the same way. > > > > > > Should work. > > > What else do I need? > > > > You are a little short on details. What error message do you receive > > from K9? > > Cannot contact server. > If I take domain out of hosts, same for kmail. > Using 143, startls on both. > > Has to be the port forwarding but this is all very straightforward. Progress. Assigned a static address in the router. This gave me communications. K-9 kicked at the certificate so I took off starttls Then it worked. So I need to update the certificate. How do I do that (or where do I copy the files on the phone)?
Re: Dovecot Problems?
On Wednesday 30 December 2015 21:31:09 Jochen Spieker wrote: > David Baron: > > I can no longer log on to my IMAP server from my Android. I can do so from > > kmail but even the URL is translated to localhost. Using k-9 mail on the > > android. > > Is kmail running in the same host as Dovecot? That's the only way I can > think of that kmail is working with localhost as the IMAP server (or a > *very* broken entry in /etc/hosts). > > > I have dovecot listening to *,:: (both ivp4 and ivp6) > > I have tried with and without ssl,tls, neither works > > > > I am not sure when it stopped working, dovecot upgrades or new router. The > > desktop ufw is set to allow all out and 143 in for all the combinations. > > If you only allow 143, IMAP over SSL will not work. It uses 993. > > > The router's port forwarding is set up the same way. > > > > Should work. > > What else do I need? > > You are a little short on details. What error message do you receive > from K9? Cannot contact server. If I take domain out of hosts, same for kmail. Using 143, startls on both. Has to be the port forwarding but this is all very straightforward.
Re: Dovecot Problems?
On Friday 25 December 2015 13:54:12 to...@tuxteam.de wrote: > On Thu, Dec 24, 2015 at 02:53:58PM +0200, David Baron wrote: > > I can no longer log on to my IMAP server from my Android. I can do so from > > kmail but even the URL is translated to localhost. Using k-9 mail on the > > android. > > > > I have dovecot listening to *,:: (both ivp4 and ivp6) > > I have tried with and without ssl,tls, neither works > > > > I am not sure when it stopped working, dovecot upgrades or new router. The > > desktop ufw is set to allow all out and 143 in for all the combinations. > > > > The router's port forwarding is set up the same way. > > > > Should work. > > What else do I need? > > Perhaps stating the obvious, but have you had a look at the dovecot logs? > Can you spot your android's login attempts? > > regards > -- t Login attempt not logged.
Dovecot Problems?
I can no longer log on to my IMAP server from my Android. I can do so from kmail but even the URL is translated to localhost. Using k-9 mail on the android. I have dovecot listening to *,:: (both ivp4 and ivp6) I have tried with and without ssl,tls, neither works I am not sure when it stopped working, dovecot upgrades or new router. The desktop ufw is set to allow all out and 143 in for all the combinations. The router's port forwarding is set up the same way. Should work. What else do I need?
Perl Transition
Is this done, ready to play?
Re: Attempt to Move Root (SOLVED!!)
On Wednesday 23 December 2015 12:39:18 Anders Andersson wrote: > On Wed, Dec 23, 2015 at 9:52 AM, David Baron wrote: > > On reboot (to old system or otherwise), the UUID of the target partition > > was CHANGED! > > Unlikely, how do you know? What would change them during a reboot? When I resized the target partition, /dev/disk/by-uuid showed what I afterwards placed in fstab and lilo.conf. Today, a desperate try, placed the new fstab on the old root and rebooted. Root could not be mounted and the original mounted read-only (correct behavior in this case). I, of course, could not fix it this way. When I tried to remount it or mount the new root over it, got error that the uuid could not be found. listing the /dev/disk/by-uuid now showed a new uuid for the target partition. Mounted the new partition by /dev/sd..., placed the correct(ed) uuid in fstab and lilo.conf, went through the recommended procedure and voile. > > > If the problem was not hidden behind a screenfull of lvm errors, I > > would/should have seen that right away, huh? > > To my knowledge, lvm does not care about UUIDs. What were these errors? The lvm error on a functional boot up is once and spurious. This is a bug somewhere in the initramfs, I suppose. The repeated lvm error meant it could not find incorrectly uuid'd partition. I repeat, I am using no logical volumes. I did not notice the errant uuid as cited in the error messages. Might have indeed been but it did not catch my eye at the times.
Re: Attempt to Move Root (SOLVED!!)
On reboot (to old system or otherwise), the UUID of the target partition was CHANGED! If the problem was not hidden behind a screenfull of lvm errors, I would/should have seen that right away, huh?
Re: Attempt to Move Root
On Monday 21 December 2015 16:15:48 Stephen Powell wrote: > On Mon, 21 Dec 2015 15:43:54 -0500 (EST), David Baron wrote: > > Repeat: NO LV's > > Oh. Sorry. Looking back over the thread, I guess I got the idea from > Anders Andersson that you were using LVM2 logical volumes. My mistake. > Yes, if / is a partition on a real disk, then /boot can be part of the same > filesystem. I've been on the wrong track for several posts now. Please > excuse the noise. Help greatly appreciated, regardless.
Re: Attempt to Move Root
On Monday 21 December 2015 14:53:16 Stephen Powell wrote: > On Mon, 21 Dec 2015 10:36:48 -0500 (EST), David Baron wrote: > > On Monday 21 December 2015 10:25:15 Stephen Powell wrote: > >> Obviously, the LILO map file is on the IDE drive. Is your /boot > >> partition > >> on the IDE drive? If so, you cannot remove it. The /boot partition must > >> be a partition on a physical drive, but obviously it cannot be on the > >> drive > >> that you want to remove. > > > > The boot is not a separate partition but is a directory on the root so > > travels with it. Copy on both old and new directories. > > No, that won't work. If the root filesystem is an LVM2 logical volume, then > /boot *cannot* be part of the root filesystem. To be more rigorous, there > will be a /boot directory in the / filesystem, but it must be an *empty* > directory, so that another filesystem can be mounted on that directory. > Another filesystem must get mounted on the /boot directory in the root > filesystem, and that filesystem must be made on a partition of a *real* > disk which is accessible via the BIOS. It cannot be an LVM2 logical > volume. The boot partition contains the LILO map file (by default, > /boot/map) as well as the kernel image file and the initial RAM filesystem > image file. LILO reads these files at boot time via BIOS calls, and the > BIOS does not support LVM2 logical volumes. You can have a physical disk > with two partitions on it, one partition of which is an LVM2 physical > volume which is part of an LVM2 logical volume, and the other one of which > is a stand-alone partition which is mounted on /boot. But the filesystem > which gets mounted on /boot must *not* be an LVM2 logical volume. I > thought I made that clear before. Also, the LILO boot sector must be > either on the MBR of a *real* disk, or the first sector of a partition on a > *real* disk. > > > The loop that I get is something more problematic. > > Agreed. As I said before, there is probably something missing from the > initial RAM file system that needs to be there for the kernel to mount an > LVM2 logical volume. > === > > Could he not dd them onto another drive? > ... >He can copy the /boot data to another drive, not necessarily >with dd. In fact, if he wants to be able to remove the >existing IDE drive, he must. But he cannot copy it to an >LVM2 logical volume. The data in /boot (after copying) >must be on a partition on a physical disk which is accessible >via the BIOS and not on the old IDE drive which he wishes >to remove. The / filesystem can be an LVM2 logical volume, >provided the initial RAM filesystem contains sufficient files >to mount an LVM2 logical volume, but the filesystem which >gets mounted on /boot must be made on a partition of a *real* >disk which is not scheduled to be removed from the system. Repeat: NO LV's
Re: Attempt to Move Root
On Monday 21 December 2015 10:25:15 Stephen Powell wrote: > On Mon, 21 Dec 2015 04:50:00 -0500 (EST), David Baron wrote: > > Went through all the motions, both ways: On native and chroot. Results > > were > > the same. Get in that loop of lv not ready messages. Difference: Native > > attempt still needs the IDE plugged in or I get 99 99 99 ... , chroot does > > not. > > > > So, what do I do next? > > Obviously, the LILO map file is on the IDE drive. Is your /boot partition > on the IDE drive? If so, you cannot remove it. The /boot partition must > be a partition on a physical drive, but obviously it cannot be on the drive > that you want to remove. > The boot is not a separate partition but is a directory on the root so travels with it. Copy on both old and new directories. > The "volume not ready" messages would indicate that LVM2, or some file(s) > needed by it, are not included in the initial RAM file system. I always get one of those on boot up, then things proceed. I have no lv's. Maybe fix-include in initramfs anyway? The loop that I get is something more problematic.
Re: Attempt to Move Root
On Monday 21 December 2015 00:50:43 David Christensen wrote: > On 12/20/2015 02:58 AM, David Baron wrote: > > So ... how do I do this?? > > On 12/20/2015 03:36 AM, David Baron wrote: > > my goal is to remove and older 80gig IDE disk from the system > > Debian version? Sid > > > What drive is root on? How is the drive partitioned? RAID? LVM? LUKS? > Other? What is the file system type? How big? Currently on partition of old IDE drive. Nothing else remaining on this drive. Partition is 10gig > > > Where do you want to move root? To an available partition of similar size on the first SATA drive. > > > What else is on the same drive as root? Boot? Swap? Do you want to > move these? Where? These are currently on first and second SATA drives, all set up and working. > initramf-tools/conf.d/resume This was NOT copied in the cp -x -a /. newroot! So copied in manually. Points to current swap on 1st SATA. Went through all the motions, both ways: On native and chroot. Results were the same. Get in that loop of lv not ready messages. Difference: Native attempt still needs the IDE plugged in or I get 99 99 99 ... , chroot does not. So, what do I do next?
Re: Attempt to Move Root
On Sunday 20 December 2015 13:18:09 Stephen Powell wrote: > On Sun, 20 Dec 2015 05:58:47 -0500 (EST), David Baron wrote: > > OK, mounted newrootpartition newroot > > Did a cp -x / newroot > > Successful so far, elementary > > > > Edited newroot/etc/fstab and newroot/etc/lilo.conf to point root to > > newrootpartition (by uuid) > > > > mount --bind /dev newroot/dev > > mount --bind /proc newroot/proc > > as instructed in various posts, to enable lilo to run. > > > > chroot newroot > > lilo ... > > > > Looked successful. Umounted everything and reboot. > > > > Get boot menu (congratulations !?). > > Chose the kernel. > > > > Now got that lvm not ready business.. I usually get this once and then > > normally boot up. Now getting it over and again. BTW, if I control/C a few > > times, I end up inside initramfs>. > > > > Put up the live DVD, regenerated the initramfs, but ... no change. > > Put up the live DVD, mounted the old root partition, went through the > > lilo > > process and back up. > > > > So ... how do I do this?? > > I have several thoughts. > > First of all, the right way to copy the root filesystem under these > conditions is > >cp -a -x /. newroot > > That period after the forward slash is important! > > Second, make sure that the initial RAM filesystem contains everything needed > to initialize a logical volume. If you make a logical volume the root > filesystem in the Debian installer, the Debian installer *should* do > whatever is necessary to make sure that everything needed to mount a > logical volume gets included in the initial RAM filesystem. I've never > tried to do this, so I can't give you a list of what files will be needed. > You can examine an existing inital RAM filesystem to see what files are > included by using lsinitramfs. > > Third, although it is possible to make a logical volume the root filesystem, > /boot must not be part of this filesystem. It must be a separate partition > on a physical volume. (Furthermore, it must be a separate partition that > is accessible via the BIOS.) The same goes for the boot sector. (The > "boot" configuration record in /etc/lilo.conf.) Usually, this is the first > sector on the /boot partition or else the master boot record. And if it is > not the master boot record, then a generic MBR boot loader program must be > installed in the MBR and the /boot partition must be on that physical disk, > and it must be marked active in the partition table (and all other > partitions marked inactive). Finally, make sure that the BIOS is actually > booting from this physical disk. > > Although the specific subject of using an LVM2 logical volume as the root > filesystem is not specifically covered, you may find some useful lilo > tidbits on my lilo web page: > >http://www.stevesdebianstuff.org/lilo.htm > > Finally, make sure that there are no duplicate UUIDs in the system that > might confuse the kernel during boot. Thanks for the detailed explanation! I am not now using logical volumes. (When I did in the past, boot was indeed separate.) Do not need the layer of complication and unless one is careful to leave unallocated areas, the whole thing becomes locked up anyway. I did not know about the /. so will definitely try it this way. The first time I did this, moving from the tiny partition to the old IDE partition, I did not do any of this. I did the copy, edited the files in situ (old root), ran lilo and it booted up. But ... the old root was still active because the newroot files were not the edited copies (i.e., old fstab). So once I fixed that, it simply played, no fuss, no muss. So ... do I need the chroot and the binds and all this at all?
Re: Attempt to Move Root
On Sunday 20 December 2015 08:07:31 Renaud OLGIATI wrote: > On Sun, 20 Dec 2015 12:58:47 +0200 > > David Baron wrote: > > Edited newroot/etc/fstab and newroot/etc/lilo.conf to point root to > > newrootpartition (by uuid) > > Have you tried getting rid of the UUID crap in both newroot/etc/fstab and > newroot/etc/lilo.conf, and mount them the old way, as /dev/something ? > Could do this, but only is his "deprecated" and not recommended anywhere else, but my goal is to remove and older 80gig IDE disk from the system. As soon as I unplug it, those /dev/somethings are invalid. Which is why using UUID is recommended.
Attempt to Move Root
OK, mounted newrootpartition newroot Did a cp -x / newroot Successful so far, elementary Edited newroot/etc/fstab and newroot/etc/lilo.conf to point root to newrootpartition (by uuid) mount --bind /dev newroot/dev mount --bind /proc newroot/proc as instructed in various posts, to enable lilo to run. chroot newroot lilo ... Looked successful. Umounted everything and reboot. Get boot menu (congratulations !?). Chose the kernel. Now got that lvm not ready business.. I usually get this once and then normally boot up. Now getting it over and again. BTW, if I control/C a few times, I end up inside initramfs>. Put up the live DVD, regenerated the initramfs, but ... no change. Put up the live DVD, mounted the old root partition, went through the lilo process and back up. So ... how do I do this??
Moving Partitions
In the continuing struggle to undo the damage of the ridiculous partitions made by the installer, I bought another one terra disk and now have loads of /usr space and and real /opt partition. Now, two left: /var which can either go to the 8gig partition freed by moving /usr or to a larger partition on the new disk. / root, which is on a old 80gig IDE which should be removed from the system (even though the smart errors are most likely due to the partial support of the hardware, no data read or write errors). This can either go to the 8gig partition freed by moving /usr or to a larger partition on the new disk, whichever one /var does not inherit. Question: Must root be on a primary partition (the 8gig is secondary --- I had failed to move root to a currently third disk before this so that 8gig might be preferred.)
Re: Apt Archives Usage
On Thursday 10 December 2015 17:29:06 David Baron wrote: > Has this changed in latest-and-greatest from Sid?? > > I symlink /var/cache/apt off to another drive because the partition the > install gave me is too small. /var has started filling up again on apt-get. Seemed to have solved itself.
Apt Archives Usage
Has this changed in latest-and-greatest from Sid?? I symlink /var/cache/apt off to another drive because the partition the install gave me is too small. /var has started filling up again on apt-get.
Re: Do I need to do fstrim on Jessie?
On Wednesday 25 November 2015 20:22:59 Sven Hartge wrote: > David Baron wrote: > >>> Either you add "discard" as a mount option to your fstab or you > >>> crate a cronjob to run "fstrim -a -v". > > > > fstab created by the installer (normal SATA HDs) only has "defaults." > > Is this implicit here? > > Sorry, I don't understand. What is implicit where? > > Grüße, > Sven. Do I need to add "discard" or does the "defaults" setting include this? Running Sid.
Re: Do I need to do fstrim on Jessie?
> > Either you add "discard" as a mount option to your fstab or you crate a > > cronjob to run "fstrim -a -v". > fstab created by the installer (normal SATA HDs) only has "defaults." Is this implicit here?
Re: var is full...
On Wednesday 18 November 2015 15:36:47 Brian wrote: > On Wed 18 Nov 2015 at 12:20:51 -0300, Renaud OLGIATI wrote: > > On Wed, 18 Nov 2015 15:42:29 +0100 > > > > Hans wrote: > > > try to boot from a live system like Knoppix or any other live-cd. > > > > > > Then mount the partition, where /var resides and you can delete files > > > you do not need (for example old packages). > > > > Or just su to root in a console, cd to /var/cache/apt/archive and rm > > -f *.deb to remove all the old packages. > > Why have a dog and bark yourself? > > apt-get autoclean Not enough. Apt-get clean/autoclean just goes so far. I have that /var/cache/apt on the oversized home that the installation partitions and I symlink that back to /var/cache. Would be better to mount --bind. This is what I did to have /opt and /usr/local. Also not enough room. When I get another disk, can stop all this trickery, but until then, it is OK.
Re: Kali, Redux
On Thursday 05 November 2015 10:13:34 The Wanderer wrote: > On 2015-11-05 at 09:59, David Baron wrote: > > On Thursday 05 November 2015 09:47:12 The Wanderer wrote: > >> On 2015-11-05 at 09:41, Lisi Reisz wrote: > >>> On Thursday 05 November 2015 14:26:07 David Baron wrote: > >>>> Attempt to apt-get --reinstall install base-files will produce > >>>> error "cannot be downloaded." In Synaptic, the Debian symbol > >>>> does not appear with the package. Maybe it is only on stable? > >>> > >>> https://packages.debian.org/search?keywords=base-files > >> > >> Perhaps more usefully: > >> > >> What does 'apt-cache policy base-files' say on your machine? Exact > >> output, please; don't just give part of the response, > >> copy-and-paste the entire thing, the way I did in my previous mail. > > > > ~$ apt-cache policy base-files > > > > base-files: > > Installed: 1:2.0 > > Candidate: 1:2.0 > > > > Version table: > > *** 1:2.0 0 > > > > 100 /var/lib/dpkg/status > > > > 9.5 0 > > > > 500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages > > 500 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages > > That sheds some light on things. > > In your earlier sources.list, the lines for the Kali repos were > commented out. That means that any package versions which were pulled > only from those repos will show as being available only locally, with no > repo source for re-download. > > I suspect that when the Kali repos were enabled, something resulted in > your upgrading base-files, and since the Kali repos had a version number > with an epoch (the '1:' at the beginning of the version number) their > version trumped the one from the official repos. > > _IF_ you want to revert base-files to the official Debian version, > abandoning the Kali variant, you should be able to do it with the > following command: > > apt-get install base-files=9.5 > > > Note that if you do that, you probably won't be able to get back to the > current state, unless either A: you have the appropriate .deb file > cached (e.g. in /var/cache/apt/archives) or B: you un-comment the Kali > repos in sources.list and apt-get update again. > > However, since you presumably (based on your having started this thread > in the first place) don't want the Kali packages anyway, you probably > won't consider this a bad thing. Did the job! Called it a "downgrade."
Re: Kali, Redux
On Thursday 05 November 2015 09:47:12 The Wanderer wrote: > On 2015-11-05 at 09:41, Lisi Reisz wrote: > > On Thursday 05 November 2015 14:26:07 David Baron wrote: > >> Attempt to apt-get --reinstall install base-files will produce > >> error "cannot be downloaded." In Synaptic, the Debian symbol does > >> not appear with the package. Maybe it is only on stable? > > > > https://packages.debian.org/search?keywords=base-files > > Perhaps more usefully: > > What does 'apt-cache policy base-files' say on your machine? Exact > output, please; don't just give part of the response, copy-and-paste the > entire thing, the way I did in my previous mail. > ~$ apt-cache policy base-files base-files: Installed: 1:2.0 Candidate: 1:2.0 Version table: *** 1:2.0 0 100 /var/lib/dpkg/status 9.5 0 500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages 500 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages > Similarly, what is the exact output you get from 'apt-get install > --reinstall base-files'? ~$ sudo apt-get --reinstall install base-files Reading package lists... Done Building dependency tree Reading state information... Done Reinstallation of base-files is not possible, it cannot be downloaded. 0 upgraded, 0 newly installed, 0 to remove and 21 not upgraded. > Also, just to double-check: you have run 'apt-get update' recently, > correct? Done at least daily, cron job.
Re: Kali, Redux
On Thursday 05 November 2015 08:47:48 The Wanderer wrote: > On 2015-11-05 at 03:22, David Baron wrote: > > On Wednesday 04 November 2015 16:35:57 David Wright wrote: > >> On Wed 04 Nov 2015 at 22:56:42 (+0200), David Baron wrote: > >>> So, I easily edited the text in /etc/issue to something more to > >>> my liking. This is just text, no meaning. > >>> > >>> Watching a cmake session, I noticed the distribution being > >>> called, you guessed it: Kali ... > >>> > >>> Found another file: ~$ cat /etc/os-release > >>> PRETTY_NAME="Kali GNU/Linux 2.0 (sana)" > >>> NAME="Kali GNU/Linux" > >>> ID=kali > >>> VERSION="2.0 (sana)" > >>> VERSION_ID="2.0" > >>> ID_LIKE=debian > >>> ANSI_COLOR="1;31" > >>> HOME_URL="http://www.kali.org/"; > >>> SUPPORT_URL="http://forums.kali.org/"; > >>> BUG_REPORT_URL="http://bugs.kali.org/"; > >>> > >>> Actually a symlink to /usr/lib/os-release > >>> > >>> So where did I get this? > >> > >> dpkg -Sshows that they both belong to the "base-files" > >> package. > > > > This package is no longer on the repos!! > > Of course it is: > > > $ apt-cache policy base-files > base-files: > Installed: 9.5 > Candidate: 9.5 > Version table: > *** 9.5 0 > 500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages > 100 /var/lib/dpkg/status > 8+deb8u2 0 > 500 http://ftp.us.debian.org/debian/ stable/main amd64 Packages > > > I'd be extremely surprised if it weren't, since it's flagged as > "Essential: yes". > > What repositories do you have listed in /etc/apt/sources.list? > > I really suspect you're not actually running Debian as such, but some > derivative (presumably named "Kali") with which I at least am not > directly familiar, and your problems are coming from the changes > involved in their repositories. Here is my sources.list ~$ cat /etc/apt/sources.list # basic deb http://ftp.us.debian.org/debian/ testing main contrib non-free deb http://ftp.us.debian.org/debian/ unstable main contrib non-free deb http://ftp.us.debian.org/debian/ experimental main contrib non-free #Virtualbox from Oracle # deb http://download.virtualbox.org/virtualbox/debian/ squeeze contrib non- free deb http://download.virtualbox.org/virtualbox/debian/ wheezy contrib #Kde pre-releases? # deb http://qt-kde.debian.net/debian/ unstable main # deb http://qt-kde.debian.net/debian/ experimental main # deb http://qt-kde.debian.net/debian/ experimental-snapshots main # deb http://packages.siduction.org/kdenext/ experimental-snapshots main #flight simulator launcher # deb http://ppa.launchpad.net/xquiet/ppa/ubuntu/ precise main #awv.lvw plugins # deb http://ppa.launchpad.net/blablack/music-prod/ubuntu/ quantal main # deb-src http://ppa.launchpad.net/blablack/music-prod/ubuntu/ quantal main # Kali linux repositories | Added by Katoolin # deb http://http.kali.org/kali/ sana contrib non-free main # deb http://security.kali.org/kali-security/ sana/updates non-free contrib main # deb http://repo.kali.org/kali/ kali-bleeding-edge main I had those kali repos but never installed any of it, but that Katoolin script might have touched the text files. Attempt to apt-get --reinstall install base-files will produce error "cannot be downloaded." In Synaptic, the Debian symbol does not appear with the package. Maybe it is only on stable?
Re: Kali, Redux
On Thursday 05 November 2015 09:41:40 Thomas Schmitt wrote: > Hi, > > David Baron wrote: > > what should it be for Debian Sid? > > On my Sid VM i get: > > $ cat /etc/os-release > PRETTY_NAME="Debian GNU/Linux stretch/sid" > NAME="Debian GNU/Linux" > ID=debian > HOME_URL="https://www.debian.org/"; > SUPPORT_URL="https://www.debian.org/support/"; > BUG_REPORT_URL="https://bugs.debian.org/"; > > $ ls -l /etc/os-release > lrwxrwxrwx 1 root root 21 Aug 18 12:06 /etc/os-release -> > ../usr/lib/os-release Hand edited mine to this. Dependencies on now non-existent package -- strange!
Re: Kali, Redux
On Wednesday 04 November 2015 16:35:57 David Wright wrote: > On Wed 04 Nov 2015 at 22:56:42 (+0200), David Baron wrote: > > So, I easily edited the text in /etc/issue to something more to my liking. > > This is just text, no meaning. > > > > Watching a cmake session, I noticed the distribution being called, you > > guessed it: Kali ... > > > > Found another file: ~$ cat /etc/os-release > > PRETTY_NAME="Kali GNU/Linux 2.0 (sana)" > > NAME="Kali GNU/Linux" > > ID=kali > > VERSION="2.0 (sana)" > > VERSION_ID="2.0" > > ID_LIKE=debian > > ANSI_COLOR="1;31" > > HOME_URL="http://www.kali.org/"; > > SUPPORT_URL="http://forums.kali.org/"; > > BUG_REPORT_URL="http://bugs.kali.org/"; > > > > Actually a symlink to /usr/lib/os-release > > > > So where did I get this? > > dpkg -Sshows that they both belong to the "base-files" > package. This package is no longer on the repos!! > > Do I need it? > > That depends on the applications you run which might read it. cmake, for one. But that is not on the list. Removing base-files will ... Remv rsync [3.1.1-3] Remv lib32nss-mdns [0.10-6] Remv libnss-mdns-i386:i386 [0.10-6] Remv libnss-mdns:i386 [0.10-6] Remv libnss-mdns [0.10-6] Remv base-files [1:2.0] [bsd-mailx:amd64 dpkg-dev:amd64 bash:amd64 ] Remv foomatic-db-engine [4.0.12-2] [bsd-mailx:amd64 dpkg-dev:amd64 bash:amd64 ] Remv bash-completion [1:2.1-4.2] [bsd-mailx:amd64 dpkg-dev:amd64 bash:amd64 ] Remv bash [4.3-14] [bsd-mailx:amd64 dpkg-dev:amd64 ] Remv bsd-mailx [8.1.2-0.20150408cvs-1] [dpkg-dev:amd64 ] Remv build-essential [12.1] [dpkg-dev:amd64 ] Remv dh-make [1.20150601] [dpkg-dev:amd64 ] Remv debhelper [9.20151005] [dpkg-dev:amd64 dh-strip-nondeterminism:amd64 ] Remv dh-strip-nondeterminism [0.013-1] [dpkg-dev:amd64 ] Remv dpkg-dev [1.18.3] So for a package that is no longer there, quite a problem! > > If I do, what should it be for Debian Sid? > > Take a look at its "base-files". Whether installing it is useful depends, > I guess, on how much your installation actually looks like sid, and > how much any differences matter. So, now what :-)
Kali, Redux
So, I easily edited the text in /etc/issue to something more to my liking. This is just text, no meaning. Watching a cmake session, I noticed the distribution being called, you guessed it: Kali ... Found another file: ~$ cat /etc/os-release PRETTY_NAME="Kali GNU/Linux 2.0 (sana)" NAME="Kali GNU/Linux" ID=kali VERSION="2.0 (sana)" VERSION_ID="2.0" ID_LIKE=debian ANSI_COLOR="1;31" HOME_URL="http://www.kali.org/"; SUPPORT_URL="http://forums.kali.org/"; BUG_REPORT_URL="http://bugs.kali.org/"; Actually a symlink to /usr/lib/os-release So where did I get this? Do I need it? If I do, what should it be for Debian Sid? I had Kali's repos but installed none of their packages. I recall some script with a text-mode menu for treating some of their security packages but I never installed any of them. Script might have touched to two files (be there any others??)
Re: Kali?
On Thursday 29 October 2015 12:54:17 Thomas Schmitt wrote: > Hi, > > > I have this as my login title. > > At what point in the chain of events exactly do you see it ? > > A custom text after login is taken from file > /etc/motd > See man 5 motd. > A text before the password prompt might come from > /etc/issue > Learned from file > /etc/pam.d/login > which is mentioned in man 5 motd. > > > Have a nice day :) > > Thomas Issue. Where I got this Kali stuff from, who knows, but now I call it David's Linux. Simple enough. Thanks
Kali?
I have this as my login title. I have NO "Kali" packages installed, but I notice they are on the repos. I somehow picked this up during my "system dorked" adventure. So this is just text, how might I change this to my liking?
Re: System Dorked -- Help! (Interim solution!)
> * * * > > How do I make custom boot menus, kernel, init choices and such using the > > Grub? > > Heh. For just updating the kernel, it's automatic in Wheezy and > beyond. but for other purposes, it's a real riot. You might want to > stay with lilo for the time being. > > But you do want to look closely at what Gene suggests about the > location of your kernel. > > How big is your boot or root partition? (Is it separate?) If you have > only one partition, that's likely to explain a lot of what's > happening, including your observation that large SATA disks seem to > fail too quickly. Point is that I installed with separate partitions and the installer gave me ridiculously sized partitions. When I wanted two kernels around, I had to move to the current partition on the old 80gigger Here is part of df: /dev/sdb29949448443728 8977268 5% / /dev/sda58518920 7303804759336 91% /usr /dev/sda9 942340652 137805424 756643980 16% /opt /dev/sda8 368615 2106342957 1% /tmp /dev/sda62817056 2408016246224 91% /var /dev/sda9 is really home. I have /opt (and also usr/local) bound to home because of so much extra space there and shortage elsewhere. The cache part of /var is symlinked also to a folder on home. Otherwise, I would be absolutely crippled. The other one terra disk, most of which is not damaged, would provide lots of place for a proper /usr and /var, but after the last adventure, what can I do? > > (Unless you are operating at temperature extremes, or in extremely > dusty or humid environments, SATA disks should not fail especially > fast. But a kernel update ending up stored beyond BIOS read limits > could make them appear to fail.) ??
Re: System Dorked -- Help! (Interim solution!)
On Sunday 25 October 2015 08:19:41 Gene Heskett wrote: > On Sunday 25 October 2015 06:57:06 David Baron wrote: > > Using the live disk, went back to the old (failing!) 80gig disk, > > edited back to where I was, bound the /dev and chroot and mounted what > > I needed. > > update-initramfs and lilo worked without any segfault. > > > > So back up. Time to buy another big disk and move stuff or reinstall > > with Jesse. Trouble is these big SATAs are not so great. That 80gig > > IDE which smart claims is pre-failure (but does not totally support) > > predates them all. > > Another thought comes to mind since you mentioned a big disk, but I don't > recall the size if it has been quoted in this thread. > > But In installing linuxcnc (debian wheezy based) on fresh disks, I have > twice now been forced to allocate a /boot partition at the beginning of > a 2 terabyte disk. > > This may not be the reason, but my theory is that by the time the install > gets around to installing grub, (its the last thing it does) its boot > files are too far into the disk for bios/lilo/grub2 to find them, so the > reboot at the end of the install fails. > > The worst part of that is that the partitioner will not accept a 1 > gigabyte partition, which is a great plenty, so I was forced to use 5% > of the disk as a boot partition. > > That is about 47 gigabytes, of which <1% is actually used. Ridiculous, > but it works. Those 3 machines would be happy as clams with a 20 > gigabyte disk. Even SSD's are bigger than that these days. > > So I am left wondering if this might be a solution to your boot problem. > > lilo has been out of favor for a goodly piece of a decade, and with even > grub1 being far more versatile, I am amazed to hear of someone still > using it. I have no clue what its LBA capabilities are in light of the > sizes of todays drives. > > If someone could elaborate on that, it might also be of educational value > here. > > Cheers, Gene Heskett I started with wheezy 64 bit install and grub2. Did not have any clue how it worked but it did. When upgraded to Sid, added a kernel and wanted to keep the older on around just-in-case, I had no idea how to do this with Grub2 so I went back to Lilo. Lilo also makes it easy of have a systemd and older-style init choice, the latter saved me recently. Running afoul of having two 1 terra disks around could have been the problem. I have no understanding of this business. I had no problem reading and writing the partition I wanted to make root. Just could not do anything in it, either chroot or on boot into the system which malfunctioned. How do I make custom boot menus, kernel, init choices and such using the Grub?
Re: System Dorked -- Help! (Interim solution!)
Using the live disk, went back to the old (failing!) 80gig disk, edited back to where I was, bound the /dev and chroot and mounted what I needed. update-initramfs and lilo worked without any segfault. So back up. Time to buy another big disk and move stuff or reinstall with Jesse. Trouble is these big SATAs are not so great. That 80gig IDE which smart claims is pre-failure (but does not totally support) predates them all.
Re: Nouveau Cache Error
On Monday 19 October 2015 22:25:28 Sven Arvidsson wrote: > On Mon, 2015-10-19 at 22:53 +0300, David Baron wrote: > > OK, but these errors are marked by smart so may indicate disk > > problems. > > That seems very, very odd, please post logs. Here is the result of cat /var/log/syslog.1 |grep -i smart: CACHE ERRORs are to what I refer Oct 19 11:19:10 dovidhalevi smartd[907]: Device: /dev/sda [SAT], FAILED SMART self- check. BACK UP DATA NOW! Oct 19 11:19:10 dovidhalevi smartd[907]: Device: /dev/sda [SAT], Failed SMART usage Attribute: 5 Reallocated_Sector_Ct. Oct 19 11:19:10 dovidhalevi smartd[907]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 102 to 107 Oct 19 11:30:48 dovidhalevi spamd[2105]: spamd: processing message <20151019083014.117268.3...@smartphoneexperts.com> for root:65534 Oct 19 11:30:53 dovidhalevi spamd[2105]: spamd: result: Y 6 - BOTNET,HTML_MESSAGE,LOTS_OF_MONEY,RCVD_IN_DNSWL_NONE,RDNS_NONE,T_DKI M_INVALID scantime=5.6,size=21174,user=root,uid=65534,required_score=5.0,rhost=localhost,raddr=::1 ,rport=56444,mid=<20151019083014.117268.3...@smartphoneexperts.com>,autolearn=n o autolearn_force=no Oct 19 11:49:10 dovidhalevi smartd[907]: Device: /dev/sda [SAT], FAILED SMART self- check. BACK UP DATA NOW! Oct 19 11:49:10 dovidhalevi smartd[907]: Sending warning via /usr/share/smartmontools/smartd-runner to root ... Oct 19 11:49:11 dovidhalevi smartd[907]: Warning via /usr/share/smartmontools/smartd- runner to root: successful Oct 19 11:49:11 dovidhalevi smartd[907]: Device: /dev/sda [SAT], Failed SMART usage Attribute: 5 Reallocated_Sector_Ct. Oct 19 11:49:11 dovidhalevi smartd[907]: Sending warning via /usr/share/smartmontools/smartd-runner to root ... Oct 19 11:49:12 dovidhalevi smartd[907]: Warning via /usr/share/smartmontools/smartd- runner to root: successful Oct 19 11:49:12 dovidhalevi smartd[907]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 108 to 109 Oct 19 12:19:10 dovidhalevi smartd[907]: Device: /dev/sda [SAT], FAILED SMART self- check. BACK UP DATA NOW! Oct 19 12:19:10 dovidhalevi smartd[907]: Device: /dev/sda [SAT], Failed SMART usage Attribute: 5 Reallocated_Sector_Ct. Oct 19 12:19:10 dovidhalevi smartd[907]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 7 Seek_Error_Rate changed from 200 to 100 Oct 19 12:19:10 dovidhalevi smartd[907]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 107 to 103 Oct 19 12:49:10 dovidhalevi smartd[907]: Device: /dev/sda [SAT], FAILED SMART self- check. BACK UP DATA NOW! Oct 19 12:49:10 dovidhalevi smartd[907]: Device: /dev/sda [SAT], Failed SMART usage Attribute: 5 Reallocated_Sector_Ct. Oct 19 12:49:10 dovidhalevi smartd[907]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 103 to 106 Oct 19 12:49:10 dovidhalevi smartd[907]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 109 to 108 Oct 19 13:04:05 dovidhalevi systemd[1]: Started Self Monitoring and Reporting Technology (SMART) Daemon. Oct 19 13:04:06 dovidhalevi smartd[904]: smartd 6.4 2014-10-07 r4002 [x86_64- linux-4.0.0-1-amd64] (local build) Oct 19 13:04:06 dovidhalevi smartd[904]: Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org Oct 19 13:04:06 dovidhalevi smartd[904]: Opened configuration file /etc/smartd.conf Oct 19 13:04:06 dovidhalevi smartd[904]: Drive: DEVICESCAN, implied '-a' Directive on line 21 of file /etc/smartd.conf Oct 19 13:04:06 dovidhalevi smartd[904]: Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices Oct 19 13:04:06 dovidhalevi smartd[904]: Device: /dev/sda, type changed from 'scsi' to 'sat' Oct 19 13:04:06 dovidhalevi smartd[904]: Device: /dev/sda [SAT], opened Oct 19 13:04:06 dovidhalevi smartd[904]: Device: /dev/sda [SAT], WDC WD800JB-00ETA0, S/N:WD-WCAHL5220676, FW:77.07W77, 80.0 GB Oct 19 13:04:06 dovidhalevi smartd[904]: Device: /dev/sda [SAT], found in smartd database: Western Digital Caviar SE Oct 19 13:04:07 dovidhalevi smartd[904]: Device: /dev/sda [SAT], is SMART capable. Adding to "monitor" list. Oct 19 13:04:07 dovidhalevi smartd[904]: Device: /dev/sda [SAT], state read from /var/lib/smartmontools/smartd.WDC_WD800JB_00ETA0-WD_WCAHL5220676.ata.state Oct 19 13:04:07 dovidhalevi smartd[904]: Device: /dev/sdb, type changed from 'scsi' to 'sat' Oct 19 13:04:07 dovidhalevi smartd[904]: Device: /dev/sdb [SAT], opened Oct 19 13:04:07 dovidhalevi smartd[904]: Device: /dev/sdb [SAT], WDC WD10EFRX-68PJCN0, S/N:WD-WCC4J3154373, WWN:5-0014ee-25f442d96, FW:01.01A01, 1.00 TB Oct 19 13:04:07 dovidhalevi smartd[904]: Device: /dev/sdb [SAT], found in smartd database: Western Digital Red (AF) Oct 19 13:04:07 dovidhalevi smartd[904]: Device: /dev/sdb [SAT], is SMART capable. Adding t
Re: Nouveau Cache Error
On Monday 19 October 2015 21:43:41 Sven Arvidsson wrote: > On Mon, 2015-10-19 at 22:16 +0300, David Baron wrote: > > Getting Nouveau cache read errors, source from smart. > > Can freeze system (KDE). > > Where is this cache? > > Have plenty of room. > > > > Debian Sid box. > > It's not disk space, it's most likely problem with the graphics driver. > Without knowing specifics, there's quite a few hits on Google for > nouveau and CACHE_ERROR. > > Considering that nouveau is a reverse engineered driver the usual help > is to see if it's fixed with a recent kernel/drm/mesa/xorg driver. > > If it is something that worked before, try older releases and file a > bug against the package that introduced the break. OK, but these errors are marked by smart so may indicate disk problems.
Re: Systemd bybasses fstab mounting root partition(?)
On Monday 19 October 2015 19:21:18 Ivan Boro wrote: > Thats right. > > > When you think about it, it has to be. /etc/fstab is on your root > > filesystem. How do you read that file without knowing where the root > > filesystem is? > > Thank you for the detailed answer. Removed the / entry from fstab - > everything works fine. > Sorry for the mess. > > Ivan Boro Systemd balks at that / entry. Does this mean that it no longer belongs in fstab? Will init startups still work without it?
Nouveau Cache Error
Getting Nouveau cache read errors, source from smart. Can freeze system (KDE). Where is this cache? Have plenty of room. Debian Sid box.
Re: Suddenly Unbootable Systemd
On Wednesday 14 October 2015 11:41:42 Ric Moore wrote: > On 10/14/2015 07:32 AM, David Baron wrote: > > Upgraded some KF5 Baloo packages to fix dorked KDE, rebooted, then bingo. > > > > Boot stops with > > > > lvmetad is not active yet > > > > disk/by-uuid/fca . invalid path or logical > > > > Then a minute-30 second start job runs for a device (differing uuid). > > > > After that, control/D choice. > > > > Control/D will reboot, try again, same thing. > > > > Entering root password gives me a shell but I do not know what to do in > > it. > > I'm suffering the same issue, so thanks for sharing. Running stretch > here, No clue what to do after extensive googling. "/ Ric Could any of the KDE fixes have caused this? Debian bug#801702 I doubt it, but ... What else was recently upgraded that, while I left the systemd/udev stuff alone, might have done something to the initrd? LSB packages? Additionally, I removed an older kernel and some apps to free up space? Was running out on /usr thanks to the darned installation's ridiculous file partitions. Tried moving /usr/share/doc off as I previous did /usr/local. Tried boot with symlink and bind, the same. Since binding /usr/local to another partition did not cause problems before, assume doing the same for doc was not the problem. But tampering with stuff like this could do it. Anyway, at least I can boot using good old init.
Suddenly Unbootable Systemd
Systemd is still 226-4, not upgraded, had been working up until my first boot this morning which booted OK. Upgraded some KF5 Baloo packages to fix dorked KDE, rebooted, then bingo. Boot stops with lvmetad is not active yet disk/by-uuid/fca . invalid path or logical Then a minute-30 second start job runs for a device (differing uuid). After that, control/D choice. Control/D will reboot, try again, same thing. Entering root password gives me a shell but I do not know what to do in it. My second boot option is same kernel but with append="init=/lib/sysvinit/init" This boots up the old way, just fine! Relevant errors in dmesg: :~$ dmesg | grep -i fail *** [ 19.586295] systemd-logind[3346]: Failed to enable subscription: Launch helper exited with unknown return code 1 [ 19.586332] systemd-logind[3346]: Failed to fully start up daemon: Input/output error [ 37.068868] systemd-logind[4387]: Failed to enable subscription: Launch helper exited with unknown return code 1 [ 37.068899] systemd-logind[4387]: Failed to fully start up daemon: Input/output error [ 47.726971] systemd-logind[4595]: Failed to enable subscription: Launch helper exited with unknown return code 1 [ 47.727005] systemd-logind[4595]: Failed to fully start up daemon: Input/output error [ 123.679649] systemd-logind[4850]: Failed to enable subscription: Launch helper exited with unknown return code 1 [ 123.679691] systemd-logind[4850]: Failed to fully start up daemon: Input/output error [ 130.322873] systemd-logind[4873]: Failed to enable subscription: Launch helper exited with unknown return code 1 [ 130.322902] systemd-logind[4873]: Failed to fully start up daemon: Input/output error Running a mostly up-to-date 64 bit Sid box. Easy enough to get back to that root shell if there are any ideas of what to check there.
Re: Doing Dist-Upgrade or Such
> David Baron a écrit : > > Now that the g++ business is largely behind us, want to start upgrading. > > Problem is that with that darned partitioning by the Debian installation, > > there is not enough room on /var to accomplish upgrade of such size. > > Too bad you did trust the Debian installer instead of using LVM and > leaving some space available for future needs. Worth thinking about for > your next installation. > What was presented for LVM did not look any better. Used LVM quite happily on previous installation (converted to it). However, if something goes awry, getting data out can be problematic. > > What can be done about this? > > > > Note that to get an /opt, I bind this to a directory on my over-sized > > home. > > Same for /usr/local! > > These need not be mounted at boot or before home gets mounted so all this > > kludge is well-behaved and transparent. > > You can bind|link|whatever /var/cache/apt/archive to a filesystem with > enough free space. Running it this way right now, seems OK. Question: Is this directory needed at boot, i.e., before home is mounted (why I did not try this first off)?? If it does, can put it back when done. If OK, leave it this way.
Re: Doing Dist-Upgrade or Such
On Sunday 06 September 2015 20:45:02 Joe wrote: > On Sun, 06 Sep 2015 21:54:13 +0300 > > David Baron wrote: > > On Sunday 06 September 2015 09:32:08 David Christensen wrote: > > > On 09/06/2015 02:55 AM, David Baron wrote: > > > > Now that the g++ business is largely behind us, want to start > > > > upgrading. Problem is that with that darned partitioning by the > > > > Debian installation, there is not enough room on /var to > > > > accomplish upgrade of such size. > > > > > > https://lists.debian.org/debian-user/2015/08/msg01056.html > > > > > > > > > David > > > > Thanks, but I know how to, do not want to, reinstall. Should not have > > to do so. > > > > Thinking of moving the /var/tmp KDE stuff elsewhere and symlinking. > > This takes up a large plurality, even majority of /var, not needed > > before login and home is mounted. What about that? > > How close are you? If you upgrade, then clear the package cache, you > minimise the amount of work a dist-upgrade needs to do and maximise the > available space. If that isn't enough, you might manage to upgrade > groups of packages rather than all in one go. If you have a GUI, you > might find synaptic easier for that kind of work than aptitude or > apt-get. > > You don't mention which distribution, but unstable certainly isn't in a > position to fully dist-upgrade at the moment, so I wouldn't have > thought that testing is either. After the g++ earthquake, we still have > the KDE tsunami to deal with. Libreoffice also cannot be upgraded, but > it has recently been in that state twice and recovered fairly quickly, > so it probably isn't a problem. But certainly in unstable, quite a few > packages which were stuck for a few weeks have now upgraded, and I > shifted about fifty this evening. I do an apt-get clear routinely. Just does not get me enough. Yes, unstable. Problem is, longer I wait, the larger the upgrade gets. I am not doing dist- upgrade but so much of the stuff is interrelated that very few smaller groups of packages present themselves. I have about 500 meg available, just does not quite cut it. Libreoffice and Texlive are two large groups. One idea might be to sacrifice them (I do not think I ever used the Tex), upgrade, and then reinstall the libreoffice which should then reinstall without a zillion other things. Maybe safer than playing with /var/tmp which is heavily subscribed by our favorite systemd. A couple of other large but independent packages can also be not upgraded, such as the html kde docs and such.
Re: Doing Dist-Upgrade or Such
On Sunday 06 September 2015 09:32:08 David Christensen wrote: > On 09/06/2015 02:55 AM, David Baron wrote: > > Now that the g++ business is largely behind us, want to start upgrading. > > Problem is that with that darned partitioning by the Debian installation, > > there is not enough room on /var to accomplish upgrade of such size. > > https://lists.debian.org/debian-user/2015/08/msg01056.html > > > David Thanks, but I know how to, do not want to, reinstall. Should not have to do so. Thinking of moving the /var/tmp KDE stuff elsewhere and symlinking. This takes up a large plurality, even majority of /var, not needed before login and home is mounted. What about that?
Doing Dist-Upgrade or Such
Now that the g++ business is largely behind us, want to start upgrading. Problem is that with that darned partitioning by the Debian installation, there is not enough room on /var to accomplish upgrade of such size. What can be done about this? Note that to get an /opt, I bind this to a directory on my over-sized home. Same for /usr/local! These need not be mounted at boot or before home gets mounted so all this kludge is well-behaved and transparent. Trick like this for all of /var, obviously will not play. Any other ideas?? (Actually, apt's part of this is quite small in comparison.)
Re: kde fully broken in debian/testing
I have been upgrading from Sid. So far, what I have is working with some deficiencies. But working. > Am Donnerstag, 30. Juli 2015, 22:34:55 schrieb Gabriel Corona: > > Hi, > > Hello, > yeah, I am still trying to fix it. The problem is, that many version 5 > packages are still not in testing. Instead of this, the repo-maintainers > removed many version-4-packages, so you cannot go back. Sigh! I hope, they > will put it back, as at the moment, KDE is fully unusable. I tried to > install from sid, but the same problem here: packages missing, bad > versions, same pita. > > Somebody told, to use the repo from aptosid, these shall run. > > Hope this will be fixed soon. > > Best > > Hans > > > In fact, I did the update yesterday. It was quite painful but it's now > > > > working OK-ish: > > * You need to move all the plasma packages to the version 5 (I'm > > > >using testing so I had to force the packar manager to use them). > > > > * Check that you have powerdevil, plasma-desktop, kdeartwork, etc in > > > >version 5. > > > > * Purge the old plasma packages. > > > > * You need to restart the session (otheriwse it's compltely broken); > > > > * I added a `kwin` script in my path (doing 'exec kwin_init "$@"). > > > >It's probably not needed if you have updated all your packages but > >at some point I did not have window decoration and adding this > >fixed it. It was probably because I was still using some Plasma 4 > >packages. > > > > * I had to manually launch kbuildsycoca5 (otherwise systemsettings > > > >wouldn't display any configuration panel). > > > > Some remaining issues: > > * systemsettings segaults sometimes but it's mostly working. > > > > * There is not support for XEmbed systray by design: xchat, hexchat, > > > >nm-applet, etc. are quite broken. We're supposed to fill a lot of > >bugs in a log of packages in order to have SNI support in the > >applications. I used trayer [1] in order to have a systray. > > > > Good luck! > > > > [1] http://www.gabriel.urdhr.fr/2015/07/29/i-can-has-systray/ > > > > -- > > Gabriel -- 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/4062598.uTRqIHLhMR@dovidhalevi
One Error Message Down, One to GO
Kept getting warnings about mdir files being changed so copied. Got .lock in procmailrc so maybe this one is done. At least, the error message suggested using lock files (which I thought I had). Now for the expiring/disconnecting/reconnecting eth0. This is operating off a router. I went through the router's configuration, saw nothing about this. So what can I do in any of the Debian network conf files to prevent the disconnect on expire? -- 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/2516940.QdUSzHF2io@dovidhalevi
Re: Frequent Net Disconnect/Reconnect
On Saturday 18 July 2015 21:00:10 Brian wrote: > On Sat 18 Jul 2015 at 22:02:21 +0300, David Baron wrote: > > Has to do with expiry. Never had notifications of this before, however. > > And > > KWallet "clients" ask for a new login each time, which is a pain in the > > ... > > > > I remember configuring something about this a long long time ago. Can > > someone refresh my memory? Ideas? > > Refeshing your memory is not within the remit of -user. Some of us have > difficulty remembering what happened yesterday. > > Would you like to frame your problem in terms of what you did, what > happened etc. etc. The amount of detail you add can only benefit the > quality of the response. Get notices like eth0 up, expires in # seconds. after that, this does occur eth0 disconnected etho connected -- 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/2721721.cjrE0Pzzl2@dovidhalevi
Frequent Net Disconnect/Reconnect
Has to do with expiry. Never had notifications of this before, however. And KWallet "clients" ask for a new login each time, which is a pain in the ... I remember configuring something about this a long long time ago. Can someone refresh my memory? Ideas? -- 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/2530716.jYAhVqGmVz@dovidhalevi
Re: Frequent Network Disconnect/Reconnect
On Wednesday 08 July 2015 14:53:03 claude juif wrote: > Hi David, > > Please tell us more ! > - Wireless or not ? WIred > - Network Manager or not ? Yes > - Hardware ? On board > - Do you have any log messages related to this problem ? Daemon.log is loaded with both eth0.IPv4 and IPv6, various activation states, connections. Times seem to be related to: dhclient: bound to 10.0.0.1 -- renewal in 1574 seconds. this looks familiar, I remember setting something about this a long long time ago. > > Regards, > > 2015-07-08 14:27 GMT+02:00 David Baron : > > On up-to-date 64 bit Sid. This has become a royal pain in the ... > > Sometimes, every few minutes, ... has disconnected, ... has reconnected, > > re- > > enter kwallet password for the email, etc. > > > > Any ideas? > > > > > > -- > > 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/2889283.0gxH3ugpqY@dovidhalevi -- 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/4144401.v4xXCAuNUF@dovidhalevi
Frequent Network Disconnect/Reconnect
On up-to-date 64 bit Sid. This has become a royal pain in the ... Sometimes, every few minutes, ... has disconnected, ... has reconnected, re- enter kwallet password for the email, etc. Any ideas? -- 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/2889283.0gxH3ugpqY@dovidhalevi
Re: Google Chrome and Open-Source derivative listening to me without my approval
On Monday 22 June 2015 12:49:19 Stuart Longland wrote: > On 22/06/15 12:38, Ric Moore wrote: > > On 06/21/2015 06:42 PM, John Hasler wrote: > >> Tim Beelen writes: > >>> How do I find out which application is accessing what device? > >> > >> It's all software. There is no hardware involved at all: they use a > >> virtual device. It works even when the computer is off. Doesn't matter > >> if your machine has a microphone or even any audio input capability. > > > > I would truly like to know how they could manage that. > > All it needs is a little sprinkling of paranoia to do its work. :-) Just because I am paranoid, that does not mean they are not, in fact, after me. However, this seems like a pretty thin hoax to me. On phones, however, this can and is being done. -- 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/1667922.s3gPGoKNBn@dovidhalevi
Re: Is anyone else having trouble sending mail from Jessie?
A shot in the dark: The installation provides a too-small /var partition (among other too-small partitions). Update some packages, fill up some logs and bingo. Try "df." If it shows /var at 100%, that will do it. Run sudo apt-get clean and feel the difference. -- 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/10605026.NDWLIjl67R@dovidhalevi
Re: Moving from a "686-pae" kernel to "amd64"?
If you are starting with a clean disk, do not use the installer's partitioning scheme. Problematic at best. -- 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/2555858.GjuxXJF5l1@dovidhalevi
Re: Upgrading Kernel - Out of Disk Space
On Thursday 12 February 2015 11:31:43 Lisi Reisz wrote: > On Thursday 12 February 2015 09:46:35 Jochen Spieker wrote: > > > I'm not sure why the automatic partitioner didn't provide > > > for enough space for future updates. See below for the relevant logs. > > > > There's been several complaints about similar issues on this list. I am > > not sure whether there were any recent changes in debian-installer to > > solve that. Now there's still time to report bugs before jessie is > > released. > > This has gone on for years, ever since I have installed Debian. Someone > (some people) among the debian-installer developers must, I think, regard > it as a feature, not a bug. It forced me into manual partitioning several > versions back. Before that, I used to solve the problem by partitioning > with the PCLinuxOS installer before installing Debian. At that time, I > couldn't understand dedicated partitioners. ;-) > > Lisi Yeah, yeah. The partitioner provides ridiculous scheme. I moved my root to another disk partition so I can keep more than one kernel. Since the partitioner gave most all the 1 terra to /home, I have /opt and /usr/local bound to directories on that partition. Really absurd. -- 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/2307065.1ZSU8pqsdW@dovidhalevi
Spamassassin Upgraded, Now What?
Ever since my 64-bit fresh install adventure, various things simple are not working, no idea why. I no longer get logcheck emails, for example. The other one, also maybe around exim4, root, involves spamassasin. That upgraded a couple of days ago and lo and behold, I began having the spam stuff actually marked so I could make a kmail filter to dispose of it, could also change my procmailrc to do the same, that is, if the spam would get placed as specified there. However, the day after, the spam was no longer carrying the marks. Manually starting the daemon did not restore them. No idea why it stopped working or how to get it going once again. -- 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/5985032.taKLfBKVkr@dovidhalevi
Re: Query: Deprecated libsystemd0 items, initramfs-1.18 bugs
On Sunday 07 December 2014 13:30:35 Andrei POPESCU wrote: > On Du, 07 dec 14, 12:52:06, David Baron wrote: > > 1. I noticed that several of these are listed as deprecated. What replaces > > them or are they used at all? (Do not want to risk and unbootable, or > > unloginable [SIC] system by simply removing them :-) > > I'm guessing you mean libsystemd-daemon0, libsystemd-login0, etc. > > As per the package description, their functionality has been integrated > in libsystemd0, so it is safe to remove them (I don't have them > installed). So will remove them > > 2. 1.18 has been the current intramf-tools version for quite a while and > > several serious or worse bugs are open. > > And the question is? Is 1.18 safe to upgrade or wait and play it safe? -- 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/5105901.yT5k488Fbr@dovidhalevi
Query: Deprecated libsystemd0 items, initramfs-1.18 bugs
1. I noticed that several of these are listed as deprecated. What replaces them or are they used at all? (Do not want to risk and unbootable, or unloginable [SIC] system by simply removing them :-) 2. 1.18 has been the current intramf-tools version for quite a while and several serious or worse bugs are open. -- 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/806.5tI3PMb2NA@dovidhalevi
Re: Suggestion for systemd and /usr on seperate partition
On Saturday 01 November 2014 22:58:05 Elimar Riesebieter wrote: > * David Baron [2014-11-01 19:13 +0200]: > > On Friday 31 October 2014 13:08:27 Elimar Riesebieter wrote: > [...] > > > > It's your decision. MODULES=most should be okay. BUSYBOX=y is > > > essential. > > > > This is what the install gave me. I have not touched it. > > Where do I tell it to mount /usr? > > No need to. initramfs-tools does it by default. Check dmesg or > journal. > > Elimar New to .118 version? If I upgrade to that, the "Failed to remount" message will no longer happen? -- 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/3824080.Y03NvCI5ZO@dovidhalevi
Re: Suggestion for systemd and /usr on seperate partition
On Friday 31 October 2014 13:08:27 Elimar Riesebieter wrote: > * David Baron [2014-10-31 10:22 +0200]: > > On Thursday 30 October 2014 19:46:26 Elimar Riesebieter wrote: > [...] > > > > To mount /usr at boottime you need to boot with an initramfs. > > > > > > Therefor you need at least > > > > > > ii initramfs-tools 0.118 > > > ii util-linux 2.25.2-2 > > > > > > which are available in sid. I don't know wheather this works on an > > > encrypted /usr, but at the end it works on sysvinit, upstart and > > > systemd. Check the BTS for initramfs-tools and util-linux. > > > > > > Elimar > > > > Cool. I have not yet upgraded to 0.118 because of serious bugs. > > How might I set it up to mount /usr at boot time? > > Just upgrade to sid. Didn't found the way to jessie yet because of > some RC bugs. I am on Sid. This was upgraded from stable install, however. > > (Alternatively: Used to be possible to demand certain modules be > > included in the initrd. Initramfs now defaults to "all/most." I > > used to use "dep." Were some item in /usr... be actually needed at > > boot, could that be specified for inclusion to initramfs?) > > It's your decision. MODULES=most should be okay. BUSYBOX=y is > essential. This is what the install gave me. I have not touched it. Where do I tell it to mount /usr? -- 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/2125337.MWdI8tOeKl@dovidhalevi
