Kickstart-list Digest, Vol 132, Issue 1

Spike White spikewhitetx at gmail.com
Sat Jun 20 17:48:39 UTC 2015


You mention:
   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.

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.

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.

Much easier if you doing hundreds of builds than embedding disk IDs.

Here's what I did:

## 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
...

%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


On Thu, Jun 18, 2015 at 11:00 AM, <kickstart-list-request at redhat.com> wrote:

> Send Kickstart-list mailing list submissions to
>         kickstart-list at redhat.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.redhat.com/mailman/listinfo/kickstart-list
> or, via email, send a message with subject or body 'help' to
>         kickstart-list-request at redhat.com
>
> You can reach the person managing the list at
>         kickstart-list-owner at redhat.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Kickstart-list digest..."
>
> Today's Topics:
>
>    1. Very slow Fedora 22 installation (Roderick Johnstone)
>    2. Re: Very slow Fedora 22 installation (Mrinmoy Roy)
>    3. Re: Very slow Fedora 22 installation (Roderick Johnstone)
>
>
> ---------- Forwarded message ----------
> From: Roderick Johnstone <rmj at ast.cam.ac.uk>
> To: Discussion list about Kickstart <kickstart-list at redhat.com>
> Cc:
> Date: Thu, 18 Jun 2015 10:42:30 +0100
> Subject: Very slow Fedora 22 installation
> Hi
>
> I'm currently running a Fedora 22 kickstart install to one of our backup
> servers. Its been running for nearly a day now!
>
> 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.
>
> 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:
>
> 05:11:42,844 INFO blivet: hiding device existing 9.1 TiB btrfs snapshot
> home_xxx/20130423-000501 (59677) with existing btrfs filesystem
> 05:11:42,848 DEBUG blivet: existing RAID raid6 size == 9.1 TiB
> 05:11:42,852 DEBUG blivet: existing RAID raid6 size == 9.1 TiB
> 05:11:42,857 DEBUG blivet: BTRFSVolumeDevice.removeChild: kids: 32903 ;
> name: btrfs.133 ;
> 05:11:42,858 INFO blivet: removed btrfs snapshot home_xxx/20130423-000501
> (id 59677) from device tree
> 05:11:42,858 DEBUG blivet: lvm filter: adding home_xxx/20130423-000501 to
> the reject list
> 05:11:43,540 DEBUG blivet: existing RAID raid6 size == 9.1 TiB
>
> 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:
> ignoredisk --only-use=/dev/disk/by-id/ata-ST380815AS_9RA8ZRZK
>
> where ata-ST380815AS_9RA8ZRZK is the disk I want to install the operating
> system to.
>
> Is it possible that this is whats causing the slowness?
>
> 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.
>
> 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.
>
> Thanks
>
> Roderick Johnstone
>
>
>
>
> ---------- Forwarded message ----------
> From: Mrinmoy Roy <tintin4u20 at gmail.com>
> To: Discussion list about Kickstart <kickstart-list at redhat.com>
> Cc:
> Date: Thu, 18 Jun 2015 17:46:53 +0530
> Subject: Re: Very slow Fedora 22 installation
> Hi,
>
> Can you tell me which .iso are you using for Fedora 22..?
>
> Thanks
>
>
>
> On Thu, Jun 18, 2015 at 3:12 PM, Roderick Johnstone <rmj at ast.cam.ac.uk>
> wrote:
>
>> Hi
>>
>> I'm currently running a Fedora 22 kickstart install to one of our backup
>> servers. Its been running for nearly a day now!
>>
>> 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.
>>
>> 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:
>>
>> 05:11:42,844 INFO blivet: hiding device existing 9.1 TiB btrfs snapshot
>> home_xxx/20130423-000501 (59677) with existing btrfs filesystem
>> 05:11:42,848 DEBUG blivet: existing RAID raid6 size == 9.1 TiB
>> 05:11:42,852 DEBUG blivet: existing RAID raid6 size == 9.1 TiB
>> 05:11:42,857 DEBUG blivet: BTRFSVolumeDevice.removeChild: kids: 32903 ;
>> name: btrfs.133 ;
>> 05:11:42,858 INFO blivet: removed btrfs snapshot home_xxx/20130423-000501
>> (id 59677) from device tree
>> 05:11:42,858 DEBUG blivet: lvm filter: adding home_xxx/20130423-000501 to
>> the reject list
>> 05:11:43,540 DEBUG blivet: existing RAID raid6 size == 9.1 TiB
>>
>> 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:
>> ignoredisk --only-use=/dev/disk/by-id/ata-ST380815AS_9RA8ZRZK
>>
>> where ata-ST380815AS_9RA8ZRZK is the disk I want to install the operating
>> system to.
>>
>> Is it possible that this is whats causing the slowness?
>>
>> 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.
>>
>> 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.
>>
>> Thanks
>>
>> Roderick Johnstone
>>
>> _______________________________________________
>> Kickstart-list mailing list
>> Kickstart-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/kickstart-list
>>
>
>
>
> ---------- Forwarded message ----------
> From: Roderick Johnstone <rmj at ast.cam.ac.uk>
> To: kickstart-list at redhat.com
> Cc:
> Date: Thu, 18 Jun 2015 13:24:38 +0100
> Subject: Re: Very slow Fedora 22 installation
> Hi
>
> Network install with inst.repo=http://ftp.heanet.ie/mirr
> ors/fedora/linux/releases/22/Server/x86_64/os
> but with 'everything' repo added in kickstart file
>
> Roderick
>
> On 18/06/15 13:16, Mrinmoy Roy wrote:
>
>> Hi,
>>
>> Can you tell me which .iso are you using for Fedora 22..?
>>
>> Thanks
>>
>>
>>
>> On Thu, Jun 18, 2015 at 3:12 PM, Roderick Johnstone <rmj at ast.cam.ac.uk
>> <mailto:rmj at ast.cam.ac.uk>> wrote:
>>
>>     Hi
>>
>>     I'm currently running a Fedora 22 kickstart install to one of our
>>     backup servers. Its been running for nearly a day now!
>>
>>     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.
>>
>>     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:
>>
>>     05:11:42,844 INFO blivet: hiding device existing 9.1 TiB btrfs
>>     snapshot home_xxx/20130423-000501 (59677) with existing btrfs
>> filesystem
>>     05:11:42,848 DEBUG blivet: existing RAID raid6 size == 9.1 TiB
>>     05:11:42,852 DEBUG blivet: existing RAID raid6 size == 9.1 TiB
>>     05:11:42,857 DEBUG blivet: BTRFSVolumeDevice.removeChild: kids:
>>     32903 ; name: btrfs.133 ;
>>     05:11:42,858 INFO blivet: removed btrfs snapshot
>>     home_xxx/20130423-000501 (id 59677) from device tree
>>     05:11:42,858 DEBUG blivet: lvm filter: adding
>>     home_xxx/20130423-000501 to the reject list
>>     05:11:43,540 DEBUG blivet: existing RAID raid6 size == 9.1 TiB
>>
>>     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:
>>     ignoredisk --only-use=/dev/disk/by-id/ata-ST380815AS_9RA8ZRZK
>>
>>     where ata-ST380815AS_9RA8ZRZK is the disk I want to install the
>>     operating system to.
>>
>>     Is it possible that this is whats causing the slowness?
>>
>>     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.
>>
>>     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.
>>
>>     Thanks
>>
>>     Roderick Johnstone
>>
>
>
>
> _______________________________________________
> 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: <http://listman.redhat.com/archives/kickstart-list/attachments/20150620/a80836ff/attachment.htm>


More information about the Kickstart-list mailing list