Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: How to boot.local on 13.1 systemd?

  1. #1

    Default How to boot.local on 13.1 systemd?

    File comment is misleading, says it executes before the 1st runlevel and it doesn't.
    It only starts once systemd has completed everything else. How does one make it run before systemd udev?
    TBH, I would just switch to sysvinit like I did on 12.2, but it doesn't seem to boot at all on 13.1.

  2. #2
    Join Date
    Sep 2012
    Posts
    7,096

    Default Re: How to boot.local on 13.1 systemd?

    It would be easier if you explained what you are trying to achieve. May be it can be done without boot.local ...

  3. #3
    Join Date
    Jul 2008
    Location
    Seattle, WA
    Posts
    17,317

    Default Re: How to boot.local on 13.1 systemd?

    On Sat, 15 Mar 2014 17:56:01 +0000, finders wrote:

    > TBH, I would just switch to sysvinit like I did on 12.2, but it doesn't
    > seem to boot at all on 13.1.


    That is because sysvinit is deprecated and no longer supported, AFAIK.

    Jim
    --
    Jim Henderson
    openSUSE Forums Administrator
    Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

  4. #4
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: How to boot.local on 13.1 systemd?

    On 2014-03-15 18:56, finders wrote:
    >
    > File comment is misleading, says it executes before the 1st runlevel and
    > it doesn't.
    > It only starts once systemd has completed everything else. How does one
    > make it run before systemd udev?


    Available files:

    Code:
    /etc/init.d/before.local:
    
    # script with local commands to be executed from init before executing
    # any script of a runlevel.
    
    /etc/init.d/after.local:
    
    # script with local commands to be executed from init after all scripts
    # of a runlevel have been executed.
    
    /etc/init.d/boot.local:
    
    # script with local commands to be executed from init on system startup
    #
    # Here you should add things, that should happen directly after booting
    # before we're going to the first run level.
    
    /etc/init.d/halt.local:
    
    # script with local commands to be executed from init on system shutdown
    #
    # Here you should add things, that should happen directly before shuting
    # down.
    If "boot.local" doesn't run at the point it says, you should report that
    as a bug in Bugzilla. They have to either modify it so that it runs when
    it says, or change the comments so that they correctly specify the point
    at which it runs.


    On the other hand, you can create your own service file so that it runs
    before udev.

    > TBH, I would just switch to sysvinit like I did on 12.2, but it doesn't
    > seem to boot at all on 13.1.


    Mo, you simply can not do that any longer. Only systemd works now,
    that's intentional.

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" at Telcontar)

  5. #5

    Default Re: How to boot.local on 13.1 systemd?

    Quote Originally Posted by robin_listas View Post
    If "boot.local" doesn't run at the point it says, you should report that
    as a bug in Bugzilla. They have to either modify it so that it runs when
    it says, or change the comments so that they correctly specify the point
    at which it runs.

    On the other hand, you can create your own service file so that it runs
    before udev.
    It runs after "boot" which unfortunately includes a systemd network service.
    In sysvinit, network service is separate from boot services, therefore, a script can run after boot, before network is up.
    Seems like this is not supported by systemd udev, which brings up the persistent network automatically, on boot.
    Even if I set the interface to disabled or manual, it still brings it up on boot. I can remove the driver, but then the user can't ifup at all.
    If I were to create a service file, how do I make sure it runs after udev brings up disk partitions but before it brings up the network?

    Quote Originally Posted by robin_listas View Post
    Mo, you simply can not do that any longer. Only systemd works now,
    that's intentional.
    I'm currently on evergreen 11.4, where it still works just fine, I will start to worry about this somewhere around june.
    Can't say I'm looking forward to that.

  6. #6
    Join Date
    Jun 2008
    Location
    Kansas City Area, Missouri, USA
    Posts
    7,236

    Default Re: How to boot.local on 13.1 systemd?

    On 03/15/2014 04:06 PM, finders wrote:
    >
    > robin_listas;2630675 Wrote:
    >>
    >> If "boot.local" doesn't run at the point it says, you should report that
    >> as a bug in Bugzilla. They have to either modify it so that it runs when
    >> it says, or change the comments so that they correctly specify the point
    >> at which it runs.
    >>
    >> On the other hand, you can create your own service file so that it runs
    >> before udev.

    >
    > It runs after "boot" which unfortunately includes a systemd network
    > service.
    > In sysvinit, network service is separate from boot services, therefore,
    > a script can run after boot, before network is up.
    > Seems like this is not supported by systemd udev, which brings up the
    > persistent network automatically, on boot.
    > Even if I set the interface to disabled or manual, it still brings it up
    > on boot. I can remove the driver, but then the user can't ifup at all.
    > If I were to create a service file, how do I make sure it runs after
    > udev brings up disk partitions but before it brings up the network?
    >
    > robin_listas;2630675 Wrote:
    >>
    >> Mo, you simply can not do that any longer. Only systemd works now,
    >> that's intentional.

    >
    > I'm currently on evergreen 11.4, where it still works just fine, I will
    > start to worry about this somewhere around june.
    > Can't say I'm looking forward to that.


    Service files for systemd are not as difficult to write as SystemV files. When
    the time comes, check out /usr/lib/systemd/system/wpa_supplicant.service for an
    example of such a file that runs before the network is started.



  7. #7
    Join Date
    Sep 2012
    Posts
    7,096

    Default Re: How to boot.local on 13.1 systemd?

    Quote Originally Posted by finders View Post
    Seems like this is not supported by systemd udev, which brings up the persistent network automatically, on boot.
    No, it does not. In 13.1 with ifup interfaces will be started by /etc/init.d/network (or after /etc/init,d/network completes). If you have evidences that it works differently - I'm interested to see them.
    Even if I set the interface to disabled or manual, it still brings it up on boot.
    It should not happen as long as I can believe the code. Of course, bugs happen, but then you need to open bug report and provide more information.

    And you still did not explain what is wrong with the way system works by default ...

  8. #8

    Default Re: How to boot.local on 13.1 systemd?

    Quote Originally Posted by arvidjaar View Post
    And you still did not explain what is wrong with the way system works by default ...
    TBH, I'd rather not go into that, but I can give you some general examples, from this one box. (Home system, not a server)
    Note that I do this because you asked me to explain, not because I want support, as I don't care much what happens to systemd, even if it does get pushed to rhel7.

    I never asked for systemd, it just showed up as a single, mandatory replacement for sysvinit, which btw, worked for me just fine, for many years.
    Aside from boot scripts failure, and core services which cannot be removed without patching systemd, there's this:
    With systemd, run_parallel=no doesn't work, hence, it overloads the physical hdd up to the point where I can hear disk heads struggling to cope with it inside the case.
    This never happens with sysvinit. Before you ask, its a mechanical wd drive and it works perfectly fine, smartd output is normal.

    Since kms in initrd, os always fails to set proper resolution, nouveau output is corrupted, even the installer fails if no kms option is not set.
    Also, since kms in initrd, I get nvidia driver warnings, which never show up on older systems like SLED and 11.4 using same vesa vga modes, regardless of driver version.

    Next, journald I don't need, but it's doing disk writes every couple of seconds anyway, used iotop to find the source of this issue (thanks)
    Simple programs like mc, old school nc clone, they depend on libssh now, as does the majority of KDE. (I use ssh on servers, never on home box, why is this?)

    Grub2, I don't need with no uefi, but still defaults. Yast2 system services clearly lacks basic features which were there in 12.2.
    Feels almost like someone was in a hurry to implement something which was not properly tested at all. Maybe it's not regression, what do I know.

    So much for my opinion on what's wrong with defaults, but who cares about one user opinion these days anyway.
    I have found a way to migrate this old box to CentOS 5.10, and still keep most functionality, so I won't have to worry about it for quite some time.

  9. #9
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: How to boot.local on 13.1 systemd?

    On 2014-03-17 09:06, finders wrote:
    >
    > arvidjaar;2630731 Wrote:
    >> And you still did not explain what is wrong with the way system works by
    >> default ...

    >
    > TBH, I'd rather not go into that, but I can give you some general
    > examples, from this one box. (Home system, not a server)
    > Note that I do this because you asked me to explain, not because I want
    > support, as I don't care much what happens to systemd, even if it does
    > get pushed to rhel7.


    But a) this is a user support forum, and b) this is an openSUSE forum
    (rhel is irrelevant here).

    So if you state your real problems, we can try help you (and gladly). We
    can do nothing about having systemd or not in openSUSE.

    If you want to rant about systemd, well, this is not the right forum.
    You have to go to the chit-chat forum instead.

    > I never asked for systemd, it just showed up as a single, mandatory
    > replacement for sysvinit, which btw, worked for me just fine, for many
    > years.


    Almost no one asked for systemd, except a large percent of the people
    that have to maintain whatever is in current use, and they make the
    decisions, not the bases. But it is here, and it is here to stay. If you
    use openSUSE, you use systemd, want it or not.

    > Aside from boot scripts failure, and core services which cannot be
    > removed without patching systemd, there's this:


    You'd have to clarify that.

    > With systemd, run_parallel=no doesn't work, hence, it overloads the
    > physical hdd up to the point where I can hear disk heads struggling to
    > cope with it inside the case.


    Yes, systemd boots everything in parallel as fast as possible. If the
    disks can not "cope", the system waits. Hard disks are designed to work,
    so they must work.

    > Since kms in initrd, os always fails to set proper resolution, nouveau
    > output is corrupted, even the installer fails if no kms option is not
    > set.


    This has nothing to do with systemd. Actually, those changes were
    implemented before systemd was available.


    > Also, since kms in initrd, I get nvidia driver warnings, which never
    > show up on older systems like SLED and 11.4 using same vesa vga modes,
    > regardless of driver version.


    Again, this has nothing to do with systemd.


    > Next, journald I don't need, but it's doing disk writes every couple of
    > seconds anyway, used iotop to find the source of this issue (thanks)


    man journald.conf:

    Code:
    Storage=
    Controls where to store journal data. One of
    "volatile", "persistent", "auto" and "none". If
    "volatile", journal log data will be stored only
    in memory, i.e. below the /run/log/journal
    hierarchy (which is created if needed). If
    "persistent", data will be stored preferably on
    disk, i.e. below the /var/log/journal hierarchy
    (which is created if needed), with a fallback to
    /run/log/journal (which is created if needed),
    during early boot and if the disk is not
    writable.  "auto" is similar to "persistent" but
    the directory /var/log/journal is not created if
    needed, so that its existence controls where log
    data goes.  "none" turns off all storage, all log
    data received will be dropped. Forwarding to
    other targets, such as the console, the kernel
    log buffer or a syslog daemon will still work
    however. Defaults to "auto".
    In openSUSE, the default settings mean that if "/var/log/journal" does
    not exist, the journal is not written to disk. No i/o.

    journald is needed to debug problems related to systemd, like why a
    service did not start. The volatile setting is good enough and default
    for most people.


    > Simple programs like mc, old school nc clone, they depend on libssh now,
    > as does the majority of KDE. (I use ssh on servers, never on home box,
    > why is this?)


    Again, this has nothing to do with systemd.

    mc uses ssh to connect to other systems, and present you a virtual
    filesystem of the other machine on one of the panes. It is a very useful
    feature. I use it often to move files to/from my laptop, ie, not a server.


    > Grub2, I don't need with no uefi, but still defaults.


    Again, this has nothing to do with systemd.

    You can use grub 1 if you like. I do.

    > Yast2 system
    > services clearly lacks basic features which were there in 12.2.


    The module had to be rewritten. And, YaST had to be migrated from the in
    house language the used to ruby, which was done precisely on 13.1. This
    means the YaST team was so busy doing the migration that no new features
    were added to YaST; on the contrary, many were removed.

    The hope is that as there are many people that know Ruby (none knew the
    language YaST used), there will be new contributors to YaST, and we will
    get new modules and additions and corrections.


    This said, there are two modules you should look at: "system services"
    and "services manager". You probably looked at "the wrong one".


    > Feels almost like someone was in a hurry to implement something which
    > was not properly tested at all. Maybe it's not regression, what do I
    > know.


    Well, you know that YOU are the QA team here, don't you? ;-)


    > I have found a way to migrate this old box to CentOS 5.10, and still
    > keep most functionality, so I won't have to worry about it for quite
    > some time.


    Well, use whatever you like and works for you :-)

    --
    Cheers / Saludos,

    Carlos E. R.
    (from 13.1 x86_64 "Bottle" at Telcontar)

  10. #10
    Join Date
    May 2012
    Location
    Finland
    Posts
    2,187

    Default Re: How to boot.local on 13.1 systemd?

    Quote Originally Posted by finders View Post
    This never happens with sysvinit. Before you ask, its a mechanical wd drive and it works perfectly fine, smartd output is normal.
    In 5 years no one is going to use mechanical drives for booting unless they have some archaic hardware - they're going the way of the dodo and it can't happen soon enough. SSDs are now way below 100€ for "large enough to use as a system drive" whilst offering superior performance, data integrity and recoverability in the case of a catastrophic hardware failure.

    Quote Originally Posted by finders View Post
    So much for my opinion on what's wrong with defaults, but who cares about one user opinion these days anyway.
    That's because much of the time users are people who don't want things to change even when they are for the better because they are so stuck in their ancient, archaic view of things and cannot see anything outside their own limited box.

    SysV has a lot of issues: yes it's simple and it works but on the other hand it has no redundancy of any kind, no monitoring or restarting of services, no dependency handling.. and most of all - it's bloody slow on a modern computer.
    .: miuku @ #opensuse @ irc.libera.chat

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •