[systemd-devel] LLDP from Zyxel – "Operation not supported"

[Mantas Mikulėnas]

I enabled LLDP receive for eth* in networkd. It recognizes outgoing packets
sent by lldpd (on the computer itself) and by ladvd (on pfSense), but
chokes on incoming packets sent by a Zyxel switch:

> LLDP: Receive frame failed: Operation not supported

Attaching the actual packet.

(By the way, `networkctl lldp` is a bit boring – it'd be more useful to
show the SysName instead of the TTL...)

-- 
Mantas Mikulėnas 


lldp.pcapng
Description: Binary data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Chris Murphy]

On Sun, Jan 11, 2015 at 10:13 PM, Chris Murphy  wrote:
> On Sun, Jan 11, 2015 at 8:29 PM, Andrei Borzenkov  wrote:
>> В Sun, 11 Jan 2015 12:45:17 -0700
>> Chris Murphy  пишет:
>>
>>> On Sun, Jan 11, 2015 at 4:57 AM, Andrei Borzenkov  
>>> wrote:
>>> > В Sun, 11 Jan 2015 04:15:41 -0700
>>>
>>> > Does it using systemd *inside* of initrd? From upstream dracut:
>>> >
>>> > if ! dracut_module_included "systemd"; then
>>> > inst_hook cmdline 95 "$moddir/parse-block.sh"
>>> > inst_hook pre-udev 30 "$moddir/block-genrules.sh"
>>> > inst_hook mount 99 "$moddir/mount-root.sh"
>>> > ^ here it does it
>>> > fi
>>> >
>>> > Do you have Fedora specific patches to do it differently?
>>>
>>> So the reason it's mounting all file systems ro by default appears to
>>> be strictly because of the ro kernel parameter in the grub.cfg as
>>> created by grub-mkconfig.
>>
>> Again - when using mount-root.sh it will
>>
>> - *always* mount real root ro
>> - fetch other mount options from real root /etc/fstab
>> - remount real root rw with correct mount options applied
>>
>> This all got lost if you use standard systemd-fstab-generator +
>> systemd-fsck services.
>
> I don't agree with this, but here is a journalctl -b -l -o
> short-monotonic output from Fedora 21 [1], with
> systemd.log_level=debug rd.debug set. I do not see any reference to
> mount-root.sh from dracut. What I see is systemd honoring kernel
> parameter ro.

(I hit some key that made gmail send before the mail was done.)
Anyway, this is what I'm getting:

[   11.956890] f21v.localdomain systemd[257]: Executing: /bin/mount -n
/dev/disk/by-uuid/f3332d09-65f9-48c5-8539-c2b9ec8c75b4 /sysroot -t
auto -o subvol=root,ro

And no reference to mount-root.sh. This isn't new behavior in Fedora
21, Fedora 20 is the same and I think going back more versions too.
There are numerous instances of systemd-fstab-generator and
systemd-fsck that show up in the journal I referenced. Fedora stays
fairly close to upstream systemd, there really is no point for it to
be running drastically different.


-- 
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Chris Murphy]

On Sun, Jan 11, 2015 at 8:29 PM, Andrei Borzenkov  wrote:
> В Sun, 11 Jan 2015 12:45:17 -0700
> Chris Murphy  пишет:
>
>> On Sun, Jan 11, 2015 at 4:57 AM, Andrei Borzenkov  
>> wrote:
>> > В Sun, 11 Jan 2015 04:15:41 -0700
>>
>> > Does it using systemd *inside* of initrd? From upstream dracut:
>> >
>> > if ! dracut_module_included "systemd"; then
>> > inst_hook cmdline 95 "$moddir/parse-block.sh"
>> > inst_hook pre-udev 30 "$moddir/block-genrules.sh"
>> > inst_hook mount 99 "$moddir/mount-root.sh"
>> > ^ here it does it
>> > fi
>> >
>> > Do you have Fedora specific patches to do it differently?
>>
>> So the reason it's mounting all file systems ro by default appears to
>> be strictly because of the ro kernel parameter in the grub.cfg as
>> created by grub-mkconfig.
>
> Again - when using mount-root.sh it will
>
> - *always* mount real root ro
> - fetch other mount options from real root /etc/fstab
> - remount real root rw with correct mount options applied
>
> This all got lost if you use standard systemd-fstab-generator +
> systemd-fsck services.

I don't agree with this, but here is a journalctl -b -l -o
short-monotonic output from Fedora 21 [1], with
systemd.log_level=debug rd.debug set. I do not see any reference to
mount-root.sh from dracut. What I see is systemd honoring kernel
parameter ro.



[1]
https://docs.google.com/a/colorremedies.com/file/d/0B_2Asp8DGjJ9TnlmNVRlLWtETTA/edit
-- 
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH udev v5] udev: Add builtin/rule to export evdev information as udev properties

[Zbigniew Jędrzejewski-Szmek]

On Sun, Jan 11, 2015 at 08:47:19PM +0100, Carlos Garnacho wrote:
> This rule is only run on tablet/touchscreen devices, and extracts their size
> in millimeters, as it can be found out through their struct input_absinfo.
> 
> The first usecase is exporting device size from tablets/touchscreens. This
> may be useful to separate policy and application at the time of mapping
> these devices to the available outputs in windowing environments that don't
> offer that information as readily (eg. Wayland). This way the compositor can
> stay deterministic, and the mix-and-match heuristics are performed outside.
> 
> Conceivably, size/resolution information can be changed through EVIOCSABS
> anywhere else, but we're only interested in values prior to any calibration,
> this rule is thus only run on "add", and no tracking of changes is performed.
> This should only remain a problem if calibration were automatically applied
> by an earlier udev rule (read: don't).
> 
>   v2: Folded rationale into commit log, made a builtin, set properties
>   on device nodes themselves
>   v3: Use inline function instead of macro for mm. size calculation,
>   use DECIMAL_STR_MAX, other code style issues
>   v4: Made rule more selective
>   v5: Minor style issues, renamed to a more generic builtin, refined
>   rule further.
Applied.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Andrei Borzenkov]

В Sun, 11 Jan 2015 12:45:17 -0700
Chris Murphy  пишет:

> On Sun, Jan 11, 2015 at 4:57 AM, Andrei Borzenkov  wrote:
> > В Sun, 11 Jan 2015 04:15:41 -0700
> 
> > Does it using systemd *inside* of initrd? From upstream dracut:
> >
> > if ! dracut_module_included "systemd"; then
> > inst_hook cmdline 95 "$moddir/parse-block.sh"
> > inst_hook pre-udev 30 "$moddir/block-genrules.sh"
> > inst_hook mount 99 "$moddir/mount-root.sh"
> > ^ here it does it
> > fi
> >
> > Do you have Fedora specific patches to do it differently?
> 
> So the reason it's mounting all file systems ro by default appears to
> be strictly because of the ro kernel parameter in the grub.cfg as
> created by grub-mkconfig.

Again - when using mount-root.sh it will

- *always* mount real root ro
- fetch other mount options from real root /etc/fstab
- remount real root rw with correct mount options applied

This all got lost if you use standard systemd-fstab-generator +
systemd-fsck services.

If dracut now requires all root mount options to be always present on
kernel command line instead of in system /etc/fstab - fine but then this
should be stated so.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Nikolai Zhubr]

Hi,
12.01.2015 0:47, Chris Murphy:
[...]

- man tune2fs uses very strong language to set either
interval-between-checks or max-mount-counts. However, mke2fs 1.42.11
(09-Jul-2014) sets neither by default. I'm not sure when this changed,
it used to set check interval to 180, but a new file system has it set
to 0, and max mount count to -1. So it's highly recommended but not
the default anymore. *shrug* Not sure what to make of that.


I'd interpret this as yet another hint that e2fsck is not a tool for 
planned diagnostic. (Hence no default schedule.) Rather, it is a tool 
for (attempt of) recovery after some unexpected damage event.


That said, I do have quick fsck enabled at boot on all my machines, but 
it's more of a paranoid nature than somehow practically important.


(This is getting off-topic though, so maybe let's not abuse the mailing 
list further)



Thank you,
Nikolai



- ext34, XFS, and Btrfs all do a journal replay at mount time if the
fs was unmounted uncleanly, and normally this will fix things. If
there are errors, mount fails. e2fsck does same check and journal
replay if necessary that mounting does. But if that fails, e2fsck
falls back to preening the filesystem automatically.

XFS and Btrfs don't have such a fall back condition to do an automatic
preen. For one their fsck.  does nothing successfully, those files
don't point to the real repair utils. Their repair utils are only
meant to be run when normal mount is tried first and then fails;
xfs_repair will even complain if the fs hasn't been mounted first and
tell the user to try mounting it to replay the journal since
xfs_repair won't do that. For Btrfs, mount failure means trying
another mount with -o recovery, not running btrfs check, which is
almost a last resort option.

