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
|

Cannot boot after upgrading to Snapshot 20180120

CnZhx
Dear all,

I am wondering does anyone else have encounter a boot problem after upgrading
to Snapshot 20180120.

I have skipped several snapshots and upgrade my system from Snapshot 20180109
to 20180120 by issuing,

$ sudo zypper dup

zypper did pop up some information but I thought that was ok. There were two
kinds of messages:
1) Complaining that "recode" is obsoleted ( I chose to install the one from
"base" repository instead);
2) Complaining that there are 3 files from kernel 4.14.12 will be overwritten
by those from kernel 4.14.14. ( I chose "yes" for this overwriting)

After it finished, I reboot the system but it stopped at the line "Started
Command Scheduler".

Pressing Power button to restart results the same situation. I can boot into
the "pre" snapshot though. I have not issued a rollback in case I need this
state.

In case it helps, my main system packages are from Tumbleweed repos with
several applications such as qTox, kde-telepathy, dkms_acpi_call, acpi_call
and some media related packages from other repos such as packman. Here is the
list of enabled repos,
```
#  | Alias          | Name                        | Enabled | GPG Check |
Refresh
---+----------------+-----------------------------+---------+-----------
+--------
 3 | base           | base                        | Yes     | (r ) Yes  | Yes
 4 | dkms_acpi_call | dkms_acpi_call              | Yes     | (r ) Yes  | Yes
 7 | kde_fw         | kde_apps                    | Yes     | (r ) Yes  | Yes
13 | packman        | packman                     | Yes     | (r ) Yes  | Yes
14 | qTox           | qTox                        | Yes     | (r ) Yes  | Yes
16 | repo-non-oss   | openSUSE-Tumbleweed-Non-Oss | Yes     | (r ) Yes  | Yes
17 | repo-oss       | openSUSE-Tumbleweed-Oss     | Yes     | (r ) Yes  | Yes
19 | repo-update    | openSUSE-Tumbleweed-Update  | Yes     | (r ) Yes  | Yes
20 | ring           | ring                        | Yes     | (r ) Yes  | Yes
```

Any suggestion is welcomed.

Regards,
Haoxian



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

Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

Oliver Kurz-2
On Sunday, 21 January 2018 23:16:17 CET CnZhx wrote:

> Dear all,
>
> I am wondering does anyone else have encounter a boot problem after
> upgrading to Snapshot 20180120.
>
> I have skipped several snapshots and upgrade my system from Snapshot
> 20180109 to 20180120 by issuing,
>
> $ sudo zypper dup
>
> zypper did pop up some information but I thought that was ok. There were two
> kinds of messages:
> 1) Complaining that "recode" is obsoleted ( I chose to install the one from
> "base" repository instead);
> 2) Complaining that there are 3 files from kernel 4.14.12 will be
> overwritten by those from kernel 4.14.14. ( I chose "yes" for this
> overwriting)
>
> After it finished, I reboot the system but it stopped at the line "Started
> Command Scheduler".
>
> Pressing Power button to restart results the same situation. I can boot into
> the "pre" snapshot though. I have not issued a rollback in case I need this
> state.
>
> In case it helps, my main system packages are from Tumbleweed repos with
> several applications such as qTox, kde-telepathy, dkms_acpi_call, acpi_call
> and some media related packages from other repos such as packman. Here is
> the list of enabled repos,
> ```
> #  | Alias          | Name                        | Enabled | GPG Check |
> Refresh
> ---+----------------+-----------------------------+---------+-----------
> +--------
>  3 | base           | base                        | Yes     | (r ) Yes  |
> Yes 4 | dkms_acpi_call | dkms_acpi_call              | Yes     | (r ) Yes
> | Yes 7 | kde_fw         | kde_apps                    | Yes     | (r ) Yes
>  | Yes 13 | packman        | packman                     | Yes     | (r )
> Yes  | Yes 14 | qTox           | qTox                        | Yes     | (r
> ) Yes  | Yes 16 | repo-non-oss   | openSUSE-Tumbleweed-Non-Oss | Yes     |
> (r ) Yes  | Yes 17 | repo-oss       | openSUSE-Tumbleweed-Oss     | Yes    
> | (r ) Yes  | Yes 19 | repo-update    | openSUSE-Tumbleweed-Update  | Yes  
>   | (r ) Yes  | Yes 20 | ring           | ring                        | Yes
>     | (r ) Yes  | Yes ```

