[opensuse] starting lvm at boot-up ?
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?? -- Per Jessen, Zürich (7.4°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
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
Per Jessen wrote:
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?
Ah, it wouldn't matter - still, priority 50 for everything seems unusual? -- 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
-----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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2013-10-31 at 10:31 +0100, Per Jessen wrote:
Carlos E. R. wrote:
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) ?
The priority. Systemd native services have no numbers, where to start a service in relation to other is determined, I think, dynamically based on the service file definitions. Old systemv services have no corresponding systemd file, unless it is autocreated by systemd. The numbers in it have no meaning for systemd, as there are no numbers for the rest of services to compare with. So, either prioriy is determined correctly by systemd somehow, or they are started somewhere in the middle. I guess the former. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJyJSQACgkQtTMYHG2NR9XM/QCeInfrMWXGqlDhcUpz5UIpziIQ 7kQAnRf8NFo9954GeFtugsoLYwP75wnq =yrZs -----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:
On Thursday, 2013-10-31 at 10:31 +0100, Per Jessen wrote:
Carlos E. R. wrote:
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) ?
The priority. Systemd native services have no numbers, where to start a service in relation to other is determined, I think, dynamically based on the service file definitions.
Old systemv services have no corresponding systemd file, unless it is autocreated by systemd. The numbers in it have no meaning for systemd, as there are no numbers for the rest of services to compare with.
So, either prioriy is determined correctly by systemd somehow, or they are started somewhere in the middle. I guess the former.
Hmm, that sounds somewhat plausible. I found this: http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
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. -- 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
-----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
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 -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2013-10-31 at 11:55 -0400, Ken Schneider - openSUSE wrote:
Systemd has no priorities, either a service needs to run or it doesn't.
There has to be priorities. You can not run nfs till network is up. Just that they name it differently. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJyja0ACgkQtTMYHG2NR9W/mQCfQ7zpC3iSuq0YemZ/U90QMWHc 7XYAni3QzbkqWQLJmgdtLUv6usm9QEuK =rXWC -----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:
On Thursday, 2013-10-31 at 11:55 -0400, Ken Schneider - openSUSE wrote:
Systemd has no priorities, either a service needs to run or it doesn't.
There has to be priorities. You can not run nfs till network is up. Just that they name it differently.
Well, priorities <> dependencies. It's not just about naming. -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2013-10-31 at 19:07 +0100, Per Jessen wrote:
There has to be priorities. You can not run nfs till network is up. Just that they name it differently.
Well, priorities <> dependencies. It's not just about naming.
The dependencies are used to calculate the priorities, which are not written anywhere. You can read the list of services as the start gets logged, and assign mentaly the priorities: 1, 2, 3... - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlJyu88ACgkQtTMYHG2NR9VlswCfc38r7P2DJ8SBDWGou78UfdOy GvkAniKg3TQ7d+RhZA5apyNr4YphVXsK =YcAn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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. -- "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
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
El 31/10/13 13:59, Ruediger Meier escribió: Did you found the reason why it hanged for so long but then succeeded mouting / ? while it might take a few seconds , 2 minutes is unacceptable slow. systemd-analyze blame -- "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
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
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. -- "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
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
On 10/31/2013 12:11 PM, Ruediger Meier wrote:
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.
Not being able to debug initrd was the main reason I stopped trying to use it and simply booted from hard disk. -- 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 Thursday 31 October 2013, Carlos E. R. wrote:
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".
Looks like this is only true for the kernel 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)
Isn't plymouth something for graphical boot animation? Why I should need it to debug initrd? cu, Rudi -- 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)
Carlos E. R. wrote:
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? :-)
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. -- Per Jessen, Zürich (5.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
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
On Thursday 31 October 2013, Cristian Rodríguez wrote:
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
So how can I use the journal? I tried journalctl --boot -2 but it does not look like there are any messages from initrd. I know that there must be lines like "Waiting for device /dev/system/root to appear:" I don't see more lines than I have in /var/log/messages BTW journalctl is terrible slow. For example journalctl --full would take a few hours (or days) I guess. cu, Rudi -- 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 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
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
On Friday 01 November 2013, Per Jessen wrote:
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?
You can set /etc/sysconfig/boot # Run all scripts or rather start/stop all services # which are independent from each other in parallel. # RUN_PARALLEL="no" which makes life much easier. You don't need to think about all deps exactly and the system always starts in a deterministic way. Also AFAIR the logging was often broken if you used startpar.
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
participants (7)
-
Carlos E. R. -
Cristian Rodríguez -
David T-G -
Ken Schneider - openSUSE -
Linda Walsh -
Per Jessen -
Ruediger Meier