I think it would be more helpful to remove the always fsck root job,
that isn't actually doing anything 99.999% of the time. Instead, in
case of mount failure, dracut shell should end with a cheat sheet for
what the user ought to do to repair the file system. It knows what
root device it is and its file system at this point so it could spit
out the path to the repair utility, all of which now have different
names by the way: e2fsck, xfs_repair, and for Btrfs mount -o recovery
tried first. Right now the user is dropped into a desert, as rare as
it is, and we ought to do better than this until we've got magical
always self-healing file systems.



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] networkd-218 won't set bridge l2addr to slave device

[Jan Engelhardt]

When using the old-fashioned brctl to set up a bridge, it would give the 
bridge the L2 address of the first slave when the slave is added.
networkd does not do that, which leads to a setup like this:

2: enp0s3:  mtu 1500 qdisc pfifo_fast 
master brg0 state UP group default qlen 1000
link/ether 08:00:27:0a:c5:b2 brd ff:ff:ff:ff:ff:ff
inet6 fe80::a00:27ff:fe0a:c5b2/64 scope link 
   valid_lft forever preferred_lft forever
3: brg0:  mtu 1500 qdisc noqueue state 
UP group default 
link/ether fa:ef:64:e8:77:d2 brd ff:ff:ff:ff:ff:ff
inet 169.254.69.103/16 brd 169.254.255.255 scope link brg0
   valid_lft forever preferred_lft forever
inet 10.10.60.129/24 brd 10.10.60.255 scope global brg0
   valid_lft forever preferred_lft forever


tcpdump now tells us on ping:

66:ba:7f:2d:8b:80->ff:ff:ff:ff:ff:ff ethertype ARP (0x0806), length 44:
Request who-has 10.10.60.129 tell 10.10.60.1, length 28
fa:ef:64:e8:77:d2->66:ba:7f:2d:8b:80 ethertype ARP (0x0806), length 62:
Reply 10.10.60.129 is-at fa:ef:64:e8:77:d2, length 46
66:ba:7f:2d:8b:80->fa:ef:64:e8:77:d2 ethertype IPv4 (0x0800), length 100:
10.10.60.1 > 10.10.60.129: ICMP echo request, id 22523, seq 1, length 64

The problem is, the '129 machine never receives this, because the
enp0s3 interface has a different L2addr and filters this. Setting
promiscuous mode does not let it pass, probably because '129 is a
VirtualBox environment. In any case, I do not think +PROMISC would be
the right fix.

Setting the L2addr of brg0 to that of enp0s3 makes ICMP echo
exchangeable as expected. I think that networkd's default
MACAddressPolicy= should not be "random" (nor "persistent"),
but a new "slave".
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [RFC] hwdb: add MOUSE_WHEEL_CLICK_ANGLE as property

[Peter Hutterer]

Most mice have a wheel click angle of 15 degrees, i.e. 24 clicks per full
wheel rotation. Some mice, like the Logitech M325 have a larger angle. To
allow userspace to make use of that knowledge, add a property to the hwdb.
---
libinput patches to read this are here:
http://lists.freedesktop.org/archives/wayland-devel/2015-January/019340.html

This is an RFC, unless we ack this for libinput there's no user for it so
I'd like to get both out first for review. Please don't merge yet.


 hwdb/70-mouse.hwdb | 44 +++-
 1 file changed, 31 insertions(+), 13 deletions(-)

diff --git a/hwdb/70-mouse.hwdb b/hwdb/70-mouse.hwdb
index 4a4603c..f1638e0 100644
--- a/hwdb/70-mouse.hwdb
+++ b/hwdb/70-mouse.hwdb
@@ -28,6 +28,29 @@
 # mouse:usb:v17efp6019:*
 # mouse:*:name:Lenovo Optical USB Mouse:
 #
+# To add local entries, create a new file
+#   /etc/udev/hwdb.d/71-mouse-local.hwdb
+# and add your rules there. To load the new rules execute (as root):
+#   udevadm hwdb --update
+#   udevadm trigger /dev/input/eventXX
+# where /dev/input/eventXX is the mouse in question. If in
+# doubt, simply use /dev/input/event* to reload all input rules.
+#
+# If your changes are generally applicable, open a bug report on
+#   http://bugs.freedesktop.org/enter_bug.cgi?product=systemd
+# and include your new rules, a description of the device, and the
+# output of
+#   udevadm info /dev/input/eventXX
+# (or /dev/input/event*).
+#
+# Allowed properties are:
+#MOUSE_DPI
+#MOUSE_WHEEL_CLICK_ANGLE
+#
+#
+#   MOUSE_DPI   #
+#
+#
 # DPI settings are specified as
 #MOUSE_DPI=[@]
 #
@@ -64,20 +87,15 @@
 # third-party software) must not be entered into this file, use a local
 # hwdb instead.
 #
-# To add local entries, create a new file
-#   /etc/udev/hwdb.d/71-mouse-local.hwdb
-# and add your rules there. To load the new rules execute (as root):
-#   udevadm hwdb --update
-#   udevadm trigger /dev/input/eventXX
-# where /dev/input/eventXX is the mouse in question. If in
-# doubt, simply use /dev/input/event* to reload all input rules.
+#
+#   MOUSE_WHEEL_CLICK_ANGLE #
+#
+#
+# The angle in degrees per mouse wheel 'click', specified as
+# MOUSE_WHEEL_CLICK_ANGLE=
+#
+# Most mice have a 15 degree click stop (24 clicks per full rotation).
 #
-# If your changes are generally applicable, open a bug report on
-#   http://bugs.freedesktop.org/enter_bug.cgi?product=systemd
-# and include your new rules, a description of the device, and the
-# output of
-#   udevadm info /dev/input/eventXX
-# (or /dev/input/event*).
 
 #
 # Sort by by brand, type (usb, bluetooth), DPI, frequency.
-- 
2.1.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] slow systemd-networkd DHCP client on wlan0 with systemd v217

[Charles Devereaux]

Hello

With dhcpcd5 and the following options, once wpa_supplicant is done,  I
have a connection within the same second if I ignore ARP.

With systemd-network, it's much much slower.

$ systemd-analyze blame
  3.923s systemd-networkd-wait-online.service
(...)

I tried to measure the time taken on wlan0, to see where the problem came
from::

Jan 11 17:53:01 thinkpad wpa_supplicant@wlan0[391]: started
Jan 11 17:53:02 thinkpad kernel: IPv6: ADDRCONF(NETDEV_UP): wlan0: link is
not ready
Jan 11 17:53:03 thinkpad kernel: wlan0: authenticate with ea:fc:af:f6:dd:cd
Jan 11 17:53:03 thinkpad kernel: wlan0: send auth to ea:fc:af:f6:dd:cd (try
1/3)
Jan 11 17:53:03 thinkpad kernel: wlan0: authenticated
Jan 11 17:53:03 thinkpad kernel: wlan0: associate with ea:fc:af:f6:dd:cd
(try 1/3)
Jan 11 17:53:03 thinkpad kernel: wlan0: RX AssocResp from ea:fc:af:f6:dd:cd
(capab=0x411 status=0 aid=2)
Jan 11 17:53:03 thinkpad kernel: IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link
becomes ready
Jan 11 17:53:03 thinkpad kernel: wlan0: associated
Jan 11 17:53:03 thinkpad systemd-networkd[419]: wlan0   : gained
carrier
Jan 11 17:53:04 thinkpad avahi-daemon[403]: Joining mDNS multicast group on
interface wlan0.IPv6 with address fe80::xxx
Jan 11 17:53:04 thinkpad avahi-daemon[403]: New relevant interface
wlan0.IPv6 for mDNS.
Jan 11 17:53:04 thinkpad avahi-daemon[403]: Registering new address record
for fe80::xxx on wlan0.IPv6.
Jan 11 17:53:06 thinkpad systemd-networkd[419]: wlan0   : DHCPv4
address 192.168.1.19/16 via 192.168.1.1
Jan 11 17:53:06 thinkpad systemd-networkd[419]: wlan0   : link
configured
Jan 11 17:53:06 thinkpad avahi-daemon[403]: Joining mDNS multicast group on
interface wlan0.IPv4 with address 192.168.1.19.
Jan 11 17:53:06 thinkpad avahi-daemon[403]: New relevant interface
wlan0.IPv4 for mDNS.
Jan 11 17:53:06 thinkpad avahi-daemon[403]: Registering new address record
for 192.168.1.19 on wlan0.IPv4.
Jan 11 17:53:09 thinkpad systemd-resolved[428]: Switching to DNS server
192.168.1.1 for interface wlan0.