I wonder what the "ring" repo contains. Without the URL displayed I don't know
which repo that is. You can call `zypper lr --uri` to show that as well.

Are you sure your system really "stopped" or is it just taking very very long
to come up with the next point?
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

CnZhx
On Monday, 22 January 2018 07:43:17 GMT Oliver Kurz wrote:

> On Sunday, 21 January 2018 23:16:17 CET CnZhx wrote:
> > Dear all,
> >
> > I am wondering does anyone else have encounter a boot problem after
> > upgrading to Snapshot 20180120.
> >
> > I have skipped several snapshots and upgrade my system from Snapshot
> > 20180109 to 20180120 by issuing,
> >
> > $ sudo zypper dup
> >
> > zypper did pop up some information but I thought that was ok. There were
> > two kinds of messages:
> > 1) Complaining that "recode" is obsoleted ( I chose to install the one
> > from
> > "base" repository instead);
> > 2) Complaining that there are 3 files from kernel 4.14.12 will be
> > overwritten by those from kernel 4.14.14. ( I chose "yes" for this
> > overwriting)
> >
> > After it finished, I reboot the system but it stopped at the line "Started
> > Command Scheduler".
> >
> > Pressing Power button to restart results the same situation. I can boot
> > into the "pre" snapshot though. I have not issued a rollback in case I
> > need this state.
> >
> > In case it helps, my main system packages are from Tumbleweed repos with
> > several applications such as qTox, kde-telepathy, dkms_acpi_call,
> > acpi_call
> > and some media related packages from other repos such as packman. Here is
> > the list of enabled repos,
> > ```
> > #  | Alias          | Name                        | Enabled | GPG Check |
> > Refresh
> > ---+----------------+-----------------------------+---------+-----------
> > +--------
> >
> >  3 | base           | base                        | Yes     | (r ) Yes  |
> >
> > Yes 4 | dkms_acpi_call | dkms_acpi_call              | Yes     | (r ) Yes
> >
> > | Yes 7 | kde_fw         | kde_apps                    | Yes     | (r )
> > | Yes
> > |
> >  | Yes 13 | packman        | packman                     | Yes     | (r )
> >
> > Yes  | Yes 14 | qTox           | qTox                        | Yes     |
> > (r
> > ) Yes  | Yes 16 | repo-non-oss   | openSUSE-Tumbleweed-Non-Oss | Yes     |
> > (r ) Yes  | Yes 17 | repo-oss       | openSUSE-Tumbleweed-Oss     | Yes
> >
> > | (r ) Yes  | Yes 19 | repo-update    | openSUSE-Tumbleweed-Update  | Yes
> > |
> >   | (r ) Yes  | Yes 20 | ring           | ring                        |
> >   | Yes
> >   |
> >     | (r ) Yes  | Yes ```
>
> I wonder what the "ring" repo contains. Without the URL displayed I don't
> know which repo that is. You can call `zypper lr --uri` to show that as
> well.
>
> Are you sure your system really "stopped" or is it just taking very very
> long to come up with the next point?

Hi, Oliver,

Thank you for your response :-) Sorry that I hadn't made it clear with my
situation.

