Re: [systemd-devel] mount ubifs using /dev/ubi0_X path

[Mirza Krak]

2017-02-02 14:27 GMT+01:00 Zbigniew Jędrzejewski-Szmek :
> On Thu, Feb 02, 2017 at 02:11:28PM +0100, Lennart Poettering wrote:

< snip >

>> > Would you consider adding that line in upstream? IMO it fits along
>> > side SUBSYSTEM=="block", TAG+="systemd" that is all ready in the file.
>> > But I might me "embedded" damaged for requesting this...
>>
>> If ubifs is merged in the upstream kernel, then we can certainly add
>> the relevant bits to systemd too. Please post a PR for that on github
>> and we'll merge it.
>
> There's some confusion here. Ubifs vs. UBI the block device.
> UBI is certainly in the kernel [1], please submit a PR to add the TAG.

Yeah, that was probably my fault. Should not have mentioned UBIFS at
all since this is really UBI related.

Will create PR.

Best Regards
Mirza
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] mount ubifs using /dev/ubi0_X path

[Mirza Krak]

2017-01-23 18:09 GMT+01:00 Lennart Poettering <lenn...@poettering.net>:
> On Mon, 23.01.17 17:56, Mirza Krak (mirza.k...@gmail.com) wrote:
>
>> Simply running "mount -a" once the system has started up gives me no
>> issues and /data is mounted according to my specification in
>> /etc/fstab.
>>
>> Also changing my fstab entry from "/dev/ubi0_2" to "ubi0_2" or
>> "ubi0:data" produces no errors and it is mounted as expected. But I
>> really want to use the "/dev" and I do not see a reason why it should
>> not work?
>
> systemd only picks up devices that carry the "systemd" label in udev,
> and do not have SYSTEMD_READY=0 set. Usually the label is added by
> some udev rule, most likely that's missing for your devices.
>
> See systemd.device(5) for details.

Thank you Lennart for your fast response.

Adding

SUBSYSTEM=="ubi", TAG+="systemd"

did indeed solve it.

Best Regards
Mirza
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] mount ubifs using /dev/ubi0_X path

[Mirza Krak]

2017-01-23 22:36 GMT+01:00 Mirza Krak <mirza.k...@gmail.com>:
> 2017-01-23 18:09 GMT+01:00 Lennart Poettering <lenn...@poettering.net>:
>> On Mon, 23.01.17 17:56, Mirza Krak (mirza.k...@gmail.com) wrote:
>>
>>> Simply running "mount -a" once the system has started up gives me no
>>> issues and /data is mounted according to my specification in
>>> /etc/fstab.
>>>
>>> Also changing my fstab entry from "/dev/ubi0_2" to "ubi0_2" or
>>> "ubi0:data" produces no errors and it is mounted as expected. But I
>>> really want to use the "/dev" and I do not see a reason why it should
>>> not work?
>>
>> systemd only picks up devices that carry the "systemd" label in udev,
>> and do not have SYSTEMD_READY=0 set. Usually the label is added by
>> some udev rule, most likely that's missing for your devices.
>>
>> See systemd.device(5) for details.
>
> Thank you Lennart for your fast response.
>
> Adding
>
> SUBSYSTEM=="ubi", TAG+="systemd"
>
> did indeed solve it.

I just noticed that the file I ended up editing was 99-systemd.rules,
which is part of systemd. This was the file that made most sense when
I was looking trough all the .rules files I had on my system.

UBI is a common file system that is used on raw FLASH systems, in the
embedded world.

Would you consider adding that line in upstream? IMO it fits along
side SUBSYSTEM=="block", TAG+="systemd" that is all ready in the file.
But I might me "embedded" damaged for requesting this...

Best Regards
Mirza
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] mount ubifs using /dev/ubi0_X path

[Mirza Krak]

Hi all.

I am experiencing some difficulties with mounting an UBI volume using
/dev/ubi0_X path.

I will start from the beginning.

In my /etc/fstab I have an entry that says:

/dev/ubi0_2   /dataubifs   defaults,auto 0  0

So on boot I expect systemd to create an .mount unit for me and mount
according above.

It creates an .mount unit

~ # cat /run/systemd/generator/data.mount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=local-fs.target

[Mount]
What=/dev/ubi0_2
Where=/data
Type=ubifs
Options=defaults,auto

And it attempts to mount during boot, but fails:

