Cannot boot after upgrading to Snapshot 20180120

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Attempting to postpone btrfs-balance until user login (was [opensuse-factory] Cannot boot after upgrading to Snapshot 20180120)

CnZhx
On Monday, 29 January 2018 09:32:10 GMT H Zeng wrote:

> On Monday, 22 January 2018 18:17:30 GMT Andrei Borzenkov wrote:
> > 22.01.2018 19:26, CnZhx пишет:
> > ...
> >
> > >>>>>>>> Try creating  (untested)
> > >>>>
> > >>>> /etc/systemd/system/btrfs-balance.timer.d/later.conf
> > >>>>
> > >>>> containing:
> > >>>>
> > >>>> [Timer]
> > >>>> OnBootSec=1h
> > >>>>
> > >>>> and run systemctl daemon-reload
> > >>
> > >> Note that timers are triggered when either specification expires.
> > >> Which means it will run 1 hour after boot *or* as otherwise specified.
> >
> > ...
> >
> > > Mon 2018-01-29 00:00:00 GMT  6 days left         Mon 2018-01-22 16:15:01
> > > GMT 4min 52s ago       btrfs-balance.timer        
> > > btrfs-balance.service
> >
> > ...
> >
> > > So, `btrfs-balance` does run at 10min after boot. But I do not know what
> > > does other information indicate. This is beyond my knowledge.
> >
> > It is run 10 minutes after boot *and* is scheduled to run in 7 days (or
> > rather "weekly" which is Monday 00:00). So you simply added additional
> > points in time when balance runs. Before it would run only on Monday
> > (also if you reboot on Monday) now it will *additionally* run on every
> > reboot :)
> >
> > I am not sure what happens if you boot on Monday, will systemd "merge"
> > these two timer runs or you get balance run twice.
>
> ...
>
> I am going to re-enable the "1 hour delay" "later.timer" as suggested by
> Andrei Borzenkov in above quote and reboot right after this. I will report
> back two days later.

29th January, 7 days after last test on 22nd January, `btrfs-balance` ran
after the laptop was resumed from sleep. During that, I had no problem logging
into desktop. The `btrfs-balance` takes one full core of the CPU but not
hinders the login process. The "btrfs-balance.timer" was set to run at "Thu
2018-02-01 00:00:00 GMT" after this.

After resetting the "1 hour delay" configuration `/etc/systemd/system/btrfs-
balance.timer.d/later.conf` as suggested by Andrei Borzenkov, I reloaded the
configurations by issuing `systemctl daemon-reload`. The time of the "btrfs-
balance.timer" did not change.

After reboot, the time of the "btrfs-balance.timer" was "Mon 2018-01-29
11:05:35 GMT". So it was set to run "1 hour after the boot" during/after the
boot process. I guess, this is not what we want. Additionally, after it ran in
1 hour later (this time it took only 1 second to finish), the "btrfs-
balance.timer" was set to "Thu 2018-02-01 00:00:00 GMT" again. Obviously, the
"later.conf" adds more btrfs-balance to the system even if it could prevent
btrfs-balance from running during boot.

Two days later, after I boot the laptop at 8:00 AM, `jounalctl` shows the
btrfs-balance has run during boot. But I feel it has run after I input my
password on the KDE login screen (or at least it has not prevented the login
1min 36s left btrfs-balance.timer
```
Now, the `systemd list-timers` shows that btrfs-balance has been scheduled to
run at about 1 hour later. So the "1 hour delay" configuration `/etc/systemd/
system/btrfs-balance.timer.d/later.conf` does not prevent the btrfs-balance
from running during boot. It also adds this process after every boot.


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

12