My hardware is a ThinkPad T470s with an Intel Core i7-7600U. The  repos with
uri are,
```# zypper lr -E --uri
Repository priorities in effect:                                                                      
(See 'zypper lr -P' for details)
      99 (default priority) :  4 repositories
     100 (lowered priority) :  5 repositories

#  | Alias          | Name                        | Enabled | GPG Check |
Refresh | URI                                                
---+----------------+-----------------------------+---------+-----------
+---------
+-------------------------------------------------------------------------------------------------
 3 | base           | base                        | Yes     | (r ) Yes  | Yes    
| https://download.opensuse.org/repositories/Base:/System/openSUSE_Factory/
 4 | dkms_acpi_call | dkms_acpi_call              | Yes     | (r ) Yes  | Yes    
| https://download.opensuse.org/repositories/home:/ramax/openSUSE_Tumbleweed/
 7 | kde_fw         | kde_apps                    | Yes     | (r ) Yes  | Yes    
| http://download.opensuse.org/repositories/KDE:/Applications/
KDE_Frameworks5_openSUSE_Tumbleweed/
13 | packman        | packman                     | Yes     | (r ) Yes  | Yes    
| http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/
14 | qTox           | qTox                        | Yes     | (r ) Yes  | Yes    
| http://download.opensuse.org/repositories/home:/ecsos:/messenger:/tox/
openSUSE_Tumbleweed/
16 | repo-non-oss   | openSUSE-Tumbleweed-Non-Oss | Yes     | (r ) Yes  | Yes    
| http://download.opensuse.org/tumbleweed/repo/non-oss/
17 | repo-oss       | openSUSE-Tumbleweed-Oss     | Yes     | (r ) Yes  | Yes    
| http://download.opensuse.org/tumbleweed/repo/oss/ 
19 | repo-update    | openSUSE-Tumbleweed-Update  | Yes     | (r ) Yes  | Yes    
| http://download.opensuse.org/update/tumbleweed/   
20 | ring           | ring                        | Yes     | (r ) Yes  | Yes    
| http://download.opensuse.org/repositories/home:/szotsaki/openSUSE_Factory/
```
So the "ring" is for ring-client-KDE of GNU Ring.

It's the first time I ran into this situation in the 2-year time or so running
Tumbleweed as my main OS.

I have waited not too long (less than 3 minutes) for the boot. But I will try
to wait a long time for the boot after I send this email out. But this machine
has been very fast on booting.

Regards,
Haoxian




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

Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

CnZhx
In reply to this post by Oliver Kurz-2
On Monday, 22 January 2018 07:43:17 GMT Oliver Kurz wrote:
> On Sunday, 21 January 2018 23:16:17 CET CnZhx wrote:
> > Dear all,
> >
> > I am wondering does anyone else have encounter a boot problem after
> > upgrading to Snapshot 20180120.
>
> Are you sure your system really "stopped" or is it just taking very very
> long to come up with the next point?

Thanks everyone for your attention. And special thanks to Oliver for the
remind.

Now the machine boots right into desktop after a few seconds delay at the
login prompt in booting shell. This time, it has no stop after showing the
message "Started Command Scheduler" and gives the shell login prompt right
away after the message.

It is very awkward that the system actually has no problem booting. I
booted several times last night any finally decided to boot into a
read-only snapshot for checking the mailing list.

So I made a false alarm. As I added later, this machine usually takes no
more than 20 seconds to boot into desktop (KF5). But this time, it takes a
long time to do `btrfs-balance` and other stuff making me think it actually
dead. Here is the first several entries of `blame`,
```
$ systemd-analyze blame
    1min 37.267s btrfs-balance.service
         33.055s purge-kernels.service
         33.015s dkms.service
         20.642s fstrim.service
          1.620s postfix.service
          1.429s firewalld.service
          1.298s btrfsmaintenance-refresh.service
          1.153s vboxdrv.service
          1.141s tor.service
          1.089s apparmor.servic
```
Maybe the OS now performs maintenance at boot because even the BtrFS now uses
systemd-timer for scheduling actions.

Best wishes,
Haoxian


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

Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

Hadrien Grasland
Yes, one drawback to using Btrfs is that it has these unpredictable bursts of high IO usage. If these occur at boot time, you're in for a long boot, and if they occur inside of a running system, everything that involves disk IO will suddenly become super-slow...

Ideally, there would be a way to give these scheduled filesystem maintenance operations lower priority, so that they don't kill your system like that. I'm not familiar with Btrfs and kernel internals, so I don't know how easy / hard going in that direction would be...

Cheers,
Hadrien


  Message original  
De: [hidden email]
Envoyé: 22 janvier 2018 10:29 AM
À: [hidden email]
Répondre à: [hidden email]
Objet: Re: [opensuse-factory] Cannot boot after upgrading to Snapshot 20180120

