Re: Pycollada doesn't import, even if it is installed.
On 11/29/2017 10:55 PM, John Hasler wrote: Build FreeCad from source. It's easy. They provide exact instructions for building on Debian. You just copy the commands given in the instructions and run them. That's what I ended up doing. It wasn't difficult but also not as easy as it should be. The current package doesn't work with debuild as the FreeCAD instructions say. However, the regular cmake/make cycle works just fine and it's very self-contained, doesn't litter files all over the system. It even works pretty well. It only froze on me every 30 minutes or so. Now, Meshlab is really unstable. Certain commands are instant segfault. Thanks, John. -- Carl Fink c...@finknetwork.com Thinking and logic and stuff at Reasonably Literate http://reasonablyliterate.com
Filter logcheck reboot messages?
Hi all, I'm generally a happy user of logcheck, but it makes a lot of noise at boot time, from kernel messages and startup scripts. There are two problems with this: Firstly, it's a lot of work to go through and create filters for just me - I started once, and gave up. Secondly, I don't actually know, necessarily, which lines are normal, which bits change normally and should be wildcarded, and which bits I should actually be worried about. Has there been any effort to create filters for this? Maybe they could be provided by the kernel-image package? Or are there alternatives to logcheck that deal with this better? This has especially become a problem since I now have a server that only runs part time (it's in my study, it's loud, noisy and generates heat, and only does backups of remote systems at night, so I've set it up with a wake-on-lan cronjob), so it produces these messages every day. Actually two sets, because it's a VM, and the host obviously shuts down too. Thanks, Richard signature.asc Description: OpenPGP digital signature
Re: Gnome strange behavior while typing in some windows
Roberto, I figure out how to trigger and disable the problem and I think it's a BUG. The problem occurs when I press SHIFT + SPACE (together). I went though the list of shortcuts in the Gnome Control Center under Devices ->Keyboard. No shortcut is set for SHIFT + SPACE As I told you before, Input Source Options is set to: "Use the same source for all windows" But the shortcuts to change input, in case it was set otherwise are: SUPER + SPACE and SHIFT + SUPER + SPACE. Before yesterday when I typed SHIFT + SPACE I'd got a space character, now I have this weird behavior that I don't even know what it means. Thank you again for your help. Regards. On Thu, Dec 7, 2017 at 8:51 PM, Paulo Roberto wrote: > I had already checked it as well. > Use the same source for all Windows is checked. > > In the same window or tab it changes the behavior during user (typing). > > Do you know any log that could help? > > > On Thu, Dec 7, 2017 at 6:41 PM, Roberto C. Sánchez > wrote: > >> On Thu, Dec 07, 2017 at 05:51:01PM +, Paulo Roberto wrote: >> >Roberto, >> > >> >The first thing I checked was the layout. >> >Nothing changed. >> >And I don't think is related to shortcut keys, because clicking in a >> >different tab, and the problem >> >goes away for that tab. >> >> Paulo, >> >> In "Region and Language", under "Input Source Options" do you have "Use >> the same source for all windows" or "Allow different sources for each >> window"? >> >> Regards, >> >> -Roberto >> >> -- >> Roberto C. Sánchez >> >> >
Re: (OT) BIOS Can Not Find Disk
Pascal Hambourg composed on 2017-12-07 21:45 (UTC+0100): >>> In the context of a GPT partitioned disk, >> That context was missing from post you're complaining about. > That was your post, and it had plenty enough context : > - BIOS boot partition only exists in GPT You obviously know that. Some others would know that, which means not everyone, including any coming from a web search, would; thus, not enough context for everyone. >> When the (long) entire thread is read, it eventually becomes apparent that >> the >> OP switched back and forth between GPT and MBR. > No, when he suggested to remove the BIOS boot partition, the disk was > GPT all along and hadn't switched to DOS/MBR yet. "All along" would include at a minimum the entirety of Dan's 28 November and 12 December postings on account of his single multiboot project, beginning "Debian 8 and Debian 9 Dual Boot" 12 Nov 2017 22:27:36 -0500 https://lists.debian.org/debian-user/2017/11/msg00443.html then "Installer Can Not Find Root" 18 Nov 2017 21:26:33 -0500 (GMT-05:00) https://lists.debian.org/debian-user/2017/11/msg00633.html not just his/this "BIOS Can Not Find Disk" thread. -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
Re: Upgrading to stretch (jessie-backports question)
On Thu 07 Dec 2017 at 21:02:38 +0100, John Naggets wrote: > On Thu, Dec 7, 2017 at 8:29 PM, Greg Wooledge wrote: > > >> Actually moving on the Debian stretch I would not need anymore the > >> backports because the ZFS packages are included in stretch. So could I > >> just get rid of my backports APT source by deleting my list file > >> beforehand and then simply do a dist-upgrade? > > > > My personal recommendation would be to comment out (or delete) the > > old backports line(s). If in the future you find yourself wanting > > stretch-backports (from buster) then add the new backports line at > > that time. > > I think I will go for that variant as it makes the most sense to me. It doesn't make any difference. The update and upgrade will not get any packages from jessie-backports. But, whatever suits you. > What about third-party APT repositories sources such as for MongoDB, > Nextcloud, etc, would one simply replace "jessie" with "stretch" in > the sources files at the same time as for the official Debian APT > repositories before running a dist-upgrade? By all means. Whether they have stretch versions is a different matter. -- Brian
Re: Gnome strange behavior while typing in some windows
I had already checked it as well. Use the same source for all Windows is checked. In the same window or tab it changes the behavior during user (typing). Do you know any log that could help? On Thu, Dec 7, 2017 at 6:41 PM, Roberto C. Sánchez wrote: > On Thu, Dec 07, 2017 at 05:51:01PM +, Paulo Roberto wrote: > >Roberto, > > > >The first thing I checked was the layout. > >Nothing changed. > >And I don't think is related to shortcut keys, because clicking in a > >different tab, and the problem > >goes away for that tab. > > Paulo, > > In "Region and Language", under "Input Source Options" do you have "Use > the same source for all windows" or "Allow different sources for each > window"? > > Regards, > > -Roberto > > -- > Roberto C. Sánchez > >
Re: BIOS Can Not Find Disk
Le 07/12/2017 à 00:03, Felix Miata a écrit : In the context of a GPT partitioned disk, That context was missing from post you're complaining about. That was your post, and it had plenty enough context : - BIOS boot partition only exists in GPT - type EE is used in GPT protective MBR Anyway, people writing to a thread are not going to keep all the context in all posts. If a disk is GPT, we're not going to repeat that the disk is GPT in every post. Read the whole thread to get the whole context. When the (long) entire thread is read, it eventually becomes apparent that the OP switched back and forth between GPT and MBR. No, when he suggested to remove the BIOS boot partition, the disk was GPT all along and hadn't switched to DOS/MBR yet.
Re: Upgrading to stretch (jessie-backports question)
On Thu, Dec 7, 2017 at 8:29 PM, Greg Wooledge wrote: >> Actually moving on the Debian stretch I would not need anymore the >> backports because the ZFS packages are included in stretch. So could I >> just get rid of my backports APT source by deleting my list file >> beforehand and then simply do a dist-upgrade? > > My personal recommendation would be to comment out (or delete) the > old backports line(s). If in the future you find yourself wanting > stretch-backports (from buster) then add the new backports line at > that time. I think I will go for that variant as it makes the most sense to me. What about third-party APT repositories sources such as for MongoDB, Nextcloud, etc, would one simply replace "jessie" with "stretch" in the sources files at the same time as for the official Debian APT repositories before running a dist-upgrade?
Re: Upgrading to stretch (jessie-backports question)
On Thu, Dec 07, 2017 at 08:17:58PM +0100, John Naggets wrote: > On Thu, Dec 7, 2017 at 6:39 PM, Greg Wooledge wrote: > > > No. Backports have to be specifically requested. > > Aha I get it. So by changing my APT sources.list for backports from > jessie-backports to stretch-backports all my ZFS packages will simply > get upgraded to the official/main Debian (non backports) stretch ZFS > packages? Yes, assuming the package names are the same and the dependencies are satisfied. > Actually moving on the Debian stretch I would not need anymore the > backports because the ZFS packages are included in stretch. So could I > just get rid of my backports APT source by deleting my list file > beforehand and then simply do a dist-upgrade? My personal recommendation would be to comment out (or delete) the old backports line(s). If in the future you find yourself wanting stretch-backports (from buster) then add the new backports line at that time.
Re: Upgrading to stretch (jessie-backports question)
On Thu 07 Dec 2017 at 20:17:58 +0100, John Naggets wrote: > On Thu, Dec 7, 2017 at 6:39 PM, Greg Wooledge wrote: > > > No. Backports have to be specifically requested. > > Aha I get it. So by changing my APT sources.list for backports from > jessie-backports to stretch-backports all my ZFS packages will simply > get upgraded to the official/main Debian (non backports) stretch ZFS > packages? > > Actually moving on the Debian stretch I would not need anymore the > backports because the ZFS packages are included in stretch. So could I > just get rid of my backports APT source by deleting my list file > beforehand and then simply do a dist-upgrade? That's exactly it. -- Brian.
Re: Embarrassing security bug in systemd
Am 07.12.2017 um 15:37 schrieb Roberto C. Sánchez: > On Thu, Dec 07, 2017 at 03:03:44AM -0600, Dave Sherohman wrote: >> >> I no longer have any non-systemd machines handy to verify this on, but >> my memory is that I have *always* been able to use halt/poweroff/reboot >> commands from the console without requiring sudo or entering a password, >> and I've been using Debian since 2000ish, well before systemd was even a >> gleam in some programmer's eye. /sbin/shutdown may have also been >> freely available at the console, but I don't remember that one clearly, >> since I didn't use it all that often once I discovered the others. >> > I just did a fresh install of wheezy (7.11) with all defaults. Here is > what happened: > > testuser@debian:~$ cat /etc/debian_version > 7.11 > testuser@debian:~$ /sbin/reboot > reboot: must be superuser. > testuser@debian:~$ ls -l /sbin/reboot > lrwxrwxrwx 1 root root 4 Jul 14 2013 /sbin/reboot -> halt > testuser@debian:~$ ls -l /sbin/halt > -rwxr-xr-x 1 root root 15184 Jul 14 2013 /sbin/halt > > The situation is basically the same for /sbin/shutdown. Now try CTRL+ALT+DEL on the console. This will reboot your system. See /etc/inittab: # What to do when CTRL-ALT-DEL is pressed. ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now Next, try hitting the power button. This will shut down your system. On systems with acpi support, Debian has been installing acpid + acpi-support-base in the past. See /etc/acpi/powerbtn-acpi-support.sh Next install a display manager, like gdm3 or lightdm. This will allow you shutdown/reboot the system as well. Basically, it was a completely inconsistent mess before systemd. Now you at least have a central place where you can configure your system behaviour. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: Upgrading to stretch (jessie-backports question)
On Thu, Dec 7, 2017 at 6:39 PM, Greg Wooledge wrote: > No. Backports have to be specifically requested. Aha I get it. So by changing my APT sources.list for backports from jessie-backports to stretch-backports all my ZFS packages will simply get upgraded to the official/main Debian (non backports) stretch ZFS packages? Actually moving on the Debian stretch I would not need anymore the backports because the ZFS packages are included in stretch. So could I just get rid of my backports APT source by deleting my list file beforehand and then simply do a dist-upgrade?
Re: Gnome strange behavior while typing in some windows
On Thu, Dec 07, 2017 at 05:51:01PM +, Paulo Roberto wrote: >Roberto, > >The first thing I checked was the layout. >Nothing changed. >And I don't think is related to shortcut keys, because clicking in a >different tab, and the problem >goes away for that tab. Paulo, In "Region and Language", under "Input Source Options" do you have "Use the same source for all windows" or "Allow different sources for each window"? Regards, -Roberto -- Roberto C. Sánchez
[no subject]
Dear owner of http://pixels2portraits.com, I'm the webmaster of https://koacctv.com. I have visited your website http://pixels2portraits.com and found it to be most useful, as such that we want to add a text link to your website on product pages on your choice. Please kindly get back to us with anchor text and link URL that we can place on our website. We'd appreciate it if you place a link back to our site using the following an anchor text "Wholesale Distributor of CCTV" with URL: https://koacctv.com. A little bit about our company: "KOA CCTV specializes in the wholesale distribution of CCTV Cameras, DVRs, Audio & Video Products and Home Innovation. We support many top leading manufacturers and carry all respected lines including Hikvision USA, Samsung WisiNet, Bosch, Western Digital, Seagate HDD, Rachio, Nest, SkyBell, Google Home, Middle Atlantic, Russound, Current Audio, Monitor Audio, OnControls, Ring, Doorbird, Doorking, Kwikset, EzViz, Altronix, DSC, Samsung, Arlington, Louroe Electronics, Key Digital, HD-Wave, Emphasys, Lutron, Pioneer, Denon, HEOS, Boston Acoustics, Nuvo, Legrand, On-Q, Dottie, Panamax, Xantech, ZKAccess, Triplett, BES, Klein Tools, Fibaro, Z-Wave etc." This is NOT SPAM -- this is a one-time reciprocal link request. We have NO INTENTION to email you again. You can also reply to this email with REMOVE in the subject line to make sure we'll NEVER send you any more e-mails in the future. With Best Regards KOA CCTV
Re: Gnome strange behavior while typing in some windows
Roberto, The first thing I checked was the layout. Nothing changed. And I don't think is related to shortcut keys, because clicking in a different tab, and the problem goes away for that tab. It's a very weird scenario. I started writing this e-mail with the problem in the current window and when I got in the third line it went back to normal, and now it just happened again. Another point is that I can type a word with 100 characters, if I type a space or a comma for example, the word persists. If I press a control key (like ESC, or PrintScreen) or click out of the text field the word disappear if I never had written it. I can switch my layout between Portuguese (Brazil) and English (US) but the problem persist independently. Anyway I don't have any shortcut key configuration for changing layout. Thanks for the help. I look forward to hear from you. Regards. Paulo On Thu, Dec 7, 2017 at 5:12 PM, Roberto C. Sánchez wrote: > On Thu, Dec 07, 2017 at 04:07:24PM +, Paulo Roberto wrote: > >If I change window or even tabs, the typing works perfectly in the > new tab > >or window but persists in the previous one when I come back to it. > >The problem comes and goes and I don't know the exact way to > replicate it. > >I start using a tab or window for a while and it happens. > > Paulo, > > It sounds like you might have something going on with your keyboard > layouts and the shortcut key combination that changes the layout. In my > case, I tend to use L_SHIFT+CAPS_LOCK to change from a dead keys layout > to a non-dead keys layout. However, I recently installed Debian on a > new machine and found that the default had changed because the key > combination on the newly installed machine was SUPER+SPACE. > > You may want to check your "Region and Language" settings in GNOME to > see what layouts have key combinations associated with them. That may > tell you why your layout changes when you don't expect it. > > Regards, > > -Roberto > > -- > Roberto C. Sánchez > >
Re: Upgrading to stretch (jessie-backports question)
On Thu, Dec 07, 2017 at 06:37:27PM +0100, John Naggets wrote: > On Thu, Dec 7, 2017 at 6:11 PM, Tom Furie wrote: > > > Is there a reason not to switch to your backports source to stretch at > > the same time as the others? > > If I understand correctly doing that I will end up with the ZFS > packages for unstable (Debian 10) after running a dist-upgrade? Is my > understanding correct? No. Backports have to be specifically requested.
Re: Upgrading to stretch (jessie-backports question)
On Thu, Dec 7, 2017 at 6:11 PM, Tom Furie wrote: > Is there a reason not to switch to your backports source to stretch at > the same time as the others? If I understand correctly doing that I will end up with the ZFS packages for unstable (Debian 10) after running a dist-upgrade? Is my understanding correct? Currently I have the following packages from jessie-backports: ii dh-python2.20170125~bpo8+1 all Debian helper tools for packaging Python libraries and applications ii dkms 2.3-2~bpo8+1 all Dynamic Kernel Module Support Framework ii libnvpair1linux 0.6.5.9-2~bpo8+1 amd64Solaris name-value library for Linux ii libuutil1linux 0.6.5.9-2~bpo8+1 amd64Solaris userland utility library for Linux ii libzfs2linux 0.6.5.9-2~bpo8+1 amd64OpenZFS filesystem library for Linux ii libzpool2linux 0.6.5.9-2~bpo8+1 amd64OpenZFS pool library for Linux ii spl 0.6.5.9-1~bpo8+1 amd64Solaris Porting Layer user-space utilities for Linux ii spl-dkms 0.6.5.9-1~bpo8+1 all Solaris Porting Layer kernel modules for Linux ii zfs-dkms 0.6.5.9-2~bpo8+1 all OpenZFS filesystem kernel modules for Linux ii zfs-zed 0.6.5.9-2~bpo8+1 amd64OpenZFS Event Daemon ii zfsutils-linux 0.6.5.9-2~bpo8+1 amd64command-line tools to manage OpenZFS filesystems
Re: Gnome strange behavior while typing in some windows
On Thu, Dec 07, 2017 at 04:07:24PM +, Paulo Roberto wrote: >If I change window or even tabs, the typing works perfectly in the new tab >or window but persists in the previous one when I come back to it. >The problem comes and goes and I don't know the exact way to replicate it. >I start using a tab or window for a while and it happens. Paulo, It sounds like you might have something going on with your keyboard layouts and the shortcut key combination that changes the layout. In my case, I tend to use L_SHIFT+CAPS_LOCK to change from a dead keys layout to a non-dead keys layout. However, I recently installed Debian on a new machine and found that the default had changed because the key combination on the newly installed machine was SUPER+SPACE. You may want to check your "Region and Language" settings in GNOME to see what layouts have key combinations associated with them. That may tell you why your layout changes when you don't expect it. Regards, -Roberto -- Roberto C. Sánchez
Re: Upgrading to stretch (jessie-backports question)
On Thu, Dec 07, 2017 at 06:02:04PM +0100, John Naggets wrote: > Should I for example before doing the dist-upgrade to stretch delete > the APT jessie-backports source? or should I simply leave it and do a > dist-upgrade as usual? Is there a reason not to switch to your backports source to stretch at the same time as the others? Cheers, Tom -- If I traveled to the end of the rainbow As Dame Fortune did intend, Murphy would be there to tell me The pot's at the other end. -- Bert Whitney signature.asc Description: Digital signature
Upgrading to stretch (jessie-backports question)
Hi, I am currently using Debian 8 and have enabled the jessie-backports repository with the following line in /etc/apt/sources.d/backports.list: deb http://ftp.debian.org/debian jessie-backports main contrib The only reason for this is that I am using ZFS on jessie for some data disks/partitions. Now I would like to do a dist-upgrade from jessie to stretch and was wondering how to handle the jessie-backports. Should I for example before doing the dist-upgrade to stretch delete the APT jessie-backports source? or should I simply leave it and do a dist-upgrade as usual? Best regards, John
Gnome strange behavior while typing in some windows
Since yesterday my Gnome started to present some weird behavior in random Windows. While I'm typing in Terminator or Firefox, for example, everything I type get underlined until I press some key that represents a blank character (enter, space, etc or parentheses, comma, or other non letter number chars). When the window has this issue I can't type words with accent, the accent always appears after the word. While in fields with auto complete (example Firefox text fields), the auto complete doesn't work, If I insert the blank character it works. In Terminator, when I press CTRL +SHIFT +X the problem is solved and the typing comes back to normal in the specified Windows or tab. In Firefox I don't know how to solve it. If I change window or even tabs, the typing works perfectly in the new tab or window but persists in the previous one when I come back to it. The problem comes and goes and I don't know the exact way to replicate it. I start using a tab or window for a while and it happens. Version of my Gnome Shell gnome-shell 3.26.2-1 I can't even take a snapshot of the problem, because when I press the Print Screen key, the word I was typing disappear and then the screenshot happens. If I click outside the place of the current keyboard focus in the middle of a word (without inserting the blank character) the current word also disappear. Thanks in advance. I look forward to hear from you guys. Paulo Roberto.
Re: Embarrassing security bug in systemd
On Thu, Dec 07, 2017 at 03:03:44AM -0600, Dave Sherohman wrote: > > I no longer have any non-systemd machines handy to verify this on, but > my memory is that I have *always* been able to use halt/poweroff/reboot > commands from the console without requiring sudo or entering a password, > and I've been using Debian since 2000ish, well before systemd was even a > gleam in some programmer's eye. /sbin/shutdown may have also been > freely available at the console, but I don't remember that one clearly, > since I didn't use it all that often once I discovered the others. > I just did a fresh install of wheezy (7.11) with all defaults. Here is what happened: testuser@debian:~$ cat /etc/debian_version 7.11 testuser@debian:~$ /sbin/reboot reboot: must be superuser. testuser@debian:~$ ls -l /sbin/reboot lrwxrwxrwx 1 root root 4 Jul 14 2013 /sbin/reboot -> halt testuser@debian:~$ ls -l /sbin/halt -rwxr-xr-x 1 root root 15184 Jul 14 2013 /sbin/halt The situation is basically the same for /sbin/shutdown. Regards, -Roberto -- Roberto C. Sánchez
Debian Jessie: Issue with Samba 4 as PDC with NTPd and Windows 7 clients
Hello there, debian is the best - when it works :-) Maybe someone of you will have an idea. I've run into an issue with time synchronisation on windows 7 clients in a samba 4 ad domain. Setup is as follows: Server is running debian jessie with samba 4 as PDC and NTPd. I followed the tutorial at https://wiki.samba.org/index.php/Time_Synchronisation to the letter. File sharing, user logins etc. works great. And time snychronisation does work between the PDC and other servers and unix clients. But time synchronisation does NOT work with windows 7 clients (w32tm). I checked with tcpdump, the windows client is sending a message but the server nerver responds to the windows client. Other request are handled fine. However, if i start NTPd as root, now the windows clients do get a response back. I assumed a permission problem with the signd socket. However it is setup as requested by the tutorial to: drwxr-x---+ 2 root ntp 4096 Dec 6 19:47 ntp_signd and the socket itself to: srwxr-xr-x 1 root root 0 Dec 6 19:47 socket For tests changing the permissions on ntp_signd 777 does not work. Only starting the ntpd as root produces answers to the windows clients. This seems wrong to me. Any ideas on how to fix this would be greatly appreciated. Cheers Jens
Re: on-screen artifacts (red pixels) at high resolution with Intel HD 630 (Kaby Lake)
On Thu, Dec 07, 2017 at 05:20:41PM +0500, Alexander V. Makartsev wrote: > > There was a microcode bug discovered recently in Kabylake-Skylake CPUs. > It causes memory corruption if I remember it correctly. It could be > fixed for certain CPUs by updating firmware for your motherboard or > installing "intel-microcode" package. It could be the cause for your issue. > thread for reference :) https://lists.debian.org/debian-user/2017/06/msg01010.html -- I'm just a placeholder for a really awesome signature... ...that is still missing *sob* signature.asc Description: PGP signature
Re: on-screen artifacts (red pixels) at high resolution with Intel HD 630 (Kaby Lake)
On 07.12.2017 16:33, Alexandre Rossi wrote: > (please CC me as I am not subscribed to the list) > > Hi, > > I am experiencing on-screen artifacts (red dots) when running at > 1920x1080 on HDMI out. I've ruled out a hardware (cable, TV or GPU) > issue by installing win10 which does not show those problems. > > This is by using stretch, issue occurs with both kernel 4.9 or 4.13 > available in the backports. The hardware is intel HD 630 (Kaby Lake). > Xorg uses the modeset driver. > > I was wondering where to get help regarding whether this is a bug : > - xorg? > - kernel i915? > - kernel drm? > - other component? > > Thanks, > > Alex > A screenshot would be helpful. Does these artifacts appear every single time or sporadically? I'd suggest to check RAM first of all with `memtest86+` and let it run overnight. Not sure if test will get into memory area used as video memory though. There was a microcode bug discovered recently in Kabylake-Skylake CPUs. It causes memory corruption if I remember it correctly. It could be fixed for certain CPUs by updating firmware for your motherboard or installing "intel-microcode" package. It could be the cause for your issue. -- With kindest regards, Alexander. ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org ⠈⠳⣄
on-screen artifacts (red pixels) at high resolution with Intel HD 630 (Kaby Lake)
(please CC me as I am not subscribed to the list) Hi, I am experiencing on-screen artifacts (red dots) when running at 1920x1080 on HDMI out. I've ruled out a hardware (cable, TV or GPU) issue by installing win10 which does not show those problems. This is by using stretch, issue occurs with both kernel 4.9 or 4.13 available in the backports. The hardware is intel HD 630 (Kaby Lake). Xorg uses the modeset driver. I was wondering where to get help regarding whether this is a bug : - xorg? - kernel i915? - kernel drm? - other component? Thanks, Alex
Re: Embarrassing security bug in systemd
On Thu, Dec 07, 2017 at 10:02:56AM +, Tixy wrote: I'm running Jessie (with systemd running but booting with sysvinit) and trying to execute halt/poweroff/reboot/shutdown from a terminal without root privileges gives an error saying I must be superuser. Which has always been my experience in 10 years of using Debian. Be careful to double check what you are testing: in your situation it's not clear whether /sbin/reboot is a symlink to systemctl (part of systemd, so I would expect this not to work if you were not running systemd as the init system) or a separate binary. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to the list.
Re: Embarrassing security bug in systemd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Dec 07, 2017 at 03:03:44AM -0600, Dave Sherohman wrote: > On Thu, Dec 07, 2017 at 11:26:45AM +1300, Ben Caradoc-Davies wrote: > > Special privileges have been granted to console users for as long as I can > > remember, long before systemd, because they have physical access to the > > machine. Console users typically are also permitted to mount, unmount, and > > eject removable media, and have access to audio devices. > > I think this is a key point that's been overlooked in the complaints > about this behavior: It has nothing to do with systemd. No. It has to do with polkit & friends. On my system (which is a pretty "classic" setup: no systemd, but also as little as possible from all this more "modern" desktop stuff, which I don't like very much [1]), /sbin/halt *wants* me to be root. This isn't inherently more secure (or less) but just The Way it Is (TM) -- an heritage from times *every* user on an Unix system was remote. The policy kit and its descendants try to make a guess whether the user is "physically present" to allow them to shut down the computer. As others have pointed out, this does make sense (as long as the above guess is sufficiently accurate, that is), because the user can pull the cord/extract the batteries/smash the box anyway. Now to that guess: for your vanilla PC/laptop/tablet/smartphone class of machine, if the user is at the console or the local terminal, implying presence is a pretty accurate guess. That's why the default configuration comes shipped as it is. If you are installing an ATM/voting computer/AS400, I'd hope that, as a system integrator you *know what you are doing* and set the defaults appropriately. So all is well. This isn't a bug. For someone coming from "traditional" Unix, this might be unexpected (and has thus some potential for damage), but that expectation hasn't been broken by systemd this time. There are Linux distros for big IBM iron: anyone cares to have a look how the default policy settings are there? (As that's SuSE's realm, mainly, I'd guess they are similar enough to RedHat that they're using something along these lines). Cheers [1] Don't take me wrong. Those desktop thingies have their place. Just not on "my" desktop, dammit :-) - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlopFhsACgkQBcgs9XrR2kaUcwCeMgdvqAWryzSSxE5W3r8+Ol2o NE8AnAlA3wWeb2dJ4xdTN5Cyy+3Al/PT =xit+ -END PGP SIGNATURE-
Re: Embarrassing security bug in systemd
On Thu, 2017-12-07 at 03:03 -0600, Dave Sherohman wrote: > > I no longer have any non-systemd machines handy to verify this on, but > my memory is that I have *always* been able to use halt/poweroff/reboot > commands from the console without requiring sudo or entering a password, > and I've been using Debian since 2000ish, well before systemd was even a > gleam in some programmer's eye. I'm running Jessie (with systemd running but booting with sysvinit) and trying to execute halt/poweroff/reboot/shutdown from a terminal without root privileges gives an error saying I must be superuser. Which has always been my experience in 10 years of using Debian. >From a desktop environment it's usually been possible to shut a machine down from a menu option, though at least on one release I ended up having to hack some policy config to allow that to work. -- Tixy
Re: Embarrassing security bug in systemd
On Thu, Dec 07, 2017 at 11:26:45AM +1300, Ben Caradoc-Davies wrote: > Special privileges have been granted to console users for as long as I can > remember, long before systemd, because they have physical access to the > machine. Console users typically are also permitted to mount, unmount, and > eject removable media, and have access to audio devices. I think this is a key point that's been overlooked in the complaints about this behavior: It has nothing to do with systemd. I no longer have any non-systemd machines handy to verify this on, but my memory is that I have *always* been able to use halt/poweroff/reboot commands from the console without requiring sudo or entering a password, and I've been using Debian since 2000ish, well before systemd was even a gleam in some programmer's eye. /sbin/shutdown may have also been freely available at the console, but I don't remember that one clearly, since I didn't use it all that often once I discovered the others. But, then, even if I'm remembering incorrectly, it's still a policy matter, not a technical one. If the policy was changed at the same time as Debian switched to systemd, that's just a coincidence of timing and the same policy change could have happened while still under sysvinit. -- Dave Sherohman
Re: Embarrassing security bug in systemd
On Wed, 6 Dec 2017 17:35:18 -0500 Michael Stone wrote: > On Wed, Dec 06, 2017 at 10:52:17PM +0100, 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... > > It's a feature. Users at the console can reboot, on the theory that > if someone's sitting at the laptop they could also just push the > power button... > I think the point here is that it never used to be, and I don't recall any publicity about the change. Of course, I'm a mere user, not a developer but I do read changelogs, and I've never seen it there. I've used a server since sarge, and never had the slightest trace of a GUI installed. I would therefore consider myself a console user, and I always had to use sudo to shutdown or reboot, or su on a new installation. There was never any difference, local or remote. Several years ago, I used to use LXDE on my workstation (between the introductions of Gnome3 and systemd on unstable, to date it) and one day it would not shut down from the desktop applet. I needed to open a terminal to shutdown, and *then* I needed to use sudo and a password. After doing it for a while with no fix, I switched to Xfce, which I've used since, for this precise reason. So it certainly used to work the other way around: DEs had workarounds so that root or sudo was not necessary to power off, but the console command did need root privileges. It may be different now, but it's a long time since I accidentally issued a shutdown command without root privileges, and I'm not going to do it at the moment. -- Joe