Jan 22 15:54:49 colibri-vf systemd[1]: dev-ubi0_2.device: Job
dev-ubi0_2.device/start timed out.
Jan 22 15:54:49 colibri-vf systemd[1]: Timed out waiting for device
dev-ubi0_2.device.
-- Subject: Unit dev-ubi0_2.device has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit dev-ubi0_2.device has failed.
--
-- The result is timeout.
Jan 22 15:54:49 colibri-vf systemd[1]: Dependency failed for /data.
-- Subject: Unit data.mount has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit data.mount has failed.
--
-- The result is dependency.
Jan 22 15:54:49 colibri-vf systemd[1]: data.mount: Job
data.mount/start failed with result 'dependency'.
Jan 22 15:54:49 colibri-vf systemd[1]: dev-ubi0_2.device: Job
dev-ubi0_2.device/start failed with result 'timeout'

It seems that it can not not find /dev/ubi0_2", but it is there. My /
is on the same UBI part, which is attached during kernel boot so I
expect that all devices are there and it does succeed in mount the
root file system (/)

~ # ls /dev/ubi0*
/dev/ubi0/dev/ubi0_0  /dev/ubi0_1  /dev/ubi0_2

Simply running "mount -a" once the system has started up gives me no
issues and /data is mounted according to my specification in
/etc/fstab.

Also changing my fstab entry from "/dev/ubi0_2" to "ubi0_2" or
"ubi0:data" produces no errors and it is mounted as expected. But I
really want to use the "/dev" and I do not see a reason why it should
not work?

systemd version:
systemd 230 running in system mode. (-PAM -AUDIT -SELINUX -IMA
-APPARMOR -SMACK +SYSVINIT -UTMP -LIBCRYPTSETUP -GCRYPT )

Any thoughts?

Best Regards
Mirza
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-growfs blocks boot until completed

[Mirza Krak]

Hi,

I have been using the systemd-growfs feature for a while, and been
happy with it so far.

But recently I upgraded my distribution (custom based on Yocto) which
also upgraded systemd from 239 to 241, and I can see that there has
been a change in behavior of the "systemd-growfs" feature.

In systemd 241, it blocks the boot process while it is growing the
filesystem, here is an example log:

 Mounting /data...
[   10.693190] EXT4-fs (mmcblk0p4): mounted filesystem with ordered
data mode. Opts: (null)
[  OK  ] Mounted /data.
 Starting Grow File System on /data...
[   10.780109] EXT4-fs (mmcblk0p4): resizing filesystem from 131072 to
30773248 blocks
[**] A start job is running for Grow File System on /data (11s /
no limit)
[  *** ] A start job is running for Grow File System on /data (21s /
no limit)
[***   ] A start job is running for Grow File System on /data (30s / no limit)
[***   ] A start job is running for Grow File System on /data (42s / no limit)
[**] A start job is running for Grow File System on /data (52s / no limit)
[**] A start job is running for Grow Filâ…stem on /data (1min 2s / no limit)
[ ***  ] A start job is running for Grow Filâ…tem on /data (1min 15s / no limit)
[  *** ] A start job is running for Grow Filâ…tem on /data (1min 26s / no limit)
[  *** ] A start job is running for Grow Filâ…tem on /data (1min 36s / no limit)
[ ***  ] A start job is running for Grow Filâ…tem on /data (1min 46s / no limit)
[   ***] A start job is running for Grow Filâ…tem on /data (1min 56s / no limit)
[**] A start job is running for Grow Filâ…stem on /data (2min 6s / no limit)
[**] A start job is running for Grow Filâ…tem on /data (2min 17s / no limit)
[* ] A start job is running for Grow Filâ…tem on /data (2min 27s / no limit)
[ ***  ] A start job is running for Grow Filâ…tem on /data (2min 35s / no limit)

In the previous version (239), this occurred in the background and did
not obstruct the boot process in any noticeable way. Which matched my
expectations on how this feature would work.

So my question is, was the change intentional and if so, what was the reasoning?

Thank you

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

Re: [systemd-devel] systemd-growfs blocks boot until completed

[Mirza Krak]