On Monday, 22 January 2018 07:43:17 GMT Oliver Kurz wrote:
> On Sunday, 21 January 2018 23:16:17 CET CnZhx wrote:
> > Dear all,
> >
> > I am wondering does anyone else have encounter a boot problem after
> > upgrading to Snapshot 20180120.
>
> Are you sure your system really "stopped" or is it just taking very very
> long to come up with the next point?

Thanks everyone for your attention. And special thanks to Oliver for the
remind.

Now the machine boots right into desktop after a few seconds delay at the
login prompt in booting shell. This time, it has no stop after showing the
message "Started Command Scheduler" and gives the shell login prompt right
away after the message.

It is very awkward that the system actually has no problem booting. I
booted several times last night any finally decided to boot into a
read-only snapshot for checking the mailing list.

So I made a false alarm. As I added later, this machine usually takes no
more than 20 seconds to boot into desktop (KF5). But this time, it takes a
long time to do `btrfs-balance` and other stuff making me think it actually
dead. Here is the first several entries of `blame`,
```
$ systemd-analyze blame
    1min 37.267s btrfs-balance.service
         33.055s purge-kernels.service
         33.015s dkms.service
         20.642s fstrim.service
          1.620s postfix.service
          1.429s firewalld.service
          1.298s btrfsmaintenance-refresh.service
          1.153s vboxdrv.service
          1.141s tor.service
          1.089s apparmor.servic
```
Maybe the OS now performs maintenance at boot because even the BtrFS now uses
systemd-timer for scheduling actions.

Best wishes,
Haoxian


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

N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

Frederic Crozat-4
Le lundi 22 janvier 2018 à 10:44 +0100, Hadrien Grasland a écrit :
> Yes, one drawback to using Btrfs is that it has these unpredictable
> bursts of high IO usage. If these occur at boot time, you're in for a
> long boot, and if they occur inside of a running system, everything
> that involves disk IO will suddenly become super-slow...

Those are usually related to rebalancing of the FS.

Latest btrfsmaintenance package has switched from cron job to systemd
timer, this should allow you to easily "tune" the condition on when the
balancing is done, for your own need (thanks to systemd drop-in).


--
Frederic Crozat
Enterprise Desktop Release Manager
SUSE

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

Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

Thorsten Kukuk
In reply to this post by CnZhx
On Mon, Jan 22, CnZhx wrote:

> Maybe the OS now performs maintenance at boot because even the BtrFS now uses
> systemd-timer for scheduling actions.

During the first boot with a new timer systemd finds out this timer
did never run before and starts it immeaditly.
If somebody knows how to tell systemd that btrfs-balance.timer should
run once a month, but not during the first 2 hours of a reboot ...

  Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & CaaSP
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

CnZhx
On Monday, 22 January 2018 10:10:05 GMT Thorsten Kukuk wrote:
> During the first boot with a new timer systemd finds out this timer
> did never run before and starts it immeaditly.
> If somebody knows how to tell systemd that btrfs-balance.timer should
> run once a month, but not during the first 2 hours of a reboot ...

I checked and found it was set to run every 7 days.

Maybe, it's better to at least show a message at the booting screen to tell
user that the jobs are running because there is no LED indicator, at least for
newer ThinkPad models, shows the system is alive :-)

Haoxian



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

Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

CnZhx
In reply to this post by Frederic Crozat-4
On Monday, 22 January 2018 09:55:53 GMT Frederic Crozat wrote:
> Latest btrfsmaintenance package has switched from cron job to systemd
> timer, this should allow you to easily "tune" the condition on when the
> balancing is done, for your own need (thanks to systemd drop-in).

Thanks for the heads-up. Do you happen to know is it possible to add an option
of `OnBootSec=1h` in [Timer] section of .timer file to make the process start
after 1 hour after boot?

Current `/usr/lib/systemd/system/btrfs-balance.timer` looks like,
```
[Unit]                                                                                                                                
Description=Balance block groups on a btrfs filesystem                                                                                
Documentation=man:btrfs-balance                                                                                                        

[Timer]
OnCalendar=monthly
AccuracySec=1h
Persistent=true

[Install]
WantedBy=timers.target
```

And because btrfs-trim.service, btrfs-scrub.service, and btrfs-balance.service
are set to run after fstrim.service, maybe we could add this to
`fstrim.timer`.

