From rmj at ast.cam.ac.uk Thu Jun 18 09:42:30 2015 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Thu, 18 Jun 2015 10:42:30 +0100 Subject: Very slow Fedora 22 installation Message-ID: <55829286.3060301@ast.cam.ac.uk> 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 From tintin4u20 at gmail.com Thu Jun 18 12:16:53 2015 From: tintin4u20 at gmail.com (Mrinmoy Roy) Date: Thu, 18 Jun 2015 17:46:53 +0530 Subject: Very slow Fedora 22 installation In-Reply-To: <55829286.3060301@ast.cam.ac.uk> References: <55829286.3060301@ast.cam.ac.uk> Message-ID: 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 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: From rmj at ast.cam.ac.uk Thu Jun 18 12:24:38 2015 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Thu, 18 Jun 2015 13:24:38 +0100 Subject: Very slow Fedora 22 installation In-Reply-To: References: <55829286.3060301@ast.cam.ac.uk> Message-ID: <5582B886.2090003@ast.cam.ac.uk> 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 > 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 From Alton.Bledsoe at vce.com Fri Jun 19 00:21:26 2015 From: Alton.Bledsoe at vce.com (Bledsoe, Alton) Date: Thu, 18 Jun 2015 20:21:26 -0400 Subject: Not finding /tmp/include created in %pre Message-ID: <94AB9F915E1FB740AFC4AD4730642A0905C73E7E41@MX21A.corp.emc.com> First, I had to work around the fact that the execution of shell commands are terminated with a carriage return including file names that are created during %pre. The work around was simply: %pre %include http:///path/to/script.sh %post In this script.sh I write out network commands for 4 interfaces after capturing input from tty6. I write to /tmp/net-include and, using alt-F2 shell terminal, I can readily see it in /tmp The %include /tmp/net-config in the kickstart file is generating a PYCURL ERROR 22 ... 404 not found once parsed after the %pre section %end's. Why are these simple looking things that have many similar examples on the web not working? RHEL6.6 Al Bledsoe ++l|l++----+l||l+l||++l|||l++++-------+++-- PD&E Solutions Architect, Richardson, TX Cell: 214-533-1698 Desk: 972-656-5341 Alton.Bledsoe at vce.com Somebody's gotta do it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alton.Bledsoe at vce.com Sat Jun 20 00:07:28 2015 From: Alton.Bledsoe at vce.com (Bledsoe, Alton) Date: Fri, 19 Jun 2015 20:07:28 -0400 Subject: Not finding /tmp/include created in %pre Message-ID: <94AB9F915E1FB740AFC4AD4730642A0905C73E7E9C@MX21A.corp.emc.com> My bad. Need to adjust my glasses. The parser caught me on the file extension; .ks versus .sh. All is well now. But for the first point, I have never seen anyone comment on carriage returns showing up at the end of command execution if the %pre script is embedded in the Kickstart file. The clue for the work around was in an Oracle doc showing the script %included in the kickstart file. From: Bledsoe, Alton Sent: Thursday, June 18, 2015 7:21 PM To: 'kickstart-list at redhat.com' Subject: Not finding /tmp/include created in %pre First, I had to work around the fact that the execution of shell commands are terminated with a carriage return including file names that are created during %pre. The work around was simply: %pre %include http:///path/to/script.sh %post In this script.sh I write out network commands for 4 interfaces after capturing input from tty6. I write to /tmp/net-include and, using alt-F2 shell terminal, I can readily see it in /tmp The %include /tmp/net-config in the kickstart file is generating a PYCURL ERROR 22 ... 404 not found once parsed after the %pre section %end's. Why are these simple looking things that have many similar examples on the web not working? RHEL6.6 Al Bledsoe ++l|l++----+l||l+l||++l|||l++++-------+++-- PD&E Solutions Architect, Richardson, TX Cell: 214-533-1698 Desk: 972-656-5341 Alton.Bledsoe at vce.com Somebody's gotta do it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spikewhitetx at gmail.com Sat Jun 20 17:34:05 2015 From: spikewhitetx at gmail.com (Spike White) Date: Sat, 20 Jun 2015 12:34:05 -0500 Subject: Kickstart-list Digest, Vol 132, Issue 3 In-Reply-To: References: Message-ID: terminators in a ks.cfg file are a strange beast. Apparently the anaconda parser can tolerate them. So it works in a %packages section, or other anaconda-parsed sections. Like the top, overall section. However, anaconda passes off %pre sections and %post sections to the bash interpreter. Which doesn't tolerate terminators. So you can't have in a %pre or %post section. %include literally embeds the content of the specified file in place. So by extension, the same rules apply. in that file would be tolerated in certain sections, not in the %pre or %post section. Spike On Sat, Jun 20, 2015 at 11:00 AM, 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. RE: Not finding /tmp/include created in %pre (Bledsoe, Alton) > > > ---------- Forwarded message ---------- > From: "Bledsoe, Alton" > To: "kickstart-list at redhat.com" > Cc: > Date: Fri, 19 Jun 2015 20:07:28 -0400 > Subject: RE: Not finding /tmp/include created in %pre > > My bad. Need to adjust my glasses. The parser caught me on the file > extension; .ks versus .sh. All is well now. > > > > But for the first point, I have never seen anyone comment on carriage > returns showing up at the end of command execution if the %pre script is > embedded in the Kickstart file. The clue for the work around was in an > Oracle doc showing the script %included in the kickstart file. > > > > *From:* Bledsoe, Alton > *Sent:* Thursday, June 18, 2015 7:21 PM > *To:* 'kickstart-list at redhat.com' > *Subject:* Not finding /tmp/include created in %pre > > > > First, I had to work around the fact that the execution of shell commands > are terminated with a carriage return including file names that are created > during %pre. The work around was simply: > > %pre > > %include http:///path/to/script.sh > > %post > > > > In this script.sh I write out network commands for 4 interfaces after > capturing input from tty6. > > I write to /tmp/net-include and, using alt-F2 shell terminal, I can > readily see it in /tmp > > > > The %include /tmp/net-config in the kickstart file is generating a *PYCURL > ERROR 22 ? 404 not found* once parsed after the %pre section %end?s. > > > > Why are these simple looking things that have many similar examples on the > web not working? > > > > RHEL6.6 > > > > Al Bledsoe > > ++l|l++----+l||l+l||++l|||l++++-------+++-- > > PD&E Solutions Architect, Richardson, TX > > Cell: 214-533-1698 Desk: 972-656-5341 > > Alton.Bledsoe at vce.com > > Somebody?s gotta do it. > > > > _______________________________________________ > 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 spikewhitetx at gmail.com Sat Jun 20 17:48:39 2015 From: spikewhitetx at gmail.com (Spike White) Date: Sat, 20 Jun 2015 12:48:39 -0500 Subject: Kickstart-list Digest, Vol 132, Issue 1 In-Reply-To: References: Message-ID: 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, 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 > To: Discussion list about Kickstart > 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 > To: Discussion list about Kickstart > 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 > 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 > 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 > > 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: From rmj at ast.cam.ac.uk Mon Jun 22 20:14:46 2015 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Mon, 22 Jun 2015 21:14:46 +0100 Subject: Very slow Fedora 22 installation In-Reply-To: <55829286.3060301@ast.cam.ac.uk> References: <55829286.3060301@ast.cam.ac.uk> Message-ID: <55886CB6.1010005@ast.cam.ac.uk> Hi Just to report that my install just completed. Thats more than 5 days after starting, but it did it! The "hiding devices" gradually went slower and slower so my predictions of how long it was going to take were always way to optimistic. Roderick On 18/06/2015 10:42, Roderick Johnstone 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 From anders.blomdell at control.lth.se Tue Jun 23 18:34:53 2015 From: anders.blomdell at control.lth.se (Anders Blomdell) Date: Tue, 23 Jun 2015 20:34:53 +0200 Subject: Problems installing Fedora-22 on a system with 2 lvms Message-ID: <5589A6CD.40807@control.lth.se> Hi, I have a system with 4 disk, formatted as follows: # gdisk -l /dev/sda GPT fdisk (gdisk) version 1.0.0 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sda: 976773168 sectors, 465.8 GiB Logical sector size: 512 bytes Disk identifier (GUID): 43F1E071-26B9-4D53-8BDA-A3D530A2FFDC Partition table holds up to 128 entries First usable sector is 34, last usable sector is 976773134 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector) End (sector) Size Code Name 1 2048 4095 1024.0 KiB EF02 bios 2 4096 20975615 10.0 GiB FD00 boot 3 20975616 976773134 455.8 GiB FD00 lvm # gdisk -l /dev/sdb GPT fdisk (gdisk) version 1.0.0 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sdb: 976773168 sectors, 465.8 GiB Logical sector size: 512 bytes Disk identifier (GUID): 2949E789-9EE3-4456-BBCF-604EECD823D3 Partition table holds up to 128 entries First usable sector is 34, last usable sector is 976773134 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector) End (sector) Size Code Name 1 2048 4095 1024.0 KiB EF02 bios 2 4096 20975615 10.0 GiB FD00 boot 3 20975616 976773134 455.8 GiB FD00 lvm # gdisk -l /dev/sdc GPT fdisk (gdisk) version 1.0.0 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sdc: 11721045168 sectors, 5.5 TiB Logical sector size: 512 bytes Disk identifier (GUID): BA3D89D5-BB20-4CA5-9B53-18A1189D825A Partition table holds up to 128 entries First usable sector is 34, last usable sector is 11721045134 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector) End (sector) Size Code Name 1 2048 11721045134 5.5 TiB FD00 vg1 # gdisk -l /dev/sdd GPT fdisk (gdisk) version 1.0.0 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sdd: 11721045168 sectors, 5.5 TiB Logical sector size: 512 bytes Disk identifier (GUID): EB695880-E336-4814-87CF-818C37D0939C Partition table holds up to 128 entries First usable sector is 34, last usable sector is 11721045134 Partitions will be aligned on 2048-sector boundaries Total free space is 2014 sectors (1007.0 KiB) Number Start (sector) End (sector) Size Code Name 1 2048 11721045134 5.5 TiB FD00 vg1 When I try to use this with kickstart like this: part raid.0 --noformat --onpart=sda2 part raid.2 --noformat --onpart=sda3 part raid.1 --noformat --onpart=sdb2 part raid.3 --noformat --onpart=sdb3 part raid.4 --noformat --onpart=sdc1 part raid.5 --noformat --onpart=sdd1 raid pv.0 --device=UUID=f7593b3e-6c01-df74-af43-6febfa2a73d7 --noformat raid pv.1 --device=UUID=48b2669a-0463-e3ee-4a47-4d3ff89a9662 --noformat raid /boot --device=UUID=bdc393c8-22b6-55be-d360-30a7ba44fd0f --fstype=ext4 --label=/boot --useexisting volgroup vg0 --noformat volgroup vg1 --noformat logvol /opt --fstype=ext4 --label=/opt --name=opt --useexisting --vgname=vg0 logvol / --fstype=ext4 --label=/ --name=root --useexisting --vgname=vg0 logvol /usr/src --fstype=ext4 --label=/usr/src --name=src --noformat --vgname=vg0 logvol swap --fstype=swap --name=swap --useexisting --vgname=vg0 logvol /dvdbackup --fstype=ext4 --label=/dvdbackup --name=dvdbackup --noformat --vgname=vg1 logvol swap --fstype=swap --name=swap --useexisting --vgname=vg1 Anaconda gets an exception: anaconda 22.20.13-1 exception report Traceback (most recent call first): File "/usr/lib64/python2.7/site-packages/gi/overrides/BlockDev.py", line 384, in wrapped raise transform[1](msg) File "/usr/lib/python2.7/site-packages/blivet/devices/lvm.py", line 628, in _setup blockdev.lvm.lvactivate(self.vg.name, self._name) File "/usr/lib/python2.7/site-packages/blivet/devices/storage.py", line 430, in setup self._setup(orig=orig) File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 661, in execute self.device.setup(orig=True) File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 362, in processActions action.execute(callbacks) File "/usr/lib/python2.7/site-packages/blivet/blivet.py", line 162, in doIt self.devicetree.processActions(callbacks) File "/usr/lib/python2.7/site-packages/blivet/osinstall.py", line 1057, in turnOnFilesystems storage.doIt(callbacks) File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 196, in doInstall turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall, callbacks=callbacks_reg) File "/usr/lib64/python2.7/threading.py", line 766, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 244, in run threading.Thread.run(self, *args, **kwargs) LVMError: Process reported exit code 1280: Volume group "vg1" not found Cannot process volume group vg1 Local variables in innermost frame: e: g-bd-utils-exec-error-quark: Process reported exit code 1280: Volume group "vg1" not found Cannot process volume group vg1 (0) orig_obj: self: args: ('vg1', 'swap') transform: (, ) e_type: kwargs: {} msg: Process reported exit code 1280: Volume group "vg1" not found Cannot process volume group vg1 The reason seems to be that anaconda stops the second lvm (vg1) at some point (i.e it's not visible when doing an 'lvs' until I do a 'pvscan --cache' in tty2), even though it shows up in program.log (grep 'vg1' /tmp/program.log): MD_NAME=lie:vg1 17:35:32,359 INFO program: stdout[30]: ARRAY /dev/md/vg1 metadata=1.2 UUID=f7593b3e:6c01df74:af436feb:fa2a73d7 name=lie:vg1 MD_NAME=lie:vg1 17:35:32,501 INFO program: stdout[34]: ARRAY /dev/md/vg1 metadata=1.2 UUID=f7593b3e:6c01df74:af436feb:fa2a73d7 name=lie:vg1 LVM2_PV_NAME=/dev/md/vg1 LVM2_PV_UUID=Ick4oK-yuuv-Q0e6-7IMy-haTS-ojMY-kTtiJa LVM2_PE_START=1048576 LVM2_VG_NAME=vg1 LVM2_VG_UUID=GND1Fh-9uOJ-VozS-gZHX-c87h-m3HU-uszs5G LVM2_VG_SIZE=6001038196736 LVM2_VG_FREE=1706066706432 LVM2_VG_EXTENT_SIZE=4194304 LVM2_VG_EXTENT_COUNT=1430759 LVM2_VG_FREE_COUNT=406758 LVM2_PV_COUNT=1 LVM2_VG_NAME=vg1 LVM2_LV_NAME=dvdbackup LVM2_LV_UUID=RK6vlx-XFQb-6Fzz-Webs-jcen-k3HJ-icxdr1 LVM2_LV_SIZE=4294967296000 LVM2_LV_ATTR=-wi-a----- LVM2_SEGTYPE=linear LVM2_VG_NAME=vg1 LVM2_LV_NAME=swap LVM2_LV_UUID=rxYQGq-2GLg-b0Go-EqCi-09YJ-ay3z-pMyiCc LVM2_LV_SIZE=4194304 LVM2_LV_ATTR=-wi-a----- LVM2_SEGTYPE=linear 17:35:35,364 INFO program: Running [50] multipath -c /dev/md/vg1 ... 17:35:35,370 INFO program: stdout[50]: /dev/md/vg1 is not a valid multipath device path 17:35:35,567 INFO program: Running [51] multipath -c /dev/mapper/vg1-swap ... 17:35:35,703 INFO program: Running [52] multipath -c /dev/mapper/vg1-dvdbackup ... 17:35:35,710 INFO program: Running... e2fsck -f -p -C 0 /dev/mapper/vg1-dvdbackup 17:35:59,639 INFO program: Running... dumpe2fs -h /dev/mapper/vg1-dvdbackup 17:35:59,695 INFO program: Running... resize2fs -P /dev/mapper/vg1-dvdbackup 17:35:59,817 INFO program: Running [53] multipath -c /dev/mapper/vg1-swap ... 17:35:59,848 INFO program: Running [54] multipath -c /dev/md/vg1 ... 17:35:59,854 INFO program: stdout[54]: /dev/md/vg1 is not a valid multipath device path 17:36:01,812 INFO program: Running [61] lvm lvchange -an vg1/swap --config= devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] } ... 17:36:01,893 INFO program: Running [62] lvm vgchange -an vg1 --config= devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] } ... 17:36:01,946 INFO program: stdout[62]: 0 logical volume(s) in volume group "vg1" now active 17:36:01,971 INFO program: Running [63] mdadm --stop /dev/md/vg1 ... 17:36:02,505 INFO program: stderr[63]: mdadm: stopped /dev/md/vg1 17:36:08,328 INFO program: Running [81] mdadm --assemble /dev/md/vg1 --run --uuid=f7593b3e:6c01df74:af436feb:fa2a73d7 /dev/sdc1 /dev/sdd1 ... 17:36:08,443 INFO program: stderr[81]: mdadm: /dev/md/vg1 has been started with 2 drives. 17:36:08,591 INFO program: Running [82] lvm lvchange -ay vg1/dvdbackup --config= devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] } ... 17:36:08,635 INFO program: Running... mount -t ext4 -o defaults,ro /dev/mapper/vg1-dvdbackup /mnt/sysimage 17:36:08,812 INFO program: Running [83] lvm lvchange -an vg1/dvdbackup --config= devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] } ... 17:36:08,882 INFO program: Running [84] lvm vgchange -an vg1 --config= devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] } ... 17:36:08,930 INFO program: stdout[84]: 0 logical volume(s) in volume group "vg1" now active 17:36:08,950 INFO program: Running [85] mdadm --stop /dev/md/vg1 ... 17:36:09,766 INFO program: stderr[85]: mdadm: stopped /dev/md/vg1 17:36:32,782 INFO program: Running [86] mdadm --assemble /dev/md/vg1 --run --uuid=f7593b3e:6c01df74:af436feb:fa2a73d7 /dev/sdc1 /dev/sdd1 ... 17:36:32,818 INFO program: stderr[86]: mdadm: /dev/md/vg1 has been started with 2 drives. 17:36:32,923 INFO program: Running [87] lvm lvchange -ay vg1/swap --config= devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] } ... 17:36:32,949 INFO program: stderr[87]: Volume group "vg1" not found Cannot process volume group vg1 Anybody that has an idea of how to work around this? I get similar results when trying an ordinary install when trying to reuse the same partitions, see: https://bugzilla.redhat.com/show_bug.cgi?id=1234994 Regards Anders Blomdell -- Anders Blomdell Email: anders.blomdell at control.lth.se Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden From anders.blomdell at control.lth.se Tue Jun 23 19:45:38 2015 From: anders.blomdell at control.lth.se (Anders Blomdell) Date: Tue, 23 Jun 2015 21:45:38 +0200 Subject: Problems installing Fedora-22 on a system with 2 lvms In-Reply-To: <5589A6CD.40807@control.lth.se> References: <5589A6CD.40807@control.lth.se> Message-ID: <5589B762.4020501@control.lth.se> On 2015-06-23 20:34, Anders Blomdell wrote: > Hi, > > I have a system with 4 disk, formatted as follows: The reason for 4 disk was that the machine refused to boot a GPT formatted 6 TB disk. Running an ancient fdisk and setting the protective GPT entry as active solved that problem. /Anders > > # gdisk -l /dev/sda > GPT fdisk (gdisk) version 1.0.0 > > Partition table scan: > MBR: protective > BSD: not present > APM: not present > GPT: present > > Found valid GPT with protective MBR; using GPT. > Disk /dev/sda: 976773168 sectors, 465.8 GiB > Logical sector size: 512 bytes > Disk identifier (GUID): 43F1E071-26B9-4D53-8BDA-A3D530A2FFDC > Partition table holds up to 128 entries > First usable sector is 34, last usable sector is 976773134 > Partitions will be aligned on 2048-sector boundaries > Total free space is 2014 sectors (1007.0 KiB) > > Number Start (sector) End (sector) Size Code Name > 1 2048 4095 1024.0 KiB EF02 bios > 2 4096 20975615 10.0 GiB FD00 boot > 3 20975616 976773134 455.8 GiB FD00 lvm > > # gdisk -l /dev/sdb > GPT fdisk (gdisk) version 1.0.0 > > Partition table scan: > MBR: protective > BSD: not present > APM: not present > GPT: present > > Found valid GPT with protective MBR; using GPT. > Disk /dev/sdb: 976773168 sectors, 465.8 GiB > Logical sector size: 512 bytes > Disk identifier (GUID): 2949E789-9EE3-4456-BBCF-604EECD823D3 > Partition table holds up to 128 entries > First usable sector is 34, last usable sector is 976773134 > Partitions will be aligned on 2048-sector boundaries > Total free space is 2014 sectors (1007.0 KiB) > > Number Start (sector) End (sector) Size Code Name > 1 2048 4095 1024.0 KiB EF02 bios > 2 4096 20975615 10.0 GiB FD00 boot > 3 20975616 976773134 455.8 GiB FD00 lvm > > # gdisk -l /dev/sdc > GPT fdisk (gdisk) version 1.0.0 > > Partition table scan: > MBR: protective > BSD: not present > APM: not present > GPT: present > > Found valid GPT with protective MBR; using GPT. > Disk /dev/sdc: 11721045168 sectors, 5.5 TiB > Logical sector size: 512 bytes > Disk identifier (GUID): BA3D89D5-BB20-4CA5-9B53-18A1189D825A > Partition table holds up to 128 entries > First usable sector is 34, last usable sector is 11721045134 > Partitions will be aligned on 2048-sector boundaries > Total free space is 2014 sectors (1007.0 KiB) > > Number Start (sector) End (sector) Size Code Name > 1 2048 11721045134 5.5 TiB FD00 vg1 > > # gdisk -l /dev/sdd > GPT fdisk (gdisk) version 1.0.0 > > Partition table scan: > MBR: protective > BSD: not present > APM: not present > GPT: present > > Found valid GPT with protective MBR; using GPT. > Disk /dev/sdd: 11721045168 sectors, 5.5 TiB > Logical sector size: 512 bytes > Disk identifier (GUID): EB695880-E336-4814-87CF-818C37D0939C > Partition table holds up to 128 entries > First usable sector is 34, last usable sector is 11721045134 > Partitions will be aligned on 2048-sector boundaries > Total free space is 2014 sectors (1007.0 KiB) > > Number Start (sector) End (sector) Size Code Name > 1 2048 11721045134 5.5 TiB FD00 vg1 > > When I try to use this with kickstart like this: > > part raid.0 --noformat --onpart=sda2 > part raid.2 --noformat --onpart=sda3 > part raid.1 --noformat --onpart=sdb2 > part raid.3 --noformat --onpart=sdb3 > part raid.4 --noformat --onpart=sdc1 > part raid.5 --noformat --onpart=sdd1 > raid pv.0 --device=UUID=f7593b3e-6c01-df74-af43-6febfa2a73d7 --noformat > raid pv.1 --device=UUID=48b2669a-0463-e3ee-4a47-4d3ff89a9662 --noformat > raid /boot --device=UUID=bdc393c8-22b6-55be-d360-30a7ba44fd0f --fstype=ext4 --label=/boot --useexisting > volgroup vg0 --noformat > volgroup vg1 --noformat > logvol /opt --fstype=ext4 --label=/opt --name=opt --useexisting --vgname=vg0 > logvol / --fstype=ext4 --label=/ --name=root --useexisting --vgname=vg0 > logvol /usr/src --fstype=ext4 --label=/usr/src --name=src --noformat --vgname=vg0 > logvol swap --fstype=swap --name=swap --useexisting --vgname=vg0 > logvol /dvdbackup --fstype=ext4 --label=/dvdbackup --name=dvdbackup --noformat --vgname=vg1 > logvol swap --fstype=swap --name=swap --useexisting --vgname=vg1 > > Anaconda gets an exception: > > anaconda 22.20.13-1 exception report > Traceback (most recent call first): > File "/usr/lib64/python2.7/site-packages/gi/overrides/BlockDev.py", line 384, in wrapped > raise transform[1](msg) > File "/usr/lib/python2.7/site-packages/blivet/devices/lvm.py", line 628, in _setup > blockdev.lvm.lvactivate(self.vg.name, self._name) > File "/usr/lib/python2.7/site-packages/blivet/devices/storage.py", line 430, in setup > self._setup(orig=orig) > File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 661, in execute > self.device.setup(orig=True) > File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 362, in processActions > action.execute(callbacks) > File "/usr/lib/python2.7/site-packages/blivet/blivet.py", line 162, in doIt > self.devicetree.processActions(callbacks) > File "/usr/lib/python2.7/site-packages/blivet/osinstall.py", line 1057, in turnOnFilesystems > storage.doIt(callbacks) > File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 196, in doInstall > turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall, callbacks=callbacks_reg) > File "/usr/lib64/python2.7/threading.py", line 766, in run > self.__target(*self.__args, **self.__kwargs) > File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 244, in run > threading.Thread.run(self, *args, **kwargs) > LVMError: Process reported exit code 1280: Volume group "vg1" not found > Cannot process volume group vg1 > > > Local variables in innermost frame: > e: g-bd-utils-exec-error-quark: Process reported exit code 1280: Volume group "vg1" not found > Cannot process volume group vg1 > (0) > orig_obj: > self: > args: ('vg1', 'swap') > transform: (, ) > e_type: > kwargs: {} > msg: Process reported exit code 1280: Volume group "vg1" not found > Cannot process volume group vg1 > > The reason seems to be that anaconda stops the second lvm (vg1) at some point > (i.e it's not visible when doing an 'lvs' until I do a 'pvscan --cache' in tty2), even > though it shows up in program.log (grep 'vg1' /tmp/program.log): > > MD_NAME=lie:vg1 > 17:35:32,359 INFO program: stdout[30]: ARRAY /dev/md/vg1 metadata=1.2 UUID=f7593b3e:6c01df74:af436feb:fa2a73d7 name=lie:vg1 > MD_NAME=lie:vg1 > 17:35:32,501 INFO program: stdout[34]: ARRAY /dev/md/vg1 metadata=1.2 UUID=f7593b3e:6c01df74:af436feb:fa2a73d7 name=lie:vg1 > LVM2_PV_NAME=/dev/md/vg1 LVM2_PV_UUID=Ick4oK-yuuv-Q0e6-7IMy-haTS-ojMY-kTtiJa LVM2_PE_START=1048576 LVM2_VG_NAME=vg1 LVM2_VG_UUID=GND1Fh-9uOJ-VozS-gZHX-c87h-m3HU-uszs5G LVM2_VG_SIZE=6001038196736 LVM2_VG_FREE=1706066706432 LVM2_VG_EXTENT_SIZE=4194304 LVM2_VG_EXTENT_COUNT=1430759 LVM2_VG_FREE_COUNT=406758 LVM2_PV_COUNT=1 > LVM2_VG_NAME=vg1 LVM2_LV_NAME=dvdbackup LVM2_LV_UUID=RK6vlx-XFQb-6Fzz-Webs-jcen-k3HJ-icxdr1 LVM2_LV_SIZE=4294967296000 LVM2_LV_ATTR=-wi-a----- LVM2_SEGTYPE=linear > LVM2_VG_NAME=vg1 LVM2_LV_NAME=swap LVM2_LV_UUID=rxYQGq-2GLg-b0Go-EqCi-09YJ-ay3z-pMyiCc LVM2_LV_SIZE=4194304 LVM2_LV_ATTR=-wi-a----- LVM2_SEGTYPE=linear > 17:35:35,364 INFO program: Running [50] multipath -c /dev/md/vg1 ... > 17:35:35,370 INFO program: stdout[50]: /dev/md/vg1 is not a valid multipath device path > 17:35:35,567 INFO program: Running [51] multipath -c /dev/mapper/vg1-swap ... > 17:35:35,703 INFO program: Running [52] multipath -c /dev/mapper/vg1-dvdbackup ... > 17:35:35,710 INFO program: Running... e2fsck -f -p -C 0 /dev/mapper/vg1-dvdbackup > 17:35:59,639 INFO program: Running... dumpe2fs -h /dev/mapper/vg1-dvdbackup > 17:35:59,695 INFO program: Running... resize2fs -P /dev/mapper/vg1-dvdbackup > 17:35:59,817 INFO program: Running [53] multipath -c /dev/mapper/vg1-swap ... > 17:35:59,848 INFO program: Running [54] multipath -c /dev/md/vg1 ... > 17:35:59,854 INFO program: stdout[54]: /dev/md/vg1 is not a valid multipath device path > 17:36:01,812 INFO program: Running [61] lvm lvchange -an vg1/swap --config= devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] } ... > 17:36:01,893 INFO program: Running [62] lvm vgchange -an vg1 --config= devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] } ... > 17:36:01,946 INFO program: stdout[62]: 0 logical volume(s) in volume group "vg1" now active > 17:36:01,971 INFO program: Running [63] mdadm --stop /dev/md/vg1 ... > 17:36:02,505 INFO program: stderr[63]: mdadm: stopped /dev/md/vg1 > 17:36:08,328 INFO program: Running [81] mdadm --assemble /dev/md/vg1 --run --uuid=f7593b3e:6c01df74:af436feb:fa2a73d7 /dev/sdc1 /dev/sdd1 ... > 17:36:08,443 INFO program: stderr[81]: mdadm: /dev/md/vg1 has been started with 2 drives. > 17:36:08,591 INFO program: Running [82] lvm lvchange -ay vg1/dvdbackup --config= devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] } ... > 17:36:08,635 INFO program: Running... mount -t ext4 -o defaults,ro /dev/mapper/vg1-dvdbackup /mnt/sysimage > 17:36:08,812 INFO program: Running [83] lvm lvchange -an vg1/dvdbackup --config= devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] } ... > 17:36:08,882 INFO program: Running [84] lvm vgchange -an vg1 --config= devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] } ... > 17:36:08,930 INFO program: stdout[84]: 0 logical volume(s) in volume group "vg1" now active > 17:36:08,950 INFO program: Running [85] mdadm --stop /dev/md/vg1 ... > 17:36:09,766 INFO program: stderr[85]: mdadm: stopped /dev/md/vg1 > 17:36:32,782 INFO program: Running [86] mdadm --assemble /dev/md/vg1 --run --uuid=f7593b3e:6c01df74:af436feb:fa2a73d7 /dev/sdc1 /dev/sdd1 ... > 17:36:32,818 INFO program: stderr[86]: mdadm: /dev/md/vg1 has been started with 2 drives. > 17:36:32,923 INFO program: Running [87] lvm lvchange -ay vg1/swap --config= devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] } ... > 17:36:32,949 INFO program: stderr[87]: Volume group "vg1" not found > Cannot process volume group vg1 > > > Anybody that has an idea of how to work around this? I get similar results when trying an > ordinary install when trying to reuse the same partitions, see: https://bugzilla.redhat.com/show_bug.cgi?id=1234994 > > Regards > > Anders Blomdell > > -- Anders Blomdell Email: anders.blomdell at control.lth.se Department of Automatic Control Lund University Phone: +46 46 222 4625 P.O. Box 118 Fax: +46 46 138118 SE-221 00 Lund, Sweden