FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Development

 
 
LinkBack Thread Tools
 
Old 07-23-2008, 08:00 PM
Mark Hamzy
 
Default Reipl support (David Cantrell)

On Tue, 2008-07-22 at 12:10 -1000, David Cantrell wrote:



> There's got to be a better way to do this. I mean, it's stage 2 "ipc"

> to loader so loader knows whether to send SIGUSR1 or SIGUSR2 to init

> so it can do a shutdown or reboot. All of this is automatic, but

> sloppy.

>

> Mark, can we just always reboot in linuxrc.s390 and skip the logic to

> figure out if we should reboot or shutdown? This does bring s390

> closer to behavior we see on other platforms. Reboot after

> installation. If reipl sets things up correctly, it should reboot in

> to the installed system. If, for whatever reason, it failed, we get a

> failure on boot, but the system is still shut down.



The reason why s390 does a shutdown is to stop it from looping. The 390

reader is loaded with an install image of Redhat. And the reipl information

points to that reader image. So, when a reboot is performed, it has the

effect of booting into the installer again. Which is not what we want.



What you do not see is a failure on reboot. It reboots. The system

administrator sees a linux system booting up. It is just not the correct

system.



So, what issues are we against? The error checking on writing out reipl

information? The additional "ipc" to the loader to shutdown on an error?



Mark



Common Information Model/Web-Based Enterprise Management at http://www.openpegasus.org/

Take a look at the Linux Omni Printer Driver Framework at http://omniprint.sourceforge.net/_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-23-2008, 08:25 PM
Jeremy Katz
 
Default Reipl support (David Cantrell)

