Re: "Ethernet trouble" thread

[Tom H]

On Mon, Feb 3, 2020 at 2:54 PM Greg Wooledge  wrote:
> On Sat, Feb 01, 2020 at 05:45:26PM +0100, Tom H wrote:
>>
>> You state that it's no longer udev that renames NICs. The following's
>> from a sid VM using svsinit+sysvrc.
> [...]
>> udev is renaming "eth0".
>>
>> You can still use "/etc/udev/rules.d/" to rename NICs. Just like with
>> "/etc/systemd/network/*.link", you gain simple names linked to a NIC's
>> MAC address, but lose the predictable names' advantage that swapiing
>> out a NIC preserves its name.
>
> Yes, it MIGHT still work. Or it might not. Support for it has
> been officially removed. Whatever the 70-persistent-net.rules file
> does on your system is unique to your system.
>
> https://wiki.debian.org/NewInBuster#Network_interface_name_migration
>
>  "The buster release notes warn that the
>  /etc/udev/rules.d/70-persistent-net.rules method for assigning
>  persistent network interface names is no longer supported."
>
> https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#migrate-interface-names
>
>  "If your system was upgraded from an earlier release, and still uses
>  the old-style network interface names that were deprecated with stretch
>  (such as eth0 or wlan0), you should be aware that the mechanism of
>  defining their names via /etc/udev/rules.d/70-persistent-net.rules is
>  officially not supported by udev in buster (while it may still work
>  in some cases)."

Thanks. Even though this is the official policy/statement, I don't buy it.

The problem's that "70-persistent-net.rules" has been used to rename
NICs within the kernel "ethX" namespace. Until udev upstream declares
the "SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="mac_address",
NAME="net0" syntax and mechanism deprecated/obsoleted, I'll assume
that the Debian release notes and wiki are wrongly melding the fact
that renaming a NIC to "ethX" is deprecated (and that it might not
work in the future), with the fact that
"/etc/udev/rules.d/.rule" can still be used to associate a
NIC's MAC address with a name.

AMD 10.2 netinstall

[tom h]

Hello,

Recently I have installed stable on a few old optiplex workstations that
have an AMD graphics card.  On first boot I always get a black screen and
have to:

   1. Enable non-free
   2. Install firmware-linux-nonfree. Even though the netinstall media is
   firmware-10.2.0-amd64-netinst.iso
   


I see references to the AMD driver existing in the kernel and thought it
would load at boot time.

What am I missing?

Cheers,

package install: pinning and warnings

[tom h]

So I've got a test box that I have sid installed on and the following in my
/etc/apt/preferences

Package: *
Pin: release a=unstable
Pin-Priority: 1000

Package: *
Pin: release a=testing
Pin-Priority: 100

I also have these two packages installed:
sapt-listbugs apt-listchanges

I went to install libvirt and received a number of bug warnings so I
was hesitant.

Whats the best practice to get a package and NOT install the bug
versions?  Raise the priority of

the testing branch temporarily?

Thanks!

Re: An experiment in backup

[Tom H]

On Mon, Jan 19, 2015 at 1:02 PM, Kevin O'Gorman  wrote:
On Sun, Jan 18, 2015 at 9:26 AM, Tom H  wrote:
On Fri, Jan 16, 2015 at 10:28 PM, Kevin O'Gorman  wrote:
> On Fri, Jan 16, 2015 at 3:54 AM, Tom H  wrote:
>>
>> Have you looked at the logs? Especially Xorg.0.log and xsessions-errors.
>
> Xorg logs seem normal
> I don't see any xsessions-errors file

~/.xsessions-errors

Xsession: X session started for kevin at Sat Jan 17 10:42:34 PST
2015localuser:kevin being added to access control list
openConnection: connect: No such file or directory
cannot connect to brltty at :0
Script for ibus started at run_im.
Script for auto started at run_im.
Script for default started at run_im.
Unable to create /home/kevin/.dbus/session-bus
Script for ibus started at run_im.
Script for auto started at run_im.
Script for default started at run_im.
x-session-manager[1414]: CRITICAL: We failed, but the fail whale is dead.
Sorry

What are the owner and mode of the ".dbus" and "session-bus" dirs?

Re: An experiment in backup

[Tom H]

On Fri, Jan 16, 2015 at 10:28 PM, Kevin O'Gorman  wrote:
> On Fri, Jan 16, 2015 at 3:54 AM, Tom H  wrote:


>> Are you using a DM?
>
> A what? Xubuntu uses xfce4 if that answers the question.

DM = display manager

On Ubuntu, lightdm is the default DM.


>> Are you using a WM or a DE?
>
> A what?

WM = window manager

DE = desktop environment; in your case XFCE


>> Have you looked at the logs? Especially Xorg.0.log and xsessions-errors.
>
> Xorg logs seem normal
> I don't see any xsessions-errors file

~/.xsessions-errors


>> Can you launch X after logging in to the console?
>
> I don't know how.