You can see wpa_supplicant is started at :01 (I'm using a udev rule so that
it's started when wlan0 appears), and is done at :03. That's slow but normal

What's not is the time it takes to systemd-networkd : 1 second for IPv6 is
acceptable (I'm using SLAAC with radvd on the other end), but for ipv4 it's
more like 3 seconds, plus another 3 to use the proper DNS server (!!)

>From https://plus.google.com/+TomGundersen/posts/eztZWbwmxM8, I understand
it should be done much faster.

What am I doing wrong here?

After manually checking the .c files, commits mentionned on google plus,
#66a67effcc5beaf8a61e1c1147c3114b02a96439 and
#d23c45bfccb3ed6e2628e6d12b4ea12b8c920ab9 seem to have been applied to the
systemd-stable v217 I'm using.

Nothing in the code suggestssection 4.4.1 has become an opt-in, which was
mentioned in the comments.

The .network I'm using is very simple.

$ cat /etc/systemd/network/wireless.network
[Match]
Name=w*
Virtualization=no

[Network]
DHCP=both

[DHCP]
UseHostname=false

So basically, I don't know why it's so slow, except that it comes from DHCP
IPv4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] networkd-218 seems to ignore .link files

[Jan Engelhardt]

In systemd-218, I have configured the following testcase:

/etc/systemd/network# ls -al
total 20
drwxr-xr-x 2 root root 4096 Jan 11 18:14 .
drwxr-xr-x 5 root root 4096 Jan 11 16:23 ..
-rw-r--r-- 1 root root   96 Jan 11 18:14 99a-ether.link
-rw-r--r-- 1 root root  241 Jan 11 18:12 brd0.network
-rw-r--r-- 1 root root   56 Jan 11 18:12 brg0.netdev

# cat 99a-ether.link 
[Match]
MACAddress=08:00:27:0a:c5:b2

[Link]
Description=ethernet_link
Alias=ether0
Name=ether0

# systemctl status -l systemd-networkd
● systemd-networkd.service - Network Service
   Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; enabled; 
vendor preset: enabled)
   Active: active (running) since Sun 2015-01-11 18:14:59 EST; 39s ago
 Docs: man:systemd-networkd.service(8)
 Main PID: 417 (systemd-network)
   Status: "Processing requests..."
   CGroup: /system.slice/systemd-networkd.service
   └─417 /usr/lib/systemd/systemd-networkd

Jan 11 18:14:59 jng-sfac systemd-networkd[417]: brg0: netdev ready
Jan 11 18:14:59 jng-sfac systemd[1]: Started Network Service.


Why would it be ignoring the link definition file for ether0?
If I invoke `rmmod e1000; modprobe e1000`, systemctl status has
one extra line to say:

Jan 11 18:17:52 jng-sfac systemd-networkd[417]: eth0: renamed to 
enp0s3


The L2 address is certainly correct:

2: enp0s3:  mtu 1500 qdisc noop state DOWN group 
default qlen 1000
link/ether 08:00:27:0a:c5:b2 brd ff:ff:ff:ff:ff:ff
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd networking : problems with bridges

[Charles Devereaux]

(oops, accidentally replied off-list. Reposting)

Hello

On Sat, Jan 3, 2015 at 6:58 AM, Andrei Borzenkov 
wrote:

> So if I understand it correctly you want
>
> - configure one interface
> - start some program that establishes what you call "uplink". I presume
>   it results in one more interface appearing?
> - configure new "uplink" interface
>
> Am I right? Could you explain in some more details your setup?


You are right. The interface wlan0 is configured, and provides internet
connectivity to a machine having a br0 bridge.

br0 is bridging ap0 (a local access point) and vpn0 (uplink) so that
clients connected on this access point access the vpn transparently.

br0 should be configured automatically, along with the others - it should
just not block wait-online from saying the system is online

I saw an interesting discussion of the problem on
http://www.spinics.net/lists/netdev/msg172204.html

I agree with the OP conclusion
http://www.spinics.net/lists/netdev/msg174826.html
"The situation of a bridge is quite different from a physical ethernet
interface. The physical interface is usually connected to a switch and is
thus immediately up, even if no systems other than the switch are online.
In the case of a bridge on a virtualization host used to connect virtual
machines, the bridge only goes up after the first VM was started. In the
IPv6 SLAAC case, the host tries start its radvd on the bridge well before
the first VM comes up, the radvd barfs since the interface is not up, does
not come up, and the VMs are without network. In this case, it is needed to
force the bridge into an UP state earlier so that radvd can start."

My situation is indeed similar to setting up a bridge for virtual machines
only. Like lo, such bridges should be ignored by
systemd-networkd-wait-online under some conditions.

What about another option in networkd-wait-online-link.c to pass an
"ignore" parameter, along with a list of interfaces names, so that
link_relevant does: something like:

if (l->flags & IFF_LOOPBACK)
return false;

if (STR_IN_SET(l->ifname, arg_ignore)) {
return false;

At the moment, my dirty workaround is to have br0 hardcoded  in
manager_all_configured from src/network/networkd-wait-online-manager.c:

if (!link_relevant(l) || STR_IN_SET(l->ifname, "br0")) {


> Yes, systemd-networkd-online will wait for all known links to become
> ready.
>

It should have an option to ignore some, as not all links are relevant. It
would be the opposite of -i, which specifies which are important (ex: here
it can be either wlan0 or eth0 depending on the situation, while br0 is
always to be ignored)

$ ip address show
(...)
8: br0:  mtu 1500 qdisc noqueue state
DOWN group default

 I have to find a way to make br0 appear "ready".


> This sounds like broken approach. If I follow your configuration
> correctly, br0 is *the* interface that provides your network
> connectivity so wait-online should wait until it is up and running.
>

Not exactly - wlan0 or eth0 provide network connectivity to the machine.
br0 (ap0 +vpn0) are for other computers


> What is missing here is the ability to express dependency on individual
> interfaces. Alternatively support for callouts would help (start
> external helper to configure uplink as soon as physical interface is
> ready).


Indeed

I think it was discussed and for now it is intentional - you need to
> restart networkd to pick configuration changes but networkd will not
> wipe clean existing configuration.
>

Too bad. That would also be an interesting option. At the moment there is
no way to automatically clean what networkd has done.

It is up to client to renew address. May be networkd could optionally
> set very short lease time to force renewal.
>

That would be a great addition. It would fix the problem.

Alternatively, some control allowing to stop the DHCP server on this
interface would help.

In case the suggested patch to systemd-networkd-wait-online isn't accepted,
I investigated an alternative : adding a dummy0 to br0 as suggested by the
link above.

It is indeed better : br0 then has a carrier.

However in networkctl it is still considered unconfigured:

$ networkctl:
IDX LINK TYPE   OPERATIONAL SETUP
(...)
  4 br0  ether  routableconfiguring

I tested that futher by adding a br1 with a similar setup, only without any
DHCP

[Match]
Name=br1

[Network]
Address=192.168.200.224/28

$ networkctl:
IDX LINK TYPE   OPERATIONAL SETUP
(...)
  5 br1  ether  no-carrier  configured

This seems very similar to the bug reported before on
https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg22414.html

Basically, the DHCP commands prevent considering the bridge online. This
would be logical if there was only a DHCP section, but if someone also
configured a fixed IP, it should inhibit this wrong behaviour.

I traced the problem to li

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Chris Murphy]

On Sun, Jan 11, 2015 at 2:14 PM, Nikolai Zhubr  wrote:
> Hi,
> 11.01.2015 23:03, Reindl Harald:
>>
>>
>> Am 11.01.2015 um 12:48 schrieb Nikolai Zhubr:
>>>
>>> I suppose this traditional (historical) technique of maintaining
>>> mount-count, running fsck at boot time before remount r/w, etc, should
>>> not be so much attributed specifically to ext filesystem. Most probably
>>> it existed long before even ext2 appeared. However, 15 years ago I was
>>> already wondering about the motivation of running full fsck depending of
>>> mount-count. What's the point really?
>>
>>
>> because you get aware of problems
>
>
> I fully agree thay getting aware is good, but...
>
>> real story shortly before christmas: reboot of our fileserver running on
>> the same virtualization cluster and SAN storage as other servers, mount
>> count reached -> emergency shell, manual fsck and confirm all things to
>> fix
>>
>> i really do not want to know what would have happened a year later with
>> the filesystem, after that i rebooted all other servers with a forced
>> fsck and not a single one while sharing the same hardware had an error
>
>
> ... I'm not quite sure e2fsck is an appropriate and reliable tool for
> storage media diagnostics and fault monitoring. How much time would you like
> to wait before you get aware your data is lost?

- man tune2fs uses very strong language to set either
interval-between-checks or max-mount-counts. However, mke2fs 1.42.11
(09-Jul-2014) sets neither by default. I'm not sure when this changed,
it used to set check interval to 180, but a new file system has it set
to 0, and max mount count to -1. So it's highly recommended but not
the default anymore. *shrug* Not sure what to make of that.

- ext34, XFS, and Btrfs all do a journal replay at mount time if the
fs was unmounted uncleanly, and normally this will fix things. If
there are errors, mount fails. e2fsck does same check and journal
replay if necessary that mounting does. But if that fails, e2fsck
falls back to preening the filesystem automatically.

XFS and Btrfs don't have such a fall back condition to do an automatic
preen. For one their fsck. does nothing successfully, those files
don't point to the real repair utils. Their repair utils are only
meant to be run when normal mount is tried first and then fails;
xfs_repair will even complain if the fs hasn't been mounted first and
tell the user to try mounting it to replay the journal since
xfs_repair won't do that. For Btrfs, mount failure means trying
another mount with -o recovery, not running btrfs check, which is
almost a last resort option.

I think it would be more helpful to remove the always fsck root job,
that isn't actually doing anything 99.999% of the time. Instead, in
case of mount failure, dracut shell should end with a cheat sheet for
what the user ought to do to repair the file system. It knows what
root device it is and its file system at this point so it could spit
out the path to the repair utility, all of which now have different
names by the way: e2fsck, xfs_repair, and for Btrfs mount -o recovery
tried first. Right now the user is dropped into a desert, as rare as
it is, and we ought to do better than this until we've got magical
always self-healing file systems.

-- 
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Nikolai Zhubr]

Hi,
11.01.2015 23:03, Reindl Harald:


Am 11.01.2015 um 12:48 schrieb Nikolai Zhubr:

I suppose this traditional (historical) technique of maintaining
mount-count, running fsck at boot time before remount r/w, etc, should
not be so much attributed specifically to ext filesystem. Most probably
it existed long before even ext2 appeared. However, 15 years ago I was
already wondering about the motivation of running full fsck depending of
mount-count. What's the point really?


because you get aware of problems


I fully agree thay getting aware is good, but...


real story shortly before christmas: reboot of our fileserver running on
the same virtualization cluster and SAN storage as other servers, mount
count reached -> emergency shell, manual fsck and confirm all things to fix

i really do not want to know what would have happened a year later with
the filesystem, after that i rebooted all other servers with a forced
fsck and not a single one while sharing the same hardware had an error


... I'm not quite sure e2fsck is an appropriate and reliable tool for 
storage media diagnostics and fault monitoring. How much time would you 
like to wait before you get aware your data is lost?
If you value your data, you certainly put it on some sort of redundant 
storage. Now, even most regular linux mdraid offers dedicated means for 
event monitoring with an option to send warning e-amils. Moreover, 
standard linux distributions include a cron job to do a (online) raid 
check weekly, which basically compares full contents of all array 
members, so that even if some new faulty block is currently unused by 
filesystem, it has no chance to stay unnoticed for too long. Finally, 
even the cheapest consumer-level harddisks have some usefull diagnostics 
available, like the number of relocated sectors, average error rates, 
etc. There are daemons to monitor these in any standard linux 
distribution. If values start to change suspiciously -- better replace 
than wait. I'm not even talking about any special industrial environment 
-- I'm not really aware, but I'd expect that appropriate diagnostics and 
monitoring tools should be even more developed there. But that is about 
present days, 2015. And making sure media is OK by running fsck on boot 
is something more from 1970th I'm afraid... Not that I'm suggesting to 
dismiss it, but its value is very limited.



Thank you,
Nikolai





___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [TOOL] Check-undocumented arguments and bash autocompletions

[Carlos Morata Castillo]

Hi,

I've updated the tool today to work with verbs and some cache issues.

>./check-undocumented.sh -p hostnamectl
Not standar hostnamectl.Update please.
Updates needed in ../shell-completion/bash/hostnamectl
...Option not found: "--machine"
...Verb not found: "set-location"


--
#!/bin/bash 
#  This file is part of systemd.
#
#  Copyright 2015 Carlos Morata Castillo 
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
#  systemd is distributed in the hope that it will be useful, but
#  WITHOUT ANY WARRANTY; without even the implied warranty of
#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
#  Lesser General Public License for more details.
#
#  You should have received a copy of the GNU Lesser General Public License
#  along with systemd; If not, see .

#
# Parse command line commands options and search for undocumented
# options/commands in his manpage and bash autocompletion

#Version 0.1 Parse manpages and bash autocompletion options
#Version 0.2 Parse manpages and bash autocompletion verbs/commands

__version=0.2
MANPAGES=../man
BASH_AUTO=../shell-completion/bash

function get_systemd_commands(){
local regex
regex='(root)?bin_PROGRAMS[[:space:]]?(\+?)=(.*)'

grep -E $regex ../Makefile.am -A 20 | while read a; do 
[[ $a =~ $regex ]] && echo ${BASH_REMATCH[3]}
done
}

