From simpsonar77 at gmail.com Mon Feb 1 01:10:38 2016 From: simpsonar77 at gmail.com (Andrew Simpson) Date: Sun, 31 Jan 2016 20:10:38 -0500 Subject: Detecting boot drive In-Reply-To: References: Message-ID: have you thought about trying to find it by UUID or Label? I had a similar issue in a kickstart where I could not determine the boot drive while making a USB boot image. I ended up formatting the drives with a specific LABEL and using that in the kickstart instead of using sda/sdb/etc... Andrew Simpson On Fri, Jan 29, 2016 at 12:53 PM, Hajducko, Steven < Steven_Hajducko at intuit.com> wrote: > Is there a way to consistently detect the boot-drive, across multiple > hardware platforms? > > We have several different hardware types - but it remains consistent that > we always want the OS installed on the first drive in boot order. We > played around with --on-bios-disk, but that doesn't always work ( it fails, > for instance, on Dell R820's with the PERC RAID controller ). We've also > tried specifying /dev/disk/by-id/edd-int13_dev80, which works on the > Dell's, but fails on VMs. ( And then throw HP and it's cciss into the > whole mix.. ). /dev/sda isn't always the boot disk - this happens to us > with certain RAID configs like 1 logical drive and 8 JBOD's. The JBOD's > get detected as /dev/sda-h and the RAID drive ( which is the boot drive ), > ends up as /dev/sdi. > > Just curious if anyone else has come up with a solid way to always figure > out what the boot drive is. > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list at redhat.com > https://www.redhat.com/mailman/listinfo/kickstart-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven_Hajducko at intuit.com Mon Feb 1 01:22:57 2016 From: Steven_Hajducko at intuit.com (Hajducko, Steven) Date: Mon, 1 Feb 2016 01:22:57 +0000 Subject: Detecting boot drive In-Reply-To: References: Message-ID: Can you speak more to that? I'm not understanding how that would work out. Doesn't the assignment of the label happen during the partition configuration - where as I need to know which disk is the first drive in the boot order before that ( so we can tell it that it has the / partition ) This all needs to be done in a strictly automated fashion as well. From: > on behalf of Andrew Simpson > Reply-To: Discussion list about Kickstart > Date: Sunday, January 31, 2016 at 5:10 PM To: Discussion list about Kickstart > Subject: Re: Detecting boot drive have you thought about trying to find it by UUID or Label? I had a similar issue in a kickstart where I could not determine the boot drive while making a USB boot image. I ended up formatting the drives with a specific LABEL and using that in the kickstart instead of using sda/sdb/etc... Andrew Simpson On Fri, Jan 29, 2016 at 12:53 PM, Hajducko, Steven > wrote: Is there a way to consistently detect the boot-drive, across multiple hardware platforms? We have several different hardware types - but it remains consistent that we always want the OS installed on the first drive in boot order. We played around with --on-bios-disk, but that doesn't always work ( it fails, for instance, on Dell R820's with the PERC RAID controller ). We've also tried specifying /dev/disk/by-id/edd-int13_dev80, which works on the Dell's, but fails on VMs. ( And then throw HP and it's cciss into the whole mix.. ). /dev/sda isn't always the boot disk - this happens to us with certain RAID configs like 1 logical drive and 8 JBOD's. The JBOD's get detected as /dev/sda-h and the RAID drive ( which is the boot drive ), ends up as /dev/sdi. Just curious if anyone else has come up with a solid way to always figure out what the boot drive is. _______________________________________________ Kickstart-list mailing list Kickstart-list at redhat.com https://www.redhat.com/mailman/listinfo/kickstart-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From hawk at tbi.univie.ac.at Mon Feb 1 08:20:27 2016 From: hawk at tbi.univie.ac.at (Richard Neuboeck) Date: Mon, 1 Feb 2016 09:20:27 +0100 Subject: Detecting boot drive In-Reply-To: References: Message-ID: <56AF154B.1070502@tbi.univie.ac.at> I would suggest creating a pre install script that finds the correct boot device by querying all available devices until you find one that meets your constraints. You can use either udevadm or try to find some information directly in /sys. i.e. for i in /sys/block/[sv]d? do dev=$(basename $i) # next if it's an usb device if udevadm info --query=path --name=$dev | grep -q -e '/usb' then # Ignoring $dev since it's an usb device continue fi # do something else done Cheers Richard On 02/01/2016 02:22 AM, Hajducko, Steven wrote: > Can you speak more to that? I'm not understanding how that would > work out. Doesn't the assignment of the label happen during the > partition configuration - where as I need to know which disk is the > first drive in the boot order before that ( so we can tell it that > it has the / partition ) > > This all needs to be done in a strictly automated fashion as well. > > From: > on behalf of Andrew > Simpson > > Reply-To: Discussion list about Kickstart > > Date: Sunday, January 31, 2016 at 5:10 PM > To: Discussion list about Kickstart > > Subject: Re: Detecting boot drive > > have you thought about trying to find it by UUID or Label? I had a > similar issue in a kickstart where I could not determine the boot > drive while making a USB boot image. I ended up formatting the > drives with a specific LABEL and using that in the kickstart instead > of using sda/sdb/etc... > > Andrew Simpson > > On Fri, Jan 29, 2016 at 12:53 PM, Hajducko, Steven > > wrote: > > Is there a way to consistently detect the boot-drive, across > multiple hardware platforms? > > We have several different hardware types - but it remains > consistent that we always want the OS installed on the first > drive in boot order. We played around with --on-bios-disk, but > that doesn't always work ( it fails, for instance, on Dell > R820's with the PERC RAID controller ). We've also tried > specifying /dev/disk/by-id/edd-int13_dev80, which works on the > Dell's, but fails on VMs. ( And then throw HP and it's cciss > into the whole mix.. ). /dev/sda isn't always the boot disk - > this happens to us with certain RAID configs like 1 logical > drive and 8 JBOD's. The JBOD's get detected as /dev/sda-h and > the RAID drive ( which is the boot drive ), ends up as /dev/sdi. > > Just curious if anyone else has come up with a solid way to > always figure out what the boot drive is. > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list at redhat.com > https://www.redhat.com/mailman/listinfo/kickstart-list > > > > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list at redhat.com > https://www.redhat.com/mailman/listinfo/kickstart-list > -- /dev/null -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From DKimsey at trustwave.com Fri Feb 5 17:04:40 2016 From: DKimsey at trustwave.com (Daniel Kimsey) Date: Fri, 5 Feb 2016 17:04:40 +0000 Subject: What is the best way to provide status during a long %post/%pre script to a tmux-wrapped kickstart session? Message-ID: <756D273B-87FE-4B71-B90E-97A7F7CB7051@trustwave.com> I'd like my %post scripts to be able to emit messages to the status screen to give feed-back on progress. Is there any built-in mechanism to do this? I've seen (and used) the older tricks to switch the vtty. But on the newer tmux-wrapped kickstart that doesn't feel correct. I cannot find anything in the docs that suggests how I might perform this and reading the source[0] suggests theres no function to do it. [0] https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/kickstart.py#L84 Thank you -- Daniel ________________________________ This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. From spikewhitetx at gmail.com Sat Feb 6 15:56:36 2016 From: spikewhitetx at gmail.com (Spike White) Date: Sat, 6 Feb 2016 09:56:36 -0600 Subject: Detecting boot drive Message-ID: > > On Fri, Jan 29, 2016 at 12:53 PM, Hajducko, Steven < Steven_Hajducko at intuit.com> wrote: > Is there a way to consistently detect the boot-drive, across multiple hardware platforms? > > We have several different hardware types - but it remains consistent that we always want the OS installed on the first drive in boot order. We played around with --on-bios-disk, but that doesn't always work ( it fails, for instance, on Dell R820's with the PERC RAID controller ). We've also tried specifying /dev/disk/by-id/edd-int13_dev80, which works on the Dell's, but fails on VMs. ( And then throw HP and it's cciss into the whole mix.. ). /dev/sda isn't always the boot disk - this happens to us with certain RAID configs like 1 logical drive and 8 JBOD's. The JBOD's get detected as /dev/sda-h and the RAID drive ( which is the boot drive ), ends up as /dev/sdi. > > Just curious if anyone else has come up with a solid way to always figure out what the boot drive is. > I don't have HP servers in my mix, but I have Dell servers all the way from PE2850s up to the newest R730xd's. Additionally, we support static, DHCP and PXE builds which seem to enumerate the disks slightly differents. (As you say, the desired disk is not always /dev/sda). By beaucoup testing, I was able to determine my first disk always had a certain pattern. In my ks.cfg files, I have a %pre section where I interrogate the SCSI sub-system to find disks of the pattern I desire. Here's my relevant %pre section: %pre # This *definitely* works. See %include ignoredisk discussion above. FIRST_PERC_VOL=$(ls -1 /dev/disk/by-path/pci-*-scsi-0:[1-9]:0:0 | grep -v usb) echo "ignoredisk --only-use=$FIRST_PERC_VOL" > /tmp/ignoredisk echo "clearpart --all --initlabel --drives=$FIRST_PERC_VOL" >> /tmp/ignoredisk Here is my main section (I embed my research on the various builds and various server models as comments so that I remember why I ended up with this specific pattern). ## Make sure that the USB disk(s) and FC LUNs are ignored during discovery. # And that we use the first PERC vol as our system disk. # For static builds: # 1. Virtual media (USB) detected as /dev/sda, first PERC vol as /dev/sdb. # 2. Physical USB media detected as /dev/sda, first PERC vol as /dev/sdb. # 3. *However*!! if both virtual media + physical USB media present, # virtual media detected as /dev/sda (I think), physical USB media as # /dev/sdb (I think) and first PERC vol as /dev/sdc. # 4. "ignoredisk" directive no longer tolerates a "--drives=" flag with a # "--only-use=" flag. One or the other, not both. # # Same rules apply for DHCP builds, as they're also based on virtual or # physical boot media. We want to use first PERC vol (/dev/sdb for DHCP # builds). # # For PXE builds, first PERC vol is /dev/sda. (Mark's boot media is loaded # into mem I guess.) # # YUCK!!! Instead of considering all those ugly cases -- # # Consistently, the 1st PERC vol seems to be enumerated as [0:2:0:0] on # M620s and R620s. Here's example output from lsscsi -g: # # #lsscsi -g # [0:0:32:0] enclosu DP BACKPLANE 1.07 - /dev/sg0 # [0:2:0:0] disk DELL PERC 6/i 1.22 /dev/sda /dev/sg1 # [0:2:1:0] disk DELL PERC 6/i 1.22 /dev/sdb /dev/sg2 # # ks.cfg now allows /dev/disk/by-path/ and /dev/disk/by-id shell-like globs. # See http://fedoraproject.org/wiki/Anaconda/Kickstart, Special Notes for # Referring to Disks. # # So /dev/disk/by-path/pci-*-usb-* captures all USB media, # /dev/disk/by-path/pci-*-scsi-* captures all PERC vols, # /dev/disk/by-path/pci-*-scsi-0:2:0:0 captures first PERC vol (on a M620), # /dev/disk/by-path/pci-*-fc-* captures all FC LUNs. # bootloader --driveorder # # Specifies which drive is first in the BIOS boot order. For example: # bootloader --driveorder=sda,hda # # When we boot OS, the PERC vols are first in BIOS boot order. bootloader --location=mbr --driveorder=/dev/disk/by-path/pci-*-scsi-* # The boot media on a M710HD enumerates disk as so: # /dev/disk/by-path/pci-0000:00:1d.7-usb-0:3:1.0-scsi-0:0:0:0 ??? # /dev/disk/by-path/pci-0000:00:1d.7-usb-0:3:1.1-scsi-0:0:0:0 ??? # /dev/disk/by-path/pci-0000:00:1d.7-usb-0:3:1.2-scsi-0:0:0:0 USB key # /dev/disk/by-path/pci-0000:01:00.0-scsi-0:1:0:0 first PERC volume # # Would the following line work to lay down partitions only on 1st PERC # volume? Would this work on all server models? #ignoredisk --only-use=/dev/disk/by-path/pci-*-scsi-0:[1-9]:0:0 # Thus, would the following line remove all partitions, but only from 1st PERC # vol? For all server models? #clearpart --all --initlabel --drives=/dev/disk/by-path/pci-*-scsi-0:[1-9]:0:0 # This *definitely* works. See %pre section. %include /tmp/ignoredisk Also one more comment. Long ago, there was a particular Dell mode (R710). Its low-end PERC controller was forever flip-flopping the disks from one boot to the next. That is, after OS is installed on the disk and server rebooted, this first PERC vol was no longer /dev/sda, but now /dev/sdb. I believe some later rev of the PERC firmware eventually solved this problem. But in the meantime we found that this killed some of our builds, not others. We found if we created all our OS partitions as LVMs, then they'd be discovered and mounted, regardless of whether your boot disk was /dev/sda, sdb, or sdc today. This works because grub identifies its boot partition by SCSI ID -- for instance hd(0,0). Once grub loads the boot vmlinuz/initramfs, the boot kernel does a lvscan. And it finds your LVMs wherever they reside today. Moral of this story: It's good to create your OS filesystems as LVMs. For this and other reasons. Spike -------------- next part -------------- An HTML attachment was scrubbed... URL: From petro at cpetro.us Sun Feb 7 15:37:29 2016 From: petro at cpetro.us (C. Petro) Date: Sun, 7 Feb 2016 08:37:29 -0700 Subject: Detecting boot drive In-Reply-To: References: Message-ID: This won't answer your question directly since I was doing this to find the correct drive to install on--which was sometimes "sda" and sometimes "md raid sdb and sdc and then install to md0". What I did was to build a script called in %pre that ran dmidecode and grabbed the system product name and then wrote a /tmp/boot_setup based in that. I then %included that file. On Fri, Jan 29, 2016 at 10:53 AM, Hajducko, Steven wrote: > Is there a way to consistently detect the boot-drive, across multiple > hardware platforms? > > We have several different hardware types - but it remains consistent that we > always want the OS installed on the first drive in boot order. We played > around with --on-bios-disk, but that doesn't always work ( it fails, for > instance, on Dell R820's with the PERC RAID controller ). We've also tried > specifying /dev/disk/by-id/edd-int13_dev80, which works on the Dell's, but > fails on VMs. ( And then throw HP and it's cciss into the whole mix.. ). > /dev/sda isn't always the boot disk - this happens to us with certain RAID > configs like 1 logical drive and 8 JBOD's. The JBOD's get detected as > /dev/sda-h and the RAID drive ( which is the boot drive ), ends up as > /dev/sdi. > > Just curious if anyone else has come up with a solid way to always figure > out what the boot drive is. > > _______________________________________________ > Kickstart-list mailing list > Kickstart-list at redhat.com > https://www.redhat.com/mailman/listinfo/kickstart-list From fxb7-ox9n at dea.spamcon.org Tue Feb 23 06:16:04 2016 From: fxb7-ox9n at dea.spamcon.org (therbur) Date: Mon, 22 Feb 2016 22:16:04 -0800 Subject: Kickstart: How log and view %post? Method works in CentOS 5 but not CentOS 7 Message-ID: The following method has worked for years with CentOS 5, to allow live viewing of %post output and also logging it. It doesn't work in CentOS 7. What is the recommended method now? # from kickstart text mode install %post --erroronfail chvt 3 exec < /dev/tty3 > /dev/tty3 2> /dev/tty3 tail -F /root/ks-post.log & ( echo "Starting post-kickstart ..." # ... various commands echo "Done." echo echo "Do Alt-F1 and press Enter to reboot" ) >> /root/ks-post.log 2>&1 %end