Den fre 27 sep. 2019 kl 15:23 skrev Lennart Poettering :
>
> On Fr, 27.09.19 14:35, Mirza Krak (mi...@mkrak.org) wrote:
>
> > Hi,
> >
> > I have been using the systemd-growfs feature for a while, and been
> > happy with it so far.
> >
> > But recently I upgraded my distribution (custom based on Yocto) which
> > also upgraded systemd from 239 to 241, and I can see that there has
> > been a change in behavior of the "systemd-growfs" feature.
> >
> > In systemd 241, it blocks the boot process while it is growing the
> > filesystem, here is an example log:
> >
> >  Mounting /data...
> > [   10.693190] EXT4-fs (mmcblk0p4): mounted filesystem with ordered
> > data mode. Opts: (null)
> > [  OK  ] Mounted /data.
> >  Starting Grow File System on /data...
> > [   10.780109] EXT4-fs (mmcblk0p4): resizing filesystem from 131072 to
> > 30773248 blocks
> > [**] A start job is running for Grow File System on /data (11s /
> > no limit)
> > [  *** ] A start job is running for Grow File System on /data (21s /
> > no limit)
> > [***   ] A start job is running for Grow File System on /data (30s / no 
> > limit)
> > [***   ] A start job is running for Grow File System on /data (42s / no 
> > limit)
> > [**] A start job is running for Grow File System on /data (52s / no 
> > limit)
> > [**] A start job is running for Grow Filâ…stem on /data (1min 2s / no 
> > limit)
> > [ ***  ] A start job is running for Grow Filâ…tem on /data (1min 15s / no 
> > limit)
> > [  *** ] A start job is running for Grow Filâ…tem on /data (1min 26s / no 
> > limit)
> > [  *** ] A start job is running for Grow Filâ…tem on /data (1min 36s / no 
> > limit)
> > [ ***  ] A start job is running for Grow Filâ…tem on /data (1min 46s / no 
> > limit)
> > [   ***] A start job is running for Grow Filâ…tem on /data (1min 56s / no 
> > limit)
> > [**] A start job is running for Grow Filâ…stem on /data (2min 6s / no 
> > limit)
> > [**] A start job is running for Grow Filâ…tem on /data (2min 17s / no 
> > limit)
> > [* ] A start job is running for Grow Filâ…tem on /data (2min 27s / no 
> > limit)
> > [ ***  ] A start job is running for Grow Filâ…tem on /data (2min 35s / no 
> > limit)
> >
> > In the previous version (239), this occurred in the background and did
> > not obstruct the boot process in any noticeable way. Which matched my
> > expectations on how this feature would work.
> >
> > So my question is, was the change intentional and if so, what was the 
> > reasoning?
>
> Hmm, the tool doesn't do much. It just calls an fs ioctl. If you
> attach gdb to the process (or strace it), can you see what it is
> blocking on?

It seems that the ioctl operation is blocking until the resize is completed,

