On Wed, Sep 4, 2013 at 5:20 AM, Frank Steinmetzger <war...@gmx.de> wrote:
> On Wed, Sep 04, 2013 at 09:22:37AM +0200, Stefan G. Weichinger wrote:
>> Am 03.09.2013 23:31, schrieb Frank Steinmetzger:
>>
>> > This link gave me the deciding hint -- I didn't have
>> > cryptsetup-generator in my system, because I didn’t have the
>> > cryptsetup useflags enabled. I rebuilt systemd and udisks and now
>> > I’m prompted for the LUKS password during boot. \o/
>>
>> Congratulations!
>>
>> sidenote: The mentioned pam_mount way of doing things lets you boot
>> through to a login. No waiting for the passphrase ... when I login the
>> LUKS-device is opened and mounted ... only one time user/pw ...
>> personally I like it that way.
>
> Finding stuff on pam_mount doesn’t seem to be too hard. But how do I
> prevent systemd from trying it first? Just by disabling the service?
>
>> > Now I need to find out whether it’s feasible for me to use it. I’ll
>> > definitely have to procure some custom unit files, e.g. for
>> > monitorix.
>> […]
>> pls share your unit as well (or even file it as a bug on
>> bugs.gentoo.org) to help the gentoo devs (and users) here.
>
> Well, it’s an experiment, but I’m still quite hesitant to switch. It
> really shuts down fast (1 to 2 seconds or so), but I don’t see much
> improvement in booting time (still around 40 seconds until KDM is
> finished). I like the small stuff around it though, for instance
> timedatectl is neat and that there is no consolekit thread spam in htop.

Even considering that you need to input the LUKS password, 40 seconds
is too much. You can use systemd-analyze and systemd-analyze blame
after a fresh boot to see what is taking most of the boot time.

> I also see now why some people rant about it, e.g. that it has an own
> logging daemon (“one big block of everything”) which uses a binary data
> format. OTOH, logging becomes very handy with it in that you can see all
> messages associated with a particular service. Systemdadm is a start,
> but impractical on a netbook screen.

Don't forget journalctl -b -p err and journalctl -b -p warning. Hugh
time savings.

> I was hoping I could have openrc and systemd in parallel on the system
> (so I don’t have to maintain two systems, especially on a slow netbook),
> but b/c I removed consolekit altogether, a lot of stuff doesn’t work
> anymore if I try booting with openrc.
>
> Perhaps someone can give me a hint about the following:
> - I’m missing openrc’s feature of using the menu key to switch between
>   the last two TTYs, that’s very useful.

I didn't realized it was gone. However, I don't think is a feature of
OpenRC, it's just that OpenRC calls agetty differently from systemd, I
suppose.

> - No login prompt on TTY1.

Sure it is. Perhaps is just garbled? Try to log in and do a reset.

> - A resource link on how to set up networking without network manager. I
>   always did it the conf.d/net way.

You can set up the network without networkmanager just fine.

If you want to use DHCP:

dhcpcd@.service
----------------------------------------------------
[Unit]
Description=DHCP on %I
After=basic.target
Documentation=man:dhcpcd(8)

[Service]
ExecStartPre=/bin/ifconfig %I up
ExecStart=/sbin/dhcpcd -B %I

[Install]
WantedBy=multi-user.target
----------------------------------------------------

If you want to use static network:

----------------------------------------------------
[Unit]
Description=Static network service
After=local-fs.target
Documentation=man:ifconfig(8)
Documentation=man:route(8)

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/ifconfig <interface> <ip> broadcast <broadcast> netmask
<netmask> up
ExecStart=/bin/route add default gw <gateway> <interface>
----------------------------------------------------

(You can use the new ip command, but ifconfig is still the one
installed by default in Gentoo).

Or if you need something more complicated, you can put it in several
ExecStart lines, or put it in a script and call that.

Regards.
-- 
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Reply via email to