[sles-beta] Suggestion to speed up installs/Upgrades/patching for "future" SLE

[Darren Thompson]

Matthias

All good points and certainly for upgrades I agree with you, it's one of
the best features of SLES that the updates can (mostly) be recovered if
there are errors.

I would still say that the "New Install" workflow would benefit enormously
(much mpre than the "2-3 minutes of time" you suggest) from removing this
repeated, time consuming step.

I have not put a "stop watch" to it but I would say that between 20% and
30% of the installation time is taken with repeated dracut builds
- at-least in my test ring case. I concede that "super fast" hardware would
not be so impacted.

In any case, as a beta tester I understood my role was to "make
observations" and I still feel that this was a reasonable suggestion.

Darren


On 23 June 2014 10:36, Matthias G. Eckermann <mge at suse.com> wrote:

> Hello Darren,
>
> don't you think that we already did consider this?
>
> The problem with this approach is that it leaves the
> system in an undefinied / inconsistent state for a few
> minutes, and if it crashes then, you have a really bad
> experience.
>
> Thus we have decided to follow the save way which indeed
> needs a bit more time, but we hope that people appreciate
> consistency and stability over 2-3 minutes of time.
>
> so long -
>         MgE
>
> On 2014-06-23 T 09:29 +1000 Darren Thompson wrote:
> > Team
> >
> > Whilst watching an upgrade/install of SLE-12 I made the following
> > observation:
> > 1. dracut takes a long time to build it's images and install.
> > 2. dracut is called LOTS of times during the installation process (every
> > time a process touches a startup device etc, e.g. Kernel, multipath,
> > portland etc.
> > 3. Logically only the 'last" time it's run is it doing anything useful.
> >
> > My suggestion:
> > Analyse the installation process for modules that touch a startup device.
> > Set a "dracut needed" flag instead of actually running dracut
> > Get yast/zypper to check for the "dracut needed" flag and run it as the
> > last action during an install if set.
> >
> > I know that probably requires touching some low level install processes
> but
> > I think the speed-up produced would make that worth investigation.
> >
> > Regards
> >
> > --
> >
> > Darren Thompson
> >
> > Professional Services Engineer / Consultant
> >
> >  *[image: cid:image001.jpg at 01CB7C0C.6C6A2AE0]*
> >
> > Level 3, 60 City Road
> >
> > Southgate, VIC 3006
> >
> > Mb: 0400 640 414
> >
> > Mail: darrent at akurit.com.au <steve at akurit.com.au>
> > Web: www.akurit.com.au
>
>
>
> > _______________________________________________
> > sles-beta mailing list
> > sles-beta at lists.suse.com
> > http://lists.suse.com/mailman/listinfo/sles-beta
>
>
> --
> Matthias G. Eckermann     Senior Product Manager   SUSE® Linux Enterprise
> Phone: +49 30 44315731    Mobile: +49 179 2949448    E-Mail: mge at suse.com
> SUSE LINUX Products GmbH  Maxfeldstraße 5          90409 Nürnberg Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
>



-- 

Darren Thompson

Professional Services Engineer / Consultant

 *[image: cid:image001.jpg at 01CB7C0C.6C6A2AE0]*

Level 3, 60 City Road

Southgate, VIC 3006

Mb: 0400 640 414

Mail: darrent at akurit.com.au <steve at akurit.com.au>
Web: www.akurit.com.au
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140623/1983cc81/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 3692 bytes
Desc: not available
URL: <http://lists.suse.com/mailman/private/sles-beta/attachments/20140623/1983cc81/attachment.jpg>