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@xxxxxxxxxx> wrote:
Send Kickstart-list mailing list submissions to
kickstart-list@xxxxxxxxxx
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@xxxxxxxxxx
You can reach the person managing the list at
kickstart-list-owner@xxxxxxxxxx
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@xxxxxxxxxxxxx>
To: Discussion list about Kickstart <kickstart-list@xxxxxxxxxx>
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@xxxxxxxxx>
To: Discussion list about Kickstart <kickstart-list@xxxxxxxxxx>
Cc:
Date: Thu, 18 Jun 2015 17:46:53 +0530
Subject: Re: Very slow Fedora 22 installationHi,Can you tell me which .iso are you using for Fedora 22..?ThanksOn Thu, Jun 18, 2015 at 3:12 PM, Roderick Johnstone <rmj@xxxxxxxxxxxxx> 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/kickstart-list
---------- Forwarded message ----------
From: Roderick Johnstone <rmj@xxxxxxxxxxxxx>
To: kickstart-list@xxxxxxxxxx
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@xxxxxxxxxxxxx
<mailto:rmj@xxxxxxxxxxxxx>> 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/kickstart-list
_______________________________________________ Kickstart-list mailing list Kickstart-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/kickstart-list