You can check that the basic functionality of X is OK with
xinit /usr/bin/xterm -- /usr/bin/X :0 -nolisten tcp vt01
(assuming that you're on tty1 when launching X)

Otherwise, you can start X with
xinit [...]
startx [...]
service lightdm [re]start


-- 
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/CAOdo=SzCMuz+ssPHE6S3-WgtRS104JWey1uKMKYVhKK3Nn=z...@mail.gmail.com

Re: An experiment in backup

[Tom H]

On Thu, Jan 15, 2015 at 10:19 PM, Kevin O'Gorman  wrote:
>
> I have a tar backup of the entire system, excluding /sys, /proc and /dev.
> I have a tar backup of a bind-mount of /dev.
> These were taken while the system was running, but quiet. I did it this
> way because I cannot get the system to boot into single user mode. Putting
> "single" on the end of the "linux" like results in a black screen.
>
> I restored these, created /sys and /proc, and tried to boot the resulting
> partition. It boots, but X does not come up, or even seem to try. I can do
> a console login to my usual account, and stuff is there.

What commands did you run to back up and restore the system?

Is '/tmp' a tmpfs filesystem? If not, did you back up and restore it?

Did you exclude '/run'? If not, did you restore it?

Did you create '/proc' and '/sys' with the right ownership and mode?

If this is a Debian system, is it a non-standard install that doesn't
use udev (AFAIK this is still possible)? If not, there's no point in
backing up and restoring '/dev'.

If this is an Ubuntu system, the default '(recovery)' grub entry will
have 'nomodeset' appended. Try that when you add 'single'.

Are you using a DM?

Are you using a WM or a DE?

Have you looked at the logs? Especially Xorg.0.log and xsessions-errors.

Can you launch X after logging in to the console?


-- 
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/CAOdo=swjn5qggmjo7qta_2otefqgzihwpn35hykxshk4_oa...@mail.gmail.com

systemctl disable/mask

[Tom H]

On 28 Sep 2014 04:35:03 +0200, lee  wrote:
>
> Anyway, it gives me to think that such a misunderstanding has come
> up to begin with and that it hasn't been fixed long ago. Someone who
> doesn't understand what "disabled" means is programming an init
> system: What other misunderstandings might have gone into it? Why
> obfuscate things and mislead and confuse the users?

I was scrolling last night through the debian-user@ archives, looking
for a non-systemd thread, and clicked on this post [1] through a
fat-fingered error. (I unsubscribed a few weeks ago because a group of
anti-systemd trolls have hijacked the list and are spamming it with
BS.)

You're angered by the fact that the systemd developers have chosen
"systemctl disable service" to mean "disable at boot" and "systemctl
mask service" to mean "disable completely".

Since you use both Debian and Fedora, have you ranted or filed a bug
about the fact that:

- "apt-get update" means "update the local cache" and "yum update"
means "update the local cache and upgrade all the packages to their
latest versions"

- "apt-get update" and "yum makecache" both mean "update the local cache"

- "apt-get dist-upgrade" means "upgrade all the packages to their
latest versions" and is therefore more less equivalent to "yum update"
(if you pre-run "yum makecache", "apt-get dist-upgrade" and "yum -C
update" are equivalent)

- "apt-get upgrade" doesn't have a Fedora equivalent

- "apt-get dist-upgrade" could be considered ambiguous, it could mean
"upgrade to the latest version of the distro" or "upgrade to the next
version of a distro" (perhaps you could suggest "apt-get
release-upgrade" for the latter so as to avoid this ambiguity...)

Furthermore, the MO that the systemd developers have chosen has a
precedent. In "/etc/modprobe.conf" and "/etc/modprobe.d/":

- if you use "blacklist module", the module won't be loaded but it can
be loaded manually or as a dependency

- if you use "install module /bin/true" that module won't be loaded at all

Have you ranted or filed a bug about this because, to paraphrase you,
the modprobe developers don't know what "blacklist" means?

I can understand that some people dislike systemd but complaints like
this one weaken their already-weak case and make the anti-systemd
whiners look like a bunch of clueless lunatics.

[1] https://lists.debian.org/debian-user/2014/09/msg02105.html


-- 
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/CAOdo=SwHv3fpfc3CtQJzGnOFZFY=XWRjGh=xmhjsj-wtjql...@mail.gmail.com

Re: Choose your side on the Linux divide

[Tom H]

On Mon, Aug 25, 2014 at 6:44 PM, Steve Litt  wrote:
>
> http://www.infoworld.com/d/data-center/choose-your-side-the-linux-divide-248950?source=IFWNLE_nlt_daily_pm_2014-08-25

There's a OT list for this BS.


-- 
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/CAOdo=szec1nsbphorp6b4zplmaurounwgyyvrlxpm_gdpuz...@mail.gmail.com

Re: Help: Ubuntu 12.04LTS/14.04LTS PXE/netboot/preseed - does not initiate installation

[Tom H]

On Mon, Aug 25, 2014 at 3:10 AM, Snow Leopard
 wrote:
>
> I stumbled on a problem with Ubuntu installation PXE/netboot/preseed.
>
> OS: Ubuntu 12.04LTS/14.04LTS
>
> I have setup for DHCP/TFTP/NFS which allows me to boot over network "Live
> Ubuntu" and everything works as it should.
>
> Next logical step would be automatic installation by utilizing "preseed"
> file. And here I hit a snag -- Ubuntu copies the file but I do not see any
> attempt to start installation (search on internet give multiple examples and
> most of them look alike but do not work in my case).
>
> ...
> Found 2 package indexes, 0 source indexes, 0 translation indexes and 1 
> signatures
> ...
> W: Skipping nonexistent file /cdrom/dists/precise/main/binary-i386/Packages
> W: Skipping nonexistent file
> /cdrom/dists/precise/restricted/binary-i386/Packages

(There's an ubuntu-users list for Ubuntu questions.)

Are you sure that an Ubuntu Live DVD can be used for preseeding? I've
never seen it before but maybe it is...

Your problem MIGHT be that it finds "indexes" but doesn't find
"Packages", if "indexes" are indeed "Packages.gz".

>From a loop-mounted 14.04.1 Live DVD:

# find . -name "*Packages*"
./dists/trusty/main/binary-amd64/Packages.gz
./dists/trusty/main/binary-i386/Packages.gz
./dists/trusty/restricted/binary-amd64/Packages.gz
./dists/trusty/restricted/binary-i386/Packages.gz


-- 
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/CAOdo=szj75cog7bf3t4qwh55nt9tsatmqphqp1wlw4wbqwh...@mail.gmail.com

Re: I hate network-manager (was /etc/rc.local and systemd)

[Tom H]

On Sun, Aug 24, 2014 at 6:00 PM, Stephen Powell  wrote:
> On Sun, 24 Aug 2014 15:44:26 -0400 (EDT), David Baron wrote:
>> On Sunday 24 August 2014 11:45:40 Stephen Powell wrote:


> I have a static route command in my /etc/rc.local file to define
> a route to another network. I won't go into the reasons for why
> it's there. Suffice it to say that there's a reason for it.
>
> But the command is
>
> route add -net 192.168.1.4 netmask 255.255.255.252 gw 192.168.0.2 metric 2
>
> At some point, I issued the command
>
> netstat -rn
>
> to see if my static route was there. It wasn't. I therefore
> concluded (erroneously, as it turned out) that /etc/rc.local
> had not been executed. But it had. The culprit turned out to
> be network-manager. The default installation of Debian for a
> desktop system (XFCE in my case) installs both ifupdown and
> network-manager. It allows ifupdown to manage only the local
> loopback interface (lo) and allows network-manager to manage
> everything else, including the wired ethernet interface (eth0).

The default "/etc/NetworkManager/NetworkManager.conf" has
[ifupdown]
managed=false
so if you have a nic defined in "/etc/network/interfaces", NM'll ignore it.

You can set the route in "/etc/network/if-up.d/" and the script'll be
run by ifupdown and NM, whichever's bringing up eth0.

For an NM-only solution, you can set the route in
"/etc/NetworkManager/dispatcher.d/".


> I have changed this and have given ifupdown control of the eth0
> interface. But network manager insists on creating an "eth0"
> connection on every start-up. If I right-click on the network-
> manager icon, then left-click on "Edit Connections", I see two
> connections listed. One is "ifupdown (eth0)" and the other is
> simply "eth0". (I have "managed=true" in the [ifupdown] section
> of /etc/NetworkManager/NetworkManager.conf.) I then select
> the "eth0" connection and click on the "Delete" button. The
> connection disappears, and "ifupdown (eth0)" becomes the default
> connection. Everything works fine. Except for two things.

"ifupdown (eth0)" means that NM is managing eth0 as defined in
"/etc/network/interfaces"; and that's because of "managed=true".


-- 
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/CAOdo=swlfpfn7vvm2z9kmta_rex+asr3lzq4ub8bcdafq+2...@mail.gmail.com

Re: /etc/rc.local and systemd

[Tom H]

Resending to the list


On Sun, Aug 24, 2014 at 2:12 PM, Erwan David  wrote:
> Le 24/08/2014 19:31, Tom H a écrit :
>>
>> With v208, there's a generator,
>> "/lib/systemd/system-generators/systemd-rc-local-generator", that
>> creates a symlink at boot in
>> "/run/systemd/generator/multi-user.target.wants/" so you don't need
>> the above.
>
> And with the *definitive* version ?
>  Or is systemd still under development ?

It's evolving in the same way that the kernel (for example) is. I
*VAGUELY* remember reading the commit message for the initial cut of
rc-local-generator and IIRC it was because there was an issue with
calling and ordering rc.local pre-generator.

This change is transparent to a user, except possibly in boot speed,
so it doesn't matter.


--
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/CAOdo=swwvym4g+goh1r-hk2-au3prwdw2y3narh8rg5nxyd...@mail.gmail.com

Re: /etc/rc.local and systemd

[Tom H]

On Sun, Aug 24, 2014 at 11:45 AM, Stephen Powell  wrote:
>
> I just thought I'd pass along something that I recently discovered.
> When using sysvinit as the init system, if the file /etc/rc.local
> exists and is executable, it will be invoked at the tail end of the
> boot process. But under systemd, this file is not executed during
> boot. Not by default anyway. Here is how I enabled it. (The
> following commands are executed as root.)
>
> cd /lib/systemd/system/multi-user.target.wants
> ln -s ../rc-local.service rc-local.service
>
> Now shutdown and reboot. /etc/rc.local will get executed this time.
> If this is the "wrong" way to do it, or someone knows a better way,
> please let me know.

With v204, it's better to use "systemctl enable rc-local.service" or
to create a symlink in "/etc/systemd/system/multi-user.target.wants/"
(the systemctl command does that).

With v208, there's a generator,
"/lib/systemd/system-generators/systemd-rc-local-generator", that
creates a symlink at boot in
"/run/systemd/generator/multi-user.target.wants/" so you don't need
the above.


-- 
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/CAOdo=sy5ztmx5tys2ztgrjlnsepgezmsse_qkccfs8qcgvr...@mail.gmail.com

Re: sysvinit->systemd transition details

[Tom H]

On Sat, Aug 23, 2014 at 5:24 PM, Alexandre Ferrieux
 wrote:
> On Saturday, August 23, 2014 3:00:02 PM UTC+2, Brian wrote:
>> On Fri 22 Aug 2014 at 17:20:03 -0700, Alexandre Ferrieux wrote:


>>> I have a Jessie-based system, which up to the last upgrade used
>>> sysvinit of course, and where I had added sysv-rc-conf, and was
>>> happily juggling with a few runlevels.
>>>
>>> But after an upgrade (still in Jessie), systemd rules. No problem
>>> about this, but what degree of compatibility should I expect ?
>>> Specifically, is there some automated mechanism that would:
>>
>>> - extract initdefault from inittab and do a "systemctl set-default
>>> runlevelX.target"
>>> - scan /etc/rcX.d and do the appropriate "systemctl enable" for all S
>>> scripts
>>
>> Systemd doesn't use /etc/inittab.
>
> Sure, but if the systemd packaged by Debian goes through the hassle of
> defining runlevelX.target, it might have made sense to carry the initdefault 
> along.

The "runlevelX.target" units exist upstream.


>>> If the answer is "no", why is sysv-rc-conf still tolerated under
>>> systemd?
>>
>> For backwards compatibilty?
>
> Well, it's a strange form of backwards compatibility. The net result is that 
> the
> upgrade instantly broke my system. I am not talking about switching from 
> wheezy
> to jessie, I was already in jessie.

How does "sysv-rc-conf" interact with systemd? Isn't it still
available in jessie for use with sysvinit (only)?


-- 
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/CAOdo=Sxaei06JCPDuh6GqSMejt_=rogb1vgguttwymk-aqv...@mail.gmail.com

Re: Got skype 4.2 to connect again

[Tom H]

On Wed, Aug 20, 2014 at 1:02 PM, Tom H  wrote:
>
> Edit build/DEBIAN/control and bump up "Version: " (or create
> a "Version" line of it doesn't exist because dpkg-deb needs it but
> dpkg-buildpackage doesn't so it might not be there).

I felt that this was nonsense when I wrote it but I was in too much of
a hurry to reread it and think about it.

If you're getting "control" from a deb, it'll have a "Version" line. Sorry.


-- 
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/CAOdo=syzn1nblsbrxjshikregubj+qa7v7kgdwwbdrpxrry...@mail.gmail.com

Re: Got skype 4.2 to connect again

[Tom H]

On Wed, Aug 20, 2014 at 4:53 AM, Hans  wrote:
>
> just another thing relating to this. I would like to repack the debian package
> and would like to change these in the package:
>
> - changelog
> - skype binary
>
> I tried dpkg-deb -x and also with -e, but I guess, this is wrong, as it did
> not work (or I did not understand the manual correctly).
>
> The repackage is needed for my own purposes, as I added skype in my Germanized
> version of my own KALI-Linux build (see: http://www.ccpeine.de/?p=1152).
>
> Of course, I can figure it out for myself after some time, but a little help
> would be nice.
>
> Is repacking correcting all gpg keys to the new version (check at unpack???),
> or do only repo masters verify complete packages?

Download the skype deb.

(This is just thinking it through without testing it...)

Expand it with ar (rather than with dpkg).

mkdir -p build/DEBIAN

tar -xzf control.tar.gz -C build/DEBIAN

tar -xzf data.tar.gz -C build
(it could be .bz or .xz)

Edit build/share/doc/skype/changelog.Debian.gz to
add an entry and bump up the version.

Edit build/DEBIAN/control and bump up "Version: " (or create
a "Version" line of it doesn't exist because dpkg-deb needs it but
dpkg-buildpackage doesn't so it might not be there).

find build -type d -exec chmod 0755 +

If they exist:
chmod 0775 build/DEBIAN/post{inst,rm}

Make your changes to "debian/usr/bin/skype" or whatever other changes
you'd like to make.

Recreate "build/DEBIAN/md5sums".

fakeroot dpkg-deb -b build skype<...something...>.deb


-- 
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/CAOdo=sxct3s9x8+c1sccqhkkoowjducp__rpxr8nfhseb9y...@mail.gmail.com

Re: Busybox: compile statically?

[Tom H]

On Sat, Aug 16, 2014 at 12:25 PM, antispammbox-debian
 wrote:
>
> How to compile busybox in static mode, adding some utility different from
> the usual, -dd, cat, other,... -, example, partimage, with all the
> dependencies, compress it, and install on a usb stick?

You can get the Debian source, modify "debian/config/pkg/static", and
build the "binary-arch_busybox-static" target.

Or you can get the upstream source, run "make menuconfig", and compile.


-- 
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/CAOdo=SyBvuJiF9uz_z=ibjLJ-hhX3XBkUUa03=CDxeTu8R1r=g...@mail.gmail.com

Re: auto starting of ppp has stopped working

[Tom H]

On Sun, Aug 17, 2014 at 7:15 AM, Michael Biebl  wrote:
> Am 01.08.2014 10:45, schrieb Tom H:
>
>> Either "/etc/modprobe.d/.conf" or in "/etc/modules" if the
>> former isn't early enough.
>
> You are mixing two things up here:
>
> /etc/modprobe.conf and /etc/modprobe.d/*.conf are for specifying module
> parameters.
>
> If you want to load modules during boot, you have add it to
> /etc/modules or /etc/modules-load.d/*.conf.
> As you already pointed out /etc/modules-load.d/modules.conf being a
> symlink to /etc/modules. This is out of convenience to keep the old
> filename working.

I guess that I expressed myself badly.

AIUI, the symlink from "/etc/modules-load.d/modules.conf" to
"/etc/modules" is a good transition mechanism for loading a module
early when booting via systemd but, unlike sysvinit, systemd cannot
load module options from that file/directory so you have to use
"/etc/modprobe.d/" to load options (over and above "/etc/modules").


-- 
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/CAOdo=Sxo-g3yhwGc+pECgEBNWT0+cEeEKG4PJevDEtwVipt=t...@mail.gmail.com

Re: Jessie won't install

[Tom H]

On Sat, Aug 16, 2014 at 8:47 AM, Francesco Ariis  wrote:
> On Sat, Aug 16, 2014 at 02:24:53PM +0200, Diogene Laerce wrote:
>>
>> Jessie (last testing version) does not want to install in a VM. It just
>> get stucked
>
> If it regards Jessie, probably debian-testing [1] is a better place where
> to post it.
>
> [1] https://lists.debian.org/debian-testing/

https://lists.debian.org/debian-user/2014/07/msg01217.html


-- 
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/CAOdo=SxYz=pUf92AZ-EY1maUj0omXeNx6=qka0top-yhrew...@mail.gmail.com

Re: systemd fails to poweroff - "A stop job is running for Session 2 of user $USER"

[Tom H]

On Fri, Aug 15, 2014 at 7:46 AM, Chris Bannister
 wrote:
> On Thu, Aug 14, 2014 at 10:35:11AM -0400, Tom H wrote:
>>
>> "Stop" in "stop job" isn't an adjective, it's a noun (or an
>> attributive noun) just like "office" in "office chair."
>
> Or it could be a verb, as in a command "Stop job!" :)
> Maybe Steve heard it years ago. :)

:)


-- 
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/CAOdo=Sx=p2Ecu11tYROoNiSLK6jfqgkV1brvESYaucDP1J=+8...@mail.gmail.com

Re: Irony

[Tom H]

On Thu, Aug 14, 2014 at 10:10 PM, Paul E Condon
 wrote:
>
> In my view SQL is a query language that can do much more than look up
> records in a single table. To claim that some init system is superior
> to some other init system because it has 'SQL logging' is, as Andrew
> said, silly. Almost none of the power of the language is being used in
> the init system application. Using the fact of SQL logging as a claim
> for systemd is bullet point one-up-manship.

IIRC, the OP said that he liked the structured logging of systemd and
wished that it had sql logging.

(It's rsyslog that has mysql and pgsql output modules.)


-- 
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/CAOdo=SwLjWcQ=8tziynit-ufraosppqtbmkdmctjz1ade48...@mail.gmail.com

Re: networking fails with temporary systemd (was auto starting of ppp has stopped working)

[Tom H]

On Thu, Aug 14, 2014 at 12:14 PM, Rusi Mody  wrote:
> On Thursday, August 14, 2014 9:10:02 PM UTC+5:30, Tom H wrote:
>> On Thu, Aug 14, 2014 at 10:32 AM, Rusi Mody wrote:
>>>
>>> To add to my earlier report:
>>> I managed to remove graphviz and its associated libraries.
>>> So that now aptitude dist-upgrade gives me only 1 'issue' :
>>> The following packages have unmet dependencies:
>>> systemd-sysv : Conflicts: sysvinit-core but 2.88dsf-53.3 is to be installed.
>>> The following actions will resolve these dependencies:
>>> Remove the following packages:
>>> 1) sysvinit-core
>>
>> You can either accept to remove sysvinit-core and run with systemd
>> only or install systemd-shim and you won't be prompted to install
>> systemd-sysv - and you'll be able to boot with sysvinit by default or
>> systemd if you add "init=/lib/systemd/systemd" to the kernel cmdline.
>> (the archives have this repeated a number of times!)




> systemd-shim is currently installed

OK, although it doesn't make sense. systemd-sysv shouldn't be pulled in.

This is on an "unstable" system:


# dpkg-query -W -f='${Package}\n${Version}\n${Status}\n\n'
{init,systemd,systemd-shim,systemd-sysv,sysvinit,sysvinit-core,udev}
init
1.20
install ok installed

systemd
208-7
install ok installed

systemd-shim
6-5
install ok installed

systemd-sysv

unknown ok not-installed

sysvinit
2.88dsf-55.2
install ok installed

sysvinit-core
2.88dsf-53.3
install ok installed

udev
208-7
install ok installed


# aptitude search -F%p '?depends(systemd-sysv)'
gpsd
init
libpam-systemd
sysvinit


# aptitude search -F%p '?depends(systemd-shim)'
libpam-systemd


# aptitude search -F%p '?depends(sysvinit-core)'
init
sysvinit


# apt-cache show gpsd | grep Depends
Depends: netbase | systemd-sysv, ...


# dpkg -L netbase
/.
/etc
/etc/rpc
/etc/protocols
/etc/services
/etc/network
/usr
/usr/share
/usr/share/doc
/usr/share/doc/netbase
/usr/share/doc/netbase/copyright
/usr/share/doc/netbase/changelog.gz


# apt-cache show netbase | grep Priority
Priority: important


Given the "Priority" of netbase, neither gpsd nor the other three
should be pulling in systemd-sysv unless you don't have sysvinit-core
or systemd-shim installed - although the "netbase | systemd-sysv" is
weird.




> Running with init=/bin/systemd makes networking stop working

IIRC, it's a question of moving the module options from "/etc/modules"
to "/etc/modprobe.d/.conf" until the systemd maintainers
figure out how to do this on transition to systemd.




> And /bin/systemd is softlinked to /lib/systemd/systemd so I guess that
> is a non-difference

"/bin/systemd" is a Debianism but as you say it doesn't make a 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/CAOdo=SwdofZyF5Jb4gJzQgueLkoCxyZR6Y+Lw8v4kK=gahs...@mail.gmail.com

Re: networking fails with temporary systemd (was auto starting of ppp has stopped working)

[Tom H]

On Thu, Aug 14, 2014 at 10:32 AM, Rusi Mody  wrote:
>
> To add to my earlier report:
>
> I managed to remove graphviz and its associated libraries.
>
> So that now aptitude dist-upgrade gives me only 1 'issue' :
>
> The following packages have unmet dependencies:
>  systemd-sysv : Conflicts: sysvinit-core but 2.88dsf-53.3 is to be installed.
> The following actions will resolve these dependencies:
>
>  Remove the following packages:
> 1) sysvinit-core

You can either accept to remove sysvinit-core and run with systemd
only or install systemd-shim and you won't be prompted to install
systemd-sysv - and you'll be able to boot with sysvinit by default or
systemd if you add "init=/lib/systemd/systemd" to the kernel cmdline.
(the archives have this repeated a number of times!)


-- 
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/CAOdo=SwotZ5w0JMb7aA2iU=3zickvooeakc-vacb_gis8l3...@mail.gmail.com

Re: systemd fails to poweroff - "A stop job is running for Session 2 of user $USER"

[Tom H]

On Thu, Aug 14, 2014 at 1:04 AM, Paul E Condon
 wrote:
>
> In English, both 'stop job' and 'stopped job' are an adjective
> modifying a noun. The noun in both cases is 'job'. 'stop job' is a
> noun phrase expressing a type of job, and must be some kind of geeky
> usage. OTOH, the noun phrase 'stopped job' is a job that is not
> progressing, or not running. But in this context, 'job' must itself
> have a geeky, technical jargon meaning.

I don't understand why you've got a bee under your bonnet because of
the "stop job" phrase!

"Stop" in "stop job" isn't an adjective, it's a noun (or an
attributive noun) just like "office" in "office chair."


-- 
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/CAOdo=SxjM8=tX7qBip5qtVvWnVu5vdfWvTZ9zfTqXkUs=ym...@mail.gmail.com

Re: Irony

[Tom H]

On Tue, Aug 12, 2014 at 5:06 PM, Charles Kroeger
 wrote:
> On Tue, 12 Aug 2014 11:50:02 +0200
> Tom H  wrote:
>
>> Debian isn't as special as you think, at least not from this perspective.
>
> Everybody earns money and needs money in this development. Organizations like
> Debian go forward by people with jobs volunteering time and expertise.

As I said in the part of my email that you snipped out, I know of
three distributions that employ developers and therefore Debian isn't
special because it's put together by volunteers. It's special because
it has a large number of derivatives and because of the DFSG.


-- 
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/CAOdo=Sw=J=xwy4ef5qcx+b_vstjvac+zqnskj8nnlmzswph...@mail.gmail.com

Re: systemd fails to poweroff - "A stop job is running for Session 2 of user $USER"

[Tom H]

On Tue, Aug 12, 2014 at 2:51 PM, Paul E Condon
 wrote:
>
> I interpret the quoted string in the Subject: header as being flawed
> use of English language. 'stop' should be 'stopped'. And, there is a
> bug in the script that fails to evaluate the variable USER and
> therefore fails to print the name of the user (aka. owner) of the
> stopped job in Session 2.

The wording's probably derived from the fact that it's a "systemctl
stop ..." job that's failing.


-- 
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/CAOdo=SyvexA3X56=ZsPTjeiXmhZ6HfEiYvPeG3evR+ir=eo...@mail.gmail.com

Re: systemd fails to poweroff - "A stop job is running for Session 2 of user $USER"

[Tom H]

On Tue, Aug 12, 2014 at 10:50 AM, Zenaan Harkness  wrote:
>
> Debian sid
>
> systemd currently fails to poweroff for me
>
> XFCE (appears to) exit, the mouse point shows
> for a while, then the kernel/ shutdown log appears.
>
> The last message is:
> "A stop job is running for Session 2 of user me"
>
> Red asterisks (up to 3) appear to oscillate at left
> edge in an ascii "wait for me" animation.
>
> Requires hard powercycle to poweroff.
>
> How might I debug this?

https://lists.debian.org/debian-user/2014/07/msg01108.html

I've been assuming that the Debian maintainers had backported the fix
to (1) in the link above, but perhaps not. I haven't experienced this
though and you seem to be the first to report this on the list in
spite of many seemingly using systemd in testing and unstable,
willingly or not.


-- 
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/CAOdo=SwZ5HrXj8JdgJGbJPcjjHk5nKRjp6rAmdi4gZzL3=i...@mail.gmail.com

Re: IP Forwarding to Windows machine

[Tom H]

On Tue, Aug 12, 2014 at 5:19 AM, Joe  wrote:
> On Tue, 12 Aug 2014 04:53:51 -0400
> Tom H  wrote:
>>
>> And you've proven my point...
>
> Agreed, I just can't see why there is any controversy.

You misunderstand. The fact that you can't accept that there may be
others who have good reason (whatever it may be; I don't care) to
consider that having ACCEPT as a policy is the proof that this is as
controversial and contentious as vi/emacs, postfix/sendmail/exim, etc.


-- 
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/CAOdo=SwYrGZA=jjptdkm_x-mrp5a38nznqoahcy8sr0huaa...@mail.gmail.com

Re: Irony

[Tom H]

On Mon, Aug 11, 2014 at 3:31 PM, Charles Kroeger
 wrote:
> On Sun, 10 Aug 2014 21:50:01 +0200
> Lisi Reisz  wrote:
>>
>> I had understood that Debian is in this, as in many things, different from
>> most Linux distros.
>
> Yes you're right, that's what makes Debian special, passion always trumps 
> money.

Are there any distros that have salaried developers other than SUSE,
RHEL, and Ubuntu?

Debian isn't as special as you think, at least not from this perspective.


-- 
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/CAOdo=sx_kvojqkxxcw6zftxvjl2u0rknboaeruugswfb7r9...@mail.gmail.com

Re: IP Forwarding to Windows machine

[Tom H]

On Sun, Aug 10, 2014 at 4:30 PM, Joe  wrote:
> On Sun, 10 Aug 2014 16:07:01 -0400
> Tom H  wrote:
>> On Sun, Aug 10, 2014 at 2:24 PM, Nemeth Gyorgy 
>> wrote:
>>> 2014-08-10 11:33 keltezéssel, Pascal Hambourg írta:
>>>>
>>>> sysctl -w net.ipv4.ip_forward=1
>>>> iptables -t nat -P ACCEPT
>>>> iptables -t filter -P ACCEPT
>>>
>>> This is really a big sechole.
>>
>> This is one of these hopelessly unresolvable issues where some people
>> believe that the correct config is to have policy DROP/REJECT and
>> others believe that the correct config is to have a policy of ACCEPT
>> and to have the final rule in the respective chains be DROP/REJECT..
>
> Why is it unresolvable? A DROP/REJECT policy is fail-safe, ACCEPT
> isn't. If the rest of the rules are correct, (and more importantly,
> guaranteed always to stay that way in the face of editing, sometimes
> rushed) an ACCEPT policy is redundant, and if they're not, it's
> dangerous. You will never *ever* want that ACCEPT policy rule to be
> traversed.

And you've proven my point...


--
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/CAOdo=swtrbbs2otn-70xukucaozz8umhlk5o592qpkhsuc2...@mail.gmail.com

Re: IP Forwarding to Windows machine

[Tom H]

On Sun, Aug 10, 2014 at 2:24 PM, Nemeth Gyorgy  wrote:
> 2014-08-10 11:33 keltezéssel, Pascal Hambourg írta:
>>
>> Nemeth Gyorgy's ruleset is too complicated. Use the bare minimum :
>>
>> sysctl -w net.ipv4.ip_forward=1
>> iptables -t nat -P ACCEPT
>> iptables -t filter -P ACCEPT
>
> This is really a big sechole.

This is one of these hopelessly unresolvable issues where some people
believe that the correct config is to have policy DROP/REJECT and
others believe that the correct config is to have a policy of ACCEPT
and to have the final rule in the respective chains be DROP/REJECT..


--
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/CAOdo=sxfu3syvakxq5vjwpst0gbmcmf7ko0ood-0j-tfdzr...@mail.gmail.com

Re: Debian Jessie Release

[Tom H]

On Sun, Aug 10, 2014 at 2:12 PM, Erwan David  wrote:
>
> PS: and I am still waiting for the replacement of policy-rc.d

We know; you've complained here more than once.

Have you filed a bug report?


-- 
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/CAOdo=SxP7nPAjjGkqShEM0kL2ga1zv=x3jlj0uwvuwwaida...@mail.gmail.com

Re: System broken after full-upgrade: please help!

[Tom H]

On Sun, Aug 10, 2014 at 10:26 AM, The Wanderer  wrote:
> On 08/10/2014 10:15 AM, Tom H wrote:
>> On Sun, Aug 10, 2014 at 9:29 AM, The Wanderer 
>> wrote:
>>> On 08/10/2014 09:26 AM, Tom H wrote:
>>>>
>>>> halt/poweroff/reboot have called shutdown at least since
>>>> 6/squeeze.
>>>
>>> Ah, so that may be a Debian-specific behavior, rather than an
>>> upstream one?
>>>
>>> That might explain the discrepancy, if so.
>>>
>>> If not, perhaps the environment in question is simply using older
>>> versions of those tools, which do not yet invoke 'shutdown'...
>>
>> It's in the BSDs that halt&co don't call shutdown. It's been called
>> in sysvinit for a long time.
>
> It's entirely possible that that environment in question does not use
> sysvinit even in part, so it's not entirely impossible that it's
> actually using halt etc. from a non-sysvinit source. I'll have to
> investigate if I decide it's worth the bother to find out.
>
> Thanks for the information; this is a potentially interesting puzzle
> where I didn't even realize one might exist.

You're welcome.

FTR, even sysvinit 2.57 in pre-buzz had the note about this being a
version where using halt&co is OK.


-- 
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/CAOdo=swhc9c5q35dmp8uzpu2iw774xl6xmtdjkf2jzkuc+9...@mail.gmail.com

Re: System broken after full-upgrade: please help!

[Tom H]

On Sun, Aug 10, 2014 at 9:29 AM, The Wanderer  wrote:
> On 08/10/2014 09:26 AM, Tom H wrote:
>> On Sun, Aug 10, 2014 at 8:46 AM, The Wanderer 
>> wrote:
>>> On 08/10/2014 02:45 AM, Bonno Bloksma wrote:
>>>>
>>>> If  halt  or  reboot is called when the system is not in runlevel
>>>> 0 or 6, in other words when it's running normally, shutdown will
>>>> be invoked instead (with the -h or -r flag). For more info see
>>>> the shutdown(8) manpage.
>>>
>>> That's weird, and if it represents a change made by systemd,
>>> possibly unfortunate. I know of at least one somewhat degenerate,
>>> but broadly distributed and not uncommonly used, environment (which
>>> I think may be based on SuSE) where 'shutdown' does not work at all
>>> - exits with an error when called - but 'halt' and 'reboot' do
>>> work. (And probably so does 'poweroff'.)
>>
>> halt/poweroff/reboot have called shutdown at least since 6/squeeze.
>
> Ah, so that may be a Debian-specific behavior, rather than an upstream
> one?
>
> That might explain the discrepancy, if so.
>
> If not, perhaps the environment in question is simply using older
> versions of those tools, which do not yet invoke 'shutdown'...

It's in the BSDs that halt&co don't call shutdown. It's been called in
sysvinit for a long time.

This is the halt man page from the upstream sysvinit 2.75 release,
which was in hamm (debian 2.0). Take a look at the "NOTES":

HALT(8)
   Linux System
Administrator's Manual
 HALT(8)



NAME
   halt, reboot, poweroff - stop the system.

SYNOPSIS
   /sbin/halt [-n] [-w] [-d] [-f] [-i] [-p]
   /sbin/reboot [-n] [-w] [-d] [-f] [-i]
   /sbin/poweroff [-n] [-w] [-d] [-f] [-i]

DESCRIPTION
   Halt notes that the system is being brought down in the file
/var/log/wtmp, and then either tells the kernel to halt, reboot or
poweroff the system. If halt or reboot is called when the system is
not in runlevel 0 or 6, shutdown(8) will be invoked instead
   (with the flag -h or -r).

OPTIONS
   -n Don't sync before reboot or halt.

   -w Don't actually reboot or halt but only write the wtmp
record (in the /var/log/wtmp file).

   -d Don't write the wtmp record. The -n flag implies -d.

   -f Force halt or reboot, don't call shutdown(8).

   -i Shut down all network interfaces just before halt or reboot.

   -p When halting the system, do a poweroff. This is the
default when halt is called as poweroff.

DIAGNOSTICS
   If you're not the superuser, you will get the message `must be
superuser'.

NOTES
   Under previous sysvinit releases, reboot and halt should never
be called directly. From this release on halt and reboot invoke
shutdown(8) if the system is not in runlevel 0 or 6.

AUTHOR
   Miquel van Smoorenburg, miqu...@cistron.nl

SEE ALSO
   shutdown(8), init(1)


  Feb 24, 1998

  HALT(8)


-- 
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/CAOdo=SwfDJxFeSo+LfWJ8rNqnauFnF=54gikwhq1tqqi8az...@mail.gmail.com

Re: System broken after full-upgrade: please help!

[Tom H]

On Sun, Aug 10, 2014 at 8:46 AM, The Wanderer  wrote:
> On 08/10/2014 02:45 AM, Bonno Bloksma wrote:
>>
>> Charlie: According to the man pages all 3, halt, poweroff and reboot,
>> use the shutdown command to perform the necessary steps when not
>> starting in runlevel 0 or 6, which is pretty much always. So it is
>> really weird that in your case poweroff does not work but shutdown
>> does.
>>
>> If  halt  or  reboot is called when the system is not in runlevel 0
>> or 6, in other words when it's running normally, shutdown will be
>> invoked instead (with the -h or -r flag). For more info see the
>> shutdown(8) manpage.
>
> That's weird, and if it represents a change made by systemd, possibly
> unfortunate. I know of at least one somewhat degenerate, but broadly
> distributed and not uncommonly used, environment (which I think may be
> based on SuSE) where 'shutdown' does not work at all - exits with an
> error when called - but 'halt' and 'reboot' do work. (And probably so
> does 'poweroff'.)

halt/poweroff/reboot have called shutdown at least since 6/squeeze.

AIUI halt and poweroff are different if the system has a mode where
the OS can be halted without being powered off, similar to a Solaris
SPARC box where going to runlevel 0 shuts down the OS to go to a
firmware prompt and runlevel 5 shuts down the OS and powers off the
box.


-- 
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/CAOdo=sxbiznuv31tkb7ub16vpviyl1rkrozgllms5faog+k...@mail.gmail.com

Re: Question about dch

[Tom H]

On Sun, Aug 10, 2014 at 5:26 AM, Tom H  wrote:
> On Sat, Aug 9, 2014 at 2:18 PM, George Shuklin  
> wrote:
>> On 08/09/2014 07:16 PM, Tom H wrote:
>>>
>>> From the man page:
>>>
>>> --increment, -i
>>> Increment either the final component of the Debian release num-
>>> ber  or, if this is a native Debian package, the version number.
>>> On Ubuntu, this will also  change  the  suffix  from buildX  to
>>> ubuntu1. ...
>>>
>> Means it hardcoded? Thanks.
>
> Sorry, I was too terse earlier.
>
> It can be overridden with "--vendor".

One more thing.

I'm assuming that you're packaging on Ubuntu for Debian so using
"--vendor debian" will not append "ubuntu" to the version.

I've never tried it but I don't think that you can use any name for
the vendor and, other than "debian", that name'll be appended to the
version.

A better way is to use "-U" (u for upstream).

Anyway, you can edit whatever dch sets as a version.


-- 
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/CAOdo=SxUWCpe_QS-Q23=3wmvjjsshcklyebwabywkoknq_f...@mail.gmail.com

Re: Quiet Bootups

[Tom H]

On Sun, Aug 10, 2014 at 6:36 AM, David Baron  wrote:
>
> With Grub, I did not see that endless stream of text pouring on the screen to
> rapidly to read.
>
> Because I (presumably) know how to configure it, I have gone back to lilo. Now
> have all that text back. Is there an append= or lilo.conf entry to
> control/eliminate the text playback?

append="quiet"


-- 
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/CAOdo=SwXWcQNJVfp16yjpHiTuD5j=0nsfswvjefjsnszqce...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Sun, Aug 10, 2014 at 1:15 AM, Bob Proulx  wrote:
> Tom H wrote:
>> Bob Proulx wrote:
>>>
>>> I believe the point was that it should be "make before break". They
>>> should have allowed people to use systemd without preventing people
>>> from not using it. They didn't make a new system without breaking the
>>> old one. They broke the old one while trying to build the new one.
>>> That is the problem. You shouldn't burn down your old house while you
>>> are still designing and building your new house.
>>
>> Had Gnome not had to rely on systemd as pid 1, we might not have had a
>> CTTE bug, etc.
>
> But then the question becames did the GNOME 3 folks "had to rely" on
> systemd? Did they really have to do it? No. We have had a plethora
> of window managers and desktop systms for years and years and years
> without it. They didn't have to require it.
>
> I am not saying that there weren't corner cases with problems. I am
> saying that for all of those years we were apparently happy in spite
> of those corner case problems. Therefore I don't think GNOME 3 "had"
> to rely on systemd as pid 1. That is disproven by the last few
> decades without it. And somehow I think all of the happy *BSD users
> who don't have systemd will also disagree that it is a hard
> requirement.
>
> My point is that it would have been much easier if they had created a
> system that you could optionally migrate to without being *forced*
> onto it. Then if it turns out to be clearly superior people will
> desire to move to it. People would then move of their own volition
> because they would want to move to it. If they had done it that way
> it would have avoided much unpleasantness.

I wasn't disagreeing with you. I was just reminding you of the chronology.

IIRC it was the maintainer of the Gnome power applet who decided to
depend on logind. There was some pushback and his response was "I'm
the maintainer. It's my decision."

Olav Vitters, a Gnome guy who always argues on behalf of Gnome/systemd
on debian-devel@ (I don't think that he's involved in Debian in any
other way), has said on his blog "it seems eventually GNOME will head
to be systemd and Linux-only" (even when he was saying the opposite on
debian-devel@, like "we support consolekit").

So I agree with you (and I should've said so in my earlier post) that,
for jessie, sysvinit should've been the default init and those people
wanting to use systemd (or Gnome {or KDE[?]}) would've added
"init=/lib/systemd/systemd" to the kernel cmdline. The Debian systemd
maintainers could've used that extra release to integrate systemd
without the pressure of an upcoming freeze/release.

As I've said in an earlier thread, AIUI, systemd is going to be the
only init unless someone develops a dbus manager (for a standalone
udev; the way that Ubuntu developed a cgroup manager for a standalone
logind) once kdbus is in-kernel uptream and Debian compiles it into
its kernel.


-- 
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/CAOdo=sx7jn4z37-fnom1fkz9rcxhc5kmrs2_3tqgredz8ym...@mail.gmail.com

Re: Irony

[Tom H]

On Sat, Aug 9, 2014 at 4:47 PM, AW  wrote:
> On Sat, 9 Aug 2014 16:26:40 -0400
> Steve Litt  wrote:
>>
>> Some of the reasons I switched my desktop from Ubuntu to Debian were:
>>
>> 1) To do more config by editor and less by magical binary program.
>>
>> 2) To get rid of gratuitous boot gunge (in this case Plymouth)
>>
>> 3) To get closer to the Unix Philosophy
>>
>> Within months of my switch, oops, here comes systemd.
>
> A new thread... I chase this one, knowing full well that convincing anyone of
> anything is nearly impossible.
>
> There remains only a few holdouts from the "major" distributions: Gentoo and
> Slackware. So, give 'em a go...

Gentoo can be installed with either openrc or systemd.

Gentoo "stable" tracks upstream systemd more closely than Debian
"unstable" does.

If you want to use Gnome, the only supported init is systemd. There's
a "force-openrc" (I'm not sure of the wording but it's close to this)
USE variable for Gnome users who insist on using openrc but it's
unsupported.


-- 
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/CAOdo=syqekrqptzqp+xospdhsvacbwz8pjzzrwz5jglrypf...@mail.gmail.com

Re: Netflix in chrome-unstable on Debian Sid

[Tom H]

On Sat, Aug 9, 2014 at 10:51 PM, Hugo Vanwoerkom  wrote:
> And what is that "google-chrome-unstable deb"? Does that have a version
> number?

$ apt-cache show google-chrome-unstable | grep Ver
Version: 38.0.2114.2-1
$ apt-cache show google-chrome-beta | grep Ver
Version: 37.0.2062.68-1
$ apt-cache show google-chrome-stable | grep Ver
Version: 36.0.1985.125-1

And the major version be bumped up whenever Google chooses has a new release.

google-chrome-unstable has a minor version bump almost daily.


-- 
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/CAOdo=SzahPnJOC0+DQ=mo9zmue4ziakux-o-hn6xzq84ybm...@mail.gmail.com

Re: NFS and iptables during bootup

[Tom H]

On Sat, Aug 9, 2014 at 3:40 PM, Martin T  wrote:
> On Sat, Aug 9, 2014 at 6:33 AM, Tom H  wrote:
>> On Fri, Aug 8, 2014 at 11:47 AM, Martin T  wrote:
>>>
>>> I moved the script from /etc/init.d to /etc/network directory and
>>> changed the shebang line from /bin/bash to /bin/sh. /bin/sh on my
>>> system points to /bin/dash. Thanks for those tips!
>>>
>>> Content of firewall rule-files can be seen here:
>>>
>>> # cat /etc/firewall.conf /etc/firewall6.conf
>>> # Generated by iptables-save v1.4.8 on Tue Jul  1 10:41:45 2014
>>> *filter
>>> :INPUT DROP [17:1605]
>>> :FORWARD ACCEPT [0:0]
>>> :OUTPUT ACCEPT [259:30520]
>>> -A INPUT -s 10.10.10.0/24 -j ACCEPT
>>> -A INPUT -s 8.8.8.8/32 -j ACCEPT
>>> -A INPUT -s 8.8.4.4/32 -j ACCEPT
>>> COMMIT
>>> # Completed on Tue Jul  1 10:41:45 2014
>>> # Generated by ip6tables-save v1.4.8 on Tue Jul  1 10:41:56 2014
>>> *filter
>>> :INPUT DROP [10518:992304]
>>> :FORWARD DROP [0:0]
>>> :OUTPUT DROP [0:0]
>>> COMMIT
>>> # Completed on Tue Jul  1 10:41:56 2014
>>>
>>> If I comment out just the "iptables-restore .." line from
>>> firewall-script and leave the "ip6tables-restore .." line uncommented,
>>> the machine also boots without problems, i.e. it's the IPv4 iptables
>>> rules which seem to cause the statd to fail. I modified the IPv4
>>> rules(/etc/firewall.conf file) in a following manner:
>>>
>>> # cat /etc/firewall.conf
>>> # Generated by iptables-save v1.4.8 on Fri Aug  8 17:08:22 2014
>>> *filter
>>> :INPUT DROP [1:146]
>>> :FORWARD ACCEPT [0:0]
>>> :OUTPUT ACCEPT [50:7006]
>>> -A INPUT -s 10.10.10.0/24 -i eth0 -j ACCEPT
>>> -A INPUT -s 8.8.8.8/32 -i eth0 -j ACCEPT
>>> -A INPUT -s 8.8.4.4/32 -i eth0 -j ACCEPT
>>> -A INPUT -i lo0 -j ACCEPT
>>> COMMIT
>>> # Completed on Fri Aug  8 17:08:22 2014
>>
>> Your problem's probably that there's no lo0 (a BSD loopback device
>> name?). It's lo.
>
> Yes, I erroneously used "lo0" instead of "lo" in iptables rules. I use
> FreeBSD on daily basis :) However, once I allowed traffic to loopback
> interface and started NFS("/etc/init.d/nfs-common start"), I saw some
> traffic on loopback interface:
>
> 48   560 ACCEPT all  --  lo *   0.0.0.0/0
>   0.0.0.0/0
>
> During the statd start following traffic is seen on loopback interface:
>
> 20:39:48.789936 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4
> (0x0800), length 98: 127.0.0.1.997 > 127.0.0.1.111: UDP, length 56
> 20:39:48.790044 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4
> (0x0800), length 70: 127.0.0.1.111 > 127.0.0.1.997: UDP, length 28
> 20:39:48.790221 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4
> (0x0800), length 98: 127.0.0.1.997 > 127.0.0.1.111: UDP, length 56
> 20:39:48.790250 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4
> (0x0800), length 70: 127.0.0.1.111 > 127.0.0.1.997: UDP, length 28
> 20:39:48.790649 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4
> (0x0800), length 98: 127.0.0.1.997 > 127.0.0.1.111: UDP, length 56
> 20:39:48.790759 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4
> (0x0800), length 70: 127.0.0.1.111 > 127.0.0.1.997: UDP, length 28
> 20:39:48.791156 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4
> (0x0800), length 98: 127.0.0.1.997 > 127.0.0.1.111: UDP, length 56
> 20:39:48.791278 00:00:00:00:00:00 > 00:00:00:00:00:00, ethertype IPv4
> (0x0800), length 70: 127.0.0.1.111 > 127.0.0.1.997: UDP, length 28
>
> Once I save the iptables rules and restart the machine, it boots up
> without issues. Thanks! In addition, I will look into
> iptables-persistent package.
>
> However, last but not least, in which situations one firewalls
> loopback interface? Or is it a best practice just to allow everything
> through the loopback interface like I did?

Please bottom-post.

You're welcome.

I've always allowed lo - and I've never seen anyone else disallow it.

But now that you've asked I feel like checking what apf, arno, and ufw
set by default. I can't see them disallowing lo but they might have
lo-to-lo-only rules.

Your dump above shows that it's 127.0.0.1 communicating to 127.0.0.1
so in statd's case it's feasible.


-- 
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/CAOdo=syauxmyzngmivgdvzxyosd3kdo1ydbhto8stfcrg-a...@mail.gmail.com

Re: Question about dch

[Tom H]

On Sat, Aug 9, 2014 at 2:18 PM, George Shuklin  wrote:
> On 08/09/2014 07:16 PM, Tom H wrote:
>> On Sat, Aug 9, 2014 at 10:52 AM, George Shuklin
>>  wrote:
>>>
>>> dch -i tool allows to add new version to debian/changelog file.
>>>
>>> When I add new version I make this:
>>>
>>> package (1.0.2-1myname1-ubuntu0) UNRELEASED; urgency=medium
>>>
>>>   *
>>>   -- signature and date
>>>
>>> package (1.0.2-1myname1) unstable; urgency=medium
>>>
>>>* old changes
>>>
>>> -- signature and date
>>>
>>> If version ends on 'ubuntu' it bumped properly (ubuntu1, ubuntu2, etc),
>>> and
>>> when I use my own suite, it just append 'ubuntu'.
>>>
>>> Where dch take sting 'ubuntu' to add to version?
>>
>> >From the man page:
>>
>> --increment, -i
>>Increment either the final component of the Debian release
>> num-
>>ber  or, if this is a native Debian package, the version
>> number.
>>On Ubuntu, this will also  change  the  suffix  from
>> buildX  to
>>ubuntu1. ...
>>
> Means it hardcoded? Thanks.

Sorry, I was too terse earlier.

It can be overridden with "--vendor".


-- 
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/CAOdo=sxwv9e4pkxvah6uikvjmj8pqax7-ru-x-7zdutdfon...@mail.gmail.com

Re: Question about dch

[Tom H]

On Sat, Aug 9, 2014 at 10:52 AM, George Shuklin
 wrote:
>
> dch -i tool allows to add new version to debian/changelog file.
>
> When I add new version I make this:
>
> package (1.0.2-1myname1-ubuntu0) UNRELEASED; urgency=medium
>
>  *
>  -- signature and date
>
> package (1.0.2-1myname1) unstable; urgency=medium
>
>   * old changes
>
> -- signature and date
>
> If version ends on 'ubuntu' it bumped properly (ubuntu1, ubuntu2, etc), and
> when I use my own suite, it just append 'ubuntu'.
>
> Where dch take sting 'ubuntu' to add to version?

>From the man page:

--increment, -i
  Increment either the final component of the Debian release  num-
  ber  or, if this is a native Debian package, the version number.
  On Ubuntu, this will also  change  the  suffix  from  buildX  to
  ubuntu1. ...


-- 
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/CAOdo=sxawue+fi5mzqwrfab4y7ievowg7kbcexc0ccxvx5e...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Fri, Aug 8, 2014 at 4:19 PM, Bob Proulx  wrote:
> Zenaan Harkness wrote:
>> Joel Rees wrote:
>>>
>>> This is precisely why systemd should have been brought up to speed in
>>> a separate, parallel, volunteer-only distro.
>>>
>>> (If you don't understand what I mean by a separate, parallel,
>>> volunteer-only distribution, think of kfreebsd, but a little closer to
>>> home.)
>>>
>>> I'd still say there's time for debian to go for a course correction,
>>
>> Seriously?
>>
>> What is sid for?
>
> I believe the point was that it should be "make before break".  They
> should have allowed people to use systemd without preventing people
> from not using it.  They didn't make a new system without breaking the
> old one.  They broke the old one while trying to build the new one.
> That is the problem.  You shouldn't burn down your old house while you
> are still designing and building your new house.

Had Gnome not had to rely on systemd as pid 1, we might not have had a
CTTE bug, etc.


-- 
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/CAOdo=Sy85acEdV_FtAT7BvobHjPS=f=9i-fejphuta3jeko...@mail.gmail.com

Re: NFS and iptables during bootup

[Tom H]

On Fri, Aug 8, 2014 at 11:47 AM, Martin T  wrote:
>
> I moved the script from /etc/init.d to /etc/network directory and
> changed the shebang line from /bin/bash to /bin/sh. /bin/sh on my
> system points to /bin/dash. Thanks for those tips!
>
> Content of firewall rule-files can be seen here:
>
> # cat /etc/firewall.conf /etc/firewall6.conf
> # Generated by iptables-save v1.4.8 on Tue Jul  1 10:41:45 2014
> *filter
> :INPUT DROP [17:1605]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [259:30520]
> -A INPUT -s 10.10.10.0/24 -j ACCEPT
> -A INPUT -s 8.8.8.8/32 -j ACCEPT
> -A INPUT -s 8.8.4.4/32 -j ACCEPT
> COMMIT
> # Completed on Tue Jul  1 10:41:45 2014
> # Generated by ip6tables-save v1.4.8 on Tue Jul  1 10:41:56 2014
> *filter
> :INPUT DROP [10518:992304]
> :FORWARD DROP [0:0]
> :OUTPUT DROP [0:0]
> COMMIT
> # Completed on Tue Jul  1 10:41:56 2014
>
> If I comment out just the "iptables-restore .." line from
> firewall-script and leave the "ip6tables-restore .." line uncommented,
> the machine also boots without problems, i.e. it's the IPv4 iptables
> rules which seem to cause the statd to fail. I modified the IPv4
> rules(/etc/firewall.conf file) in a following manner:
>
> # cat /etc/firewall.conf
> # Generated by iptables-save v1.4.8 on Fri Aug  8 17:08:22 2014
> *filter
> :INPUT DROP [1:146]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [50:7006]
> -A INPUT -s 10.10.10.0/24 -i eth0 -j ACCEPT
> -A INPUT -s 8.8.8.8/32 -i eth0 -j ACCEPT
> -A INPUT -s 8.8.4.4/32 -i eth0 -j ACCEPT
> -A INPUT -i lo0 -j ACCEPT
> COMMIT
> # Completed on Fri Aug  8 17:08:22 2014

Your problem's probably that there's no lo0 (a BSD loopback device
name?). It's lo.


-- 
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/CAOdo=sxevvfggwlj5suae-6vfbjwkqm8gsbpjfgukxt5vno...@mail.gmail.com

Re: Systemd: follow-up

[Tom H]

On Thu, Aug 7, 2014 at 6:57 PM, Joel Rees  wrote:
> On Fri, Aug 8, 2014 at 4:04 AM, Brian  wrote:
>> On Thu 07 Aug 2014 at 20:25:22 +0200, Johann Spies wrote:
>>
>>> After rescuing two laptops which were unbootable after the installation of
>>> systemd-sysfs I had problems with stuff as bluetooth and some of the
>>> services.
>>
>> There are wiser and more cautious courses of action to follow other
>> than installing systemd-sysv.
>
> http://en.wikipedia.org/wiki/Sysfs
>
> And, note, that he said, systemd-sysfs

But he meant systemd-sysv, the package that sets up systemd as the
only provider of "/sbin/init" and uninstalls sysvinit-core.


-- 
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/CAOdo=sy9tlg8qyvmb+nvu4tj6vevcohonzjyfrf1mpv27hj...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Thu, Aug 7, 2014 at 3:12 AM, Slavko  wrote:
> Dňa Wed, 6 Aug 2014 16:25:21 -0400 Tom H  napísal:
>>
>> I've saved one or two relevant URLs from debian-devel@ pre-CTTE bug
>> thread. I can dig them up and post them if you're interested.
>
> Please, give them.

More than two...

I'd intended to re-read them and possibly not post them all but I
haven't had the time to do so .

Russ Allberry
https://lists.debian.org/debian-devel/2012/02/msg00911.html
https://lists.debian.org/debian-devel/2012/02/msg01079.html
https://lists.debian.org/debian-devel/2012/04/msg00638.html
https://lists.debian.org/debian-devel/2013/07/msg00456.html

Ben Hutchings
https://lists.debian.org/debian-devel/2012/05/msg00263.html

Roger Leigh (sysvinit developer)
https://lists.debian.org/debian-devel/2012/05/msg00267.html

Petter Reinholdtsen (sysvinit developer)
https://lists.debian.org/debian-devel/2012/02/msg01043.html


--
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/CAOdo=SzEOmZOQewFK7yvEpWEEwh815hbBGrH_OX2s9k=t...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Thu, Aug 7, 2014 at 11:49 AM, AW  wrote:
> On Thu, 7 Aug 2014 16:19:03 +0100
> Darac Marjal  wrote:
>
>  > Consider it to be another database format. You wouldn't necessarily try
>  > to cat a MySQL or PostgreSQL datastore; you'd use the appropriate tools
>  > to select all from it.
>
> Yes.  But it's not.  Although it should and could be an easily queried data
> store.
> ...
> SYSLOG_IDENTIFIER=apache2
> _PID=1808
> _COMM=apache2
> _CMDLINE=/bin/sh /etc/init.d/apache2 start
> _SYSTEMD_CGROUP=/system.slice/apache2.service
> _SYSTEMD_UNIT=apache2.service
> MESSAGE=.
> Thu 2014-08-07 06:21:24.805036 EDT [...]
> PRIORITY=6
> _UID=0
> _GID=0
> ...
>
> This is filled with problems and pitfalls.  And the outputted text from the
> data store search tool is terribly formatted for further inclusion with other
> regular GNU/Linux command line text processing tools.  I would say, systemd 
> and
> journald are a great start to a great end -- but right now, it's not so much
> fun...

journalctl has output options:

-o, --output=

Controls the formatting of the journal entries that are shown. Takes
one of the following options:

short

is the default and generates an output that is mostly identical to the
formatting of classic syslog files, showing one line per journal
entry.

short-iso

is very similar, but shows ISO 8601 wallclock timestamps.

short-precise

is very similar, but shows timestamps with full microsecond precision.

short-monotonic

is very similar, but shows monotonic timestamps instead of wallclock timestamps.

verbose

shows the full-structured entry items with all fields.

export

serializes the journal into a binary (but mostly text-based) stream
suitable for backups and network transfer (see Journal Export Format
for more information).

json

formats entries as JSON data structures, one per line (see Journal
JSON Format for more information).

json-pretty

formats entries as JSON data structures, but formats them in multiple
lines in order to make them more readable by humans.

json-sse

formats entries as JSON data structures, but wraps them in a format
suitable for Server-Sent Events.

cat

generates a very terse output, only showing the actual message of each
journal entry with no metadata, not even a timestamp.


-- 
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/CAOdo=Szsd2R4nozcB72E0mPjSu5jJMwToF05d7YPXLz89Z=p...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Wed, Aug 6, 2014 at 4:27 PM, AW  wrote:
> On Wed, 6 Aug 2014 16:25:21 -0400
> Tom H  wrote:
>>
>> So, yeah, /var/log/messages sucks, and journalctl is better at
>> generating a compatible output that that file ever was in itself.
>
> I definitely agree.

FTR, it was a quote.


-- 
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/CAOdo=sxaf6wahj4ltmdop6ry5npynnv9rj9getpzbu-_zzk...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Wed, Aug 6, 2014 at 5:54 AM, Slavko  wrote:
> Dňa Tue, 5 Aug 2014 16:33:23 -0400 Tom H  napísal:
>> On Tue, Aug 5, 2014 at 9:50 AM, Slavko  wrote:
>>> Dňa Tue, 5 Aug 2014 08:58:47 -0400 Tom H 
>>> napísal:


>>>> If tomh-init is faster than htom-init, whether there's just ssh
>>>> running or 100 daemons running, I want to use tomh-init.
>>>>
>>>> I can understand that there are people who don't want to adopt
>>>> systemd simply because it boots faster because they dislike some
>>>> other aspect(s) of systemd, but attacking systemd because it boots
>>>> faster is silly.
>>>
>>> I know, that you are not responding to me, but i have one note:
>>>
>>> The boot speed is often used as argument for the systemd. But no all
>>> users are interested on boot time, then there are reaction as this
>>> (and as my). IMO, there aren't a lot information about other
>>> aspects of systemd and then people (include me) don't know about
>>> them.
>>>
>>> Until will be boot time again and again used as argument, then here
>>> will be responses as these.
>>>
>>> To be precise, i often read about these things: monolitic, binary
>>> files and boot speed. I don't like first two and i am not
>>> interested in latest.
>>
>> I thought that I'd answered you.
>>
>> I'm objecting to this line of reasoning: I'm not interested in boot
>> speed therefore I'm not interested in systemd.
>>
>> Since you're not interested in boot speed, you shouldn't care that
>> boot's faster with systemd! You don't have to dislike everything that
>> systemd claims that it provides.
>>
>> But if you want to say "boot speed isn't enough of an argument for me
>> to like/use systemd", fine.
>
> Yes, that is what i mean, thanks for help - writing my thinks in
> English is sometime terrible for me.

You're welcome. I'm glad that we cleared this up.


> Yes, you have rsyslog for storing logs in text files. Now you have two
> deamons for one thing. Nice, but where is the advantage?
>
> I understand that sometime there is time to change, e.g. from text to
> binary files, it is OK. But to i (and perhaps others too) can accept
> this change, it must give something, what is useful for me.

Imagine if the systemd maintainers proposed to replace rsyslog with
journald. I'd unsubscribe for a month or two in order to let the
outrage die down. :)

At my $day_job, as part of our future RHEL 7 rollout, we're looking
into using journald for local logs and configuring rsyslog to send our
logs to a dedicated syslog server without storing any of the usual
"/var/log/" files locally.

This is from an email by Lennart:

/var/log/messages is *very* badly designed:

  The timestamps do not contain a year
  The timestamps do not contain a timezone
  The timestamps are accurate to the second only
  PID information is optional, not implied
  PID information is fakeable, because user supplied
  The file "tag" part is completely optional, free-form, and fakeable
by unpriveed clients
  The files do not carry any information about the log priority
  The files do not carry any information about who is logging
(service, process name, argv, binary path..)
  The files do not carry any information about the credentials of who
is logging (uid, gid, selinux context, audit, ...)

And so on and so on.

It's so bad, that rsyslog upstream even suggests not to use these files
anymore, but write them in a more modern formatting that leaves a bit
more information in (such as iso timestamps). But you know what? If you
do that than all your compatibility is gone too.

The interesting things is that "journalctl" is *better* at generating
the same text stream that is normally contained in /var/log/messages
than /var/log/messages itself is. "journalctl" can stuff more
information into it then /var/log/messages. And how does that happen?
Because we have more data around. We can agument the ouput with colors
(indicating priorities), we can add additional informational separator
lines (indicating reboots), we can add add in fields that aren't there
(such as the tag from the comm field, or the PID). We can timezone
correct the timestamps (because we have UTC times). And we can filter by
any of the fields, securely.

So, yeah, /var/log/messages sucks, and journalctl is better at
generating a compatible output that that file ever was in itself.

I didn't save the URL :(

And another:

> So maybe we (Fedora) should go with XML instead of binary or some
> dedicated RDMBS for storing system logs? I'm not again

Re: End of hypocrisy, beginning of reason

[Tom H]

On Wed, Aug 6, 2014 at 2:53 AM, Erwan David  wrote:
> On Wed, Aug 06, 2014 at 01:01:57AM CEST, AW 
>  said:
>> On Tue, 5 Aug 2014 17:57:02 -0400
>> Tom H  wrote:
>>>
>>> journalctl SYSLOG_FACILITY=4
>>
>> Thanks!
>> But why '4'? Why not '42'? Or even better...
>> journalctl show auth
>> journalctl show apache2
>> journalctl show postgresql
>> or even better still
>> journalctl show -v postgresql
>
> man says it is journalctl [OPTIONS] [MATCHES] what MATCHES are is not
> defined.
>
> just examples where we have to guess there are "fields" (list not given) two 
> of them can be _SYSTEMD_UNIT and _PID
>
> Reading this I feel I am told "this is not for you, you are only a suer and 
> you are not allowed to know"

You have to read more than the first lines of a man page to learn how
to use a command.

"man ps" has "ps [options]" and "man nmap" has "nmap [Scan Type...]
[Options] {target specification}"...

See the last lines of my earlier email to display the fields with tab
completion:

https://lists.debian.org/debian-user/2014/08/msg00342.html

Also:

man journalctl
man systemd.journal-fields


-- 
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/CAOdo=syhuanqcgyunzv7huobur7htuc3pqj2ocsw_4bvqu7...@mail.gmail.com

Re: End of hypocrisy, beginning of reason

[Tom H]

On Tue, Aug 5, 2014 at 7:01 PM, AW  wrote:
> On Tue, 5 Aug 2014 17:57:02 -0400
> Tom H  wrote:
>>
>> journalctl SYSLOG_FACILITY=4
>
> Thanks!
> But why '4'? Why not '42'? Or even better...
> journalctl show auth
> journalctl show apache2
> journalctl show postgresql
> or even better still
> journalctl show -v postgresql

You're welcome.

Weirdly, you can find the correspondence between the facility name and
the facility number in "/usr/include/x86_64-linux-gnu/sys/syslog.h"
and not in a man page. (You can also find it in the IETF syslog RFC!)

The ones that I keep in mind are 3 (daemons), 4 (auth), 10 (authpriv).
I can't remember any other, although I /think/ that mail is 2.

Run "journalctl -u " (u for unit) to see the log for a specific service.

"journalctl -u " is the same as (or perhaps I should say
"short for") "journalctl _SYSTEMD_UNIT=.service". I don't know
why you have to append ".service" to the latter but tab completion
takes care of it anyway.


-- 
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/CAOdo=Sww=tno09cvek9wavlze+rpqgtyvim+yh0znewrfvf...@mail.gmail.com

Re: End of hypocrisy, beginning of reason

[Tom H]

On Tue, Aug 5, 2014 at 4:12 PM, AW  wrote:
>
> cat /var/log/auth.log
> or
> journalctl 'something unknown by me'

journalctl SYSLOG_FACILITY=4

There's tab completion, so on my laptop where I've aliased systemctl
and journalctl to sc and jc (and duplicated the systemctl and
journalctl bash completion), I type:

jc[space]S[tab]F[tab]4

To know what fields are available:

jc[space]-F[space][tab][tab]
or
jc[space]-F[tab][tab][tab]


-- 
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/CAOdo=Sx0FpLiZpEuHbepOSU=TFoMwM6XLNn7A6nQv=12npp...@mail.gmail.com

Re: End of hypocrisy, beginning of reason

[Tom H]

On Tue, Aug 5, 2014 at 3:44 PM, Steve Litt  wrote:
>
> LOL, perhaps I'll boot to bin/bash, and then run a script to do
> everything else. Oh wait, I can't do that: I hear PAM now depends on
> systemd, for what reason I haven't a clue.

Maybe you should look into adapting the Android Init Language :)


-- 
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/CAOdo=Szh3zrTpOEC4vboUq7zGmJwJq6=ahhwk2laublfo19...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Tue, Aug 5, 2014 at 9:50 AM, Slavko  wrote:
> Dňa Tue, 5 Aug 2014 08:58:47 -0400 Tom H  napísal:
>>
>> If tomh-init is faster than htom-init, whether there's just ssh
>> running or 100 daemons running, I want to use tomh-init.
>>
>> I can understand that there are people who don't want to adopt systemd
>> simply because it boots faster because they dislike some other
>> aspect(s) of systemd, but attacking systemd because it boots faster is
>> silly.
>
> I know, that you are not responding to me, but i have one note:
>
> The boot speed is often used as argument for the systemd. But no all
> users are interested on boot time, then there are reaction as this (and
> as my). IMO, there aren't a lot information about other aspects of
> systemd and then people (include me) don't know about them.
>
> Until will be boot time again and again used as argument, then here
> will be responses as these.
>
> To be precise, i often read about these things: monolitic, binary files
> and boot speed. I don't like first two and i am not interested in
> latest.

I thought that I'd answered you.

I'm objecting to this line of reasoning: I'm not interested in boot
speed therefore I'm not interested in systemd.

Since you're not interested in boot speed, you shouldn't care that
boot's faster with systemd! You don't have to dislike everything that
systemd claims that it provides.

But if you want to say "boot speed isn't enough of an argument for me
to like/use systemd", fine.

Re "binary files": Please repeat after me "systemd doesn't require
binary files." I currently have two systemd systems, a sid VM (where
systemd-sysv has been pulled in by the recent libpam-systemd
dependency change) and a Fedora 20 installation on my laptop. On the
sid VM, I have the default Debian setup whereby journald forwards logs
to rsyslog and the logs are stored in text files in "/var/log/". On my
Fedora installation, I've set "Storage=persistent" in
"/etc/systemd/journald.conf" so my only logs are binary files in
"/var/log/journal/".

Re "monolithic": Someone said earlier in the thread "gratuitous
interdependency". That's more accurate. There are many executables in
systemd and many are interdependent. A systemd fan would tell you that
the interdependency isn't gratuitous; I'd tend to disagree.


--
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/CAOdo=SwH=pgcapr0qbhmsba9wmlnbaxk-6mev61we_b_zzj...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Tue, Aug 5, 2014 at 2:45 AM, Erwan David  wrote:
> On Mon, Aug 04, 2014 at 11:17:02PM CEST, Tom H  said:
>> On Mon, Aug 4, 2014 at 4:04 PM, Bob Proulx  wrote:
>>> Andrew McGlashan wrote:
>>>>
>>>> Yes, that's what I meant, sysvinit is not broken.
>>>
>>> I rather agree. But the opponents cite corner cases where the
>>> previous security model doesn't handle every possible access case.
>>>
>>> I always hate it when people say such vague statements such as
>>> "modern" or "is broken" without actually saying why it is one way or
>>> the other. After reading months of arguments these next two postings
>>> were the first real postings I had read with any detail in them.
>>> Especially the second one.
>>>
>>> https://lists.debian.org/debian-devel/2014/06/msg00455.html
>>> https://lists.debian.org/debian-devel/2014/06/msg00461.html
>>>
>>> These are things that probably 99.44%[1] of the population hasn't ever
>>> needed before. The 99% where everything works for us are all of us
>>> crying about the disruption. But for that 0.56% that worried about
>>> those corner cases they see the old system as really broken. They are
>>> probably right that it is broken for them. But there are better ways
>>> to go about improving the system than the unpleasant way that systemd
>>> has been rolled out to the community.
>>
>> Didn't all DEs use consolekit and policykit? IIRC wasn't the CTTE bug
>> filed because of a debian-devel@ thread about Gnome depending on
>> systemd (because of logind and/or libpam-systemd)?
>>
>> The problem's that consolekit is abandonware upstream, logind is its
>> replacement, policykit removed consolekit support, and logind requires
>> systemd as pid 1 (or systemd-shim).
>
> logind requires pam-systemd which as of today version in testing requires 
> systemd-sysv
>
> systemd-shim today is NOT an option. No more. It was *remived* from
> the dependencies. And completeley removed,the dependency is not on a
> version ot yet in testing. For me that means that systemd developper
> want to remove it.

There have been multiple posts on this list about the fact that the
systemd-shim "||" dependency would be restored once cgmanager had been
uploaded. it's done and we're now waiting for the systemd maintainers
to change the dependencies:

https://lists.debian.org/debian-devel/2014/08/msg00037.html


-- 
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/CAOdo=sz5y7ravk8wih+tvk3qd9ablnd-amh7orzodunxdp+...@mail.gmail.com

Re: Wireless card unavailable in Debian, but works in Ubuntu

[Tom H]

On Tue, Aug 5, 2014 at 2:18 AM, S4mmael  wrote:
>
> I have a liittle problem with a wireless card of a cheap HP laptop. It works
> perfectly well out of the box in Ubuntu 14.04, but not in Debian Jessie.
>
> Here is what a managed to find.
>
> In Ubuntu it looks like that:
>
> root@ubuntu:~# dmesg | grep 02:00.0
> [0.986323] pci :02:00.0: [10ec:8179] type 00 class 0x028000
> [0.986347] pci :02:00.0: reg 0x10: [io  0x2000-0x20ff]
> [0.986383] pci :02:00.0: reg 0x18: [mem 0x9070-0x90703fff 64bit]
> [0.986486] pci :02:00.0: supports D1 D2
> [0.986490] pci :02:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> [0.986542] pci :02:00.0: System wakeup disabled by ACPI
>
> root@ubuntu:~# lspci -s 02:00.0 -v
> 02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188EE
> Wireless Network Adapter (rev 01)
> Subsystem: Hewlett-Packard Company Device 197d
> Flags: bus master, fast devsel, latency 0, IRQ 17
> I/O ports at 2000 [size=256]
> Memory at 9070 (64-bit, non-prefetchable) [size=16K]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
> Capabilities: [70] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Device Serial Number 00-e0-4c-ff-fe-81-91-01
> Capabilities: [150] Latency Tolerance Reporting
> Kernel driver in use: rtl8188ee
>
> Whereas in Jessie it looks like that:
>
> root@debian:~# dmesg | grep 02:00.0
> [1.109622] pci :02:00.0: [eaea:eaea] type 6a class 0xeaeaea
> [1.109628] pci :02:00.0: unknown header type 6a, ignoring device
>
> root@debian:~# lspci -s 02:00.0 -v -H1
> 02:00.0 Class eaea: Device eaea:eaea (rev ea) (prog-if ea)
> !!! Unknown header type 6a
>
> It's only available in the output of lspci with -H1 option.
>
> I'm aware that header type 6a is incorrect, but is there any workaround or
> something? How do I make the card work in Debian? It seems to be really
> interesting to find out how Ubuntu does that and use the same technique in
> Debian.

Which jessie kernel are you running?

# find /lib/modules/3.14-1-amd64 -name rtl8188ee.ko
/lib/modules/3.14-1-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8188ee/rtl8188ee.ko

# find /lib/modules/3.14-2-amd64 -name rtl8188ee.ko
/lib/modules/3.14-2-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8188ee/rtl8188ee.ko

Can you modprobe this driver?


-- 
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/CAOdo=swki-+26mx3hvuca9mof9wnu4fq+8xzqrhb+tdycvj...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Mon, Aug 4, 2014 at 7:21 PM, Joel Rees  wrote:
> On Tue, Aug 5, 2014 at 6:20 AM, Tom H  wrote:
>> On Mon, Aug 4, 2014 at 4:18 PM, Andrew McGlashan
>>  wrote:
>>> On 5/08/2014 5:44 AM, Erwan David wrote:
>>>> Le 04/08/2014 21:34, Tom H a écrit :
>>>>>
>>>>> Suppose that you have a 16-node cluster, some patches were applied to
>>>>> the systems overnight, a mistake was made, and you have to correct
>>>>> this mistake on all of the systems during trading hours. Once you get
>>>>> all the OKs that are needed for this kind of emergency change, the
>>>>> head of the trading desk that uses that cluster calls you and says
>>>>> "I'm going to be on the line for as long as you're working on our
>>>>> system." So you fix one node, reboot it, make sure that it's back in
>>>>> the cluster and doing its job, and fix another, etc. You can be sure
>>>>> that everyone's happier that the systems boot quickly and that the
>>>>> cluster was running with 15 rather than 16 nodes for as few minutes as
>>>>> possible (because you can be sure that the fact that this cluster
>>>>> wasn't running at full capacity for X minutes will come up in
>>>>> managerial meetings, both in IT ones and in IT-Business ones).
>>>
>>> The argument here is likely that the upgrade should have been tested on
>>> a test cluster FIRST and perhaps extensively -- if you have that many
>>> servers in play, you should have a development, test and production
>>> environment to work with and very stringent change control methods in place.
>>
>> Come on! Changes go through dev and uat before being rolled out to
>> prod. The night-shift sysadmin who made the changes screwed up. It
>> happens...
>
> When the operating system itself tries to hold the night-shift admin
> by the hand, we have serious problems.
>
> Current trading systems are completely wrong. It's no surprise if they
> can't get the failover part right, either.

The init system isn't baby-sitting the sysadmin and it has nothing to
do with trading system failover.

It's a question of having to correct a configuration error one node at
a time while the other nodes keep on doing whatever they're emant to
be doing and rebooting these nodes as quickly as possible.


--
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/CAOdo=SzoiPO=vfvp2f4cm8vvzf93vcz1-ym4astzk6+7yje...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Mon, Aug 4, 2014 at 6:44 PM, Steve Litt  wrote:
> On Mon, 4 Aug 2014 15:34:22 -0400
> Tom H  wrote:
>> On Mon, Aug 4, 2014 at 10:37 AM, Andrew McGlashan
>>  wrote:
>>> On 4/08/2014 11:32 PM, Tom H wrote:
>
>>> Sure it counts, but if you have 1000s of servers, you likely have
>>> many other considerations and you'll be pooling [at least] those
>>> servers in a cluster type arrangement ... much lessening the need
>>> for any machine to startup so quickly.
>>
>> It's a nice theory. I'll give you an example (not fully technical but
>> an example nonetheless; and I could give you others.
>>
>> Suppose that you have a 16-node cluster, some patches were applied to
>> the systems overnight, a mistake was made, and you have to correct
>> this mistake on all of the systems during trading hours. Once you get
>> all the OKs that are needed for this kind of emergency change, the
>> head of the trading desk that uses that cluster calls you and says
>> "I'm going to be on the line for as long as you're working on our
>> system." So you fix one node, reboot it, make sure that it's back in
>> the cluster and doing its job, and fix another, etc. You can be sure
>> that everyone's happier that the systems boot quickly and that the
>> cluster was running with 15 rather than 16 nodes for as few minutes as
>> possible (because you can be sure that the fact that this cluster
>> wasn't running at full capacity for X minutes will come up in
>> managerial meetings, both in IT ones and in IT-Business ones).
>
> If I understand correctly, these nodes are servers. Tell me one more
> time, just so I understand, why do these boxes have so many daemons
> that their boots take minutes?

Who cares how many daemons are running?!

If tomh-init is faster than htom-init, whether there's just ssh
running or 100 daemons running, I want to use tomh-init.

I can understand that there are people who don't want to adopt systemd
simply because it boots faster because they dislike some other
aspect(s) of systemd, but attacking systemd because it boots faster is
silly.

Everyone wants faster boot and wake-up. One of the reasons I hear time
and again regarding iPads is that they're so much better than laptops
and desktops because you cna use them instantly. So it's not just in
data centers that fast boot is appreciated.


-- 
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/CAOdo=swrqjv222yw1kpqjttd995-zbtd9l2+g+hauknsd+2...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Mon, Aug 4, 2014 at 6:28 PM, Steve Litt  wrote:
> On Mon, 4 Aug 2014 14:03:35 +0200
> Raffaele Morelli  wrote:
>>
>> I've seen tons of posts sent to this list about systemd... bla bla
>> bla... and did not understand what's the matter with it.
>>
>> I wonder what are you all doing with your init scripts which doesn't
>> work with systemd. So what?


> 1) Binary log files. If you can't see what a radical departure that is
>from the world of Unix, look again.

In the current default Debian setup, the rsyslog logs are saved as
text in "/var/log/" just as with sysvinit - and it has been pointed
out more than once on this list.


> 2) Gratuitous interdependency.

+1, more or less.


-- 
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/CAOdo=Sy4fV+cHuQkQyaFm0eq8Z=bztpqwred6_45omo6k3s...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Mon, Aug 4, 2014 at 5:56 PM, Brian  wrote:
> On Mon 04 Aug 2014 at 17:17:02 -0400, Tom H wrote:
>
>> Didn't all DEs use consolekit and policykit? IIRC wasn't the CTTE bug
>> filed because of a debian-devel@ thread about Gnome depending on
>> systemd (because of logind and/or libpam-systemd)?
>
> Consolekit did indeed reign supreme but had been on its way out for some
> time. The formal proposal to the Ctte was
>
>https://lists.debian.org/debian-ctte/2013/10/msg00019.html
>
> Read the rest for a roller-coaster ride.

That made me go back and look(!).

This thread
https://lists.debian.org/debian-devel/2013/10/msg00444.html
lead to this thread
https://lists.debian.org/debian-devel/2013/10/msg00651.html
which lead to the one that you posted.


-- 
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/CAOdo=SwzpS+VZmzkvLQOuJQt_4hdm8nvBuc=kqwtcewxbku...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Mon, Aug 4, 2014 at 4:18 PM, Andrew McGlashan
 wrote:
> On 5/08/2014 5:44 AM, Erwan David wrote:
>> Le 04/08/2014 21:34, Tom H a écrit :
>>>
>>> Suppose that you have a 16-node cluster, some patches were applied to
>>> the systems overnight, a mistake was made, and you have to correct
>>> this mistake on all of the systems during trading hours. Once you get
>>> all the OKs that are needed for this kind of emergency change, the
>>> head of the trading desk that uses that cluster calls you and says
>>> "I'm going to be on the line for as long as you're working on our
>>> system." So you fix one node, reboot it, make sure that it's back in
>>> the cluster and doing its job, and fix another, etc. You can be sure
>>> that everyone's happier that the systems boot quickly and that the
>>> cluster was running with 15 rather than 16 nodes for as few minutes as
>>> possible (because you can be sure that the fact that this cluster
>>> wasn't running at full capacity for X minutes will come up in
>>> managerial meetings, both in IT ones and in IT-Business ones).
>
> The argument here is likely that the upgrade should have been tested on
> a test cluster FIRST and perhaps extensively -- if you have that many
> servers in play, you should have a development, test and production
> environment to work with and very stringent change control methods in place.

Come on! Changes go through dev and uat before being rolled out to
prod. The night-shift sysadmin who made the changes screwed up. It
happens...


--
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/CAOdo=SweELVZb=kqzy0e1uogwcpzukfobu7n8xbf1qheumc...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Mon, Aug 4, 2014 at 4:04 PM, Bob Proulx  wrote:
> Andrew McGlashan wrote:
>>
>> Yes, that's what I meant, sysvinit is not broken.
>
> I rather agree. But the opponents cite corner cases where the
> previous security model doesn't handle every possible access case.
>
> I always hate it when people say such vague statements such as
> "modern" or "is broken" without actually saying why it is one way or
> the other. After reading months of arguments these next two postings
> were the first real postings I had read with any detail in them.
> Especially the second one.
>
> https://lists.debian.org/debian-devel/2014/06/msg00455.html
> https://lists.debian.org/debian-devel/2014/06/msg00461.html
>
> These are things that probably 99.44%[1] of the population hasn't ever
> needed before. The 99% where everything works for us are all of us
> crying about the disruption. But for that 0.56% that worried about
> those corner cases they see the old system as really broken. They are
> probably right that it is broken for them. But there are better ways
> to go about improving the system than the unpleasant way that systemd
> has been rolled out to the community.

Didn't all DEs use consolekit and policykit? IIRC wasn't the CTTE bug
filed because of a debian-devel@ thread about Gnome depending on
systemd (because of logind and/or libpam-systemd)?

The problem's that consolekit is abandonware upstream, logind is its
replacement, policykit removed consolekit support, and logind requires
systemd as pid 1 (or systemd-shim).


-- 
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/CAOdo=sz2spufui38q+l2hgjxmkv7bmfwuelfzksey2z3mgg...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Mon, Aug 4, 2014 at 3:44 PM, Erwan David  wrote:
>
> What takes most time when booting a server is what the server does
> before booting the OS (before grub in case of linux). Optimising what
> comes after is non-sense.

And VMs?


-- 
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/CAOdo=SwwSP_m2Sqnh=eimugatqhjwazgh-2pneheket7m0p...@mail.gmail.com

Re: The Fine Art of Making a Bootable Drive

[Tom H]

On Mon, Aug 4, 2014 at 10:57 AM, Martin G. McCormick
 wrote:
> Tom H writes:
>>
>> Are you mounting "/mnt/{dev,proc,sys}" before chrooting?
>
> No. I did try the mount command after chrooting which successfully ran, but
> didn't fix the missing /dev. I bet this is the crux of the
> problem, however. Mount just mounts everything in /etc/fstab. I
> don't remember if dev is there but /proc is there for sure
> When I mount /dev/sdf1 on /mnt and do a ls -l /dev/sda,
> it looks good.
>
> brw-rw 1 root disk 8, 0 Jul 28 19:09 sda
>
> Do I need to mount those befor chrooting?
>
> The only thing I am concerned about is of course is not
> overwriting the good boot sector on the old drive.:-(

You need to mount these filesystems within the chroot for it to be functional.

"/dev/sda" won't be accessible once you enter the chroot. You need to
have "/mnt/dev/sda".

Just in case you don't believe me, here are two links.

The Gentoo installation manual (just under "Mounting the necessary
Filesystems"):

https://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1&chap=6#doc_chap1

The Arch install instructions:

https://wiki.archlinux.org/index.php/Install_from_Existing_Linux

The Arch installation script (the "api_fs_mount" function):

https://projects.archlinux.org/arch-install-scripts.git/tree/common

(I'm surprised that Gentoo rbinds "/sys"; it wasn't there when I last
looked at the handbook - possibly a few years ago; I usually don't
even bind it. I'm suprised that Arch doesn't bind "/dev"; I've never
seen this before.)

The way that I ensure that I'm running grub-install on the right disk
is to run blkid to see which filesystem is on which disk.


-- 
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/CAOdo=sxfaurueo+vvwmn6jug+9jlw_nukgzs-oetpr1yhkj...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Mon, Aug 4, 2014 at 11:20 AM, Slavko  wrote:
> Dňa Tue, 05 Aug 2014 00:37:06 +1000 Andrew McGlashan
>  napísal:
>> On 4/08/2014 11:32 PM, Tom H wrote:
>>> On Mon, Aug 4, 2014 at 6:37 AM, Andrew McGlashan
>>>  wrote:
>>>>
>>>> systemd gives faster boot times, so what! I prefer to boot less
>>>> often and run with what works until I /have/ to do a reboot, so it
>>>> wouldn't matter if it took 10 times as long to boot. Improving
>>>> boot times is just like overclocking for games, it is largely
>>>> irrelevant and something to boast about ... ie, no real benefit.
>>>
>>> Boot speed might not be an important feature for you but for
>>> organizations with 1000s of servers, the faster the better.
>>
>> Sure it counts, but if you have 1000s of servers, you likely have many
>> other considerations and you'll be pooling [at least] those servers
>> in a cluster type arrangement ... much lessening the need for any
>> machine to startup so quickly.
>
> And this is IMO main point of the problem. I have no 1000 servers and i
> will not boot my machine any 2 min, to take advantage from faster
> boot ;-)

Since you don't care about boot speed, you shouldn't care that your
system boots faster.


> And it is the point where to business take precedence before freedom of
> choice (the boot system in this case). The systemd is forced (as
> dependency) by the policykit and perhaps some X software, then it
> switch from default to only one!

Luckily for you, there's a horrible corporation called Canonical that
employs a developer who put together systemd-shim and another
developer who put together cgmanager for you to be able to use logind
and policykit/polkit without having to use systemd as pid 1.


--
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/CAOdo=Sw9tN_wFyodAtLyL9=ynZJzffoN9D3uOZno2LyML=i...@mail.gmail.com

Re: NFS and iptables during bootup

[Tom H]

On Mon, Aug 4, 2014 at 10:52 AM, Martin T  wrote:
>
> I made a very simple bash script which loads the iptables
> configuration from /etc/firewall.conf and /etc/firewall6.conf files:
>
> # cat /etc/init.d/firewall
> #!/bin/bash
>
> iptables-restore < /etc/firewall.conf
> ip6tables-restore < /etc/firewall6.conf
>
> Script is stored in /etc/init.d/ directory, but I haven't configured
> init to load this script directly. I use the pre-up option in
> /etc/network/interfaces instead:
>
> # grep pre-up /etc/network/interfaces
>   pre-up /etc/init.d/firewall
>
> /etc/firewall.conf and /etc/firewall6.conf contain few simple
> allow-rules to input chain and set default policies for chains in
> input table to drop.
>
> Now if I reload the machine, the bootup takes more than 6 minutes.
> Bootlog can be seen below:
>
> ...
> Mon Aug  4 15:43:39 2014: Starting portmap daemon
> Mon Aug  4 15:43:39 2014: Starting NFS common utilities: statdSetting
> kernel variables ...done.
> Mon Aug  4 15:46:39 2014:  ^[[31mfailed!^[[39;49m
> ...
> Mon Aug  4 15:46:40 2014: startpar: service(s) returned failure:
> nfs-common ... ^[[31mfailed!^[[39;49m
> ...
> Mon Aug  4 15:46:40 2014: Starting portmap daemon...Already running..
> ...
> Mon Aug  4 15:46:40 2014: Starting NFS common utilities: statd
> ^[[31mfailed!^[[39;49m
> ...
>
> Once the system is started, the iptables and ip6tables rules are
> properly installed. According to log messages seen above, the problem
> seems to be with NFS. Has anyone seen something like this before?

What makes you think that it's iptables that's preventing statd?

Do you have this problem when you comment out "pre-up ..."?

Is there more info about nfs/statd in "/var/log/"?

Is "/usr" a separate filesystem mount?

Can you start nfs after the system boots?

Small "style" nitpick: Since "/etc/init.d/firewall" isn't integrated
into sysvinit, you might as well move it to
"/etc/{,firewall,network}"; or move it to "/etc/network/pre-up.d/" and
remove the "pre-up ..." line. I prefer installing iptables-persistent
but you might not want to or be allowed to...


-- 
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/CAOdo=sxtvdsbnc6k7ssavoq-em_b7uekzgdzph_sjxtkqyn...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Mon, Aug 4, 2014 at 10:37 AM, Andrew McGlashan
 wrote:
> On 4/08/2014 11:32 PM, Tom H wrote:
>> On Mon, Aug 4, 2014 at 6:37 AM, Andrew McGlashan
>>  wrote:


>>> My own view is "why systemd"  fix sysinit instead, where it is
>>> broken or rather the packages [whatever they are] that don't work properly.
>>
>> Who should fix sysvinit? The upstream sysvinit developers are DDs and
>> they didn't do it (I'm not blaming them, I'm just noting that fact).
>
> Yes, that's what I meant, sysvinit is not broken.

Some people'll disagree with the above statement. For example, if you
stop a sysvinit daemon, you cannot be sure that all of its children
will stop too whereas you can be with systemd.

Going back to "fix sysinit instead" (which is what I was replying to),
did anyone add cgroup support to sysvinit so someone could tell
Lennart "f-u, sysvinit can kill double-forked children"?


>>> systemd gives faster boot times, so what! I prefer to boot less often
>>> and run with what works until I /have/ to do a reboot, so it wouldn't
>>> matter if it took 10 times as long to boot. Improving boot times is
>>> just like overclocking for games, it is largely irrelevant and something
>>> to boast about ... ie, no real benefit.
>>
>> Boot speed might not be an important feature for you but for
>> organizations with 1000s of servers, the faster the better.
>
> Sure it counts, but if you have 1000s of servers, you likely have many
> other considerations and you'll be pooling [at least] those servers in a
> cluster type arrangement ... much lessening the need for any machine to
> startup so quickly.

It's a nice theory. I'll give you an example (not fully technical but
an example nonetheless; and I could give you others.

Suppose that you have a 16-node cluster, some patches were applied to
the systems overnight, a mistake was made, and you have to correct
this mistake on all of the systems during trading hours. Once you get
all the OKs that are needed for this kind of emergency change, the
head of the trading desk that uses that cluster calls you and says
"I'm going to be on the line for as long as you're working on our
system." So you fix one node, reboot it, make sure that it's back in
the cluster and doing its job, and fix another, etc. You can be sure
that everyone's happier that the systems boot quickly and that the
cluster was running with 15 rather than 16 nodes for as few minutes as
possible (because you can be sure that the fact that this cluster
wasn't running at full capacity for X minutes will come up in
managerial meetings, both in IT ones and in IT-Business ones).

I don't care what's bringing up a system,
sysvinit/systemd/smf/launchd, the faster the better.

I also once read an article that claimed that Google had said that
every reboot costs it money. I googled for it but nothing came up.


-- 
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/CAOdo=szepe6tacv76nlfh4zvzcrna3zum58hxx1b_qgzyo7...@mail.gmail.com

Re: The Fine Art of Making a Bootable Drive

[Tom H]

On Mon, Aug 4, 2014 at 7:33 AM, Martin G. McCormick
 wrote:
>
> It turns out that the reason I never thought of using mkfs to
> build a working boot sector is that mkfs doesn't do that. Grub,
> however, does but I am still a bit confused as to how to get it
> working. I mounted the new drive on /mnt
> #mount /dev/sdf1 /mnt
> It's all there.
> #chroot /mnt
> / is now the top of that directory.
> #grub-install /dev/sda
> /dev/sda isthere but grub reports it can't find that device and
> "is /dev mounted?" This is one of those time you wish siri was
> part of Linux and you could yell at her! Seriously, how do I
> safely do this so that I make this disk think it is /dev/sda
> which will be what it is when it really boots?

Are you mounting "/mnt/{dev,proc,sys}" before chrooting?


-- 
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/CAOdo=SzTurM8K76ye-NbjzXOhGpd4XEDqiX4Dh3NUqc5=gv...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Mon, Aug 4, 2014 at 6:37 AM, Andrew McGlashan
 wrote:


> My own view is "why systemd"  fix sysinit instead, where it is
> broken or rather the packages [whatever they are] that don't work properly.

Who should fix sysvinit? The upstream sysvinit developers are DDs and
they didn't do it (I'm not blaming them, I'm just noting that fact).


> systemd gives faster boot times, so what!  I prefer to boot less often
> and run with what works until I /have/ to do a reboot, so it wouldn't
> matter if it took 10 times as long to boot.  Improving boot times is
> just like overclocking for games, it is largely irrelevant and something
> to boast about ... ie, no real benefit.

Boot speed might not be an important feature for you but for
organizations with 1000s of servers, the faster the better.


-- 
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/CAOdo=SxKfsc6pMntDLC7+XfFq_AfqpadUeU_d11QNO=8prl...@mail.gmail.com

Re: fsck progress not shown on boot with systemd as pid 1

[Tom H]

On Sun, Aug 3, 2014 at 2:12 PM, Bob Proulx  wrote:
>
> if [ -f /etc/inittab ]; then
>   if grep -q '^1:2345:respawn:/sbin/getty 38400 tty' /etc/inittab; then
> log "Fixing getty --noclear in /etc/inittab"
> sed --in-place '/^1/s/getty 38400/getty --noclear 38400/' /etc/inittab
> kill -1 1  # Tell init to re-read the inittab file.
>   fi
> fi

You can use "telinit q" instead of "kill -1 1".


-- 
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/CAOdo=Sw1DVGcDzi5UO+uRzsVVOJ9mmTMJKqXhw1BW9Xf9Uo==g...@mail.gmail.com

Re: Bug#736258: acpid won't stop, won't upgrade (systemd) - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736258

[Tom H]

On Sat, Aug 2, 2014 at 8:53 PM, Chris Bannister
 wrote:
>
> [snip]
>
> Is there a reason debian-user is subscribed to this bug report?

Please don't top-post.

Probably because it's a debian-user@ thread that resulted in the the
bug report and we were added to the cc as a (thoughtful) courtesy.


-- 
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/CAOdo=SwgviC=x_zs0xasrjuk1pzasa1tl4tpglbz8xdmz2_...@mail.gmail.com

Re: fsck progress not shown on boot with systemd as pid 1

[Tom H]

On Sat, Aug 2, 2014 at 8:53 PM, The Wanderer  wrote:
> On 08/02/2014 03:15 PM, Brian wrote:
>> On Sat 02 Aug 2014 at 12:24:46 -0600, Bob Proulx wrote:
>>> Brian wrote:

 With sysvinit the default at booting is for the screen messages
 to fly past at a bewildering speed and then for the screen to be
 cleared by agetty. Nobody particularily complains about this
 behaviour. Unless you have an excellent visual memory you are in
 the dark as regards what happened.
>>>
>>> Just for the record I complain about that behavior. I don't like
>>> the fancy tty colors and always disable them. I don't like the
>>> screen clearing those away and so I always set the getty --noclear
>>> option. The problem is that while there may be complaints like mine
>>> I don't see them changing anything.
>>
>> Upstream for agetty responded to concerns about security from users,
>> some of whom apparently had the compliance police breathing down
>> their necks. My view on such idiocy is probably not for this list.
>> The --noclear option rules here too.
>
> Where do you set this, exactly? /etc/inittab ? (If so, what about for
> systemd? /etc/inittab is much about runlevels, which systemd doesn't use
> AFAIK.)

In "/etc/inittab" for sysvinit and in "/etc/systemd/system/" for systemd.


-- 
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/CAOdo=swe73_kzeoobrgupnqbh+c5uaxszm2cotlnimbvjme...@mail.gmail.com

Re: /usr on own filesystem, not already mounted -- yeech!

[Tom H]

On Sun, Aug 3, 2014 at 2:59 AM, David Baron  wrote:
>
> Started to get this message several times in bootup or maybe was simply not
> quick enough to catch it before. Everything seems to play.
>
> The Debian installer itself will place /usr on it own partition/filesystem. So
> what gives?
>
> Is it now required that /usr be on on part of the root filesystem? If so, easy
> enough to accomplish. But never needed anything like that before.
>
> Also, the initrd is being done with "more." This was given by the installer.
> In the past, I had used "dep" quite successfully, possible with a few entries
> in modules.conf. Faster initial load ... "More" would seem to imply
> that this /usr business is superfluous.
>
> So what is the answer/recommendation here? I have not updated the 208.6
> systemd and udev packages yet.

Hasn't d-i always defaulted to "most" (not "more") in
"/etc/initramfs-tools/initramfs.conf"?

Roger Leigh had a patch to allow mounting "/usr" from the initramfs
but it never made it into "unstable", etc. He'd asked for it to be
installed from his personal repo and tested. IIRC I'd tried it with
with "/usr" mounted as a separate mdraid device and reported to him
that it booted OK. Perhaps there wasn't much interest in doing this so
he moved to other things.


-- 
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/CAOdo=sxfhg4ufhr3544frrjjqblogvqccxczb+n_+svspc5...@mail.gmail.com

Re: systemd waisted 5 hours of my work time today

[Tom H]

On Fri, Aug 1, 2014 at 9:40 AM, Joel Rees  wrote:
> On Fri, Aug 1, 2014 at 7:51 AM, Tom H  wrote:
>> On Sun, Jul 27, 2014 at 9:18 PM, Joel Rees  wrote:


>>> In this case, yeah, experimental is experimental, but there are
>>> limits. And that was not the way to have done it.
>>
>> I'm not sure what you're referring to. The introduction of systemd in
>> Debian or the recent removal of the systemd-shim dependency in testing
>> and unstable?
>
> The way it was introduced on Fedora. Like I said in the part I elided,
> there should have been a separate distro, advertised for those who
> wanted to join the fun.

Oh. I hadn't linked the two. Thanks for the clarification.

Fedora's stated purpose is to be a bleeding edge distro and its
unstated purpose is to be a testing ground for RHEL. It pulled out of
introducing systemd in F14 at the last minute, to Lennart's vocal
displeasure, and then introduced it in F15. As a laptop Fedora user,
the F15 introduction was OK (for me) but I still had a site using
Fedora servers (since transitioned to Ubuntu LTS) and that was more
painful than I would've liked. Fedora could've adopted the Debian way
and allowed its users to use "init=/path/to/systemd" on the kernel
cmdline for the F15 cycle. They didn't - and there may have been
political reasons for this - and we survived. There have been worse
releases in the past.


> Debian's introduction was not so great either, but at least they
> waited a couple of years longer.

Debian's so concerned with upgradability that a transition for jessie
or jessie+1 would've likely been just as painful. Although I would've
preferred for Debian to default to systemd in jessie+1 in order to
wait for systemd developement to settle down and for it to have been
in RHEL 7 for a while, but systemd-fan-DD filed a CTTE bug and...


> The shim? Well, the powers that want systemd on all things Linux want
> to push all things sysv-init off, so we should expect the shim to
> disappear from time to time, to "help" recalcitrant admins and devs to
> quit depending on it. And that's also using engineering for politics.

Now that logind and cgmanager can work together, systemd-shim is OK.
The real non-systemd-init killer is around the corner: the
introduction of kdbus into stable kernels will necessitate someone to
create a dbusmanager the way that ubuntu created cgmanager for the use
of a modern kernel and a modern udev. But there's still time for those
flame wars to erupt.


-- 
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/CAOdo=Sy5cFBKOJ_K5Cu-_cCVhCW=fEfA0cjRo8=3e-1oakw...@mail.gmail.com

Re: Skype access cancelled for Debian versions before 7

[Tom H]

On Sat, Aug 2, 2014 at 3:30 PM, Andrew McGlashan
 wrote:
>
> There must be an alternative to Skype.
>
> http://www.makeuseof.com/tag/fed-up-with-skype-here-are-6-of-the-best-free-alternatives/

In theory but not in practice - unless you want to use one of the
above and talk to yourself.


-- 
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/CAOdo=SyS1cWfT=ts2t7sjk1x2eaecphgwzdseohjpb60+2p...@mail.gmail.com

Re: Skype access cancelled for Debian versions before 7

[Tom H]

On Sat, Aug 2, 2014 at 1:29 PM, Bret Busby  wrote:
>
> I have found, in the last day, that Microsoft has apparently cancelled
> Skype access for versions of Debian before 7.x.
>
> With the error message that I encountered, with my Skype 2.2 (beta)
> running on Debian 6, I went to the Skype web site, and found that they
> have cancelled access for all but the latest version of Skype, and,
> for Debian, it apparently needs Debian 7.x, to run.
>
> No notice (on the Skype mailing list) was given.
>
> I thought that anyone like me, who is running and using Debian 6 (and
> anyone using earlier versions of Debian), most of the time, might like
> to know.

Debian 6 is oldstable so why shouldn't MS decide to withdraw Skype support?

Didn't Google withdraw Chrome support recently? (There was a thread about this.)


-- 
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/CAOdo=sxq5juvms4yymcnhly39hltzkudzoyoisct5oa5+zh...@mail.gmail.com

Re: auto starting of ppp has stopped working

[Tom H]

On Fri, Aug 1, 2014 at 2:49 AM, Chris Bannister
 wrote:
> On Thu, Jul 31, 2014 at 09:32:08PM -0700, Rusi Mody wrote:
>>
>> So now the question is:
>>
>> What is the 'modern' way of automatically doing 'modprobe pppoe'
>> at boot/ifup time?
>>
>> Evidently something has changed that has made that stop happening...
>
> Put it in /etc/modules. I hope that is still the place. BTW, a quick
> google should have helped with this ... was Google unhelpful in this
> instance?

Since "/etc/modules" is a Debianism, for systemd in Debian, there's a
symlink from "/etc/modules-load.d/modules.conf" to "/etc/modules".


-- 
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/CAOdo=sxoag8urabb6nagppzyinr-j6exmmho+-lz2vkkec6...@mail.gmail.com

Re: auto starting of ppp has stopped working

[Tom H]

On Fri, Aug 1, 2014 at 12:32 AM, Rusi Mody  wrote:
> On Friday, August 1, 2014 12:10:02 AM UTC+5:30, Rusi Mody wrote:
>>
>> After some recent upgrades (this is on jessie)
>> auto starting of ppp has stopped working.
>>
>> So every time after booting I now have to run pppoeconf.
>
> Some progress... and a different question:
>
> Doing:
>
> # pon dsl-provider
>
> I get:
>
> Plugin rp-pppoe.so loaded.
> Couldn't open the /dev/ppp device: No such file or directory
> Linux kernel does not support PPPoE -- are you running 2.4.x?
>
> However:
> # modprobe pppoe
>
> pulls in pppox and ppp_generic as well.
>
> After that
> # pon dsl-provider
>
> works
>
> So now the question is:
>
> What is the 'modern' way of automatically doing 'modprobe pppoe'
> at boot/ifup time?
>
> Evidently something has changed that has made that stop happening...

Either "/etc/modprobe.d/.conf" or in "/etc/modules" if the
former isn't early enough.


-- 
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/CAOdo=sw3jh5rwuxi9zbnyr-0ny6cbfz3kpyzaldbbr+cu4f...@mail.gmail.com

Re: systemd requires kernel to have CONFIG_CGROUPS enabled -> installer check!

[Tom H]

On Thu, Jul 31, 2014 at 4:53 PM, Andrei POPESCU
 wrote:
> On Jo, 31 iul 14, 20:13:23, JPT wrote:
>>
>> my self built system is dead because systemd installer does not check if
>> control groups are enabled BEFORE upgrading the package.
>>
>> Could someone take care so the installer checks current kernel features?
>
> Do you mean the Debian Installer? Doesn't make much sense, since the
> installer will install a Debian kernel that has everything needed
> enabled.

He must mean the systemd package's scripts not d-i.


-- 
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/CAOdo=SxLGtwiKcEm=qunwtv6rq6dk01rfj7ht1a3vkr8pub...@mail.gmail.com

Re: systemd waisted 5 hours of my work time today

[Tom H]

On Sun, Jul 27, 2014 at 9:18 PM, Joel Rees  wrote:
> On Sun, Jul 27, 2014 at 7:47 PM, Tom H  wrote:
>> On Thu, Jul 24, 2014 at 9:00 AM, Slavko  wrote:
>>> Dňa Thu, 24 Jul 2014 13:00:24 +0100 Tom Furie 
>>> napísal:
>>>>
>>>> You are, of course, aware that testing and unstable are test platforms
>>>> where breakage is to be expected? They shouldn't be used for anything
>>>> "mission critical", that's what stable is for.
>>>
>>> No, i will not comply with this.
>>>
>>> The testing must be in state, where it must to boot (except some boot
>>> options tweaks) by default. I think, that nobody here will complain if
>>> some of software/services on testing doesn't work, but computer must to
>>> boot!
>>
>> Can you point to a document where such a commitment has been made or
>> such a criterion has been decided?


> You've just touched my hotpoint, Tom

Sorry! :)


> The post that got me kicked off the Fedora developer list was the one
> a bit more than two years ago where I questioned Poettering's
> engineering qualifications specifically because he lead the putsch.
> (I'm apparently no longer on the auto-mod list over there, but I don't
> really care any more.)

Kicked off or moderated? (It would mean the same to me because I'd
unsubscribe...). I remember some threads where you were arguing about
some Fedora software policies (one about grubby?).


> Engineering by putsch is simply not what qualified engineers do to
> users who have not agreed, up front and beforehand, to be fodder for
> the putsch.
>
> Yeah, when we agree to use Sid or Rawhide, we agree to a certain
> amount of being guinea pigs, but this is a level or two beyond that,
> even.

I run rawhide on my laptop and the only systemd breakage that I've
experienced since Fedora 15 has been nfs. X and Gnome have broken more
often over the years...

I'm trying to remember systemd breakages in Debian but it's late and
I'm tired and the only one that comes to mind is the fact that systemd
doesn't respect sysvinit tmpfs settings in "/etc/default/". I suppose
that if Fedora used a similar environment file in its equivalent,
"/etc/sysconfig/", there might have been an upstream solution. As it
is, Debian users will have to use a drop-in to over-ride the systemd
.mount that they want to change, unless they write a unit to use the
Debian environment file.


> Being a little less metaphorical, the shift from sysv-init to anything
> as comprehensive as systemd necessarily breaks APIs en-masse. The
> parts that are in the specs may be manageable, but it is known that in
> systems as complex as OSses, there are more implicit linkages than any
> single person or any committee can plan for.
>
> Implicit linkages are where the API providers' understandings and the
> API users' understandings have some common base that is not recognized
> as needed to be written down.
>
> But when you expand the reach of the API or the user domain, you
> discover that the common understanding is not there after all, and
> then programmers start engineering by rumor and superstition. Both the
> API and the user domain were not just drastically expanded, but also
> shifted in this case. Uhm, by shift, I mean that the focus has changed
> significantly.
>
> Systemd is not a replacement for sysv-init. It is a set of brand-new
> functionality that sysv-init was never intended to implement. And it
> kind-of-sort-of adds the sysv-init functionality as the spoonful of
> sugar that is supposed to make the medicine go down. Woops, that's
> more metaphor.

Yes, systemd replaces sysvinit's functionality (booting up) plus extra
functionality.


> One of the symptoms of this kind of implicit linkage is where the end
> users end up saying, well, the docs say ordering shouldn't matter, but
> in this particular case it does. (See several recent threads for
> recent examples.)

I think that you're referring to the network and network-online
business. As I pointed out in that thread, the man page(s) showed that
the OP's expectation/understanding was incorrect of the necessity of
using "Requires". Quite frankly, I found the reasoning obscure
(systemd's not his) but the necessity of "Requires" as well as "After"
or "Before" (I've forgotten which one the OP was using) was
documented.


> The sort of changes being brought in by systemd are so sweeping that
> we cannot expect them all to be shaken out in the distro's
> experimental release, even if the agreement to be test users were to
> agree something to that extreme. So the stable users are going 

Re: [Wheezy] [networking] post-up NOT executed

[Tom H]

On Sun, Jul 27, 2014 at 9:52 AM, Pascal Hambourg  wrote:
> Tom H a écrit :
>> On Thu, Jul 24, 2014 at 2:41 PM, Mickael MONSIEUR
>>  wrote:
>>>
>>> post-up /sbin/route add 1.2.3.4 dev eth0
>>
>> your "route ..." syntax looks wrong to me.
>
> Not to me.
>
> zenith:~# /sbin/route add 1.2.3.4 dev eth0
> zenith:~# /sbin/route -n
> Kernel IP routing table
> Destination   Gateway  Genmask Flags Metric RefUse Iface
> 1.2.3.4   0.0.0.0  255.255.255.255 UH0  00 eth0
>
>> There's no netmask and no gateway.
>
> Because it does not need any. It is a direct route to a host address.

Thanks. And sorry, brain-fart.


--
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/CAOdo=sy847nvup4wx_yxwnwdo-nttryytns1z3ex-xst+jx...@mail.gmail.com

Re: 'strictatime' vs. 'relatime' for /tmp

[Tom H]

On Wed, Jul 30, 2014 at 4:12 AM, Andrei POPESCU
 wrote:
>
> When mounting a tmpfs on /tmp systemd sets 'strictatime'. I was
> wondering whether this is really needed. Does anybody know of software
> that would break with 'relatime' (the default) or even 'noatime'?
>
> I'd be happy to RTFM if anybody can point me to the relevant FM.

Perhaps because it cleans "/tmp" every 10 days (possibly not on Debian
but I only have access to Fedora at the moment) and therefore needs
files' atime fully updated.




/lib/systemd/system/systemd-tmpfiles-clean.timer

[Unit]
Description=Daily Cleanup of Temporary Directories
Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8)

[Timer]
OnBootSec=15min
OnUnitActiveSec=1d




/lib/systemd/system/systemd-tmpfiles-clean.service

[Unit]
Description=Cleanup of Temporary Directories
Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8)
DefaultDependencies=no
Conflicts=shutdown.target
After=systemd-readahead-collect.service
systemd-readahead-replay.service local-fs.target time-sync.target
Before=shutdown.target

[Service]
Type=oneshot
ExecStart=/usr/bin/systemd-tmpfiles --clean
IOSchedulingClass=idle




/lib/tmpfiles.d/tmp.conf

# Clear tmp directories separately, to make them easier to override
d /tmp 1777 root root 10d
d /var/tmp 1777 root root 30d

# Exclude namespace mountpoints created with PrivateTmp=yes
x /tmp/systemd-private-%b-*
X /tmp/systemd-private-%b-*/tmp
x /var/tmp/systemd-private-%b-*
X /var/tmp/systemd-private-%b-*/tmp


-- 
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/CAOdo=sxjzocwdmcpxzwndzjb2beeq2zz20g6ytcyj1qzovu...@mail.gmail.com

Re: systemd support for init level use case

[Tom H]

On Thu, Jul 24, 2014 at 7:44 PM, Gregory Seidman
 wrote:
>
> I'm on stable, but I'm reading the threads about systemd and I want to be
> prepared for the next stable release. I run a RAID1 with an encryption loop
> and LVM on top of that for my home directories and a number of data volumes
> (i.e. nothing system-critical like /usr or /var).
>
> I boot into init level 2, which does not bring up the RAID, much less
> encryption, LVM, or mounted filesystems. I then log in as root on the
> console and run a script to bring up the additional filesystems,
> particularly the encryption. This requires interaction to supply the
> password. Once the filesystems are mounted, the script runs /sbin/telinit 3
> to start additional services which depend on those filesystems (apache2,
> exim4, fetchmail, etc.).
>
> I don't always want to bring everything up, and I certainly don't want boot
> to hang on user input waiting for the encryption password. Does systemd
> have some init level equivalent? Should I be modeling my script as several
> custom systemd services (which are not automatically started), including
> some virtual service that depends on all the ones I'm currently bringing up
> as init level 3?
>
> Note that I am not complaining about the upcoming switch to systemd, just
> trying to understand and prepare for the implications for my particular
> needs.

You can create a target (basicboot.target?) and make that your default
either with "systemd.unit=basicboot.target" on the kernel cmdline of
by symlinking it to "default.target".


-- 
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/CAOdo=szrhed-fgzy4---rljvwsq03dtn7z5t_sy5wd81yjb...@mail.gmail.com

Re: [Wheezy] [networking] post-up NOT executed

[Tom H]

On Thu, Jul 24, 2014 at 2:41 PM, Mickael MONSIEUR
 wrote:
>
> I have a fresh installation of Debian Wheezy 7.6.0 amd64.
> The post-up line does not execute when eth0 is mounted!
> (by against my eth0 interface is mounted!)
>
> I have to mount routes, and are not:
>
> post-up /sbin/route add 1.2.3.4 dev eth0
>
> simple test:
>
> post-up touch /tmp/test
> reboot (...)
>
> cat /tmp/test
> cat: /tmp/1: No such file or directory
>
> Have you ever had this problem?
> I find nothing in dmesg and syslog!

I'm not too sure what "cat /tmp/test" and "/tmp/1" have to do with one
another but your "route ..." syntax looks wrong to me. There's no
netmask and no gateway. I haven't used net-tools in a while but I
remember:

route add [-net|-host]  netmask  gw
 [dev] etho


-- 
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/CAOdo=syo81np-qmyjyvde2xfv+mfwad3s5q28fbavqlskqv...@mail.gmail.com

Re: systemd waisted 5 hours of my work time today

[Tom H]

On Thu, Jul 24, 2014 at 9:00 AM, Slavko  wrote:
> Dňa Thu, 24 Jul 2014 13:00:24 +0100 Tom Furie 
> napísal:
>>
>> You are, of course, aware that testing and unstable are test platforms
>> where breakage is to be expected? They shouldn't be used for anything
>> "mission critical", that's what stable is for.
>
> No, i will not comply with this.
>
> The testing must be in state, where it must to boot (except some boot
> options tweaks) by default. I think, that nobody here will complain if
> some of software/services on testing doesn't work, but computer must to
> boot!

Can you point to a document where such a commitment has been made or
such a criterion has been decided?


--
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/CAOdo=SzSh4MGCa0Q+t=BHMKMrfkYsK7qoD3T9Zv=m7sbeed...@mail.gmail.com

Re: missing LSB tags and overrides

[Tom H]

On Thu, Jul 24, 2014 at 10:34 AM, Darac Marjal  wrote:
>
> All this, of course, assumes the OP doesn't want to use the previously
> mentioned suggestion of "aptitude purge '~c'". And that's fair enough;
> aptitude is not to everyone's taste.

If you'd rather not use aptitude to purge packages, you can still use
it to search:

apt-get purge $(aptitude search ~c -F %p)


-- 
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/CAOdo=SzbqSd2=H8AOcc_9L=ttbr+HXuuN=rxgikztc5mo9-...@mail.gmail.com

Re: systemd log messages during boot (Re: I'm not a huge fan of systemd)

[Tom H]

On Wed, Jul 23, 2014 at 2:02 AM, Erwan David  wrote:
> On Wed, Jul 23, 2014 at 12:06:51AM CEST, Michael Biebl  
> said:
>> Am 22.07.2014 19:22, schrieb Erwan David:
>>> Le 22/07/2014 18:59, Michael Biebl a écrit :
 Am 22.07.2014 18:24, schrieb The Wanderer:

> As far as I can see, there is no way to get init-system log messages
> without also getting kernel log messages
 Of course there is.

 Might help if you actually tried it before commenting on it?

 The systemd.* specific flags override the global quiet flag. The

 So you can very well keep the quiet kernel command line argument and use

 systemd.show_status=true|false
 systemd.sysv_console=true|false
 systemd.log_level=...
 systemd.log_target=...

 etc. to control in a very fine grained manner, how the data is logged.
>>>
>>> It would be interesting if the default was not changed, ie. same
>>> behaviour when using the default configuration.
>>
>> The default wasn't changed, really.
>> It's simply that SysV init scripts are so horribly inconsistent and
>> interpret the "quiet" parameter differently. So we don't have a
>> consistent behaviour wrt to logging and output.
>
> The defauklt was changed in that nomessage at all, no sign of any
> progression is NOT the former behaviour.
>>
>> The example skeleton SysV init script /etc/init.d/skeleton, which is
>> supposed to be a base for newly written init scripts uses
>> /lib/init/init-d-script. If you take a look at that script, you'll see
>> that prefixes its log message with [ "$VERBOSE" != no ] && log_*_msg
>>
>> And surprise, VERBOSE is set to "no" by /lib/init/vars.sh if the kernel
>> command line contains "quiet".
>>
>> Thankfully, this is all fixed now with systemd, where you have a
>> consistent and central place to configure that.
>
> NO it ids NOT fixed,k because what imports is NOT the theory but the
> actual behaviour. The actual behaviour is changed, and the new one is
> more than disturbing.

The behavior of the boot messages hasn't changed for me and according
to the systemd man pages it shouldn't. So your setup must be
different.


--
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/CAOdo=sx-so_i4nat1k2vo8hjtntjqwka72eueakuhys1-vm...@mail.gmail.com

Re: I'm not a huge fan of systemd

[Tom H]

On Tue, Jul 22, 2014 at 11:01 AM, The Wanderer  wrote:
> On 07/22/2014 10:34 AM, Tom H wrote:
>> On Mon, Jul 21, 2014 at 12:47 PM, Erwan David 
>> wrote:
>>>
>>> So it seems there is a quiet on the default command line, which
>>> does not mean same thing when using systemd or using init.
>>>
>>> I do not want full verbose, I would like previous behaviour. Where
>>> I could see in one glance whether it was working or blocked without
>>> having too many messages.
>>
>> I remember someone's post advising you to use
>> "systemd.show_status=true" on the kernel cmdline.
>>
>> But this is from the systemd man page
>>
>> == %< 
>> systemd.show_status=
>> Takes a boolean argument or the constant auto. If true, shows terse
>> service status updates on the console during bootup. auto behaves
>> like false until a service fails or there is a significant delay in
>> boot. Defaults to true, unless quiet is passed as kernel command line
>> option in which case it defaults to auto.
>>
>> quiet
>> Turn off status output at boot, much like systemd.show_status=false
>> would. Note that this option is also read by the kernel itself and
>> disables kernel log output. Passing this option hence turns off the
>> usual output from both the system manager and the kernel.
>> == >% 
>>
>> so you shouldn't have need it.

It should've been "so you shouldn't have needed it"...


> If memory serves, this (systemd doing things differently in response to
> the presence of non-namespaced, generic arguments on the kernel command
> line) is exactly what triggered the famous "Linus blacklists Kay Sievers
> from getting code upstream" incident.
>
> Specifically, in that case, systemd was reading 'debug' from the kernel
> command line and outputting such floods of information that the boot
> process was extremely slow and debugging it was actually hampered.
>
> The use of 'quiet' by systemd doesn't cause quite the same type of
> issue, but it does still mean that you can't silence kernel boot output
> without also silencing systemd (init-system, and probably consequently
> "service") boot output, which means it's another class of the same
> problem.
>
> The "right" solution here would be for systemd to stop consuming, or
> otherwise reacting to, any non-namespaced kernel-command-line arguments.
> ("Namespaced" here means e.g. with the "systemd." prefix, as with
> 'systemd.show_status' above. Responding to 'systemd.quiet' or
> 'systemd.debug' would be just fine.) I actually thought this had already
> been done, in response to the 'debug' incident, but maybe not - or maybe
> even they only did it for 'debug' itself, not more generally...

Linus has said that parsing "quiet" and "debug" is OK.

The "debug" problem's been fixed; IIRC it was fixed before the lkml lovefest.

AIUI, the kernel's rate-limiting logging to "/dev/kmsg" and systemd
stops logging to "/dev/kmsg" once journald is up and running.


-- 
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/CAOdo=sz8p-xro+zona020+gswpmpjxpt5py4+hws_5zoal5...@mail.gmail.com

Re: Sid Systemd upgrade

[Tom H]

On Mon, Jul 21, 2014 at 3:09 PM, Miles Fidelman
 wrote:
> Tom H wrote:
>> On Mon, Jul 21, 2014 at 11:49 AM, Miles Fidelman
>>  wrote:
>>>
>>> Damn right I don't use development or testing versions in production.
>>> I'm
>>> looking down the road a year and planning what I will use in production
>>> when
>>> my current system is ready for upgrade. It's looking less and less like
>>> Debian, and more and more like one of the BSDs.
>>
>> Maybe time'll prove that a Debian transition to systemd will be a
>> disaster but I doubt it. The DDs, and especially the members of the
>> release team (and I dare say, the systemd team) will ensure that it
>> isn't.
>>
>>
> I'm not sure I have all that much faith in that, when we have no less than
> Linus Torvalds saying things like this about key systemd developers:
>
> -
>
> “Key[sic], I'm [expletive] tired of the fact that you don't fix problems in
> the code *you* write, so that the kernel then has to work around the
> problems you cause,” he wrote.
>
> Torvalds went on to state that “this has been going on for *years*,” and
> said that he will refuse to accept patches from Sievers until Sievers cleans
> up his act.
>
> -
>
> I have a bit more faith in the Debian release team, but not so much about
> upstream.

Linus rants regularly but it's just rants.

The last time that I saw him post his uname (in the last 8-10 months),
he was using Fedora (and therfore systemd). He's ranted about Gnome
and policykit and he's using both.

You'll have a hard time avoiding Kay's coding if you're using Linux
since he's the udev maintainer.


--
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/CAOdo=sw4ajfugl2jsyi0re5uf-tgvbedccsu0ocl2kbvj23...@mail.gmail.com

Re: I'm not a huge fan of systemd

[Tom H]

On Mon, Jul 21, 2014 at 12:47 PM, Erwan David  wrote:
> Le 21/07/2014 18:23, Tom H a écrit :
>> On Mon, Jul 21, 2014 at 4:18 AM, Erwan David  wrote:
>>> On Mon, Jul 21, 2014 at 09:59:55AM CEST, Tom H  said:
>>>> On Sat, Jul 19, 2014 at 10:33 PM, sp113438  wrote:


>>>>> Booting is fast
>>>>
>>>> That's one of the development goals.
>>>
>>> I switched today, and for me booting is slow, much slowzer than before.
>>> And booting is silent : almost no information message about what happens.
>>> From the systemd-analyze man page:
>>
>> systemd-analyze time prints the time spent in the kernel before
>> userspace has been reached, the time spent in the initial RAM disk
>> (initrd) before normal system userspace has been reached, and the time
>> normal system userspace took to initialize. Note that these
>> measurements simply measure the time passed up to the point where all
>> system services have been spawned, but not necessarily until they
>> fully finished initialization or the disk is idle.
>>
>> systemd-analyze blame prints a list of all running units, ordered by
>> the time they took to initialize. This information may be used to
>> optimize boot-up times. Note that the output might be misleading as
>> the initialization of one service might be slow simply because it
>> waits for the initialization of another service to complete.
>
> Thanks for this, I now see some samba related services being rather long.

You're welcome.


>>> So you are before a screen with almost no message, not knowing if it works 
>>> or not.
>>
>> Do you have "quiet" on the kernel cmdline?
>
> I have debian's default. I did not touch it and behaviour changed.
> That's the problem.
>
> So it seems there is a quiet on the default command line, which does not
> mean same thing when using systemd or using init.
>
> I do not want full verbose, I would like previous behaviour. Where I
> could see in one glance whether it was working or blocked without having
> too many messages.

I remember someone's post advising you to use
"systemd.show_status=true" on the kernel cmdline.

But this is from the systemd man page

== %< 
systemd.show_status=
Takes a boolean argument or the constant auto. If true, shows terse
service status updates on the console during bootup. auto behaves like
false until a service fails or there is a significant delay in boot.
Defaults to true, unless quiet is passed as kernel command line option
in which case it defaults to auto.

quiet
Turn off status output at boot, much like systemd.show_status=false
would. Note that this option is also read by the kernel itself and
disables kernel log output. Passing this option hence turns off the
usual output from both the system manager and the kernel.
== >% 

so you shouldn't have need it.


--
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/CAOdo=SwUD=0wdp1rfo3xpvc101edazveiokiwugwzruke0z...@mail.gmail.com

Re: testing-dedicated ML? ( was Re: End of hypocrisy ? )

[Tom H]

On Mon, Jul 21, 2014 at 12:56 PM, David Guntner  wrote:
> Tom H grabbed a keyboard and wrote:
>>
>> There is one
>>
>> https://lists.debian.org/debian-testing/
>>
>> but a quick look at the its archives shows that it isn't a heavily
>> used list and that it's not a list for freaking out about systemd.
>
> Neither is this one, but that doesn't seem to stop people :-)

LOL. Very true. I guess that I've become more or less immune to the
fact that can't be a reasonable discussion of certain topics.

However the users of debian-testing@ might not appreciate their list
being infected with our diseases!


-- 
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/CAOdo=SwLLrBwyDSc3_++CJ-wJu9beT_F7s9AgmOph6A=eqb...@mail.gmail.com

Re: Sid Systemd upgrade

[Tom H]

On Mon, Jul 21, 2014 at 11:49 AM, Miles Fidelman
 wrote:
>
> Damn right I don't use development or testing versions in production.  I'm
> looking down the road a year and planning what I will use in production when
> my current system is ready for upgrade. It's looking less and less like
> Debian, and more and more like one of the BSDs.

Maybe time'll prove that a Debian transition to systemd will be a
disaster but I doubt it. The DDs, and especially the members of the
release team (and I dare say, the systemd team) will ensure that it
isn't.


-- 
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/CAOdo=Sw-bEwbBu+yU_0vgT7VQXX62W=fa1v5eg7ssb70gv+...@mail.gmail.com

Re: Skipping releases on dist-upgrades [was: Re: Is this safe?? Chrome in Debian 6]

[Tom H]

On Mon, Jul 21, 2014 at 10:30 AM, Joe  wrote:
> On Mon, 21 Jul 2014 04:37:40 -0400 Tom H  wrote:
>>
>> There's already been one thread about this on debian-devel@ and it was
>> a typical thread where the pro and con make their points but no
>> decision's reached. That discussion'll be back because there are
>> people who think that they ought to be able to go from squeeze-lts to
>> jessie in one step - and they'll tell you that one upgrade is safer
>> than two.
>
> Two upgrades that are almost certain to work are safer than one which
> hasn't been tested...

Feel free to join the flamewar when it takes place - because it will.


-- 
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/CAOdo=sxs4c6dfuyymv4j1rfyaqsqw9ajoxrkfc11vkq--h0...@mail.gmail.com

Re: testing-dedicated ML? ( was Re: End of hypocrisy ? )

[Tom H]

On Mon, Jul 21, 2014 at 11:58 AM,   wrote:
> Le 21.07.2014 15:31, Slavko a écrit :
>>
>> it seems, that there can good idea to provide separate ML for testing
>> users.
>
> I agree, since testing is not for normal users (well... theoretically at
> least), so we could imagine that different MLs for (beta-)testing and
> productive usage (questions about "how to do..." and stable related bugs
> would go there, I guess).
> Now, I have no idea about the complexity of maintaining a new ML. Maybe
> there are also problems because some issues can not clearly affect only one
> of both testing and stable?

There is one

https://lists.debian.org/debian-testing/

but a quick look at the its archives shows that it isn't a heavily
used list and that it's not a list for freaking out about systemd.


--
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/CAOdo=SwzmN_Wrh9UUvn4SwfprT6cbRt+myBfrCf12Dq8g+X9=g...@mail.gmail.com

Re: I'm not a huge fan of systemd

[Tom H]

On Mon, Jul 21, 2014 at 5:01 AM, Erwan David  wrote:


>>> 2) You have a specific syntax, and a specific semantics (what does
>>> ExecStart, WantedBy, etc mean), that one must learn in order to simply
>>> read this. The namles of the sections are also meaningfull. All this
>>> defines a full fledge langaue, and I did not find any comprehensive donc
>>> of the language. Each doc refers to 43 or 4 other docs who refers back
>>> to all the others, making things quite difficult to read when you need a
>>> complete doc and not only a reference on points that you already
>>> partially know.
>>
>> You have to learn the syntax of any program in order to use it.
>>
>> The LSB headers of a sysvinit script have to be learned.
>
> Yes. SO the argument "it is a simple text file not a shell script" uis
> false. It is as complicated to learn as a shell script. More for
> people knowing scripting (eg. all unix admins).

Run "file /lib/systemd/system//service" and check what it returns.

The ini file is a text file. But is has a syntax. Your argument would
mean that a text file in hindi wouldn't be a text file. No. You'd have
to learn hindi to understand the hindi file and you have to learn
systemd-speak to understand its unit files.


>> For documentation of the keys, try harder:
>>
>> man 7 systemd.directives
>
> You're joking or what ?

Not at all. Either you're an administrator and you learn about the
tools that you have to use or you're a user and you don't.


>  Accept=
>systemd.socket(5)
>
>After=
>systemd.unit(5)
>
>Alias=
>systemd.unit(5)
>
>AllowIsolate=
>systemd.unit(5)
>
>Also=
>systemd.unit(5)
>
>Backlog=
>systemd.socket(5)
>
>Before=
>systemd.unit(5)
>
>BindIPv6Only=
>systemd.socket(5)
>
>BindToDevice=
>systemd.socket(5)
>
>BindsTo=
>systemd.unit(5)
>
> Does not document anything. It is just an index to a multi file
> reference, which is useless if you do not already know the system. My
> problem is not "whioch are the options for this particular statement",
> but how do I do this (eg. How do I test a particular condition before
> starting a daemon, or how do I replace my policy-rc.d ?).

It's an index. So what? It tells you in which systemd. man
page to look up a systemd unit's key. Weren't you asking to understand
unit files and their syntax?


-- 
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/CAOdo=Szi0_Du9LaF6=2va8b+szoo5zbz1wv7kdyddfz-gas...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Mon, Jul 21, 2014 at 5:35 AM, David Baron  wrote:
> On Monday 21 July 2014 08:45:12 debian-user-digest-requ...@lists.debian.org
> wrote:
>>
>> (Using "init=/sbin/init" on the kernel cmdline will boot systemd if
>> you have systemd-sysv installed.)
>
> More and more complicated, huh?
> Will this command line work without the .shi package installed?
> What if system was installed initially, never had init?

"init=/sbin/init" is assumed. The reason that the question was asked
was because when systemd-sysv isn't installed you have to use
"init=/lib/systemd/systemd" on the kernel cmdline.

It's not possible for "/sbin/init" not to be there with the current d-i setup.


-- 
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/CAOdo=SwNb+8UL26=KEzywts3wfVKz8Bcy=cp0kg4nw2geu6...@mail.gmail.com

Re: I'm not a huge fan of systemd

[Tom H]

On Mon, Jul 21, 2014 at 4:28 AM, Erwan David  wrote:
>
> libpam-systemd now refuses systemd-shim (with v208 in testing)...

You must be skipping emails in this thread.


-- 
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/CAOdo=Swf6RKJze6MW7SHgvqDZ==va1spusnrs6fyrblr51h...@mail.gmail.com

Re: I'm not a huge fan of systemd

[Tom H]

On Mon, Jul 21, 2014 at 4:18 AM, Erwan David  wrote:
> On Mon, Jul 21, 2014 at 09:59:55AM CEST, Tom H  said:
>> On Sat, Jul 19, 2014 at 10:33 PM, sp113438  wrote:
>>>
>>> Booting is fast
>>
>> That's one of the development goals.
>
> I switched today, and for me booting is slow, much slowzer than before.
> And booting is silent : almost no information message about what happens.

>From the systemd-analyze man page:

systemd-analyze time prints the time spent in the kernel before
userspace has been reached, the time spent in the initial RAM disk
(initrd) before normal system userspace has been reached, and the time
normal system userspace took to initialize. Note that these
measurements simply measure the time passed up to the point where all
system services have been spawned, but not necessarily until they
fully finished initialization or the disk is idle.

systemd-analyze blame prints a list of all running units, ordered by
the time they took to initialize. This information may be used to
optimize boot-up times. Note that the output might be misleading as
the initialization of one service might be slow simply because it
waits for the initialization of another service to complete.

> So you are before a screen with almost no message, not knowing if it works or 
> not.

Do you have "quiet" on the kernel cmdline?


-- 
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/CAOdo=SwPuL=4iT_XiL=kmqakh3hpemdvfkzuknkeqqunksf...@mail.gmail.com

Re: I'm not a huge fan of systemd

[Tom H]

On Sun, Jul 20, 2014 at 10:47 AM, Erwan David  wrote:
> Le 20/07/2014 16:11, Andrei POPESCU a écrit :
>> On Du, 20 iul 14, 14:40:27, Erwan David wrote:


>>> Add to this the fact it throws away years of habits with yet another
>>> language (yes the systemd unit files are nit shellscripts but they use a
>>> specific language mre complicated to understand thant shell scripts,
>> You must be confusing systemd unit files with something else:
>>
>> /lib/systemd/system/mpd.service:
>>
>> [Unit]
>> Description=Music Player Daemon
>> After=network.target sound.target
>>
>> [Service]
>> EnvironmentFile=/etc/default/mpd
>> ExecStart=/usr/bin/mpd --no-daemon $MPDCONF
>>
>> [Install]
>> WantedBy=multi-user.target
>>
>> This is the classic .ini format, very easy to read without having any
>> knowledge of shell scripting (or any other programing language).
>
> This is not the classic ini format
>
> 1) this format is not so classic (except for windows users, who do not
> use systemd) and I do not find a complete definition of it (eg. I did
> not find a definition of a section, it seems rather straightforward, but
> not completely, what if a definition is before the first section title,
> is there a way to do subsections, etc...)

It is a standard ini file format, which is:

[Section]
=

It's used, for example, by postfix (without "[Section]") so it's not
just a Windows format.


> 2) You have a specific syntax, and a specific semantics (what does
> ExecStart, WantedBy, etc mean), that one must learn in order to simply
> read this. The namles of the sections are also meaningfull. All this
> defines a full fledge langaue, and I did not find any comprehensive donc
> of the language. Each doc refers to 43 or 4 other docs who refers back
> to all the others, making things quite difficult to read when you need a
> complete doc and not only a reference on points that you already
> partially know.

You have to learn the syntax of any program in order to use it.

The LSB headers of a sysvinit script have to be learned.

For documentation of the keys, try harder:

man 7 systemd.directives

RHEL 7 has just been released with systemd so there's probably extra
documentation on redhat.com.


>>> systemd may have advantages but the change is much too fast, untested
>>> and will lead to big problems that many of us cannot afford.
>>
>> You're aware of course that Debian is one of the last big distros to
>> switch to systemd, with the notable exception of Ubuntu (who was using
>> upstart anyway).
>
> RHEL 7 does not use systemd as far as I know, only fedora (which would
> be sid, but not stable).

Please do some homework before making such a statement about RHEL 7!

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.0_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.0_Release_Notes-System_and_Services.html


--
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/CAOdo=sw9zo626gpmhtvuwgzuhr73wwhqu2gk8qgbeg6ktgv...@mail.gmail.com

Re: End of hypocrisy ?

[Tom H]

On Mon, Jul 21, 2014 at 4:19 AM, Martin Steigerwald  wrote:
> Am Montag, 21. Juli 2014, 07:30:40 schrieb Erwan David:
>
> Still… also hibernate and suspend with KDE is currently broken with sysvinit-
> core. And systemd 208 just doesn´t boot my workstation at work, while it works
> nicely with my laptop. But even there I will hold systemd back. I currently
> want to do init=/sbin/init in case any systemd upgrade breaks boot. I don´t
> trust it enough yet to rely on it like I did with init.

Didn't a KDE maintainer say during the timeframe of CTTE init bug that
KDE might choose to depend in logind? So your laptop might need the
systemd-shim that depends on cgmanager.

(Using "init=/sbin/init" on the kernel cmdline will boot systemd if
you have systemd-sysv installed.)


--
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/CAOdo=swimwx8nhrj_fqqkp_gfpaaxvsuta-jwrvfs3bohnz...@mail.gmail.com