Mailinglist Archive: opensuse-project (328 mails)

["Rob OpenSuSE" <rob.opensuse.linux@xxxxxxxxxxxxxx>]

2008/12/24 Rajko M. <rmatov101@xxxxxxxxxxx>:
> On Wednesday 24 December 2008 11:47:27 am Rob OpenSuSE wrote:
> > 2008/12/24 Rajko M. <rmatov101@xxxxxxxxxxx>:
> > > On Wednesday 24 December 2008 05:13:16 am Vincent Untz wrote:
> > > > Le mercredi 24 décembre 2008, à 01:04 +0100, Carlos E. R. a écrit :

> > Do you mean specific advice for Factory?  Because there is a Wiki page
> > on what "boot configurations" are  known to work reliably eg) small
> > ext2 in primary or logical partition.
>
> I actually meant boot configuration when it is a problem it is a big problem.
> It is like a black box. One has to know how it works and has to have bootable
> system to reach files and fix configuration. We should have boot loader tests
> done before release, that needs wide testing, hits the road. A little of
> organization among testers would be very helpful. Article on wiki will help
> to see what kind of configuration is tested, so that new guy don't test same
> thing again.

http://en.opensuse.org/Bootloader/Scenarios

> > > 2) kernel will not boot on certain hardware, how to debug this.
> > > Reporting this requires a lot of text to be copied, once you make to the
> > > usable configuration. Some simple numeric indicator like line number, or
> > > breakpoint number will help much more. It is easy to note on the paper,
> > > and easy to post. Splash screen during first phase of development that
> > > can have kernel crashes, should be forbidden.
> >
> > I like the "No Splash!" idea :)
>
> No splash is just small help to first line helpers on mail lists and forums to
> skip explanation how to remove splash, and we actually need reports from
> users that know about booting so little, but can read the screen.

Most of my kernel bug reporting, has involved booting certain way,
running commands like lspci, or smartctl, may be monitoring tools, and
copying log files, and hwinfo output.

Very basic CLI, and you need files, not copy and paste (which can
easily miss bits off), in order to attach them to the bugzilla report.

> > Often an older Live CD will boot, and
> > allow info to be collected, in a pleasant way.  Perhaps a special
> > Network Install disk, with logging set up to go to another machine
> > would help testers?
>
> Logging on another machine, floppy, USB stick, existing partition, anything
> that will survive crash.
>
> > > 3) X crashes, and nothing tells that Failsafe option offers a GUI (it
> > > should be named "Failsafe Graphic Mode")
> >
> > Please make a simple obvious way to get to text mode, it may not be
> > something you'ld market, but it'd be help a lot when sleuthing
> > troubles, on forum and such.
>
> GUI is important to majority, but it is not advertised at all that it Failsafe
> GUI exists. I found that out on bugzilla. Since then I haven't stumbled over
> any other word about it. It is the same GUI used for installation, so it will
> work.

I'm not sure what you mean, I think may be a VESA driver mode?
Perhaps you have a link that explains it?

> There is not many that can use text mode email client, or web browser, to get
> help, so anybody that tried openSUSE and couldn't get in GUI is lost for us.
> Try Google "friendly linux" and second hit is Ubuntu! Guess where those that
> are disappointed will go.

Oh the kind of kernel problem you're thinking of is worse under
Ubuntu, as without run levels, it's not non-graphical but single user
mode, and start up the networking yourself via command.

> > > 4) will not log in default desktop, or desktop crashes, but alternative
> > > to change desktop is in the login screen at the bottom left corner, but
> > > how many will click on barely visible text (kdm). This is good for
> > > release. Please make life of a tester easier, and provide list, not drop
> > > down menu,
> >
> > I filed a Bugzilla on that already (useability).
> > https://bugzilla.novell.com/show_bug.cgi?id=461690
> > If you'ld care to check it over and add any comments.
>
> That is actually how I noticed that. I use that very seldom, and it will take
> time to notice that is missing, but it should be better visible.

Heheheh, glad to know someone reads the things  :)
It must have had a good title to interest you!

> > > 6) Users need fallback options to usable alternatives, example is what
> > > Knoppix and derivatives offer on a boot screen. Press function key and
> > > get list of cheat codes, or other kernels that can be used to boot a
> > > system.  Later, when all seems to work OK, that can be removed.
> >
> > Actually yes; GREAT POINT!!!
> >
> > What is wrong with including the 11.0 kernel on the ISO disk, for the
> > installation, so that it can work, to the point where the ISO's can
> > install an updated kernel from the net.
> >
> > That would reduce the effect of kernel driver regressions.
>
> It will. Once upon a time there was more than one version. Hard disks are not
> that small, and that would be good to have even on kernel update.

Yes, actually I make sure I "rpm -i" an alternative fallback kernel on
any install I've put some effort into and plan to use, as I've been
bitten by kernel update failures too many times.

> > > Development should be focused as much as it is possible.
> > > Today we test new kernel, tomorrow X, or libc, or whatever, and so on.
> > > Having to debug interaction between change in libc and the rest of the
> > > system can mean a lot of work, but it is easier then what we have now.
> >
> > Yes, I like to have kernel, gcc or glibc change, or new application
> > software, but not two of those at same time.
> >
> > > It is nice to have many new kernel features included, but if that means
> > > broken result, what is use of those features?
> >
> > In old SuSE days, it was not unknown to ship with multiple kernel
> > versions eg) 2.0 and 2.2; or 2.2 and 2.4.0 kernel (SuSE 7.1).
> >
> > > Probably some testing of skills provided by openSUSE will help to get a
> > > picture what can be tested by community and what methods and tools have
> > > to be provided as a help. Reliance on unknown number of testers, with
> > > unknown skills will not move us from current status where number of
> > > hidden errors grows.
> >
> > openSUSE isn't responsible for testing all the packages, thoroughly.
> > Things like gcc, perl, come with a test suite, which aid packagers.
> > Really the distro needs to do configuration and integration testing.
>
> From new Linux user perspective distro is the one to blame for every
> misbehavior, and vice versa, distro get all the glory if all is fine, so
> every bug removed ahead of release makes double points.

I don't think that'll be practical.  A strategy is needed to get more
experienced ppl, to migrate and help shake down releases before they
reach the masses.  How to do it, without some promise of a "Rolling
Update", nobody likes re-installing their important machines, nor
risking Distro upgrade.

The sheer number of problem posts, in the forums Thurs, Fri and Sat
were overwhelming, pages and pages.

> > There's not much point having 100 ppl, installing X.Y into Virtual
> > Box, and all saying "yes it's fine". Perhaps online update could use
> > a stored hwinfo/smolt profile, to appeal for testers for the new
> > release in a more targetted way; rather than have it installed on
> > clone-like systems.
>
> Smolt project is the beginning.

Using it is the thing, and getting feedback out to ppl who might help,
if they knew that testing their PCI card would make a real difference.
--
To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-project+help@xxxxxxxxxxxx