openat(AT_FDCWD, "/data", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/dev/block/179:4", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4
ioctl(4, BLKBSZGET, [1024]) = 0
ioctl(4, BLKGETSIZE64, [31511805952])   = 0
fstatfs64(3, 88, 0x7eb56bf0)= 0
ioctl(3, _IOC(_IOC_WRITE, 0x66, 0x10, 0x8), 0x7eb56be

I would like to clarify that it eventually will complete (after 5
minutes on my device), and then the boot proceeds as normal. The ioctl
behavior has not changed, as it was blocking in the kernel in my
previous distribution version as well, but the
systemd-growfs@data.service did not block the boot on systemd 239
where this was performed in parallel, but now it seems to block.

The Linux kernel is: 4.19.71

This is what the systemd-growfs@.service looks like:

# Automatically generated by systemd-fstab-generator
[Unit]
Description=Grow File System on %f
Documentation=man:systemd-growfs@.service(8)
DefaultDependencies=no
BindsTo=%i.mount
Conflicts=shutdown.target
After=%i.mount
Before=shutdown.target local-fs.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/lib/systemd/systemd-growfs /data
TimeoutSec=0

-- 
Med Vänliga Hälsningar / Best Regards

Mirza Krak
email: mi...@mkrak.org
web: https://mkrak.org
pgp: https://keybase.io/mirzak/key.asc
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Assertion '!ether_addr_is_null(addr)'

[Mirza Krak]

On Fri, 1 Sept 2023 at 08:21, Mirza Krak  wrote:
>
> On Thu, 31 Aug 2023 at 12:12, Lennart Poettering  
> wrote:
> >
> > On Mi, 30.08.23 15:22, Mirza Krak (mirza.k...@gmail.com) wrote:
> >
> > > Hi,
> > >
> > > Environment:
> > > * systemd: 250.5
> >
> > This release is from 2021, i.e. relatively old. The issue you are
> > descriping is almost certainly aleady addressed in newer
> > versions. Consider using a new version. Or contact your OS vendor,
> > asking them to maybe backport the fix in question.
>
> Unfortunately I am the OS vendor (Yocto Project based distribution),
> so it's up to me to solve it :). Would like to avoid updating to a
> newer version at the moment, so the backport does sound like a
> feasible path forward.
>
> Would appreciate any pointers/references to where this issue might
> reside, to help me find the necessary backports.

Should anyone stumble upon this, I backported parts of
https://github.com/systemd/systemd/pull/24174 to resolve this.

/ Mirza

Re: [systemd-devel] Assertion '!ether_addr_is_null(addr)'

[Mirza Krak]

On Thu, 31 Aug 2023 at 12:12, Lennart Poettering  wrote:
>
> On Mi, 30.08.23 15:22, Mirza Krak (mirza.k...@gmail.com) wrote:
>
> > Hi,
> >
> > Environment:
> > * systemd: 250.5
>
> This release is from 2021, i.e. relatively old. The issue you are
> descriping is almost certainly aleady addressed in newer
> versions. Consider using a new version. Or contact your OS vendor,
> asking them to maybe backport the fix in question.

Unfortunately I am the OS vendor (Yocto Project based distribution),
so it's up to me to solve it :). Would like to avoid updating to a
newer version at the moment, so the backport does sound like a
feasible path forward.

Would appreciate any pointers/references to where this issue might
reside, to help me find the necessary backports.

/ Mirza

[systemd-devel] Assertion '!ether_addr_is_null(addr)'

[Mirza Krak]

Hi,

Environment:
* systemd: 250.5
* Linux kernel 5.15.113

I am trying to do something really simple (I thought), and I have the
following .network file:

[Match]
Name=lo

[Address]
Address=169.254.66.6/32

But it fails with the following error:

Aug 30 13:17:05 localhost systemd-networkd[299]: lo: Failed to get
driver, continuing without: Operation not supported
Aug 30 13:17:05 localhost systemd-networkd[299]: lo: Saved
permanent hardware address: 00:00:00:00:00:00
Aug 30 13:17:05 localhost systemd-networkd[299]: lo: Link state is
up-to-date
Aug 30 13:17:05 localhost systemd-networkd[299]: lo: found
matching network '/lib/systemd/network/99-loopback-alias.network'.
Aug 30 13:17:05 localhost systemd-networkd[299]: lo: Ignoring
link-local autoconfiguration for loopback link
Aug 30 13:17:05 localhost systemd-networkd[299]: lo: State
changed: initialized -> configuring
Aug 30 13:17:05 localhost systemd-networkd[299]: Setting
'/proc/sys/net/ipv4/conf/lo/promote_secondaries' to '1'
Aug 30 13:17:05 localhost systemd-networkd[299]: No change in
value '1', suppressing write
Aug 30 13:17:05 localhost systemd-networkd[299]: lo: Requested to
set interface group
Aug 30 13:17:05 localhost systemd-networkd[299]: lo: Requested to
set IPv6LL address generation mode
Aug 30 13:17:05 localhost systemd-networkd[299]: lo: Requested to
set master interface
Aug 30 13:17:05 localhost systemd-networkd[299]: lo:
link_check_ready(): link layer is configuring.
Aug 30 13:17:05 localhost systemd-networkd[299]: lo: Requested to
activate link
Aug 30 13:17:05 localhost systemd-networkd[299]: lo: Configuring
IPv4ACD for address 169.254.66.6
Aug 30 13:17:05 localhost systemd-networkd[299]: Assertion
'!ether_addr_is_null(addr)' failed at
src/libsystemd-network/sd-ipv4acd.c:467, function
sd_ipv4acd_set_mac(). Ignoring.
Aug 30 13:17:05 localhost systemd-networkd[299]: lo: Failed
Aug 30 13:17:05 localhost systemd-networkd[299]: lo: State
changed: configuring -> failed

Not sure what I am doing wrong here. The same config used to work with
systemd 244.5, so either a regression, or I was doing something wrong
to begin with.

/ Mirza