| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
The approved method for determining the installed release of
Ubuntu is to execute "lsb_release". However, this is in /usr/bin and
is implemented in python so it is not safe to execute at this early
stage of booting. This code parses /etc/lsb-release which is
where "lsb_release" looks for the information.
|
|
|
|
|
|
|
|
tmpfiles quite a bit
|
|
|
|
whether something is a char or block device
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SIGSTOP
|
|
|
|
|
|
Arch has no release name, so juts prints 'Welcome to Arch Linux!'.
The color is the same as used by Arch's native rc.sysinit.
|
|
Hi,
after talked with Michael on IRC, here is the patch to see a systemd
Welcome message on Debian systems.
FYI: I had to remove "quiet" from Kernel-command-line to see it.
"Stolen from Gentoo" :-) [1,2]?
Kind Regards,
- Sedat -
[1] http://lists.freedesktop.org/archives/systemd-devel/2010-September/000267.html
[2] http://cgit.freedesktop.org/systemd/commit/?id=0d37b36b2890fdf8149d12460ebb00822e555977
From 76d860ca774cb8724de25c3ed3c455ebe5d548e3 Mon Sep 17 00:00:00 2001
From: Sedat Dilek <sedat.dilek@gmail.com>
Date: Sun, 12 Sep 2010 23:02:22 +0200
Subject: [PATCH] util: add Debian welcome message
Include the "Debian" string as /etc/debian_version contains only the Distribution name like "squeeze".
Use Light Red color for Debian.
Based on a proposal patch of Michael Biebl <biebl@debian.org>
|
|
|
|
with plymouth
https://bugzilla.redhat.com/show_bug.cgi?id=628913
|
|
https://bugzilla.redhat.com/show_bug.cgi?id=626891
|
|
|
|
|
|
decode exit codes in systemctl
|
|
socket-activate nscd anyway
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This makes it easier to support /etc/sysconfig/xxxx with command line
env vars in style of $OPTIONS which might or might not be set.
|
|
empty string
|
|
|
|
|
|
|
|
|
|
read them.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/28/2010 05:57 AM, Kay Sievers wrote:
> On Wed, Jul 28, 2010 at 11:43, Lennart Poettering
> <lennart@poettering.net> wrote:
>> On Mon, 26.07.10 16:42, Daniel J Walsh (dwalsh@redhat.com) wrote:
>>> tcontext=system_u:object_r:device_t:s0 tclass=chr_file
>>> type=1400 audit(1280174589.476:7): avc: denied { read } for pid=1
>>> comm="systemd" name="autofs" dev=devtmpfs ino=9482
>>> scontext=system_u:system_r:init_t:s0
>>> tcontext=system_u:object_r:device_t:s0 tclass=chr_file
>>> type=1400 audit(1280174589.476:8): avc: denied { read } for pid=1
>>> comm="systemd" name="autofs" dev=devtmpfs ino=9482
>>> scontext=system_u:system_r:init_t:s0
>>> tcontext=system_u:object_r:device_t:s0 tclass=chr_file
>>>
>>> Lennart, we talked about this earlier. I think this is caused by the
>>> modprobe calls to create /dev/autofs. Since udev is not created at the
>>> point that init loads the kernel modules, the devices get created with
>>> the wrong label. Once udev starts the labels get fixed.
>>>
>>> I can allow init_t to read device_t chr_files.
>>
>> Hmm, I think a cleaner fix would be to make systemd relabel this device
>> properly before accessing it? Given that this is only one device this
>> should not be a problem for us to maintain, I think? How would the
>> fixing of the label work? Would we have to spawn restorecon for this, or
>> can we actually do this in C without too much work?
>
> I guess we can just do what udev is doing, and call setfilecon(), with
> a context of an earlier matchpathcon().
>
> Kay
> _______________________________________________
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Here is the updated patch with a fix for the labeling of /dev/autofs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkxQMyoACgkQrlYvE4MpobNviACfWgxsjW2xzz1qznFex8RVAQHf
gIEAmwRmRcLvGqYtwQaZ3WKIg8wmrwNk
=pC2e
|
|
seperate arguments
|
|
Don't try to merge devices that have been created via dependencies when
they appear in the system and can be recognized as the same. Instead,
simply continue to maintain them independently of each other, however
with the same state cycle. Why? Because otherwise we'd have a hard time
to seperate the dependencies after the devices are unplugged again and
we hence cannot be sure anymore that next time the device is plugged in
it will carry the same names.
Example: if one depndency refers to dev-sda.device and another one to
dev-by-id-xxxyyy.device we only learn at time of plug in of the device
that it is actually the same device that was ment. In the moment the
device is unplugged again we won't know anymore their relation to each
other and the next time the harddisk is plugged it might even appear as
dev-by-id-xxxyyy.device and dev-sdb.service. To ensure the dependencies
continue to have the meaning they were intended to have let's hence keep
the .device objects seperate all the time, even when they are plugged
in.
This patch also introduces a new Following= property which points from
the various .device units of a specific device to the main .device unit
for it. This can be used by the client side to figure out the relation
of the .device units to each other and even filter units from display.
|
|
|
|
|