But I am not sure whether these four service are meant to run before user
login.

Cheers,
Haoxian



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

Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

Frederic Crozat-4
Le lundi 22 janvier 2018 à 10:58 +0000, CnZhx a écrit :

> On Monday, 22 January 2018 09:55:53 GMT Frederic Crozat wrote:
> >
> > Latest btrfsmaintenance package has switched from cron job to
> > systemd
> > timer, this should allow you to easily "tune" the condition on when
> > the
> > balancing is done, for your own need (thanks to systemd drop-in).
>
> Thanks for the heads-up. Do you happen to know is it possible to add
> an option 
> of `OnBootSec=1h` in [Timer] section of .timer file to make the
> process start 
> after 1 hour after boot?

Try creating  (untested)

/etc/systemd/system/btrfs-balance.timer.d/later.conf

containing:

[Timer]
OnBootSec=1h

and run systemctl daemon-reload



--
Frederic Crozat
Enterprise Desktop Release Manager
SUSE

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

Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

Axel Braun-2
Maybe we should deliver this as a standard/default setting
Schöne Grüße
 Axel
--
Written from cell phone - excuses for typos

Am 22. Januar 2018 12:43:32 MEZ schrieb Frederic Crozat <[hidden email]>:

>Le lundi 22 janvier 2018 à 10:58 +0000, CnZhx a écrit :
>> On Monday, 22 January 2018 09:55:53 GMT Frederic Crozat wrote:
>> >
>> > Latest btrfsmaintenance package has switched from cron job to
>> > systemd
>> > timer, this should allow you to easily "tune" the condition on when
>> > the
>> > balancing is done, for your own need (thanks to systemd drop-in).
>>
>> Thanks for the heads-up. Do you happen to know is it possible to add
>> an option 
>> of `OnBootSec=1h` in [Timer] section of .timer file to make the
>> process start 
>> after 1 hour after boot?
>
>Try creating  (untested)
>
>/etc/systemd/system/btrfs-balance.timer.d/later.conf
>
>containing:
>
>[Timer]
>OnBootSec=1h
>
>and run systemctl daemon-reload
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

Frederic Crozat-4
Le lundi 22 janvier 2018 à 13:07 +0100, Axel Braun a écrit :
> Maybe we should deliver this as a standard/default setting

If this is confirmed to help, feel free to report it to bugzilla (or do
a submit request against btrfsmaintenance).


--
Frederic Crozat
Enterprise Desktop Release Manager
SUSE

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

Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

CnZhx
In reply to this post by Frederic Crozat-4
On Monday, 22 January 2018 11:43:32 GMT Frederic Crozat wrote:

> Le lundi 22 janvier 2018 à 10:58 +0000, CnZhx a écrit :
> >
> > Thanks for the heads-up. Do you happen to know is it possible to add
> > an option
> > of `OnBootSec=1h` in [Timer] section of .timer file to make the
> > process start
> > after 1 hour after boot?
>
> Try creating  (untested)
>
> /etc/systemd/system/btrfs-balance.timer.d/later.conf
>
> containing:
>
> [Timer]
> OnBootSec=1h
>
> and run systemctl daemon-reload

I have created this file and reloaded the confs by running `sudo systemctl
daemon-reload`. Do you know a way to trigger it to load on next reboot? I do
not want to wait for 6 days to check it because when I check the timers, it
says,
```
$ systemctl list-timers
NEXT                         LEFT                LAST                        
PASSED             UNIT                         ACTIVATES
Mon 2018-01-22 16:00:00 GMT  56min left          Mon 2018-01-22 15:00:01 GMT  
3min 35s ago       snapper-timeline.timer       snapper-t
Tue 2018-01-23 00:00:00 GMT  8h left             Mon 2018-01-22 08:59:46 GMT  
6h ago             logrotate.timer              logrotate
Tue 2018-01-23 09:04:52 GMT  18h left            Mon 2018-01-22 09:04:52 GMT  
5h 58min ago       snapper-cleanup.timer        snapper-c
Tue 2018-01-23 09:09:52 GMT  18h left            Mon 2018-01-22 09:09:52 GMT  
5h 53min ago       systemd-tmpfiles-clean.timer systemd-t
Mon 2018-01-29 00:00:00 GMT  6 days left         Mon 2018-01-22 08:59:46 GMT  
6h ago             btrfs-balance.timer          btrfs-bal
Mon 2018-01-29 00:00:00 GMT  6 days left         Mon 2018-01-22 08:59:46 GMT  
6h ago             fstrim.timer                 fstrim.se
Thu 2018-02-01 00:00:00 GMT  1 weeks 2 days left Sun 2018-01-07 19:40:45 GMT  
2 weeks 0 days ago btrfs-scrub.timer            btrfs-scr

7 timers listed.
Pass --all to see loaded but inactive timers, too.
lines 1-11/11 (END)
```

Cheers,
Haoxian


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

Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

Andrei Borzenkov
On Mon, Jan 22, 2018 at 6:07 PM, CnZhx <[hidden email]> wrote:

> On Monday, 22 January 2018 11:43:32 GMT Frederic Crozat wrote:
>> Le lundi 22 janvier 2018 à 10:58 +0000, CnZhx a écrit :
>> >
>> > Thanks for the heads-up. Do you happen to know is it possible to add
>> > an option
>> > of `OnBootSec=1h` in [Timer] section of .timer file to make the
>> > process start
>> > after 1 hour after boot?
>>
>> 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.

This was discussed recently, the only way to do it is to have second
timer that triggers 1 hour after boot and starts service that starts
fstrim.timer while leaving fstrim.timer itself disabled.

> I have created this file and reloaded the confs by running `sudo systemctl
> daemon-reload`. Do you know a way to trigger it to load on next reboot? I do
> not want to wait for 6 days to check it because when I check the timers, it
> says,
> ```
> $ systemctl list-timers
> NEXT                         LEFT                LAST
> PASSED             UNIT                         ACTIVATES
> Mon 2018-01-22 16:00:00 GMT  56min left          Mon 2018-01-22 15:00:01 GMT
> 3min 35s ago       snapper-timeline.timer       snapper-t
> Tue 2018-01-23 00:00:00 GMT  8h left             Mon 2018-01-22 08:59:46 GMT
> 6h ago             logrotate.timer              logrotate
> Tue 2018-01-23 09:04:52 GMT  18h left            Mon 2018-01-22 09:04:52 GMT
> 5h 58min ago       snapper-cleanup.timer        snapper-c
> Tue 2018-01-23 09:09:52 GMT  18h left            Mon 2018-01-22 09:09:52 GMT
> 5h 53min ago       systemd-tmpfiles-clean.timer systemd-t
> Mon 2018-01-29 00:00:00 GMT  6 days left         Mon 2018-01-22 08:59:46 GMT
> 6h ago             btrfs-balance.timer          btrfs-bal
> Mon 2018-01-29 00:00:00 GMT  6 days left         Mon 2018-01-22 08:59:46 GMT
> 6h ago             fstrim.timer                 fstrim.se
> Thu 2018-02-01 00:00:00 GMT  1 weeks 2 days left Sun 2018-01-07 19:40:45 GMT
> 2 weeks 0 days ago btrfs-scrub.timer            btrfs-scr
>
> 7 timers listed.
> Pass --all to see loaded but inactive timers, too.
> lines 1-11/11 (END)
> ```
>
> Cheers,
> Haoxian
>
>
> --
> To unsubscribe, e-mail: [hidden email]
> To contact the owner, e-mail: [hidden email]
>
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

CnZhx
On Monday, 22 January 2018 15:16:44 GMT Andrei Borzenkov wrote:

> On Mon, Jan 22, 2018 at 6:07 PM, CnZhx <[hidden email]> wrote:
> > On Monday, 22 January 2018 11:43:32 GMT Frederic Crozat wrote:
> >> Le lundi 22 janvier 2018 à 10:58 +0000, CnZhx a écrit :
> >> > Thanks for the heads-up. Do you happen to know is it possible to add
> >> > an option
> >> > of `OnBootSec=1h` in [Timer] section of .timer file to make the
> >> > process start
> >> > after 1 hour after boot?
> >>
> >> 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.
>
> This was discussed recently, the only way to do it is to have second
> timer that triggers 1 hour after boot and starts service that starts
> fstrim.timer while leaving fstrim.timer itself disabled.
>
Before this comment, I set 10 minutes for the `/etc/systemd/system/btrfs-
balance.timer.d/later.conf`, and reload by running `systemctl daemon-reload`.
Then I reboot the machine.

