Per Jessen wrote:

I have a newly installed 12.3 system. Yesterday I attached a disk-array to it, with a number of existing logical volumes. On boot-up, they weren't activated, apparently due to /etc/init.d/boot/lvm not being called. I ran 'insserv boot.lvm' which solved the problem, but I am wondering how that would/should normally be done?

Also a little odd - I have a slightly older system which also uses LVM. Here I have presumably enabled boot.lvm a while ago, but:

# find /etc/init.d -iname \*lvm\* /etc/init.d/boot.d/K05boot.lvm /etc/init.d/boot.d/S09boot.lvm /etc/init.d/boot.lvm

On my new system:

# find /etc/init.d -iname \*lvm\* /etc/init.d/boot.d/K50boot.lvm /etc/init.d/boot.d/S50boot.lvm /etc/init.d/boot.lvm

In fact, everything in boot.d has priority 50 - why is that??

That appears to be 'insserv' handing out 50 for everything. Perhaps I should have used 'systemctl enable', but shouldn't 'insserv' at least give me a warning or redirect to systemctl? -- Per Jessen, Zürich (7.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2013-10-31 at 09:53 +0100, Per Jessen wrote:

Ah, it wouldn't matter - still, priority 50 for everything seems unusual?

It is probably ignored, anyway. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJyIfEACgkQtTMYHG2NR9VicACgiIyVSzpQnp6vIQiX+jtNzc2L r6gAn3t0hySlme4zRcwNLk3bKllNKlxJ =2zjQ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Thursday, 2013-10-31 at 09:53 +0100, Per Jessen wrote:

...

Ah, it wouldn't matter - still, priority 50 for everything seems unusual?

It is probably ignored, anyway.

The priority or the service (or both) ? -- Per Jessen, Zürich (7.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

David T-G wrote:

Per --

...and then Per Jessen said... % ... % % Ah, it wouldn't matter - still, priority 50 for everything seems % unusual?

There's a lot I don't know about system startup and service management any more, but my recollection is that ordering is simply to allow something that MUST come first to be started before something else that depends on it. If there are no particular dependencies, then simple alphabetical order is fine. In fact, the '50' isn't even necessary; I suspect that it's there because 1) of habit and 2) it's middle-ish and thus allows for prioritization of an add-on that might need to come before or after.

Well, in openSUSE, sysVinit startup/shutdown priorities have been assigned for a very long time. See my first example where boot.lvm, is given 5 and 9. Handing out 50 for everything is new. -- Per Jessen, Zürich (7.7°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 10/31/2013 05:28 AM, David T-G pecked at the keyboard and wrote:

Per --

...and then Per Jessen said... % ... % % Ah, it wouldn't matter - still, priority 50 for everything seems % unusual?

There's a lot I don't know about system startup and service management any more, but my recollection is that ordering is simply to allow something that MUST come first to be started before something else that depends on it. If there are no particular dependencies, then simple alphabetical order is fine. In fact, the '50' isn't even necessary; I suspect that it's there because 1) of habit and 2) it's middle-ish and thus allows for prioritization of an add-on that might need to come before or after.

HTH & HAND

:-D

Systemd has no priorities, either a service needs to run or it doesn't. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thursday 31 October 2013, Cristian Rodríguez wrote:

El 31/10/13 05:32, Per Jessen escribió:

...

I have a newly installed 12.3 system. Yesterday I attached a disk-array to it, with a number of existing logical volumes. On boot-up, they weren't activated, apparently due to /etc/init.d/boot/lvm not being called. I ran 'insserv boot.lvm' which solved the problem, but I am wondering how that would/should normally be done?

In 13.1 this is completely different and done automatically using systemd generators and native units, if you upgrade it will no longer be there.

Yep, I noticed after upgrade to 13.1 it hang about 2 minutes before mounting /. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2013-10-31 at 10:48 +0100, Per Jessen wrote:

Carlos E. R. wrote:

...

LSB header dependency information matters. The SysV implementations on many distributions did not use the dependency information encoded in LSB init script headers, or used them only in very limited ways. Due to that they are often incorrect or incomplete. systemd however fully interprets these headers and follows them closely at runtime (and not at installation time like some implementations).

Which seems to imply that the priorities do not matter.

Right, the numbers do not matter. The LSB headers that specify dependencies are what matter, at run time. Those headers were used by sysv to create the numbers at install time. That's the difference. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJyjlYACgkQtTMYHG2NR9WcIwCeKvgeMCCoHZSi0lJtco+5C/An HqUAnifEbIwD8T/db1OWpVEyD2lsCMhZ =XLx8 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Cristian Rodríguez wrote:

El 31/10/13 05:32, Per Jessen escribió:

...

I have a newly installed 12.3 system. Yesterday I attached a disk-array to it, with a number of existing logical volumes. On boot-up, they weren't activated, apparently due to /etc/init.d/boot/lvm not being called. I ran 'insserv boot.lvm' which solved the problem, but I am wondering how that would/should normally be done?

In 13.1 this is completely different and done automatically using systemd generators and native units, if you upgrade it will no longer be there.

Okay, that's cool. We will not be upgrading to 13.1 in production for a while though. -- Per Jessen, Zürich (6.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thursday 31 October 2013, Cristian Rodríguez wrote:

