<div dir="ltr">You mention:<div> <span style="font-size:12.8000001907349px">I guess I could remove the ignoredisk line now since I use the by-id name to identify the disk to install to in the 'part' commands. </span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Yes agree. The "by-id" and "by-path" anaconda enhancements were wonderful for identifying patterns of disks. In order to identfy the desired OS disk on a variety of platforms.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">I re-wrote our ks.cfg templates recently. We do a variety of static, DHCP and PXE builds for Linux servers. The first RAID vol will enumerate slightly different due to different server models and different built types. But it's always close. I was able to find a by-path pattern that captured all the possibilities.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Much easier if you doing hundreds of builds than embedding disk IDs.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Here's what I did:</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><div style><span style="font-size:12.8000001907349px">## Make sure that the USB disk(s) and FC LUNs are ignored during discovery.</span></div><div style><span style="font-size:12.8000001907349px"># And that we use the first PERC vol as our system disk.</span></div><div style><span style="font-size:12.8000001907349px"><br></span></div><div style><span style="font-size:12.8000001907349px"># For static builds:</span></div><div style><span style="font-size:12.8000001907349px"># 1. Virtual media (USB) detected as /dev/sda, first PERC vol as /dev/sdb.</span></div><div style><span style="font-size:12.8000001907349px"># 2. Physical USB media detected as /dev/sda, first PERC vol as /dev/sdb.</span></div><div style><span style="font-size:12.8000001907349px"># 3. *However*!! if both virtual media + physical USB media present,</span></div><div style><span style="font-size:12.8000001907349px"># virtual media detected as /dev/sda (I think), physical USB media as</span></div><div style><span style="font-size:12.8000001907349px"># /dev/sdb (I think) and first PERC vol as /dev/sdc.</span></div><div style><span style="font-size:12.8000001907349px"># 4. "ignoredisk" directive no longer tolerates a "--drives=" flag with a</span></div><div style><span style="font-size:12.8000001907349px"># "--only-use=" flag. One or the other, not both.</span></div><div style><span style="font-size:12.8000001907349px">#</span></div><div style><span style="font-size:12.8000001907349px"># Same rules apply for DHCP builds, as they're also based on virtual or</span></div><div style><span style="font-size:12.8000001907349px"># physical boot media. We want to use first PERC vol (/dev/sdb for DHCP</span></div><div style><span style="font-size:12.8000001907349px"># builds).</span></div><div style><span style="font-size:12.8000001907349px">#</span></div><div style><span style="font-size:12.8000001907349px"># For PXE builds, first PERC vol is /dev/sda. (Mark's boot media is loaded</span></div><div style><span style="font-size:12.8000001907349px"># into mem I guess.)</span></div><div style><span style="font-size:12.8000001907349px">#</span></div><div style><span style="font-size:12.8000001907349px"># YUCK!!! Instead of considering all those ugly cases --</span></div><div style><span style="font-size:12.8000001907349px">#</span></div><div style><span style="font-size:12.8000001907349px"># Consistently, the 1st PERC vol seems to be enumerated as [0:2:0:0] on</span></div><div style><span style="font-size:12.8000001907349px"># M620s and R620s. Here's example output from lsscsi -g:</span></div><div style><span style="font-size:12.8000001907349px">#</span></div><div style><span style="font-size:12.8000001907349px"># #lsscsi -g</span></div><div style><span style="font-size:12.8000001907349px"># [0:0:32:0] enclosu DP BACKPLANE 1.07 - /dev/sg0</span></div><div style><span style="font-size:12.8000001907349px"># [0:2:0:0] disk DELL PERC 6/i 1.22 /dev/sda /dev/sg1</span></div><div style><span style="font-size:12.8000001907349px"># [0:2:1:0] disk DELL PERC 6/i 1.22 /dev/sdb /dev/sg2</span></div><div style><span style="font-size:12.8000001907349px">#</span></div><div style><span style="font-size:12.8000001907349px"># ks.cfg now allows /dev/disk/by-path/ and /dev/disk/by-id shell-like globs.</span></div><div style><span style="font-size:12.8000001907349px"># See <a href="http://fedoraproject.org/wiki/Anaconda/Kickstart">http://fedoraproject.org/wiki/Anaconda/Kickstart</a>, Special Notes for</span></div><div style><span style="font-size:12.8000001907349px"># Referring to Disks.</span></div><div style><span style="font-size:12.8000001907349px">#</span></div><div style><span style="font-size:12.8000001907349px"># So /dev/disk/by-path/pci-*-usb-* captures all USB media,</span></div><div style><span style="font-size:12.8000001907349px"># /dev/disk/by-path/pci-*-scsi-* captures all PERC vols,</span></div><div style><span style="font-size:12.8000001907349px"># /dev/disk/by-path/pci-*-scsi-0:2:0:0 captures first PERC vol (on a M620),</span></div><div style><span style="font-size:12.8000001907349px"># /dev/disk/by-path/pci-*-fc-* captures all FC LUNs.</span></div><div style><span style="font-size:12.8000001907349px"><br></span></div><div style><span style="font-size:12.8000001907349px"># bootloader --driveorder</span></div><div style><span style="font-size:12.8000001907349px">#</span></div><div style><span style="font-size:12.8000001907349px"># Specifies which drive is first in the BIOS boot order. For example:</span></div><div style><span style="font-size:12.8000001907349px"># bootloader --driveorder=sda,hda</span></div><div style><span style="font-size:12.8000001907349px">#</span></div><div style><span style="font-size:12.8000001907349px"># When we boot OS, the PERC vols are first in BIOS boot order.</span></div><div style><span style="font-size:12.8000001907349px">bootloader --location=mbr --driveorder=/dev/disk/by-path/pci-*-scsi-*</span></div><div style><span style="font-size:12.8000001907349px"><br></span></div><div style><span style="font-size:12.8000001907349px"># The boot media on a M710HD enumerates disk as so:</span></div><div style><span style="font-size:12.8000001907349px"># /dev/disk/by-path/pci-0000:00:1d.7-usb-0:3:1.0-scsi-0:0:0:0 ???</span></div><div style><div style><span style="font-size:12.8000001907349px"># /dev/disk/by-path/pci-0000:00:1d.7-usb-0:3:1.1-scsi-0:0:0:0 ???</span></div><div style><span style="font-size:12.8000001907349px"># /dev/disk/by-path/pci-0000:00:1d.7-usb-0:3:1.2-scsi-0:0:0:0 USB key</span></div><div style><span style="font-size:12.8000001907349px"># /dev/disk/by-path/pci-0000:01:00.0-scsi-0:1:0:0 first PERC volume</span></div><div style><span style="font-size:12.8000001907349px">#</span></div><div style><span style="font-size:12.8000001907349px"># Would the following line work to lay down partitions only on 1st PERC</span></div><div style><span style="font-size:12.8000001907349px"># volume? Would this work on all server models?</span></div><div style><span style="font-size:12.8000001907349px">#ignoredisk --only-use=/dev/disk/by-path/pci-*-scsi-0:[1-9]:0:0</span></div><div style><span style="font-size:12.8000001907349px"><br></span></div><div style><span style="font-size:12.8000001907349px"># Thus, would the following line remove all partitions, but only from 1st PERC</span></div><div style><span style="font-size:12.8000001907349px"># vol? For all server models?</span></div><div style><span style="font-size:12.8000001907349px">#clearpart --all --initlabel --drives=/dev/disk/by-path/pci-*-scsi-0:[1-9]:0:0</span></div><div style><span style="font-size:12.8000001907349px"><br></span></div><div style><span style="font-size:12.8000001907349px"># This *definitely* works. See %pre section.</span></div><div style><span style="font-size:12.8000001907349px">%include /tmp/ignoredisk</span></div><div style="font-size:12.8000001907349px">...</div></div><div><br></div><div><div>%pre</div><div># This *definitely* works. See %include ignoredisk discussion above.</div><div>FIRST_PERC_VOL=$(ls -1 /dev/disk/by-path/pci-*-scsi-0:[1-9]:0:0 | grep -v usb)</div><div><br></div><div>echo "ignoredisk --only-use=$FIRST_PERC_VOL" > /tmp/ignoredisk</div><div>echo "clearpart --all --initlabel --drives=$FIRST_PERC_VOL" >> /tmp/ignoredisk</div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 18, 2015 at 11:00 AM, <span dir="ltr"><<a href="mailto:kickstart-list-request@redhat.com" target="_blank">kickstart-list-request@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Kickstart-list mailing list submissions to<br>
<a href="mailto:kickstart-list@redhat.com">kickstart-list@redhat.com</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://www.redhat.com/mailman/listinfo/kickstart-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/kickstart-list</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:kickstart-list-request@redhat.com">kickstart-list-request@redhat.com</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:kickstart-list-owner@redhat.com">kickstart-list-owner@redhat.com</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Kickstart-list digest..."<br>
<br>Today's Topics:<br>
<br>
1. Very slow Fedora 22 installation (Roderick Johnstone)<br>
2. Re: Very slow Fedora 22 installation (Mrinmoy Roy)<br>
3. Re: Very slow Fedora 22 installation (Roderick Johnstone)<br>
<br><br>---------- Forwarded message ----------<br>From: Roderick Johnstone <<a href="mailto:rmj@ast.cam.ac.uk">rmj@ast.cam.ac.uk</a>><br>To: Discussion list about Kickstart <<a href="mailto:kickstart-list@redhat.com">kickstart-list@redhat.com</a>><br>Cc: <br>Date: Thu, 18 Jun 2015 10:42:30 +0100<br>Subject: Very slow Fedora 22 installation<br>Hi<br>
<br>
I'm currently running a Fedora 22 kickstart install to one of our backup servers. Its been running for nearly a day now!<br>
<br>
The root partition is on ext4 but there is a btrfs file system on top of md raid6 that holds our user backups. Each users' files are rsycned to the btrfs filesystem and then a snapshot made, so there are many thousands of snapshots.<br>
<br>
Currently the install has been running for nearly a day (the main screen is full of dots). Behind the scenes the installer seems to be working its way through all the snapshots with messages like this in storage.log:<br>
<br>
05:11:42,844 INFO blivet: hiding device existing 9.1 TiB btrfs snapshot home_xxx/20130423-000501 (59677) with existing btrfs filesystem<br>
05:11:42,848 DEBUG blivet: existing RAID raid6 size == 9.1 TiB<br>
05:11:42,852 DEBUG blivet: existing RAID raid6 size == 9.1 TiB<br>
05:11:42,857 DEBUG blivet: BTRFSVolumeDevice.removeChild: kids: 32903 ; name: btrfs.133 ;<br>
05:11:42,858 INFO blivet: removed btrfs snapshot home_xxx/20130423-000501 (id 59677) from device tree<br>
05:11:42,858 DEBUG blivet: lvm filter: adding home_xxx/20130423-000501 to the reject list<br>
05:11:43,540 DEBUG blivet: existing RAID raid6 size == 9.1 TiB<br>
<br>
In my kickstart file I have a (legacy) line which I use to make sure that there is no possibility of the install happening to the wrong device:<br>
ignoredisk --only-use=/dev/disk/by-id/ata-ST380815AS_9RA8ZRZK<br>
<br>
where ata-ST380815AS_9RA8ZRZK is the disk I want to install the operating system to.<br>
<br>
Is it possible that this is whats causing the slowness?<br>
<br>
I guess I could remove the ignoredisk line now since I use the by-id name to identify the disk to install to in the 'part' commands. I think we introduced 'ignoredisk' ages ago when we had to specify partitions by names like /dev/hda1 and I was caught out once when the disks were enumerated in a different order in the installer than in the previous operating system I was using and the install happened to the wrong device.<br>
<br>
I'm disinclined to interrupt the install at the moment, as it does seem to be making progress, but confirmation that removing the 'ignoredisk' line would avoid the issue I described would be useful.<br>
<br>
Thanks<br>
<br>
Roderick Johnstone<br>
<br>
<br>
<br><br>---------- Forwarded message ----------<br>From: Mrinmoy Roy <<a href="mailto:tintin4u20@gmail.com">tintin4u20@gmail.com</a>><br>To: Discussion list about Kickstart <<a href="mailto:kickstart-list@redhat.com">kickstart-list@redhat.com</a>><br>Cc: <br>Date: Thu, 18 Jun 2015 17:46:53 +0530<br>Subject: Re: Very slow Fedora 22 installation<br><div dir="ltr">Hi,<div><br></div><div>Can you tell me which .iso are you using for Fedora 22..?</div><div><br></div><div>Thanks</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 18, 2015 at 3:12 PM, Roderick Johnstone <span dir="ltr"><<a href="mailto:rmj@ast.cam.ac.uk" target="_blank">rmj@ast.cam.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
I'm currently running a Fedora 22 kickstart install to one of our backup servers. Its been running for nearly a day now!<br>
<br>
The root partition is on ext4 but there is a btrfs file system on top of md raid6 that holds our user backups. Each users' files are rsycned to the btrfs filesystem and then a snapshot made, so there are many thousands of snapshots.<br>
<br>
Currently the install has been running for nearly a day (the main screen is full of dots). Behind the scenes the installer seems to be working its way through all the snapshots with messages like this in storage.log:<br>
<br>
05:11:42,844 INFO blivet: hiding device existing 9.1 TiB btrfs snapshot home_xxx/20130423-000501 (59677) with existing btrfs filesystem<br>
05:11:42,848 DEBUG blivet: existing RAID raid6 size == 9.1 TiB<br>
05:11:42,852 DEBUG blivet: existing RAID raid6 size == 9.1 TiB<br>
05:11:42,857 DEBUG blivet: BTRFSVolumeDevice.removeChild: kids: 32903 ; name: btrfs.133 ;<br>
05:11:42,858 INFO blivet: removed btrfs snapshot home_xxx/20130423-000501 (id 59677) from device tree<br>
05:11:42,858 DEBUG blivet: lvm filter: adding home_xxx/20130423-000501 to the reject list<br>
05:11:43,540 DEBUG blivet: existing RAID raid6 size == 9.1 TiB<br>
<br>
In my kickstart file I have a (legacy) line which I use to make sure that there is no possibility of the install happening to the wrong device:<br>
ignoredisk --only-use=/dev/disk/by-id/ata-ST380815AS_9RA8ZRZK<br>
<br>
where ata-ST380815AS_9RA8ZRZK is the disk I want to install the operating system to.<br>
<br>
Is it possible that this is whats causing the slowness?<br>
<br>
I guess I could remove the ignoredisk line now since I use the by-id name to identify the disk to install to in the 'part' commands. I think we introduced 'ignoredisk' ages ago when we had to specify partitions by names like /dev/hda1 and I was caught out once when the disks were enumerated in a different order in the installer than in the previous operating system I was using and the install happened to the wrong device.<br>
<br>
I'm disinclined to interrupt the install at the moment, as it does seem to be making progress, but confirmation that removing the 'ignoredisk' line would avoid the issue I described would be useful.<br>
<br>
Thanks<br>
<br>
Roderick Johnstone<br>
<br>
_______________________________________________<br>
Kickstart-list mailing list<br>
<a href="mailto:Kickstart-list@redhat.com" target="_blank">Kickstart-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/kickstart-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/kickstart-list</a><br>
</blockquote></div><br></div>
<br><br>---------- Forwarded message ----------<br>From: Roderick Johnstone <<a href="mailto:rmj@ast.cam.ac.uk">rmj@ast.cam.ac.uk</a>><br>To: <a href="mailto:kickstart-list@redhat.com">kickstart-list@redhat.com</a><br>Cc: <br>Date: Thu, 18 Jun 2015 13:24:38 +0100<br>Subject: Re: Very slow Fedora 22 installation<br>Hi<br>
<br>
Network install with inst.repo=<a href="http://ftp.heanet.ie/mirr" rel="noreferrer" target="_blank">http://ftp.heanet.ie/mirr</a><br>
ors/fedora/linux/releases/22/Server/x86_64/os<br>
but with 'everything' repo added in kickstart file<br>
<br>
Roderick<br>
<br>
On 18/06/15 13:16, Mrinmoy Roy wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
Can you tell me which .iso are you using for Fedora 22..?<br>
<br>
Thanks<br>
<br>
<br>
<br>
On Thu, Jun 18, 2015 at 3:12 PM, Roderick Johnstone <<a href="mailto:rmj@ast.cam.ac.uk" target="_blank">rmj@ast.cam.ac.uk</a><br>
<mailto:<a href="mailto:rmj@ast.cam.ac.uk" target="_blank">rmj@ast.cam.ac.uk</a>>> wrote:<br>
<br>
Hi<br>
<br>
I'm currently running a Fedora 22 kickstart install to one of our<br>
backup servers. Its been running for nearly a day now!<br>
<br>
The root partition is on ext4 but there is a btrfs file system on<br>
top of md raid6 that holds our user backups. Each users' files are<br>
rsycned to the btrfs filesystem and then a snapshot made, so there<br>
are many thousands of snapshots.<br>
<br>
Currently the install has been running for nearly a day (the main<br>
screen is full of dots). Behind the scenes the installer seems to be<br>
working its way through all the snapshots with messages like this in<br>
storage.log:<br>
<br>
05:11:42,844 INFO blivet: hiding device existing 9.1 TiB btrfs<br>
snapshot home_xxx/20130423-000501 (59677) with existing btrfs filesystem<br>
05:11:42,848 DEBUG blivet: existing RAID raid6 size == 9.1 TiB<br>
05:11:42,852 DEBUG blivet: existing RAID raid6 size == 9.1 TiB<br>
05:11:42,857 DEBUG blivet: BTRFSVolumeDevice.removeChild: kids:<br>
32903 ; name: btrfs.133 ;<br>
05:11:42,858 INFO blivet: removed btrfs snapshot<br>
home_xxx/20130423-000501 (id 59677) from device tree<br>
05:11:42,858 DEBUG blivet: lvm filter: adding<br>
home_xxx/20130423-000501 to the reject list<br>
05:11:43,540 DEBUG blivet: existing RAID raid6 size == 9.1 TiB<br>
<br>
In my kickstart file I have a (legacy) line which I use to make sure<br>
that there is no possibility of the install happening to the wrong<br>
device:<br>
ignoredisk --only-use=/dev/disk/by-id/ata-ST380815AS_9RA8ZRZK<br>
<br>
where ata-ST380815AS_9RA8ZRZK is the disk I want to install the<br>
operating system to.<br>
<br>
Is it possible that this is whats causing the slowness?<br>
<br>
I guess I could remove the ignoredisk line now since I use the by-id<br>
name to identify the disk to install to in the 'part' commands. I<br>
think we introduced 'ignoredisk' ages ago when we had to specify<br>
partitions by names like /dev/hda1 and I was caught out once when<br>
the disks were enumerated in a different order in the installer than<br>
in the previous operating system I was using and the install<br>
happened to the wrong device.<br>
<br>
I'm disinclined to interrupt the install at the moment, as it does<br>
seem to be making progress, but confirmation that removing the<br>
'ignoredisk' line would avoid the issue I described would be useful.<br>
<br>
Thanks<br>
<br>
Roderick Johnstone<br>
</blockquote>
<br>
<br>
<br>_______________________________________________<br>
Kickstart-list mailing list<br>
<a href="mailto:Kickstart-list@redhat.com">Kickstart-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/kickstart-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/kickstart-list</a><br></blockquote></div><br></div>