Observation gives has follows.

> > I have created this file and reloaded the confs by running `sudo systemctl
> > daemon-reload`. Do you know a way to trigger it to load on next reboot? I
> > do not want to wait for 6 days to check it because when I check the
> > timers, it says,
> > ```
> > $ systemctl list-timers
> > NEXT                         LEFT                LAST
> > PASSED             UNIT                         ACTIVATES
> > Mon 2018-01-22 16:00:00 GMT  56min left          Mon 2018-01-22 15:00:01
> > GMT 3min 35s ago       snapper-timeline.timer       snapper-t
> > Tue 2018-01-23 00:00:00 GMT  8h left             Mon 2018-01-22 08:59:46
> > GMT 6h ago             logrotate.timer              logrotate
> > Tue 2018-01-23 09:04:52 GMT  18h left            Mon 2018-01-22 09:04:52
> > GMT 5h 58min ago       snapper-cleanup.timer        snapper-c
> > Tue 2018-01-23 09:09:52 GMT  18h left            Mon 2018-01-22 09:09:52
> > GMT 5h 53min ago       systemd-tmpfiles-clean.timer systemd-t
> > Mon 2018-01-29 00:00:00 GMT  6 days left         Mon 2018-01-22 08:59:46
> > GMT 6h ago             btrfs-balance.timer          btrfs-bal
> > Mon 2018-01-29 00:00:00 GMT  6 days left         Mon 2018-01-22 08:59:46
> > GMT 6h ago             fstrim.timer                 fstrim.se
> > Thu 2018-02-01 00:00:00 GMT  1 weeks 2 days left Sun 2018-01-07 19:40:45
> > GMT 2 weeks 0 days ago btrfs-scrub.timer            btrfs-scr
> >
> > 7 timers listed.
> > Pass --all to see loaded but inactive timers, too.
> > lines 1-11/11 (END)
> > ```
Now, the list-timers looks like this,
```
systemctl list-timers
NEXT                         LEFT                LAST                        
PASSED             UNIT                         ACTIVATES
Mon 2018-01-22 16:14:52 GMT  3min 46s left       Mon 2018-01-22 08:59:46 GMT  
7h ago             btrfs-balance.timer          btrfs-balance.service
Mon 2018-01-22 16:14:52 GMT  3min 46s left       n/a                          
n/a                snapper-cleanup.timer        snapper-cleanup.service
Mon 2018-01-22 16:19:52 GMT  8min left           n/a                          
n/a                systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mon 2018-01-22 17:00:00 GMT  48min left          n/a                          
n/a                snapper-timeline.timer       snapper-timeline.service
Tue 2018-01-23 00:00:00 GMT  7h left             Mon 2018-01-22 08:59:46 GMT  
7h ago             logrotate.timer              logrotate.service
Mon 2018-01-29 00:00:00 GMT  6 days left         Mon 2018-01-22 08:59:46 GMT  
7h ago             fstrim.timer                 fstrim.service
Thu 2018-02-01 00:00:00 GMT  1 weeks 2 days left Sun 2018-01-07 19:40:45 GMT  
2 weeks 0 days ago btrfs-scrub.timer            btrfs-scrub.service

7 timers listed.
Pass --all to see loaded but inactive timers, too.
```
It seems that snapper-cleanup.timer, systemd-tmpfiles-clean.timer and snapper-
timeline.timer are different.

And after several minutes, `sudo journalctl -f -u btrfs-balance.service` gives
me this,
```-- Logs begin at Mon 2018-01-22 14:53:27 GMT. --
Jan 22 16:15:01 ostp.cnzhx.net btrfs-balance.sh[9598]: Done, had to relocate 0
out of 19 chunks
... (truncated similar messages)...
```