(A couple of helpful hints: please fix your mail client so that replies
are properly threaded and also don't send html mail to the list)

On Wed, 2008-07-23 at 15:00 -0500, Mark Hamzy wrote:
> On Tue, 2008-07-22 at 12:10 -1000, David Cantrell wrote:
> > There's got to be a better way to do this. I mean, it's stage 2 "ipc"
> > to loader so loader knows whether to send SIGUSR1 or SIGUSR2 to init
> > so it can do a shutdown or reboot. All of this is automatic, but
> > sloppy.
> >
> > Mark, can we just always reboot in linuxrc.s390 and skip the logic to
> > figure out if we should reboot or shutdown? This does bring s390
> > closer to behavior we see on other platforms. Reboot after
> > installation. If reipl sets things up correctly, it should reboot in
> > to the installed system. If, for whatever reason, it failed, we get a
> > failure on boot, but the system is still shut down.
>
> The reason why s390 does a shutdown is to stop it from looping. The 390
> reader is loaded with an install image of Redhat. And the reipl information
> points to that reader image. So, when a reboot is performed, it has the
> effect of booting into the installer again. Which is not what we want.

And if you have a failure to install the bootloader on a lot of other
platforms, you end up booting back into the installer also. So s390
isn't special here.

> What you do not see is a failure on reboot. It reboots. The system
> administrator sees a linux system booting up. It is just not the correct
> system.

Again, this isn't different from other architectures

> So, what issues are we against? The error checking on writing out reipl
> information? The additional "ipc" to the loader to shutdown on an error?

I'm against adding architecture specific codepaths when, realistically,
there's no good reason to. This sounds like a case where the behavior
on s390 is no different from that of any other platform. And so we
should let it follow the code paths that we use everywhere else.

And then, if we're concerned about possible (uncommon) errors there,
let's add something *COMMON* to handle informing the user about the
error rather than one-offs for s390

Jeremy

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-24-2008, 01:39 PM
John Summerfield
 
Default Reipl support (David Cantrell)

Jeremy Katz wrote:



And if you have a failure to install the bootloader on a lot of other
platforms, you end up booting back into the installer also. So s390
isn't special here.


What you do not see is a failure on reboot. It reboots. The system
administrator sees a linux system booting up. It is just not the correct
system.


Again, this isn't different from other architectures


So, what issues are we against? The error checking on writing out reipl
information? The additional "ipc" to the loader to shutdown on an error?


I'm against adding architecture specific codepaths when, realistically,
there's no good reason to. This sounds like a case where the behavior
on s390 is no different from that of any other platform. And so we
should let it follow the code paths that we use everywhere else.

And then, if we're concerned about possible (uncommon) errors there,
let's add something *COMMON* to handle informing the user about the
error rather than one-offs for s390


It's becoming less a problem on intellish hardware these days, as one
can commonly interrupt the BIOS and make a one-off choice to boot
something different.


I've not seen the problem on Apples or on the Sparcs I've had my hands on.

It's a _very_ long time since I had my hands on a mainframe; those with
long memories might recall the System/370 range (I played with models
135, 145 and 168) and Facom (Fujitsu) M-series (I had my hands on a
M190, which was a little newer). On real hardware, one set a dial (or
screen selection) to the boot device, and it stayed on that selection;
under VM one might say "IPL 180."


I'm curious as to how the boot loop occurs on the modern zSeries.

fwiw I'm subscribed to the Linux-390 hosted by Marist. AFAICS people
generally don't use the vendor's install procedure very much, atm
they're discussing procedures to clone and customise systems, and some
discussion as to whether it's better done in VM or in Linux: the Linux
proponent has just said he can have a new system on the network in under
a minute.


There are people from RH (Brad Hinson) and Novell subscribed to the list
just now.





--

Cheers
John

-- spambait
1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-25-2008, 04:50 PM
Steffen Maier
 
Default Reipl support (David Cantrell)

John Summerfield wrote:
> fwiw I'm subscribed to the Linux-390 hosted by Marist. AFAICS people
> generally don't use the vendor's install procedure very much, atm
> they're discussing procedures to clone and customise systems, and some
> discussion as to whether it's better done in VM or in Linux: the Linux
> proponent has just said he can have a new system on the network in under
> a minute.

Absolutely. However, those are experienced users having a framework for
doing their Linux cloning. Think of potential new customers doing a
proof of concept or similar installing RHEL for the first time. IMHO,
chances are quite high, they use the distro installer anaconda and we
should make their life as easy as possible.

Steffen Maier

Linux on System z Development
IBM Deutschland Research & Development GmbH
Schönaicher Straße 220
D-71032 Böblingen

e-Mail: maier@de.ibm.com
Phone: +49-(0)7031-16-2354
Fax: +49-(0)7031-16-3456

Internal address: Kst. 3282, 71032-06-022

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-25-2008, 04:58 PM
Steffen Maier
 
Default Reipl support (David Cantrell)

Jeremy Katz wrote:
> On Wed, 2008-07-23 at 15:00 -0500, Mark Hamzy wrote:
>> On Tue, 2008-07-22 at 12:10 -1000, David Cantrell wrote:
>>> Mark, can we just always reboot in linuxrc.s390 and skip the logic to
> And if you have a failure to install the bootloader on a lot of other
> platforms, you end up booting back into the installer also. So s390
> isn't special here.

The reipl support is not about the installation of a bootloader. IMHO,
these are two different things. I agree that in case of failure to
install the bootloader it makes sense to boot into the installer again.
However, reipl configuration may fail due to certain versions of
hardware and software (in case of z/VM) as explained in one of my other
postings. Even in the case of failing reipl config, manual reboot by the
user still works and should be done.

Steffen Maier

Linux on System z Development
IBM Deutschland Research & Development GmbH
Schönaicher Straße 220
D-71032 Böblingen

e-Mail: maier@de.ibm.com
Phone: +49-(0)7031-16-2354
Fax: +49-(0)7031-16-3456

Internal address: Kst. 3282, 71032-06-022

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschäftsführung: Herbert Kircher
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-28-2008, 12:05 PM
John Summerfield
 
Default Reipl support (David Cantrell)

Steffen Maier wrote:

John Summerfield wrote:

fwiw I'm subscribed to the Linux-390 hosted by Marist. AFAICS people
generally don't use the vendor's install procedure very much, atm
they're discussing procedures to clone and customise systems, and some
discussion as to whether it's better done in VM or in Linux: the Linux
proponent has just said he can have a new system on the network in under
a minute.


Absolutely. However, those are experienced users having a framework for
doing their Linux cloning. Think of potential new customers doing a
proof of concept or similar installing RHEL for the first time. IMHO,
chances are quite high, they use the distro installer anaconda and we
should make their life as easy as possible.


Certainly, and part of that would be the friendly fellow from IBM
pointing out the Red Books and the Linux-390 list.


Additionally, for such folk Novell has a starter system. I expect it's
like the starter systems and such I used 20+ years ago for OS/VS VS1 (or
its successor, I recall something more complete, but forget what IBM
called it. Express something, I think). Almost anyone with VM,
OS/DOS-type experience should be able to restore to disk and IPL it.






--

Cheers
John

-- spambait
1aaaaaaa@coco.merseine.nu Z1aaaaaaa@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 01:27 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org