Mailinglist Archive: opensuse-factory (505 mails)

[Rob OpenSuSE <rob.opensuse.linux@xxxxxxxxx>]

On 1 July 2011 02:06, Brian K. White <brian@xxxxxxxxx> wrote:
> On 6/30/2011 6:56 PM, Adam Tauno Williams wrote:
> > On Thu, 2011-06-30 at 18:34 -0400, Brian K. White wrote:
> > > As one who has to maintain a bunch of boxes and has to spend a lot of
> > > time devising atomated procedures and training non-admins who never the
> > > less have to do adminly stuff because I cannot always be available,
> > > every backwards incompatible change, every change in default behavior,
> > > every thing that breaks because of little or no testing prior to making
> > > it part of the official system costs me lots of time I and my employer
> > > and my customers would rather I be spending doing other new stuff rather
> > > than just playing keep-up-with-suse just to maintain what I already had.

> How does turning off updates on a given box or all boxes adress anything I
> said? Updates do not cause os version upgrades, and nothing changes too
> radically within a given version for the life of that version.
>
> For example how does turning off updates address the fact that on a given
> piece of hardware, it was possible to install 10.3 successfully using only
> the normal installer onto a fully software raid setup, and have it create a
> working grub that actually booted and worked, yet on later versions the
> exact same setup on the exact same hardware didn't work and the only way to
> get the box running was to jump to another vc or ssh session and manually
> edit grub files and/or manually create the mdadm arrays before that.
>
> How does turning off updates address the fact that the repair-system and
> boot-installed-system options disappeared from the installer?
>
> Hey I know those are hard things to do. What's damning is that openSUSE used
> to do them and now doesn't, or tries but now fails a lot more often. Things
> like that were part of what made SUSE stand out in the first place.
>
> Then there is the long standing difficulty of using a serial console.
> Several hard coded assumptions in openSUSE are broken for a serial console
> but whatever who uses those? So on all my boxes I have to be careful to
> uninstall and taboo all the gfxboot and splashy stuff before allowing it to
> boot the first time.

> vga=normal which I already had was being ignored and after some googling I
> find out about the new nomodeset or i915.modeset=0
> This is new, active behavior that's on-by-default and broke a box that
> worked fine on the previous version.

So I start off having sympathy with what you said.  But may be you
ought to consider, things you can do to minimise the issues, apart
from the obvious switching to SLED/SLES for longer term support.  But
10.3 was horrible release for me initially, I had huge number of
problems to sort and it was months before it became stable & super
solid.  My honest impression is 12.1 M2 is far more solid & useable
than any of the GM releases I've tried; I think things really are
getting better & more mature.

Requiring redundant features to be on install DVD, when you can use a
System Rescue, or build your own Live CD/DVD is not rational.

Suggestions

* Don't track the latest release on production systems, until they're
solid for you.  11.3 works well, actually 11.1 & 11.2 plus Evergreen
do to
* Use Auto Yast to get rid of the boot gimmicks.  Even lilo is still
there and useable.
* Use Kiwi or SuSE Studio to allow test of hardware with Live DVD
before upgrades, similarly repair of systems
* Actually read the Release Notes, things like nomodeset=0 are well explained
* Software RAID is easy enough to configure, post install, if you plan
for it.  Given all the testing required to proof against single disk
or controller failure, a pro sysadmin ought to cope with building
software RAID themselves, it allows installing into a degenerate
mirror for example
* Don't work on Live Production machines, roll out a new server, then
upgrade the old one after the new is "signed off"

The possibilities for well tested transitions have never been better.
Plan for them by dual booting and try out "zypper dup", with a
suitably configured proxy as an installation & update cache it should
fly.

If you don't want improvements, or problems of early adoption use an
old supported release on production and pay for it!
If you use a community release in production, it's wise to test things
like milestones, so you can point out overlooked downsides in new
features and hopefully influence developers before it's too late
(adding /usr "hooks" into udev for example).

If there weren't changes, then there'd not be a need for skilled
sysadmins, so it's in our interest to embrace and enthuse about them!

Regards Rob
-- 
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx