Apologies from me also for getting it so wrong the first time. It was early in the morning, and my brain hadn't kicked in yet. I figured zipl had to store hard pointers to avoid reading the filesystem.
I was puzzled at first about how SLES7 worked without an initrd, so I went and checked and found that the DASD driver is actually built in, not a module. This surprised me because the bootstrap kernel you load from the reader during install (which we use for recovery sometimes) does NOT have the dasd module linked in, you HAVE to load it from the initrd. No reason why this shouldn't be, it just confused me for a bit. Haven't tried RHEL, but I'll keep this tidbit for future reference, just in case. > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of > Post, Mark K > Sent: Friday, April 02, 2004 12:23 PM > To: [EMAIL PROTECTED] > Subject: Re: [LINUX-390] new disk for linux > > > Well, sort of. When zipl is run, it stores pointers to the > boot sector, > kernel and the contents of the parmfile in a specific place > on the disk. > Strictly speaking, there is no access to the file system on > the disk. This > is why if you write over those files with new contents, your > next boot is > likely to fail because they wind up in different physical > locations on the > disk, and the pointers are now pointing to free space that > may get written > over with something else as time goes on. (If the free space > doesn't get > written over, then you just get the old versions of the files.) > > When the boot loader invokes the linuxrc script on the > initrd, it appears to > pass the contents parmfile that is "imbedded" with the kernel > on the boot > disk as arguments (or environment variables) to linuxrc. So, if in > /etc/zipl.conf you have > parameters="dasd=300,301,400 root=/dev/dasda2" > Then it appears that linuxrc gets invoked as > linuxrc dasd=300,301,400 root=/dev/dasda2 > or perhaps as > dasd=300,301,400 root=/dev/dasda2 linuxrc > ?? > > This allows the SUSE linuxrc to issue this command > insmod dasd_mod dasd=$dasd > since the variable dasd has the value of "300,301,400" > > So, you're correct that SLES8 does not require the initrd to > be regenerated > simply to add new DASD device numbers. > > RHEL3 is another story entirely, unfortunately. There, the > linuxrc script > does this: > insmod /lib/dasd_mod.o dasd=300-301,400 > > So, the case of RHEL3, you really do need to regenerate the > initrd if you > want to add DASD devices to your system. > > Now, hopefully I've got all this straight in my mind so that > I won't be > arguing with people when they're more right than I am. > Apologies for doing > so in this case. > > > Mark Post > > -----Original Message----- > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On > Behalf Of Hall, > Ken (IDS ECCS) > Sent: Friday, April 02, 2004 8:20 AM > To: [EMAIL PROTECTED] > Subject: Re: new disk for linux > > > The kernel modules (dasd_mod.o and dasd_eckd_mod) are in the > initrd, but the > DASD parm is picked up from the BOOT filesystem. That's > updated by running > zipl, copied from /etc/zipl.conf. You don't boot from the > initrd, that's > mounted AFTER the kernel loads from the boot filesystem. If > you needed the > initrd to boot, you wouldn't be able to get it, since that > ALSO lives in the > boot filesystem (/boot/initrd). > > In practice, the only reason for using an initrd is if you > want to separate > the boot filesystem from the root filesystem. When you do > this, you hit a > Catch-22: You can't mount the root filesystem until you have the dasd > drivers loaded, but if they're not in the same filesystem > you booted from, > you can't load them. The initrd gets around this by > providing a temporary > ramdisk "mini-root" filesystem that contains the dasd drivers. > > This used to be done in Intel boxen mainly because of the old > requirement > that the boot partition be smaller than ~500 mb. I've never seen a > compelling reason for separating the boot and root > filesystems on zLinux, or > even on current level Intel hardware, but it's a common > practice, so SUSE > allowed for it in SLES8. > > > -----Original Message----- > > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of > > Post, Mark K > > Sent: Thursday, April 01, 2004 5:10 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [LINUX-390] new disk for linux > > > > > > On SLES8 systems (default, out of the box), the kernel > modules and the > > script that invokes them are all in the initrd. At the > time the DASD > > driver gets loaded by that script, there is no way for it to be able > > to access the > > contents of anything on disk. If you're not using an initrd, > > then of course > > you don't have to rebuild it. If you are using SLES8 with an > > initrd, then > > the HOWTO I referenced is applicable, and has fixed the > > problems many people > > on this list have had with SLES8, since it acted differently > > than previous > > SUSE platforms. > > > > > > Mark Post > > -----Original Message----- > > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On > Behalf Of > > Hall, Ken (IDS ECCS) > > Sent: Thursday, April 01, 2004 4:18 PM > > To: [EMAIL PROTECTED] > > Subject: Re: new disk for linux > > > > > > Uh, yes it does. > > > > Whether or not an initrd is used, the DASD parm comes from the boot > > parameter file created by zipl. That's on the disk you boot from, > > which may or may not also contain the root filesystem. (In > my case it > > does.) > > > > I just changed /etc/zipl.conf on my test system, ran zipl, and > > rebooted. The change was reflected in /proc/dasd/devices. > I've never > > had to rebuild > > the initrd manually. > > > > The only time you have to update the initrd is when you do a kernel > > upgrade, and if you're using the RPM packaged kernels, that's taken > > care of by the > > install. > > > > > -----Original Message----- > > > From: Linux on 390 Port > [mailto:[EMAIL PROTECTED] Behalf Of > > > Post, Mark K > > > Sent: Thursday, April 01, 2004 4:01 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [LINUX-390] new disk for linux > > > > > > > > > Umm, no, it does not. With SLES8, SUSE went to using an > > initrd. The > > > HOWTO I referenced in another reply talks about how to > update that. > > > > > > > > > Mark Post > > > > > > -----Original Message----- > > > From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On > > Behalf Of > > > Hall, Ken (IDS ECCS) > > > Sent: Thursday, April 01, 2004 3:47 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: new disk for linux > > > > > > > > > I think you added the device to the wrong file. I > usually add it to > > > /etc/zipl.conf, then run zipl. I believe zipl copies > > zipl.conf to the > > > /boot files (among other things). > > > > > > > -----Original Message----- > > > > From: Linux on 390 Port > > [mailto:[EMAIL PROTECTED] Behalf Of > > > > Scorch Burnet > > > > Sent: Thursday, April 01, 2004 3:44 PM > > > > To: [EMAIL PROTECTED] > > > > Subject: [LINUX-390] new disk for linux > > > > > > > > > > > > I am trying to add another disk to one of my SLES8 > Linux images on > > > > z/VM. I added the mdisk statement to the user direct, > excuted the > > > > directxa, and logged onto the guest. after cms > formatting the new > > > > mdisk, iI added the new disk address to > > /boot/zipl/parmfile and ran > > > > zipl. > > > > > > > > After rebooting, I expected to be able to format and > > > partition the new > > > > disk, but I do not see it in /proc/dasd/devices. > > > > > > > > Can someone give me a list of the steps I need to perform > > > in order to > > > > add this new dasd to my linux machine. > > > > > > > > any help is appreciated > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > For LINUX-390 subscribe / signoff / archive access > > > instructions, send > > > > email to [EMAIL PROTECTED] with the message: INFO > > LINUX-390 or > > > > visit http://www.marist.edu/htbin/wlvindex?LINUX-390 > > > > > > > > > > ============================================================== > > > ============== > > > == > > > > > > If you are not an intended recipient of this e-mail, please > > notify the > > > sender, delete it and do not read, act upon, print, > disclose, copy, > > > retain or redistribute it. > > > > > > Click here for important additional terms relating to this e-mail. > > > <http://www.ml.com/email_terms/> > > > > > > ============================================================== > > > ============== > > > == > > > > > > > > > ---------------------------------------------------------------------- > > > For LINUX-390 subscribe / signoff / archive access > > instructions, send > > > email to [EMAIL PROTECTED] with the message: INFO > LINUX-390 or > > > visit http://www.marist.edu/htbin/wlvindex?LINUX-390 > > > > > > > > > ---------------------------------------------------------------------- > > > For LINUX-390 subscribe / signoff / archive access > > instructions, send > > > email to [EMAIL PROTECTED] with the message: INFO > LINUX-390 or > > > visit http://www.marist.edu/htbin/wlvindex?LINUX-390 > > > > > > > ============================================================== > > ============== > > == > > > > If you are not an intended recipient of this e-mail, please > notify the > > sender, delete it and do not read, act upon, print, disclose, copy, > > retain or redistribute it. > > > > Click here for important additional terms relating to this e-mail. > > <http://www.ml.com/email_terms/> > > > > ============================================================== > > ============== > > == > > > > > ---------------------------------------------------------------------- > > For LINUX-390 subscribe / signoff / archive access > instructions, send > > email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or > > visit http://www.marist.edu/htbin/wlvindex?LINUX-390 > > > > > ---------------------------------------------------------------------- > > For LINUX-390 subscribe / signoff / archive access > instructions, send > > email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or > > visit http://www.marist.edu/htbin/wlvindex?LINUX-390 > > > > ============================================================== > ============== > == > > If you are not an intended recipient of this e-mail, please notify the > sender, delete it and do not read, act upon, print, disclose, > copy, retain > or redistribute it. > > Click here for important additional terms relating to this e-mail. > <http://www.ml.com/email_terms/> > > ============================================================== > ============== > == > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access > instructions, send email > to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > > ---------------------------------------------------------------------- > For LINUX-390 subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: INFO > LINUX-390 or visit > http://www.marist.edu/htbin/wlvindex?LINUX-390 > ============================================================================== If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. <http://www.ml.com/email_terms/> ============================================================================== ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