function get_options(){
local com args arg value
com=$1
[[ ! $com ]] && return
hash $com 2>/dev/null || return 0

args=($($com -h))
for arg in $(seq 0 $((${#args[@]}-1))); 
do
value=${args[arg]}
if [[ $value == -* ]]; then
echo $value
fi
done
}

function get_verbs(){
local com regex_commands regex_verbs line arr found
com="$1 -h"
regex_commands='^(.*)Commands:$'
regex_verbs='^([[:space:]]){1,2}([-[:alnum:]])(.*)'; 

while IFS= read -r line
do
[[ "$line" =~ $regex_commands ]] && found=1 && continue
if [[ $found ]]; 
then
if [[ "$line" =~ $regex_verbs ]]; 
then
arr=(${line//[[:space:]]/ })
echo ${arr[0]}
fi
fi
done < <($com)
}

function filter(){
local value ret
value=$1
ret="true"

#Shall it leave out -M and -H or not?
[[ "$value" = "-h" || "$value" = "--help" 
|| "$value" = "-M" || "$value" = "-H" 
|| "$value" = "--version" ]] &&
ret="false"
echo "$ret"
}


function do_manpage_options(){
local value r clean regex1 regex2 lines com args
com=$1
lines=$2

#GET OPTIONS
args=($(get_options $com))
[[ -z $args ]] && echo Command not found or unknown options in: $com! && return

for num in $(seq 0 $((${#args[@]}-1))); 
do 
value=${args[num]}
r=$(filter $value)
if [[ "$r" == "true" ]]; then
[[ $value =~ (-+)([-[:alnum:]]*)(.*) ]] && clean=${BASH_REMATCH[2]}
regex1=''
regex2='(-*)'$clean'(.*)<.*'
if [[ ! $lines =~ $regex1 ]] && [[ ! $lines =~ $regex2 ]];
then
[[ $bool -eq 0 ]] && echo Updates needed in $MANPAGES/$com.xml && 
bool=1
echo ...Need to document the option \"$value\" 
fi
fi
done
}

function do_manpage_verbs(){
local value r clean regex1 regex2 lines com args
com=$1
lines=$2

#What happened with journalctl commands?
[[ $com = "journalctl" ]] && return 

#COMMANDS/VERBS
args=($(get_verbs $com))
[[ -z $args ]] && return
for num in $(seq 0 $((${#args[@]}-1))); 
do 
value=${args[num]}
regex1=''$value'(.*)'
regex2='systemd-analyze '$value'(.*)'
if [[ ! $lines =~ $regex1 ]] && [[ ! $lines =~ $regex2 ]];
then
[[ $bool -eq 0 ]] && echo Updates needed in $MANPAGES/$com.xml && bool=1
echo ...Need to document the command \"$value\" 
fi
done

}

function do_manpage(){
local value r clean regex1 regex2 lines com args
com=$1
bool=0
[[ ! -f $MANPAGES/$com.xml ]] && echo No manpage for $com! && return

mapfile -t lines <<< $(cat $MANPAGES/$com.xml)

do_manpage_options $com "$lines" 
do_manpage_verbs $com "$lines" 

}


function do_manpages(){
local com
local -a commands
cat 

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Reindl Harald]

Am 11.01.2015 um 12:48 schrieb Nikolai Zhubr:

I suppose this traditional (historical) technique of maintaining
mount-count, running fsck at boot time before remount r/w, etc, should
not be so much attributed specifically to ext filesystem. Most probably
it existed long before even ext2 appeared. However, 15 years ago I was
already wondering about the motivation of running full fsck depending of
mount-count. What's the point really?


because you get aware of problems

real story shortly before christmas: reboot of our fileserver running on 
the same virtualization cluster and SAN storage as other servers, mount 
count reached -> emergency shell, manual fsck and confirm all things to fix


i really do not want to know what would have happened a year later with 
the filesystem, after that i rebooted all other servers with a forced 
fsck and not a single one while sharing the same hardware had an error




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH udev v5] udev: Add builtin/rule to export evdev information as udev properties

[Carlos Garnacho]

This rule is only run on tablet/touchscreen devices, and extracts their size
in millimeters, as it can be found out through their struct input_absinfo.

The first usecase is exporting device size from tablets/touchscreens. This
may be useful to separate policy and application at the time of mapping
these devices to the available outputs in windowing environments that don't
offer that information as readily (eg. Wayland). This way the compositor can
stay deterministic, and the mix-and-match heuristics are performed outside.

Conceivably, size/resolution information can be changed through EVIOCSABS
anywhere else, but we're only interested in values prior to any calibration,
this rule is thus only run on "add", and no tracking of changes is performed.
This should only remain a problem if calibration were automatically applied
by an earlier udev rule (read: don't).

  v2: Folded rationale into commit log, made a builtin, set properties
  on device nodes themselves
  v3: Use inline function instead of macro for mm. size calculation,
  use DECIMAL_STR_MAX, other code style issues
  v4: Made rule more selective
  v5: Minor style issues, renamed to a more generic builtin, refined
  rule further.
---
 Makefile.am  |  2 ++
 rules/60-evdev_id.rules  | 10 ++
 src/udev/udev-builtin-evdev_id.c | 78 
 src/udev/udev-builtin.c  |  1 +
 src/udev/udev.h  |  2 ++
 5 files changed, 93 insertions(+)
 create mode 100644 rules/60-evdev_id.rules
 create mode 100644 src/udev/udev-builtin-evdev_id.c

diff --git a/Makefile.am b/Makefile.am
index 8a60f3f..f601601 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3460,6 +3460,7 @@ dist_udevrules_DATA += \
rules/42-usb-hid-pm.rules \
rules/50-udev-default.rules \
rules/60-drm.rules \
+   rules/60-evdev_id.rules \
rules/60-keyboard.rules \
rules/70-mouse.rules \
rules/60-persistent-storage-tape.rules \
@@ -3543,6 +3544,7 @@ libudev_core_la_SOURCES = \
src/udev/udev-builtin.c \
src/udev/udev-builtin-btrfs.c \
src/udev/udev-builtin-hwdb.c \
+   src/udev/udev-builtin-evdev_id.c \
src/udev/udev-builtin-input_id.c \
src/udev/udev-builtin-keyboard.c \
src/udev/udev-builtin-net_id.c \
diff --git a/rules/60-evdev_id.rules b/rules/60-evdev_id.rules
new file mode 100644
index 000..4716a10
--- /dev/null
+++ b/rules/60-evdev_id.rules
@@ -0,0 +1,10 @@
+# do not edit this file, it will be overwritten on update
+
+ACTION!="add", GOTO="evdev_id_end"
+SUBSYSTEM!="input", GOTO="evdev_id_end"
+KERNEL!="event*", GOTO="evdev_id_end"
+
+ENV{ID_INPUT_TOUCHSCREEN}=="1", IMPORT{builtin}="evdev_id"
+ENV{ID_INPUT_TABLET}=="1", IMPORT{builtin}="evdev_id"
+
+LABEL="evdev_id_end"
diff --git a/src/udev/udev-builtin-evdev_id.c b/src/udev/udev-builtin-evdev_id.c
new file mode 100644
index 000..1b58bdd
--- /dev/null
+++ b/src/udev/udev-builtin-evdev_id.c
@@ -0,0 +1,78 @@
+/*
+ * evdev_id - extracts miscellaneous information from evdev devices
+ *
+ * Copyright (C) 2014 Red Hat
+ * Author:
+ *   Carlos Garnacho  
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with keymap; if not, write to the Free Software Foundation,
+ * Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
+ */
+
+#include 
+#include "udev.h"
+#include "util.h"
+
+static inline int abs_size_mm(const struct input_absinfo *absinfo) {
+/* Resolution is defined to be in units/mm for ABS_X/Y */
+return (absinfo->maximum - absinfo->minimum) / absinfo->resolution;
+}
+
+static void extract_info(struct udev_device *dev, const char *devpath, bool 
test) {
+char width[DECIMAL_STR_MAX(int)], height[DECIMAL_STR_MAX(int)];
+struct input_absinfo xabsinfo = {}, yabsinfo = {};
+_cleanup_close_ int fd = -1;
+
+fd = open(devpath, O_RDONLY|O_CLOEXEC);
+if (fd < 0)
+return;
+
+if (ioctl(fd, EVIOCGABS(ABS_X), &xabsinfo) < 0 ||
+ioctl(fd, EVIOCGABS(ABS_Y), &yabsinfo) < 0)
+return;
+
+if (xabsinfo.resolution <= 0 || yabsinfo.resolution <= 0)
+return;
+
+snprintf(width, sizeof(width), "%d", abs_size_mm(&xabsinfo));
+snprintf(height, sizeof(height), "%d", abs_size_mm(&yabsinfo));
+
+udev_builtin_add_property(dev, test, "ID_INPUT_WIDTH_MM", width);
+udev_buil

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Chris Murphy]

On Sun, Jan 11, 2015 at 4:57 AM, Andrei Borzenkov  wrote:
> В Sun, 11 Jan 2015 04:15:41 -0700

> Does it using systemd *inside* of initrd? From upstream dracut:
>
> if ! dracut_module_included "systemd"; then
> inst_hook cmdline 95 "$moddir/parse-block.sh"
> inst_hook pre-udev 30 "$moddir/block-genrules.sh"
> inst_hook mount 99 "$moddir/mount-root.sh"
> ^ here it does it
> fi
>
> Do you have Fedora specific patches to do it differently?

So the reason it's mounting all file systems ro by default appears to
be strictly because of the ro kernel parameter in the grub.cfg as
created by grub-mkconfig. This is the same on Fedora as it is
upstream, it's hardcoded into /etc/grub.d/10_linux:

Fedora 21:

10_linux:147: ${linuxefi} ${rel_dirname}/${basename}
root=${linux_root_device_thisversion} ro ${args}
10_linux:151: linux${sixteenbit} ${rel_dirname}/${basename}
root=${linux_root_device_thisversion} ro ${args}

Upstream:
http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub.d/10_linux.in

10_linux:132: linux ${rel_dirname}/${basename}
root=${linux_root_device_thisversion} ro ${args}

So systemd is just doing what it's being told. If I manually change
the ro to rw then the first mount is rw and there is no remount unless
there are fstab non-default options.

If the first mount should be rw then I think this needs to be changed
upstream. And at least one other distro does change this, I think it's
opensuse, but it could be Ubuntu (or both).

-- 
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH udev v4] udev: Add builtin/rule to export touchscreen/tablet size as udev properties

[Carlos Garnacho]

Hey David,

On dom, 2015-01-11 at 14:37 +0100, David Herrmann wrote:



> Otherwise, looks all good. I was about to push it, but could you
> rename it to something more generic? "udev_builtin_evdev_id" for
> example. I don't want a different builtin for each evdev property we
> add, so lets be generic enough right from the beginning.

Yeah, I agree that makes sense, the accelerometer program doesn't differ
much from this TBH. I'm sending an updating patch with the suggested
changes.

Cheers,
  Carlos


___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] Break JobNew signal dbus signature by adding JobType.

[Dimitri John Ledkov]

At the moment JobNew and JobRemoved signals are not useful for
tracking streams of events. JobType is missing from both of them, and
thus one can only track that "something" is happening and to which
units (And whether "something" is about to happen, finished, failed,
got aborted etc.). To get the JobType, one needs to query property
from the job, however this works only for "slow" jobs, typically the
job is gone on the systemd side already and thus subscriber has no
chance in quering the job type.

It looks like previously JobNew signal api was changed in 2012. Today
however there are slightly more clients of JobNew/JobRemoved
signals. Performing the codesearch.debian.net queries, JobRemoved has
a few users (e.g. go-systemd -> docker.io), but JobNew only has
systemd-ui as it's consumer. I am proposing to break JobNew signature,
patch systemd-ui to handle both cases. And then users of JobRemoved
signal would be able to get job_type, by subscribing to JobNew signal
and caching/storing the job_type.
---
 src/core/dbus-job.c | 2 +-
 src/core/dbus-manager.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/core/dbus-job.c b/src/core/dbus-job.c
index 8b5ea25..6d6a73b 100644
--- a/src/core/dbus-job.c
+++ b/src/core/dbus-job.c
@@ -121,7 +121,7 @@ static int send_new_signal(sd_bus *bus, void *userdata) {
 if (r < 0)
 return r;
 
-r = sd_bus_message_append(m, "uos", j->id, p, j->unit->id);
+r = sd_bus_message_append(m, "uoss", j->id, p, j->unit->id, j->type);
 if (r < 0)
 return r;
 
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 6181ba8..2ef301f 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -2020,7 +2020,7 @@ const sd_bus_vtable bus_manager_vtable[] = {
 
 SD_BUS_SIGNAL("UnitNew", "so", 0),
 SD_BUS_SIGNAL("UnitRemoved", "so", 0),
-SD_BUS_SIGNAL("JobNew", "uos", 0),
+SD_BUS_SIGNAL("JobNew", "uoss", 0),
 SD_BUS_SIGNAL("JobRemoved", "uoss", 0),
 SD_BUS_SIGNAL("StartupFinished", "tt", 0),
 SD_BUS_SIGNAL("UnitFilesChanged", NULL, 0),
-- 
2.1.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH 1/2] machinectl: use GNU basename, not the XPG version

[Cristian Rodríguez]

---
 src/machine/machinectl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/machine/machinectl.c b/src/machine/machinectl.c
index 749170e..980fba1 100644
--- a/src/machine/machinectl.c
+++ b/src/machine/machinectl.c
@@ -32,7 +32,7 @@
 #include 
 #include 
 #include 
-
+#undef basename
 #include "sd-bus.h"
 #include "log.h"
 #include "util.h"
-- 
2.2.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Dave Reisner]

On Sun, Jan 11, 2015 at 10:09:08AM +0300, Andrei Borzenkov wrote:
> В Sat, 10 Jan 2015 16:51:24 +0300
> Nikolai Zhubr  пишет:
> 
> > Hi,
> > 09.01.2015 23:48, Chris Murphy:
> > [...]
> > >> I might be missing something, but what's wrong with the existing 
> > >> "root=...
> > >> rootfstype=... rootflags=... rw" options? Why is the remount even 
> > >> necessary?
> > >
> > > Seems to be distro specific. I see rw for opensuse or Ubuntu, and ro for 
> > > Fedora.
> > >
> > > The ro seems antiquated to me, meant for interactive fsck on an ro
> > > mounted filesystem when booting single user. 'btrfs check' refuses to
> > > run on mounted file systems, even if ro. And xfs_repair requires the
> > > use of -d "repair dangerously" to do so.
> > >
> > > Both XFS and Btrfs have placeholder fsck's, if you man fsck.xfs or
> > > fsck.btrfs you'll see. These filesystems are designed to fix most
> > 
> > Ok. I've invented a quick-and-dirty fix. I'll modify systemd-fsck so 
> > that when run with no argument it does nothing and exit successfully. 
> > This way I'll still have rootfs fsck'ed every boot, but never twice.
> > 
> 
> Uh. Why not simply mount rootfs rw in initrd then?
> 
> > I'll soon need this box for work anyway, reverting to some 12.x does not 
> > seem very attractive, and living with this bug every day won't give me a 
> > good feeling either. (Just a week ago I had one single erroneous fsck 
> > rendering my rootfs essentially to a complete trash)
> > 
> > Hope someone will come up with a better solution though :)
> 
> The more I think about it the more I find it non-issue. As was already
> mentioned, systemd-fsck checks whether rootfs is mounted read-write and
> will skip check in this case. Could someone give a compelling reason why
> initrd would want to mount rootfs read-only after having fsck'ed it?
> 
> Otherwise the only way to prevent second fsck is to pass some flag from
> initrd to real root, like /run/systemd/fsck-root-done. There is no

This flag file used to exist (though differently named). As soon as
dracut started using systemd, the flag file was deemed unnecessary for
everyone. See commit 956eaf2b8d6 for its removal. See /dev/null for the
discussion which took place before removing it.

> feasible way to reuse the same systemd-fsck-root.service without
> introducing hard dependency on initrd implementation. I hoped to get
> away by just symlinking systemd-fsck-root.service to
> systemd-fsck@root-dev.service, but it's not possible. 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Andrei Borzenkov]

В Thu, 08 Jan 2015 21:32:08 +0100
Harald Hoyer  пишет:

> 
> In case of systemd in the initrd, the fstab-generator ensures that fsck is 
> done
> on root and /usr and any other partition marked with x-initrd.mount.
> 

How is it supposed to work? In native systemd mode fstab-generator runs
early before /sysroot is mounted so it cannot fetch information from
real root. Either dracut has to copy and adjust /etc/fstab or do
daemon-reload after real root is mounted. So far I could not find where
it does either.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Nikolai Zhubr]

Hi,
11.01.2015 15:54, Andrei Borzenkov:

It's no more ugly than using privately patched distribution package. I
did not suggest it as long term generic solution.


Yes, absolutely. Therefore I'm reading all the answers to find a 
reasonable workaround and avoid whatever ugly patching.



Otherwise it is functional gap between non-systemd and systemd
enabled dracut. Without systemd dracut will actually mount root
read-only, then fetch mount options from real root /etc/fstab and then
remount real root read-write using correct options. This all got lost
when converting to systemd.


Hmm, can not find any dracut-specific mailing list to ask. Apparently
there is none :(


There is; you keep removing it from Cc.


Oh. Sorry! :(

[...]

Even if you add additional parsing of in-initrd /etc/fstab, it still
means you need to regenerate initrd every time you change /etc/fstab so
you still have the same problem as when explicitly adding rootflags -
keeping both in sync :)


Well, doing "mkinitrd" is not a problem? It has to be rerun in case of 
some other changes too. And Yast anyway has to know when it is necessary 
to run mkinitrd in order to apply changes I'd suppose? (I'm trying to 
check this now; I think I recall Yast used to be quite smart about it)



Thank you,
Nikolai





___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH udev v4] udev: Add builtin/rule to export touchscreen/tablet size as udev properties

[David Herrmann]

Hi

On Mon, Dec 22, 2014 at 5:04 PM, Carlos Garnacho  wrote:
> This rule is only run on tablet/touchscreen devices, and extracts their size
> in millimeters, as it can be found out through their struct input_absinfo.
>
> This may be useful to separate policy and application at the time of mapping
> these devices to the available outputs in windowing environments that don't
> offer that information as readily (eg. Wayland). This way the compositor can
> stay deterministic, and the mix-and-match heuristics are performed outside.
>
> Conceivably, that information can be changed through EVIOCSABS anywhere
> else, but we're only interested in values prior to any calibration, this
> rule is thus only run on "add", and no tracking of changes is performed.
> This should only remain a problem if calibration were automatically applied
> by an earlier udev rule (read: don't).
>
>   v2: Folded rationale into commit log, made a builtin, set properties
>   on device nodes themselves
>   v3: Use inline function instead of macro for mm. size calculation,
>   use DECIMAL_STR_MAX, other code style issues
>   v4: Made rule more selective
> ---
>  Makefile.am|  2 +
>  rules/60-input_abs_size.rules  |  9 
>  src/udev/udev-builtin-input_abs_size.c | 81 
> ++
>  src/udev/udev-builtin.c|  1 +
>  src/udev/udev.h|  2 +
>  5 files changed, 95 insertions(+)
>  create mode 100644 rules/60-input_abs_size.rules
>  create mode 100644 src/udev/udev-builtin-input_abs_size.c
>
> diff --git a/Makefile.am b/Makefile.am
> index ab07d3b..db3e014 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -3412,6 +3412,7 @@ dist_udevrules_DATA += \
> rules/42-usb-hid-pm.rules \
> rules/50-udev-default.rules \
> rules/60-drm.rules \
> +   rules/60-input_abs_size.rules \
> rules/60-keyboard.rules \
> rules/70-mouse.rules \
> rules/60-persistent-storage-tape.rules \
> @@ -3512,6 +3513,7 @@ libudev_core_la_SOURCES = \
> src/udev/udev-builtin.c \
> src/udev/udev-builtin-btrfs.c \
> src/udev/udev-builtin-hwdb.c \
> +   src/udev/udev-builtin-input_abs_size.c \
> src/udev/udev-builtin-input_id.c \
> src/udev/udev-builtin-keyboard.c \
> src/udev/udev-builtin-net_id.c \
> diff --git a/rules/60-input_abs_size.rules b/rules/60-input_abs_size.rules
> new file mode 100644
> index 000..90c0eef
> --- /dev/null
> +++ b/rules/60-input_abs_size.rules
> @@ -0,0 +1,9 @@
> +# do not edit this file, it will be overwritten on update
> +
> +ACTION!="add", GOTO="input_abs_size_end"
> +KERNEL!="event*", GOTO="input_abs_size_end"

Please also match on the "input" subsystem here. There might be other
devices called "event".

> +
> +ENV{ID_INPUT_TOUCHSCREEN}=="1", IMPORT{builtin}="input_abs_size"
> +ENV{ID_INPUT_TABLET}=="1", IMPORT{builtin}="input_abs_size"
> +
> +LABEL="input_abs_size_end"
> diff --git a/src/udev/udev-builtin-input_abs_size.c 
> b/src/udev/udev-builtin-input_abs_size.c
> new file mode 100644
> index 000..faf707e
> --- /dev/null
> +++ b/src/udev/udev-builtin-input_abs_size.c
> @@ -0,0 +1,81 @@
> +/*
> + * input_abs_size - extracts abs X/Y size in millimeters from input devices
> + *
> + * Copyright (C) 2014 Red Hat
> + * Author:
> + *   Carlos Garnacho  
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with keymap; if not, write to the Free Software Foundation,
> + * Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
> + */
> +
> +#include 
> +#include "udev.h"

Please include "util.h" directly, as you use quite a bunch of helpers from it.

> +
> +static inline int abs_size_mm(const struct input_absinfo *absinfo)
> +{

We put the opening-braces on the same line as the function.

> +/* Resolution is defined to be in units/mm for ABS_X/Y */
> +return (absinfo->maximum - absinfo->minimum) / absinfo->resolution;
> +}
> +
> +static void extract_info(struct udev_device *dev, const char *devpath, bool 
> test)
> +{
> +char width[DECIMAL_STR_MAX(int)], height[DECIMAL_STR_MAX(int)];
> +struct input_absinfo xabsinfo = {}, yabsinfo = {};
> +_cleanup_close_ int fd = -1;
> +
> +fd = open(devpath, O_RDONLY|O_CLOEXEC);
> +

Drop that empty line.

> +if (fd < 0)
> +return;
> +
> +if (ioctl(fd, EVIOCGAB

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Nikolai Zhubr]

11.01.2015 15:22, Nikolai Zhubr:

By adding all needed options to rootflags="..." (modify
GRUB_CMDLINE_LINUX_DEFAULT and possibly GRUB_CMDLINE_LINUX_RECOVERY
in /etc/default/grub; you can use yast for it).


Ah, indeed.
Although it feels a bit ugly because the consistency between fstab and
GRUB_CMDLINE_* will have to be verified manually forever then.


I was wrong. Proper rootflags are already there automagically. They are 
not inserted in the first mount command though...


(BTW, are we abusing systemd mailing list for slightly offtopic 
discussion?)



Thank you,
Nikolai
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Andrei Borzenkov]

В Sun, 11 Jan 2015 15:22:54 +0300
Nikolai Zhubr  пишет:

> Hi,
> 11.01.2015 14:11, Andrei Borzenkov:
> [...]
> > By adding all needed options to rootflags="..." (modify
> > GRUB_CMDLINE_LINUX_DEFAULT and possibly GRUB_CMDLINE_LINUX_RECOVERY
> > in /etc/default/grub; you can use yast for it).
> 
> Ah, indeed.
> Although it feels a bit ugly because the consistency between fstab and 
> GRUB_CMDLINE_* will have to be verified manually forever then.
> 

It's no more ugly than using privately patched distribution package. I
did not suggest it as long term generic solution.

> > Otherwise it is functional gap between non-systemd and systemd
> > enabled dracut. Without systemd dracut will actually mount root
> > read-only, then fetch mount options from real root /etc/fstab and then
> > remount real root read-write using correct options. This all got lost
> > when converting to systemd.
> 
> Hmm, can not find any dracut-specific mailing list to ask. Apparently 
> there is none :(

There is; you keep removing it from Cc.

> Anyway, generally, why not pack a real fstab from the host into initrd 
> then? Or at least one line ("/") from it? Something prohibits this?
> 

Dracut does pack /etc/fstab in initrd if run in host-specific mode,
but right now systemd-fstab-generator will never parse /etc/fstab
for /sysroot mounts. Pre-systemd dracut would actually merge options
from rootfs /etc/fstab and rootflags.

Even if you add additional parsing of in-initrd /etc/fstab, it still
means you need to regenerate initrd every time you change /etc/fstab so
you still have the same problem as when explicitly adding rootflags -
keeping both in sync :) 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Nikolai Zhubr]

Hi,
11.01.2015 15:04, Chris Murphy:

That's all I meant by bouncing back to ext devs. I don't mean there's
anything wrong with ext4. It's pretty clear the XFS and Btrfs devs
expect that if a normal rw mount fails, that boot fails and we're
dropped to a dracut shell with an unmounted root. And hopefully our fs
repair tool is in the initramfs so we can run it on the unmounted
root. Is that good enough for ext4 also? Or do they still really want
e2fsck run every boot?


ext4 is perfectly able to run for years (with moderate everyday load) 
without a single full fsck, I can assure. It is basically a really 
zero-maintenance filesystem (if treated properly).



Thank you,
Nikolai



It just seems there's a more elegant way to do this. Wasn't there some
big blow up recently, where some people were mad they couldn't cancel
these lengthy e2fsck's on ext4 volumes? Seems like a bad idea to
cancel an in-progress fsck anyway, but it had been scheduled 180 days
prior as the mkfs default. There was already tacit permission to do
this full fsck. However, a vastly better UX would be to communicate
the need to do this differently, like a notification that says "a full
fsck is recommended on the next boot, set this now?"





___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Nikolai Zhubr]

Hi,
11.01.2015 14:11, Andrei Borzenkov:
[...]

By adding all needed options to rootflags="..." (modify
GRUB_CMDLINE_LINUX_DEFAULT and possibly GRUB_CMDLINE_LINUX_RECOVERY
in /etc/default/grub; you can use yast for it).


Ah, indeed.
Although it feels a bit ugly because the consistency between fstab and 
GRUB_CMDLINE_* will have to be verified manually forever then.



Otherwise it is functional gap between non-systemd and systemd
enabled dracut. Without systemd dracut will actually mount root
read-only, then fetch mount options from real root /etc/fstab and then
remount real root read-write using correct options. This all got lost
when converting to systemd.


Hmm, can not find any dracut-specific mailing list to ask. Apparently 
there is none :(
Anyway, generally, why not pack a real fstab from the host into initrd 
then? Or at least one line ("/") from it? Something prohibits this?



Thank you,
Nikolai






___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Chris Murphy]

On Sun, Jan 11, 2015 at 4:57 AM, Andrei Borzenkov  wrote:

> Does it using systemd *inside* of initrd?

I don't know how to find the answer to this. There is an initramfs and
systemd-journald is the first thing (other than kernel) to be found in
dmesg after the initramfs is unpacked, well before root is mounted.



 From upstream dracut:
>
> if ! dracut_module_included "systemd"; then
> inst_hook cmdline 95 "$moddir/parse-block.sh"
> inst_hook pre-udev 30 "$moddir/block-genrules.sh"
> inst_hook mount 99 "$moddir/mount-root.sh"
> ^ here it does it
> fi
>
> Do you have Fedora specific patches to do it differently?

No idea.


-- 
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Chris Murphy]

On Sun, Jan 11, 2015 at 4:48 AM, Nikolai Zhubr  wrote:
> Hi,
> 11.01.2015 1:31, Chris Murphy:
>>
>> Yeah it's a bit messy and I really think to some degree this should be
>> bounced back to the ext developers and say "how do you envision this
>> working" because doing the right thing for ext4 really burdens
>> multiple other processes: systemd of course, but also dracut, and then
>> linux-utils is pulled in since that's where generic fsck is, which
>> then calls e2fsck. It's at this point really overly complicated.
>
>
> IMO there is nothing wrong with ext4 itself. It is relaible and simple. It
> does not tend to break spontaneously, or because mount-count reached some
> higher number, or because of extended periods of uptime, or even because of
> abrupt power-off. It only breaks when something _external_ really hurts it,
> like failed hardware, failed raid, mad user, or some invalid fsck.
>
> I suppose this traditional (historical) technique of maintaining
> mount-count, running fsck at boot time before remount r/w, etc, should not
> be so much attributed specifically to ext filesystem. Most probably it
> existed long before even ext2 appeared. However, 15 years ago I was already
> wondering about the motivation of running full fsck depending of
> mount-count. What's the point really?

That's all I meant by bouncing back to ext devs. I don't mean there's
anything wrong with ext4. It's pretty clear the XFS and Btrfs devs
expect that if a normal rw mount fails, that boot fails and we're
dropped to a dracut shell with an unmounted root. And hopefully our fs
repair tool is in the initramfs so we can run it on the unmounted
root. Is that good enough for ext4 also? Or do they still really want
e2fsck run every boot?

It just seems there's a more elegant way to do this. Wasn't there some
big blow up recently, where some people were mad they couldn't cancel
these lengthy e2fsck's on ext4 volumes? Seems like a bad idea to
cancel an in-progress fsck anyway, but it had been scheduled 180 days
prior as the mkfs default. There was already tacit permission to do
this full fsck. However, a vastly better UX would be to communicate
the need to do this differently, like a notification that says "a full
fsck is recommended on the next boot, set this now?"



-- 
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Andrei Borzenkov]

В Sun, 11 Jan 2015 04:15:41 -0700
Chris Murphy  пишет:

> On Sun, Jan 11, 2015 at 4:11 AM, Andrei Borzenkov  wrote:
> > В Sun, 11 Jan 2015 13:43:34 +0300
> > Nikolai Zhubr  пишет:
> >
> >> >
> >> > Uh. Why not simply mount rootfs rw in initrd then?
> >>
> >> I'm not against generally. But it'd mean that this first mount is
> >> actually a real mount, the fs will start up in full. Then I'd suppose it
> >> is definitely a must to supply all necessary mount options (from fstab)
> >> at this stage already. I don't easily see how to do this currently, at
> >> least on my opensuse system.
> >>
> >
> > By adding all needed options to rootflags="..." (modify
> > GRUB_CMDLINE_LINUX_DEFAULT and possibly GRUB_CMDLINE_LINUX_RECOVERY
> > in /etc/default/grub; you can use yast for it).
> >
> > Otherwise it is functional gap between non-systemd and systemd
> > enabled dracut. Without systemd dracut will actually mount root
> > read-only, then fetch mount options from real root /etc/fstab and then
> > remount real root read-write using correct options. This all got lost
> > when converting to systemd.
> 
> 
> Not true on Fedora even still with 21. The kernel parameter ro is
> present, so dracut mounts root read-only, then reads fstab, then does
> a remount. Fedora is a systemd OS of course.
> 
> 

Does it using systemd *inside* of initrd? From upstream dracut:

if ! dracut_module_included "systemd"; then
inst_hook cmdline 95 "$moddir/parse-block.sh"
inst_hook pre-udev 30 "$moddir/block-genrules.sh"
inst_hook mount 99 "$moddir/mount-root.sh"
^ here it does it
fi

Do you have Fedora specific patches to do it differently?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Nikolai Zhubr]

Hi,
11.01.2015 1:31, Chris Murphy:

Yeah it's a bit messy and I really think to some degree this should be
bounced back to the ext developers and say "how do you envision this
working" because doing the right thing for ext4 really burdens
multiple other processes: systemd of course, but also dracut, and then
linux-utils is pulled in since that's where generic fsck is, which
then calls e2fsck. It's at this point really overly complicated.


IMO there is nothing wrong with ext4 itself. It is relaible and simple. 
It does not tend to break spontaneously, or because mount-count reached 
some higher number, or because of extended periods of uptime, or even 
because of abrupt power-off. It only breaks when something _external_ 
really hurts it, like failed hardware, failed raid, mad user, or some 
invalid fsck.


I suppose this traditional (historical) technique of maintaining 
mount-count, running fsck at boot time before remount r/w, etc, should 
not be so much attributed specifically to ext filesystem. Most probably 
it existed long before even ext2 appeared. However, 15 years ago I was 
already wondering about the motivation of running full fsck depending of 
mount-count. What's the point really?


At present it seems even more pointless because of btrfs/xfs/... thing, 
and also because in case of trouble one can use a bootable usb stick 
with a whole lot of tools, or easily disconnect the drive in question 
and plug it into some similar box, or even prepare some write-protected 
media with a self-contained emergency system attached inside the box in 
question for immediate access, etc etc etc.


So generally I'd agree that it would be good to critically reconsider 
the validity of antique techniques for current environment.



Thank you,
Nikolai




Windows and OS X by default at boot time do not do fsck. They defer to
the kernel mount code replaying the journal and only if there's
journal inconsistency does this trigger fsck. So I feel like somehow
there needs to be a deference to not doing fsck unless asked, and
maybe that requires the kdbus stuff to get finished first
(speculation)? That way only when kernel code says, yeah no that's not
gonna work, it can then communicate a need for an offline fsck. And
hypothetically it's possible in such a case to unmount root and do a
prescribed (recommended) offline fsck regardless of what filesystem it
is, and if that exits succesfully, resume normal boot. And just do
away with this mount ro and remount rw, and all the stupid fake fsck's
floating around.

Chris Murphy




___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Chris Murphy]

On Sun, Jan 11, 2015 at 4:11 AM, Andrei Borzenkov  wrote:
> В Sun, 11 Jan 2015 13:43:34 +0300
> Nikolai Zhubr  пишет:
>
>> >
>> > Uh. Why not simply mount rootfs rw in initrd then?
>>
>> I'm not against generally. But it'd mean that this first mount is
>> actually a real mount, the fs will start up in full. Then I'd suppose it
>> is definitely a must to supply all necessary mount options (from fstab)
>> at this stage already. I don't easily see how to do this currently, at
>> least on my opensuse system.
>>
>
> By adding all needed options to rootflags="..." (modify
> GRUB_CMDLINE_LINUX_DEFAULT and possibly GRUB_CMDLINE_LINUX_RECOVERY
> in /etc/default/grub; you can use yast for it).
>
> Otherwise it is functional gap between non-systemd and systemd
> enabled dracut. Without systemd dracut will actually mount root
> read-only, then fetch mount options from real root /etc/fstab and then
> remount real root read-write using correct options. This all got lost
> when converting to systemd.


Not true on Fedora even still with 21. The kernel parameter ro is
present, so dracut mounts root read-only, then reads fstab, then does
a remount. Fedora is a systemd OS of course.


-- 
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Chris Murphy]

On Sun, Jan 11, 2015 at 3:43 AM, Nikolai Zhubr  wrote:
> Hi,
> 11.01.2015 10:09, Andrei Borzenkov:
>>>
>>> Ok. I've invented a quick-and-dirty fix. I'll modify systemd-fsck so
>>> that when run with no argument it does nothing and exit successfully.
>>> This way I'll still have rootfs fsck'ed every boot, but never twice.
>>>
>>
>> Uh. Why not simply mount rootfs rw in initrd then?
>
>
> I'm not against generally. But it'd mean that this first mount is actually a
> real mount, the fs will start up in full. Then I'd suppose it is definitely
> a must to supply all necessary mount options (from fstab) at this stage
> already. I don't easily see how to do this currently, at least on my
> opensuse system.

That's a really good point. The remount is always necessary if fstab
specifies / with non-default options, and I think some file systems
will not enable certain options on remount if already mounted rw,
hence the initial ro mount in order to read the fstab in the first
place.

Archaic.

Anyway, the work around is to use kernel parameter rootflags= to
specify the mount options and then comment out the / entry in fstab.


-- 
Chris Murphy
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Andrei Borzenkov]

В Sun, 11 Jan 2015 13:43:34 +0300
Nikolai Zhubr  пишет:

> >
> > Uh. Why not simply mount rootfs rw in initrd then?
> 
> I'm not against generally. But it'd mean that this first mount is 
> actually a real mount, the fs will start up in full. Then I'd suppose it 
> is definitely a must to supply all necessary mount options (from fstab) 
> at this stage already. I don't easily see how to do this currently, at 
> least on my opensuse system.
> 

By adding all needed options to rootflags="..." (modify
GRUB_CMDLINE_LINUX_DEFAULT and possibly GRUB_CMDLINE_LINUX_RECOVERY
in /etc/default/grub; you can use yast for it).

Otherwise it is functional gap between non-systemd and systemd
enabled dracut. Without systemd dracut will actually mount root
read-only, then fetch mount options from real root /etc/fstab and then
remount real root read-write using correct options. This all got lost
when converting to systemd.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Nikolai Zhubr]

Hi,
11.01.2015 10:09, Andrei Borzenkov:

Ok. I've invented a quick-and-dirty fix. I'll modify systemd-fsck so
that when run with no argument it does nothing and exit successfully.
This way I'll still have rootfs fsck'ed every boot, but never twice.



Uh. Why not simply mount rootfs rw in initrd then?


I'm not against generally. But it'd mean that this first mount is 
actually a real mount, the fs will start up in full. Then I'd suppose it 
is definitely a must to supply all necessary mount options (from fstab) 
at this stage already. I don't easily see how to do this currently, at 
least on my opensuse system.



Hope someone will come up with a better solution though :)


The more I think about it the more I find it non-issue. As was already
mentioned, systemd-fsck checks whether rootfs is mounted read-write and
will skip check in this case. Could someone give a compelling reason why
initrd would want to mount rootfs read-only after having fsck'ed it?


That might indeed be a relict of some ancient established techniques of 
system maintenance and repair, which no longer reasonably apply now, but 
I'm no expert in this actually.


Otherwise the only way to prevent second fsck is to pass some flag from
initrd to real root, like /run/systemd/fsck-root-done.


I like this idea. Quite generic and simple, and allowing a quick fix for 
existing systems while avoiding risky intrusive changes.



Thank you,
Nikolai
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel