Didn't thought about that!
Thanks again.
Roberto.
El dom., 25 de ago. de 2019 a la(s) 11:49, Mark Post (mp...@suse.com)
escribió:
> On 8/25/19 2:04 AM, Roberto Ibarra Magdaleno wrote:
> > To bad that this shop doesn't have SUSE.
>
> Go to https://scc.suse.com/ and create a no-cost account. Then
On 8/25/19 2:04 AM, Roberto Ibarra Magdaleno wrote:
> To bad that this shop doesn't have SUSE.
Go to https://scc.suse.com/ and create a no-cost account. Then go to
https://download.suse.com/Download?buildid=xbuTZMVIYxE~ and sign in with
that account to download SLES15 SP1 for Z. Use the rescue
Hello Mark,
Thanks a lot, you have been a great help. I did took out the cio_ignore
parameter but the rescue system, strictly speaking, never jumped out. About
the !, as I told you it didn't work, but funny that in the zipl.conf file
it do was an ! an it has no problem!
To bad that this shop
009
crashkernel=auto"
15. Exited the chgroot shell.
[anaconda root@linux8 sbin]# exit
exit
16. Mounted de boot DASD.
[anaconda root@linux8 root]# mkdir /boot
[anaconda root@linux8 root]# mount -t ext4 /dev/dasdb1 /boot
17. Ran the zipl with config. file parameter.
[anaconda ro
On 8/21/19 6:50 PM, Roberto Ibarra Magdaleno wrote:
> Hello Mark,
>
-snip-
> I’m not familiar with RH configuration files either, sincerely? I prefer
> SUSE =]
In that case, IPL a SUSE installation kernel and initrd and use the
rescue system from there. Or, if you have a currently running SUSE
Hi Roberto,
On 8/22/19 12:34 AM, Roberto Ibarra Magdaleno wrote:
Tried this configuration:
root=/dev/ram0 ro ip=off ramdisk_size=4
rescue
and still booting installer, not a rescue system:
Starting sshd to allow login over the
network.
Connect now to 172.27.20.19 and log in as user
Hello Mark,
> I'm hoping that right bracket is a typo, since it should be an
>exclamation point.
That “]” is what the system translated when I transferred de .RPM file from
the ISO. Changed to “!” and the VM didn’t IPLed the installer (from the
reader with the rescue.exec).
>As Steffen
Hello Steffen,
Tried this configuration:
root=/dev/ram0 ro ip=off ramdisk_size=4
rescue
and still booting installer, not a rescue system:
…
Starting sshd to allow login over the
network.
Connect now to 172.27.20.19 and log in as user install to start the
installation
.
E.g. using: ssh
On 8/20/19 7:20 PM, Roberto Ibarra Magdaleno wrote:
> Hello everyone again, Mark,
>
>
> I tried to IPL in rescue mode by doing these 2 configuration files:
>
> RESCUE PRM A1
>
> root=/dev/ram0 ro ip=off ramdisk_size=4 cio_ignore=all,]0.0.0009
I'm hoping that right bracket is a
Hi Roberto,
On 8/21/19 1:20 AM, Roberto Ibarra Magdaleno wrote:
I tried to IPL in rescue mode by doing these 2 configuration files:
RESCUE PRM A1
root=/dev/ram0 ro ip=off ramdisk_size=4 cio_ignore=all,]0.0.0009
inst.rescue
This looks like upstream (and RHEL7 or RHEL8) syntax
.
Roberto.
El vie., 16 de ago. de 2019 a la(s) 14:38, Roberto Ibarra Magdaleno (
roberto.ibar...@gmail.com) escribió:
> Hello Mark,
>
> Tried adding the DASDs in the IPL command, same result:
>
> *CP I 200 PARM RD_DASD=0.0.0205
> RD_DASD=0.0.0206 *
Hello Mark,
Tried adding the DASDs in the IPL command, same result:
*CP I 200 PARM RD_DASD=0.0.0205
RD_DASD=0.0.0206 *
zIPL v1.8.2-28.el6 interactive boot
menu
0. default
(linux)
1.
linux
Note: VM users please use 'Ñcp vi vmsg
'
Please choose (default
Roberto:
There are two things you can try:
The right way is to boot the system off CD, mount all the devices, do a chroot
to your disks, fix /etc/zipl.conf, do "mkinitrd ; zipl", and then shut
everything down. Suse describes it in detail at
https://www.suse.com/support/kb/doc/?
Yes, but it doesn’t help when you don’t have another user ID at your
disposal or don’t have the privileges.
(In 2019, one should remove SET SECUSER and SET OBSERVER from class G to
prevent a user from giving his or her console to another ID.)
Regards,
Alan Altmark
IBM
> On Aug 16, 2019, at
True, but I left it so the user could specify VMSG or PVMSG. I also missed the
SEND CP rather than just SEND in the 1st instance.
On 8/16/19, 13:27, "Linux on 390 Port on behalf of Michael Harding"
wrote:
A little more complicated...
I think you want 'VINPUT VMSG'
Then, if your
ARIST.EDU
> Date: 08/16/2019 09:57 AM
> Subject: [EXTERNAL] Re: Defined minidisks RHEL 6.0 on z/VM to grow /
> FS, forgot to Persistently Setting DASDs Online with /etc/zipl.conf and
zipl.
> Sent by: Linux on 390 Port
>
> In the interim a simple REXX program? (Assuming you hav
Correction:
/* */
parse arg Target Command
upper Target
CPRc = DIAGRC(8,'SEND CP' Target 'VINPUT' Command)
parse var CPRC Rc Message
if (Rc <> 0) then
say Message
exit Rc
--
For LINUX-390 subscribe / signoff / archive
On 8/16/19 9:32 AM, Dan Horák wrote:
> I think the kernel cmdline parameters are case sensitive, so using
> something like
> #cp vi vmsg 1 rd_DASD=210 rd_DASD=211
> on the console to manually select the boot entry might fix the problem
It's might easier and less guess-intensive if you put that
In the interim a simple REXX program? (Assuming you have a SECUSER or a
privileged user)
/* */
parse arg Target Command
upper Target
CPRc = DIAGRC(8,'SEND' Target 'VINPUT' Command)
parse var CPRC Rc Message
if (Rc <> 0) then
say Message
exit Rc
On 8/16/19, 12:47, "Linux on 390 Port on
Alan wrote:
>I've been thinking for some time that we might want to consider revisiting
>that for the VINPUT command. It's a command specifically designed to
>deliver data to a guest, not CP and not someone else's console. As such,
>it should be left to the guest to do the translation if it
On Friday, 08/16/2019 at 01:55 GMT, "Dan Horák" wrote:
> On Fri, 16 Aug 2019 08:38:20 -0500
> Roberto Ibarra Magdaleno wrote:
>
> > Hi Dan,
> >
> > Tried that mixed case from the VM session console but it convert it to
> > upper case.
> > Suggestion?
>
> hm, maybe the upper-casing is a feature
arra Magdaleno wrote:
> >
> > > Hello all,
> > >
> > > I defined 2 new z/VM 6.2.0 minidisks for a RHEL 6.0 VM to grow /
> > > FS, everything went right except I forgot to Persistently Setting
> > > DASDs Online with /etc/zipl.conf and zipl. Got "Ref
I defined 2 new z/VM 6.2.0 minidisks for a RHEL 6.0 VM to grow / FS,
> > everything went right except I forgot to Persistently Setting DASDs
> > Online with /etc/zipl.conf and zipl. Got "Refusing activation of
> > partial LV lv_root. Use --partial to override." in next IPL.
On Thu, 15 Aug 2019 20:48:17 -0500
Roberto Ibarra Magdaleno wrote:
> Hello all,
>
> I defined 2 new z/VM 6.2.0 minidisks for a RHEL 6.0 VM to grow / FS,
> everything went right except I forgot to Persistently Setting DASDs
> Online with /etc/zipl.conf and zipl. Got "
21:48
To: LINUX-390@VM.MARIST.EDU
Subject: Defined minidisks RHEL 6.0 on z/VM to grow / FS, forgot to
Persistently Setting DASDs Online with /etc/zipl.conf and zipl.
Hello all,
I defined 2 new z/VM 6.2.0 minidisks for a RHEL 6.0 VM to grow / FS, everything
went right except I forgot
Hello all,
I defined 2 new z/VM 6.2.0 minidisks for a RHEL 6.0 VM to grow / FS,
everything went right except I forgot to Persistently Setting DASDs Online
with /etc/zipl.conf and zipl. Got "Refusing activation of partial LV
lv_root. Use --partial to override." in next IPL. Since
On 05/01/2017 10:20 PM, Marcy Cortes wrote:
Is my dump volume made with zipl -d on SLES 11 SP4 still good for SLES 12 SP2?
Would be nice not to have 2 of them.
There might be some differences regarding SMT (and maybe also SIMD)
support but I'm not sure that's really all to take into account
>>> On 5/1/2017 at 04:20 PM, Marcy Cortes <marcy.d.cor...@wellsfargo.com>
>>> wrote:
> Is my dump volume made with zipl -d on SLES 11 SP4 still good for SLES 12
> SP2?
> Would be nice not to have 2 of them.
I don't really know. I suspect that what's on t
Is my dump volume made with zipl -d on SLES 11 SP4 still good for SLES 12 SP2?
Would be nice not to have 2 of them.
Marcy
This message may contain confidential and/or privileged information. If you are
not the addressee or authorized to receive this for the addressee, you must not
use, copy
On Wed, 15 Aug 2012 12:09:24 -0400 (EDT), Mark Post wrote:
On 8/14/2012 at 10:22 PM, Stephen Powell zlinux...@wowway.com wrote:
But getting to the root of the problem, whenever you delete
a DASD device you need to re-build your initial RAM file system,
then run zipl. Running zipl, by itself
(mounted on / as ext3)
Kernel Modules: jbd mbcache ext3 scsi_mod scsi_dh scsi_dh_alua scsi_dh_hp_sw
scsi_dh_emc scsi_dh_rdac dasd_mod dasd_eckd_mod crc-t10
dif sd_mod
Features: block dasd
24950 blocks
lnx050:/etc # zipl
Using config file '/etc/zipl.conf'
Building bootmap in '/boot/zipl
On 8/16/2012 at 02:20 PM, Dean, David (I/S) david_d...@bcbst.com wrote:
At this point is really just academic because I can make it work, BUT here is
the data from my experiment.
Removed parameters= line totally, then:
I don't think anyone ever recommended that step.
-snip-
Keep
Mark, here you go.
Original zipl.conf
[ipl]
image = /boot/image
target = /boot/zipl
ramdisk = /boot/initrd,0x400
parameters = root=/dev/dasda1 dasd=202,700-730 TERM=dumb
run zipl
Server comes up fine.
Now:
CHANGE zipl.conf to remove parameter root=/dev/dasda1 and run zipl
Mark, you are correct. I was running only zipl and NOT mkinitrd. As always,
thanks.
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Mark Post
Sent: Tuesday, August 14, 2012 4:28 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: zipl
On 8/14/2012
I think you were supposed to remove the dasd= - not the root=
Scott Rohling
On Wed, Aug 15, 2012 at 7:16 AM, Dean, David (I/S) david_d...@bcbst.comwrote:
Mark, here you go.
Original zipl.conf
[ipl]
image = /boot/image
target = /boot/zipl
ramdisk = /boot/initrd,0x400
On 8/14/2012 at 10:22 PM, Stephen Powell zlinux...@wowway.com wrote:
But getting to the root of the problem, whenever you delete
a DASD device you need to re-build your initial RAM file system,
then run zipl. Running zipl, by itself, is not enough. The
list of DASD devices to be brought
We have gotten in to trouble twice now with zipl.conf. We are on 10.3,
upgrading to 10.4 then to 11.2. We have removed DASD in the past - USER
DIRECTORY - and when we boot again without running zipl we get problems with it
trying to load the old DASD def. I do not have, I recently discovered
On 8/14/2012 at 03:59 PM, Dean, David (I/S) david_d...@bcbst.com wrote:
We have gotten in to trouble twice now with zipl.conf. We are on 10.3,
upgrading to 10.4 then to 11.2. We have removed DASD in the past - USER
DIRECTORY - and when we boot again without running zipl we get problems
On Tue, 14 Aug 2012 15:59:19 -0400 (EDT), David Dean wrote:
We have gotten in to trouble twice now with zipl.conf.
We are on 10.3, upgrading to 10.4 then to 11.2.
We have removed DASD in the past - USER DIRECTORY -
and when we boot again without running zipl we get problems
with it trying
On Jan 25, 2012, at 8:41 AM, Alan Altmark wrote:
On Tuesday, 01/24/2012 at 03:07 EST, James Vincent
jamesscottvinc...@gmail.com wrote:
We have dump devices set up with the zIPL tool from the s390utils
package
(the 1.8.2 level). The tool has worked great but we have noticed
something
. So for the case that you have a
large standby area after the last online chunk (as in your example) that
would make the dump much smaller.
It is possible to tell the dumper to only dump nn MB by specifiying this
when zipl is called (e.g. zipl -d /dev/dasdxy1,nnM). But this probably
is no option
On Tuesday, 01/24/2012 at 03:07 EST, James Vincent
jamesscottvinc...@gmail.com wrote:
We have dump devices set up with the zIPL tool from the s390utils
package
(the 1.8.2 level). The tool has worked great but we have noticed
something
interesting. We are setting up our linux guests
Am I reading that right? Only for DASD disk devices?Does this
mean that I have no alternative and no means to build a boot menu?
Unfortunately this seems to be a feature of the scsi load mechanism. The
boot configuration sections are still there, but it never puts up an actual
menu to
or reach
single user mode, but this might be a problem in the future.
I see in the doc from a 'man zipl.conf' command this:
Boot menu
The zipl tool provides a boot menu function which enables users
to choose a boot con-
figuration and to modify the kernel command line parameters at
IPL
Tim,
A menu doesn't appear, but to select the various stanza in /etc/zipl.conf,
before you IPL, use the following to Specify the SCSI boot disk’s target
port and LUN and which zipl boot configuration is to be used in the CMS
LOADDEV environment variable. Omitting the BOOTPROG parameter
, 2010 12:39 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: zipl, bootmenu and FCP devices
Tim,
A menu doesn't appear, but to select the various stanza in /etc/zipl.conf,
before you IPL, use the following to Specify the SCSI boot disk’s target
port and LUN and which zipl boot configuration is to be used
Mark Post wrote:
I'm not sure how to react to Peter's email. If zipl hasn't been updated to
deal with MPIO, then I don't understand how the IPL through IFCC feature is
supposed to work.
IPL through IFCC refers to a minor improvement in the way IFCCs are
handled during the very early stage
Romanowski, John (OFT) wrote:
But on sles 11 zipl will accept multipath LUN and reports
Target device information
Device..: fd:0a
Device name.: dm-10
Device driver name..: device-mapper
Type: disk device
As a concession to the recession we've crowd-sourced support.
-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
Mark Post
Sent: Thursday, May 28, 2009 2:50 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: sles11 zipl multipath /boot problem
, but it would be
nice to know what happens in real life.
I'm not sure how to react to Peter's email. If zipl hasn't been updated to
deal with MPIO, then I don't understand how the IPL through IFCC feature is
supposed to work.
Mark Post
-...@vm.marist.edu] On Behalf Of
Mark Post
Sent: Friday, May 29, 2009 12:15 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: sles11 zipl multipath /boot problem
On 5/28/2009 at 3:39 PM, Romanowski, John (OFT)
john.romanow...@cio.ny.gov
wrote:
As a concession to the recession we've crowd
Linux
Enterprise Server 11. (Which I think means zipl can now write the scsi
bootloader to a multipath LUN.)
unluckily, it's a long time ago i played around with scsi/fcp on z Series - but
if i remember correctly,
there it is no possibility to use zipl on a multipath device (i.e.
/dev/mpath0
Hi Marc,
My experiences and workaround on sles 9 and 10 agrees with yours; zipl-ing a
multipath LUN on sles 10 rejects it with message
Error: Unsupported device driver 'device-mapper'
But on sles 11 zipl will accept multipath LUN and reports
Target device information
Device
in SUSE Linux
Enterprise Server 11. (Which I think means zipl can now write the scsi
bootloader to a multipath LUN.)
The release notes for SLES11 doesn't mention zipl specifically, but section
3.9 System z lists under Hardware: Multipath IPL (IPL through IFCC)
That means if Linux receives
On 5/28/2009 at 10:37 AM, Romanowski, John (OFT)
john.romanow...@cio.ny.gov
wrote:
Hi Marc,
My experiences and workaround on sles 9 and 10 agrees with yours; zipl-ing a
multipath LUN on sles 10 rejects it with message
Error: Unsupported device driver 'device-mapper'
But on sles 11
sles 11 Storage Guide steps to turn on multipathing say just run mkinitrd and
reboot, no mention of zipl.
I thought that a typo but
man mkinitrd describes a -B option to suppress it running update-bootloader
and after running mkinitrd the /boot/zipl/bootmap file has the same timestamp
multipath-tools makes device-mapper devices.
My multipath /boot partition is device 253:10 or fd:0a as reported by zipl
multipathd is running, boot.multipath runs during boot.
per the Storage Guide, for multipathing I changed zipl.conf from disk/by-path
to disk/by-id.
zipl.conf
On 5/28/2009 at 12:34 PM, Romanowski, John (OFT)
john.romanow...@cio.ny.gov
wrote:
sles 11 Storage Guide steps to turn on multipathing say just run mkinitrd and
reboot, no mention of zipl.
I thought that a typo but
man mkinitrd describes a -B option to suppress it running update
On 5/28/2009 at 1:12 PM, Romanowski, John (OFT)
john.romanow...@cio.ny.gov
wrote:
multipath-tools makes device-mapper devices.
My multipath /boot partition is device 253:10 or fd:0a as reported by zipl
multipathd is running, boot.multipath runs during boot.
We typically recommend
On a z10 I have a sles 11 with multipath /boot LUN and a separate multipath /
LUN
sles 11 Storage Guide says sles 11 supports a multipath /boot:
DM-MP is now available and supported for /boot and /root in SUSE Linux
Enterprise Server 11. (Which I think means zipl can now write the scsi
Hello people ...
Here I bring another concern, which I imagine you have crossed it.
After performing the cloning of linux and minidisks (rw and ro) and the
links to the gold disc from the machine ... gives the following error
Mounting root /dev/dasdb1
dasd_erp(3990): 0.0.01b1: EXAMINE 24:
390 Port cc
linux-...@vm.mar
IST.EDU Subject
error zipl linux clone
[mailto:linux-...@vm.marist.edu] On Behalf Of
Richard Troth
Sent: Monday, February 23, 2009 9:23 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Why does one need to mkinitrd/zipl ? (WAS :
Broken logical volume group)
Ken --
In the thread, we may have not specifically mentioned that list
@VM.MARIST.EDU
Subject: Re: [LINUX-390] Why does one need to mkinitrd/zipl ? (WAS :
Broken logical volume group)
Richard Troth wrote:
Ivan ... hear this:
With SLES10, unless you are changing something about the root FS, you
do not need to re-stamp your INITRD. It is exactly as you say it
should
@VM.MARIST.EDU
Subject: Re: [LINUX-390] Why does one need to mkinitrd/zipl ? (WAS :
Broken logical volume group)
Richard Troth wrote:
Ivan ... hear this:
With SLES10, unless you are changing something about the root FS, you
do not need to re-stamp your INITRD. It is exactly as you say it
should
to be on a particular address is the one you boot
from.
-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
Scott Rohling
Sent: Monday, February 23, 2009 9:31 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Why does one need to mkinitrd/zipl
on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
Scott Rohling
Sent: Monday, February 23, 2009 9:31 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Why does one need to mkinitrd/zipl ? (WAS :
Broken logical volume group)
Good point.. I've always advised giving ranges
.
-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
Scott Rohling
Sent: Monday, February 23, 2009 9:31 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Why does one need to mkinitrd/zipl ? (WAS :
Broken logical volume group)
Good point.. I've
, 2009 9:37 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: [LINUX-390] Why does one need to mkinitrd/zipl ? (WAS :
Broken logical volume group)
Richard Troth wrote:
Ivan ... hear this:
With SLES10, unless you are changing something about the root FS, you
do not need to re-stamp your INITRD
On Wed, 18 Feb 2009 21:03:59 +0100,
Ivan Warren i...@vmfacility.fr wrote:
- IPL time ensuing from having many thousand devices (Lordy.. Issuing
Sense-ID, RDC and read of cyl 0 track 1 - on 1 devices shouldn't
take but a couple seconds anyway.. What's wrong here.. all modern OSes
do
On Thu, Feb 19, 2009 at 4:36 AM, Ivan Warren i...@vmfacility.fr wrote:
Now about Diag 250.. What's the gain ?
performance ? let's face it.. CP has become very efficient at
translating VM issued CCWs to real CCWs over the past 40 years or so..
When dealing with a 1.2 Mips 4341 Model 2, CP
Adam Thornton wrote:
Now, it *is* nice if it works under Hercules because that opens up the
development community to an order of magnitude more people. This is
the cause of my apparent schizophrenia whereby I'm strongly suggesting
that it would be neat if Hercules learned to do the (now fully
Rob van der Heij wrote:
One of the neat things about Diag250 is that it supports a fast-path
when the data is in MDC (the I/O complete is returned immediately,
skipping the entire process of reflecting an interrupt later). Linux
supports that in that you also get a quick route back there. I've
On Thu, Feb 19, 2009 at 11:47 AM, Ivan Warren i...@vmfacility.fr wrote:
Rob van der Heij wrote:
One of the neat things about Diag250 is that it supports a fast-path
when the data is in MDC (the I/O complete is returned immediately,
skipping the entire process of reflecting an interrupt
to the VG. In that case, you're dead meat if you didn't
re-run mkinitrd and zipl.
That's what I'm saying !
mkinitrd/zipl shouldn't be needed *UNLESS* you are changing something
about the root fs !
Granted.. adding a PV to the VG in which the root fs LV resides also
qualifies as a root fs
Richard Troth wrote:
Ivan ... hear this:
With SLES10, unless you are changing something about the root FS, you
do not need to re-stamp your INITRD. It is exactly as you say it
should be.
-- R;
That's good enough for me ;)
At least the idea that I would have gave me fodder for a tantrum
Mark Post wrote:
You need to chroot to /mnt/sysimage before running the mkinitrd.
Sorry to hop on route.. but..
I was wondering...
Why on earth does one need to mkinitrd/zipl after adding a DASD volume
to z/Linux ?
Most (if not all) 'distributed' platforms are perfectly happy to add
On 2/18/2009 at 1:58 PM, Ivan Warren i...@vmfacility.fr wrote:
-snip-
I was wondering...
Why on earth does one need to mkinitrd/zipl after adding a DASD volume
to z/Linux ?
Basically, some historical, performance, and data integrity reasons.
When the DASD driver initializes, particularly
I find that with SLES10, you do NOT have to mkinitrd and zipl. It
will happily find the additional DASD and bring them online without
needing special intelligence in the INITRD.
The whole INITRD thing ... I will hold my peace for the moment.
Now if you added a different KIND of DASD (if you
the initrd
seems to me like a unnecessary and superfluous step.
What I am saying, is that, eventually, you're going to wind up with
people running zipl/mkinitrd no matter what.. but there is *some*
(minor) danger to this ! (actually, of course, it's going to be
mkinitrd/zipl - in that order
Richard Troth wrote:
The whole INITRD thing ... I will hold my peace for the moment.
I'm with you here..
I mean..
On 'distributed' platforms you may have.. what.. 200.. 300 different
drivers..
On z.. you have what ... 15 ?
A monolithic kernel would make all the sense in the world..
if the fs is designed to be RO.. through the directory or maybe
a
CMS profile..).. and modifying the fstab.. Having to alter the initrd
seems to me like a unnecessary and superfluous step.
What I am saying, is that, eventually, you're going to wind up with
people running zipl/mkinitrd no matter what
the kernel to ignore ranges of device
numbers. That value gets stored in the boot parms, which are written out by
zipl. (There's no equivalent to grub that will read a parm file at boot
time.) So, if your I/O config changes, you still need to re-run zipl.
Time to produce a SALIPL or DCSS
On 2/18/2009 at 2:15 PM, Richard Troth vmcow...@gmail.com wrote:
I find that with SLES10, you do NOT have to mkinitrd and zipl. It
will happily find the additional DASD and bring them online without
needing special intelligence in the INITRD.
That's going to depend on just how the DASD
where / is an LV and you added a new
volume to the VG. In that case, you're dead meat if you didn't re-run mkinitrd
and zipl.
That's what I'm saying !
mkinitrd/zipl shouldn't be needed *UNLESS* you are changing something
about the root fs !
Granted.. adding a PV to the VG in which the root fs
On 2/18/2009 at 3:03 PM, Ivan Warren i...@vmfacility.fr wrote:
Why doesn't mkinitrd *ONLY* take care of the IPL
volume (or volumes in you're LVM).. - as the initrd was designed - then
- depending on what config is on the root fs, enable this or that volume
- once control has been passed
it. If you do it manually, you better know what you're
doing, either in the setup, or the recovery effort. :)
Wait !
I'm not denying that actually going through a mkinitrd/zipl cycle is a
bad thing (I might have said something in the liking.. but the pros
outweigh the cons here)! As you said, adding
On 2/18/2009 at 3:12 PM, Ivan Warren i...@vmfacility.fr wrote:
A monolithic kernel would make all the sense in the world.. and IPL
directly with your root !
And would be different from how everything else is done, driving up costs,
generating complaints (Why is this different from my other
proper operations and you didn't forget something
and you didn't mess up.. and don't forget to mkinitrd/zipl !'
As far as the 'complaint generation', most of the complaint are driven
by experience, not implementation. Most of the people do not *CARE*
whether a driver is linked with the kernel or loaded
On Feb 18, 2009, at 4:30 PM, Ivan Warren wrote:
Basically, the requirement for an initrd was generated by
'distributed'
systems.. Where you can stick in brand XXX variant ZZZ HBA.. but on
IBM
System z.. you can't do that ! And even more... Even if you were
allowed
to, it would have to follow
Adam Thornton wrote:
Or diag250.
Sure, doesn't work on the metal. Nevertheless.
Well.. Diag 250 is just a way to talk to a DASD.
Whatever you do with Diag 250, you can also do with SSCH, an ORB and
some CCWs... So even if Diag 250 isn't embedded in the kernel, you
should still be able to
On Feb 18, 2009, at 9:36 PM, Ivan Warren wrote:
Now about Diag 250.. What's the gain ?
a) tons easier for the device driver writers. Take a look at the disk
driver in OpenSolaris/z to see why I care.
Now.. Simplicity ? Device independence ? well, to support LPAR, you're
going to have to
Good morning,
I have just realized that I accidently deleted my initrd-xxx.img file
and the system will not boot up.
I did not setup any options from the zipl menu to point to another .img
file .. shame on me ...
Is there another way to pass the at ipl time a parm to use another
initrd-.img
On 2/3/2009 at 11:22 AM, Ayer, Paul W pwa...@statestreet.com wrote:
-snip-
Is there another way to pass the at ipl time a parm to use another
initrd-.img file?
Not that I'm aware of. Booting from a rescue/installation system looks like
the only way to repair this.
Mark Post
Patrick Spinler wrote:
I'm experiencing an issue with zipl on redhat 5.2, where it doesn't
appear to create a usable default for it's boot menu. Has anyone seen
anything similar? I just opened a PMR with IBM, but thought I'd ask
here, also.
Interresting. When reading the config file, it looks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi:
I'm experiencing an issue with zipl on redhat 5.2, where it doesn't
appear to create a usable default for it's boot menu. Has anyone seen
anything similar? I just opened a PMR with IBM, but thought I'd ask
here, also.
I've appended lots
One of the more common issues that have come up on this mailing list have been
related to people making changes, such as adding DASD, and then not re-running
mkinitrd or zipl. I opened a feature request for SLES10 SP2, to make sure that
YaST takes care of this automatically. What I'm being
to
Linux on 390 Port LINUX-390@VM.MARIST.EDU
To
LINUX-390@VM.MARIST.EDU
cc
Subject
Re: SLES9 zipl
On Sun, Jul 8, 2007 at 5:42 PM, in message
[EMAIL PROTECTED],
Tim Hare [EMAIL PROTECTED] wrote:
SLES9 and trying to follow the instructions in:
http://linuxvm.org/present/SHARE108/S9240jb.pdf
SLES9 and trying to follow the instructions in:
http://linuxvm.org/present/SHARE108/S9240jb.pdf
To correct startup errors...
When I mount /dev/dasda1 as /mnt it complains about not finding
/bin/bash.
When I mount /dev/dasda2 as /mnt, it works OK, but when I run /sbin/zipl
it complains
/bin/bash.
When I mount /dev/dasda2 as /mnt, it works OK, but when I run /sbin/zipl
it complains that /boot/image doesn't exist. I did find an image file on
/dev/dasda1.
It sounds as though dasda1 is /boot, and dasda2 is /. If you want to run zipl,
you'll need to mount dasda2 on /mnt
1 - 100 of 223 matches
Mail list logo