Then, `$ systemctl list-timers` shows this,
```
NEXT                         LEFT                LAST                        
PASSED             UNIT                         ACTIVATES
Mon 2018-01-22 17:00:00 GMT  40min left          n/a                          
n/a                snapper-timeline.timer       snapper-timeline.service
Tue 2018-01-23 00:00:00 GMT  7h left             Mon 2018-01-22 08:59:46 GMT  
7h ago             logrotate.timer              logrotate.service
Tue 2018-01-23 16:15:01 GMT  23h left            Mon 2018-01-22 16:15:01 GMT  
4min 52s ago       snapper-cleanup.timer        snapper-cleanup.service
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
Mon 2018-01-29 00:00:00 GMT  6 days left         Mon 2018-01-22 08:59:46 GMT  
7h ago             fstrim.timer                 fstrim.service
Thu 2018-02-01 00:00:00 GMT  1 weeks 2 days left Sun 2018-01-07 19:40:45 GMT  
2 weeks 0 days ago btrfs-scrub.timer            btrfs-scrub.service
n/a                          n/a                 Mon 2018-01-22 16:19:53 GMT  
30ms ago           systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service

7 timers listed.
Pass --all to see loaded but inactive timers, too.
```

So, `btrfs-balance` does run at 10min after boot. But I do not know what does
other information indicate. This is beyond my knowledge.

I guess, if the `btrfs-balance` does run regularly, maybe it will not take too
much long time every time. As long as users know this could happen, it won't
cause problem except for delaying the login screen sometimes. Then, a message
saying that BtrFS maintenance is running is enough. Does this deserve a bug
report?

Regards,
Haoxian


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

Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

Brüns, Stefan
In reply to this post by Thorsten Kukuk
On Monday, 22 January 2018 11:10:05 CET Thorsten Kukuk wrote:

> On Mon, Jan 22, CnZhx wrote:
> > Maybe the OS now performs maintenance at boot because even the BtrFS now
> > uses systemd-timer for scheduling actions.
>
> During the first boot with a new timer systemd finds out this timer
> did never run before and starts it immeaditly.
> If somebody knows how to tell systemd that btrfs-balance.timer should
> run once a month, but not during the first 2 hours of a reboot ...
>
>   Thorsten
I found no way to specify this directly, but what might work is using a
"blocking" target, see e.g. the time-sync.target.

For the beginning, putting "After=default.target" should mitigate the problem.
It may slow down the login, but with some luck the user already had the
display manager idle around a bit.

Regards,

Stefan

--
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
home: +49 241 53809034     mobile: +49 151 50412019

signature.asc (201 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

Andrei Borzenkov
In reply to this post by CnZhx
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.

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

Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

CnZhx
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 won't know because I have already delete that `later.conf` after the reboot
and I rarely reboot but just sleep the laptop. But I guess it's true given
that it had run after the reboot.



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

Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

CnZhx
In reply to this post by Andrei Borzenkov
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.

Ok, it's Monday. But I forgot to shutdown the laptop but just suspended it to
RAM. So it did not experience a "boot" process this morning but only a
"resume".

The "btrfs-balance" did run after the resume for about 4 minutes,
```
cnzhx@ostp:~>  systemd-analyze blame
      4min 906ms btrfs-balance.service
         23.638s fstrim.service
          1.441s logrotate.service
          1.111s tor.service
          1.072s apparmor.service
           931ms dkms.service
           898ms btrfsmaintenance-refresh.service
           884ms display-manager.service
...
```
And now, it is automatically set to run on "Thu 2018-02-01 00:00:00 GMT". I
guess it wants to run as scheduled "monthly".

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.



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

Reply | Threaded
Open this post in threaded view
|

Re: Cannot boot after upgrading to Snapshot 20180120

Achim Gratz
In reply to this post by Andrei Borzenkov
Andrei Borzenkov writes:
> 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 :)

How do I get rid of this nonsense once and for all?  Of course this
timer triggered today when I booted the machine and it stopped
responding right when I've had entered the password for the desktop
session.  There was absolutely no indication of what is going on.  I
could switch to the console, but then could not log in there either, so
of course I assumed there was something wrong entirely and rebooted
after a few minutes with absolutely no activity.  Only after the reboot
I could see in the journal log that it had started to balance and
remembered that it would do this on Mondays…


Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

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

12