El 31/10/13 13:59, Ruediger Meier escribió:

Did you found the reason why it hanged for so long but then succeeded mouting / ?

I've had a thread about this issue on factory list ("system boot hangs more than 100s"). The problem disappeared after I removed an lvm snapshot of my root partition. Of course I am not 100% sure that this snapshot caused the problem because there were also some updates in the meanwhile.

while it might take a few seconds , 2 minutes is unacceptable slow.

I'am glad that it managed to boot at all ... the first time that an upgrade worked for me since 11.4. I tried 12.1/2/3 and got always problems.

systemd-analyze blame

It hang in initrd. On 11.4 there is still a useful /var/log/boot.msg but now I don't know how to get the initrd logs. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Thursday 31 October 2013, Cristian Rodríguez wrote:

El 31/10/13 15:27, Ruediger Meier escribió:

...

It hang in initrd. On 11.4 there is still a useful /var/log/boot.msg but now I don't know how to get the initrd logs.

This information is stored in the journal..or should be. at least it does when you use dracut.

There is a problem with the initrd which is created per default by mkinitrd. I don't think I can debug THIS initrd when I create another one whith another tool. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2013-10-31 at 20:27 +0200, Ruediger Meier wrote:

It hang in initrd. On 11.4 there is still a useful /var/log/boot.msg but now I don't know how to get the initrd logs.

The information that was logged to "/var/log/boot.msg" goes now to "/var/log/messages". And, at least in 12.3, you get an "/var/log/boot.msg" written by plymouth (I don't know if always or not) - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJyvJ8ACgkQtTMYHG2NR9Xy3gCglMc5RIejyTtgSJ17nBu2OMMD RpkAni2oR+LUMCRTNfPN8Gr5OxCskw8v =Dcfd -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2013-10-31 21:57, Ruediger Meier wrote:

...

And, at least in 12.3, you get an "/var/log/boot.msg" written by plymouth (I don't know if always or not)

Isn't plymouth something for graphical boot animation? Why I should need it to debug initrd?

Because it saves that log file you want? :-) Try, in "/etc/default/grub"

GRUB_CMDLINE_LINUX_DEFAULT=" resume=/dev/disk/by-label/Swap_2 splash=verbose showopts"

or

GRUB_CMDLINE_LINUX_DEFAULT=" resume=/dev/disk/by-label/Swap showopts splash=verbose console=tty1 loglevel=3"

After which you have to regenerate grub - I forget the exact command to do so... ah, yes: grub2-mkconfig -o /boot/grub2/grub.cfg with that you get a very verbose boot, similar to what we got with systemv - however, if you are booting to level 5, it will be erased, so you need to add a 3 in there, or change the sysmlink:

/etc/systemd/system/default.target -> /usr/lib/systemd/system/runlevel3.target

-- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)

On 10/31/2013 11:06 AM, Per Jessen wrote:

Cristian Rodríguez wrote:

...

In 13.1 this is completely different and done automatically using systemd generators and native units, if you upgrade it will no longer be there.

Okay, that's cool. We will not be upgrading to 13.1 in production for a while though.

Just like I had my problem points with initrd forcing me into direct disk booting, the fact that when I tried systemd I couldn't control the boot order (strictly, it used the deps to *start* the service, but it didn't wait for any of them to finish before it started services that had those deps. So I had to come up with my own that could ensure that a dependency was there before starting a dependent. I had local mounts that were lvm based, failing due to system starting the lvm process, but not waiting -- and instead, got to either sit through long timeouts OR have it come up without /home being mounted (as well as squid's cache and such). Since networking was included in udev included in systemd, I had to write network startup scripts as well --- much faster than the originals. Had to write that and a few other things, including a 1st generation systemd-side effect correction script (which really needs a 2nd gen, but after getting things working with latest factory last spring w/o systemd, I had to take a break from the madness), a network-group priority script using the net-cgroup feature. Of course it needs to be ported to use DSCP instead of TOS/Prio... sigh... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

El 31/10/13 19:27, Per Jessen escribió:

What about systems without plymouth? (e.g. text-only). It does seem ridiculous (in the extreme) that plymouth should play a role wrt logging at all.

It does not play any role in logging, that's the role of the journal. it simply provide that file for convenient reading of the log using the plymouth-log-viewer -- "Judging by their response, the meanest thing you can do to people on the Internet is to give them really good software for free". - Anil Dash -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Linda Walsh wrote:

On 10/31/2013 11:06 AM, Per Jessen wrote:

...

Cristian Rodríguez wrote:

...

In 13.1 this is completely different and done automatically using systemd generators and native units, if you upgrade it will no longer be there.

Okay, that's cool. We will not be upgrading to 13.1 in production for a while though.

---

Just like I had my problem points with initrd forcing me into direct disk booting, the fact that when I tried systemd I couldn't control the boot order (strictly, it used the deps to *start* the service, but it didn't wait for any of them to finish before it started services that had those deps.

Isn't that pretty much what sysvinit does too?

I had local mounts that were lvm based, failing due to system starting the lvm process, but not waiting --

My issue only seems to be that boot.lvm isn't started by default, so _something_ needs to enable it when there logical volumes to be mounted. Not sure what that _something_ is, it was just a little annoying that it didn't happen automagically. -- Per Jessen, Zürich (7.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org