Re: F26 Self Contained Change: Anaconda LVM RAID
On Tue, 2017-01-31 at 15:52 -0400, Robert Marcano wrote: > On 01/31/2017 03:44 PM, Chris Adams wrote: > > > > Also: does this apply to /boot partition RAID 1? IIRC that didn't > > work > > with LVM RAID at one time. > > > > This is important, that mdraid is still available in anaconda and > not > entirely replaced by LVM RAID. Not only /boot partition but UEFI > boot > partition on mdraid 1 My understanding is that this only applies to "LVM on RAID" layouts. If you create /boot in anaconda and set the device type to "Software RAID" it will be created and managed with mdadm. It's only if you set a RAID level on an LVM volume group that you will be affected by this change. Change owners/sponsors, please correct me if I'm wrong. David > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Fedora Rawhide-20160915.n.0 compose check report
On Thu, 2016-09-15 at 22:28 -0700, Adam Williamson wrote: > On Fri, 2016-09-16 at 04:45 +, Fedora compose checker wrote: > > > > New failures (same test did not fail in Rawhide-20160914.n.0): > > > > > > ID: 34503 Test: x86_64 Server-dvd-iso > > server_realmd_join_kickstart > > URL: https://openqa.fedoraproject.org/tests/34503 > > ID: 34520 Test: x86_64 universal install_delete_pata > > URL: https://openqa.fedoraproject.org/tests/34520 > > ID: 34521 Test: x86_64 universal install_delete_pata@uefi > > URL: https://openqa.fedoraproject.org/tests/34521 > > ID: 34524 Test: x86_64 universal install_multi > > URL: https://openqa.fedoraproject.org/tests/34524 > > ID: 34530 Test: x86_64 universal install_delete_partial > > URL: https://openqa.fedoraproject.org/tests/34530 > > ID: 34542 Test: x86_64 universal install_delete_partial@uefi > > URL: https://openqa.fedoraproject.org/tests/34542 > > ID: 34548 Test: x86_64 universal install_kickstart_hdd > > URL: https://openqa.fedoraproject.org/tests/34548 > This looks like a crop of genuine new failures, probably related to > the > new python-blivet; I'll investigate and file bugs tomorrow. david, if > you want to get a head start, you can find all the logs on the Logs & > Assets tab for each test (except for the kickstart tests; kickstart > tests don't upload logs when they fail, it's an issue with how the > tests are set up that I keep meaning to fix...) I'm taking Friday off. Several of those are missing the anaconda-tb file, but I think the following patch will fix it for now. If you feel it's necessary, you are welcome to add that in dist-git and do a -2 build. If not, I'll see to it that it gets fixed on Monday. diff --git a/blivet/deviceaction.py b/blivet/deviceaction.py index 01f6431..5132107 100644 --- a/blivet/deviceaction.py +++ b/blivet/deviceaction.py @@ -693,8 +693,6 @@ class ActionDestroyFormat(DeviceAction): if isinstance(self.device, PartitionDevice) and self.device.disklabel_supported: if self.format.parted_flag: self.device.unset_flag(self.format.parted_flag) -if self.format.parted_system is not None: -self.device.parted_partition.system = None self.device.disk.format.commit_to_disk() super(ActionDestroyFormat, self).execute(callbacks=callbacks) status = self.device.status David ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Announce: blivet-2.0.0
Hi everyone, I would like to announce the release of blivet-2.0.0[1]. See the release notes[2] for information about all of the changes in this version and the documentation[3] for the public API specification. Some of the larger changes: - full PEP8 compliance - thread-safety - added support for creating LVM RAID volumes - added support for resizing LUKS encrypted block devices - use libbytesize[4] as the backend for blivet's Size class - device tree updates based on uevents (disabled by default) - dropped support for python2 For now there is a blivet-2.0.0 build in my copr[5] for anyone who wants to check it out. I also want to give a heads-up that I plan to build blivet-2.0.1 in rawhide next week, which means switching anaconda to use it at that time. Thanks, David [1] https://github.com/rhinstaller/blivet/releases/tag/blivet-2.0.0 [2] https://github.com/rhinstaller/blivet/blob/2.0-release/release_note s.rst [3] http://rhinstaller.github.io/blivet/docs/api.html [4] https://github.com/rhinstaller/libbytesize [5] https://copr.fedorainfracloud.org/coprs/dlehman/blivet/ -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: default btrfs partitioning setup
On 06/02/2015 06:08 AM, Neal Becker wrote: I have an older setup created by anaconda from 2013, and it looks like UUID=7246327b-1905-4fe2-9b6b-b9376017264f / btrfs subvolid=5,subvol=root00 0 0 UUID=2c04be93-34c1-4016-ba41-60fd9fd90616 /boot ext4 defaults1 2 UUID=7246327b-1905-4fe2-9b6b-b9376017264f /home btrfs subvol=home 0 0 So we have only 1 disk. There is 1 btrfs partition, but root and home are 2 different btrfs subvolumes. This is a good setup IMO, since I can reinstall the OS without touching home. I recently got a laptop and did F21 install using btrfs, and I believe I used automatic partitioning. This time, I got just 1 btrfs subvol with home as a subdir, which does not offer the flexibility. I suggest the default for btrfs should be as shown above, with home on a separate subvol. This has not been changed intentionally. If it has indeed changed you should file a bug including the logs from installation, which are in /tmp during installation and in /var/log/anaconda afterwards. Thanks, David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: libblockdev reaches the 1.0 milestone!
On 05/25/2015 08:56 PM, Dennis Jacobfeuerborn wrote: On 21.05.2015 20:08, Vratislav Podzimek wrote: A year ago, I started working on a new storage library for low-level operations with various types of block devices -- *libblockdev*. Today, I'm happy to announce that the library reached the **1.0** milestone which means that it covers all the functionality that has been stated in the initial goals and it's going to keep the API stable. Read the blog post I wrote for more information: http://blog-vpodzime.rhcloud.com/?p=61 This looks very interesting. I don't see any function to deal with plain old block devices though just LVM, MD Raid, etc. Is this correct or am I missing something? There is no support yet for partitions. The libblockdev roadmap[1] shows a target of early August for v2.0 to include partitioning and filesystem plugins. David [1] https://github.com/rhinstaller/libblockdev/blob/master/roadmap.rst Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Does your application depend on, or report, free disk space? Re: F20 Self Contained Change: OS Installer Support for LVM Thin Provisioning
On Fri, 2013-07-26 at 22:59 +0200, Miloslav Trmač wrote: > On Fri, Jul 26, 2013 at 10:17 PM, DJ Delorie wrote: > > > >> If your package reports disk space usage to users, and bases this on > >> filesystem free space, please consider whether it might need to take > >> LVM thin provisioning into account. > > > > Perhaps you could include a small code snippet explaining *how* to do > > this? Is there an lvm_thin_statfs() we can use? > > I'd love to, but I don't know how. David, could you suggest something, > please? As noted by drago01, this is not exactly new or specific to thinp -- a similar situation exists with btrfs. You would have to ask the developers of lvm and btrfs for a way to decode the magic. I don't know any manageable solution to this problem. > Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: when startup delays become bugs
On Fri, 2013-05-17 at 17:45 +0200, Lennart Poettering wrote: > On Fri, 17.05.13 10:18, David Lehman (dleh...@redhat.com) wrote: > > > On Fri, 2013-05-17 at 09:07 +0200, Hans de Goede wrote: > > > Hi, > > > > > > On 05/17/2013 01:31 AM, Lennart Poettering wrote: > > > > On Thu, 16.05.13 16:17, Bill Nottingham (nott...@redhat.com) wrote: > > > > > > > >> Lennart Poettering (mzerq...@0pointer.de) said: > > > >>>> RequiredBy= > > > >>>> WantedBy=dmraid-activation.service > > > >>>> > > > >>>> I'm not using dmraid, or md raid, or any kind of raid at the moment. > > > >>>> I also have this entry, previously explained in this thread as > > > >>>> probably not being needed unless dmraid is being used, so is the > > > >>>> likely offender for udev-settle. > > > >>>> > > > >>>>2.823s dmraid-activation.service > > > >>> > > > >>> Given that this is really only needed for exotic stuff I do wonder why > > > >>> we need to install this by default even. > > > >> > > > >> We *could* drop all the assorted local storage tools from @standard > > > >> and just leave > > > >> them to be installed by anaconda if they're being used to create such > > > >> storage. They'd have to remain on the live image, though, and so this > > > >> would > > > >> not help installs done from the live images. > > > > > > > > Does anaconda have infrastructure for this? > > > > > > Yes, it already drags in for example iscsi-initiator-utils automatically > > > when > > > iscsi disks are used during install. IIRC doing the same for dmraid should > > > not be hard. > > > > This has been in place since somewhere around F11 or F12. You just can't > > tell since dmraid is in base. There is still the anaconda-tools group, > > which I forget the purpose of (live media?). > > So, are you saying we could simply drop dmraid from base, and anaconda > would do the right thing and install it when dmraid is used for the > installation? Yes. Likewise lvm2, mdadm, cryptsetup, e2fsprogs, and whatever other storage-specific packages are in there. > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: when startup delays become bugs
On Fri, 2013-05-17 at 09:07 +0200, Hans de Goede wrote: > Hi, > > On 05/17/2013 01:31 AM, Lennart Poettering wrote: > > On Thu, 16.05.13 16:17, Bill Nottingham (nott...@redhat.com) wrote: > > > >> Lennart Poettering (mzerq...@0pointer.de) said: > RequiredBy= > WantedBy=dmraid-activation.service > > I'm not using dmraid, or md raid, or any kind of raid at the moment. I > also have this entry, previously explained in this thread as probably > not being needed unless dmraid is being used, so is the likely offender > for udev-settle. > > 2.823s dmraid-activation.service > >>> > >>> Given that this is really only needed for exotic stuff I do wonder why > >>> we need to install this by default even. > >> > >> We *could* drop all the assorted local storage tools from @standard and > >> just leave > >> them to be installed by anaconda if they're being used to create such > >> storage. They'd have to remain on the live image, though, and so this would > >> not help installs done from the live images. > > > > Does anaconda have infrastructure for this? > > Yes, it already drags in for example iscsi-initiator-utils automatically when > iscsi disks are used during install. IIRC doing the same for dmraid should > not be hard. This has been in place since somewhere around F11 or F12. You just can't tell since dmraid is in base. There is still the anaconda-tools group, which I forget the purpose of (live media?). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How do *you* use Fedora?
On Fri, 2013-04-05 at 08:59 -0600, Pete Travis wrote: > On Thu, Apr 4, 2013 at 9:55 AM, David Lehman > wrote: > On Thu, 2013-04-04 at 08:59 -0400, Matthew Miller wrote: > > On Wed, Apr 03, 2013 at 08:29:21AM -0600, Pete Travis wrote: > > > equated to the memory requirements for the running > environment, especially > > > for cloud guests. @minimal requires less memory to install > than a full > > > desktop - but does anyone want to run Fedora with less > memory than that, or > > > is doing so venturing out of reasonable guidelines and > into > > > proof-of-concept adventureland? > > > > Yes, people want to run Fedora in VMs with less memory than > that. (Key > > demographic: large computer science classes.) > > > Would those classes be installing the VMs themselves, or would > the > instructor/assistant do that beforehand? If the latter, this > is a > perfect case for anaconda's install-to-a-disk-image-file > capability and > makes little sense to handle by doing dozens of interactive > installations. > > Dave > > > > > I wasn't aware of this compelling capability. I experimented with it a > bit; encouragingly, I can create an image with qcow-create that > anaconda recognizes, but I haven't sorted out how to run anaconda from > the command line without it taking over the system that runs it, with > varying degrees of success. The functionality seems... inconsistent. > Is this the way I'm using it[1] ? > > > [1] ssh to a guest to I don't kill my workstation > # ssh targetvm anaconda --kickstart=http://host/ks.cfg > --image=/root/anaconda.img I found a bug just a few minutes ago that would prevent disk image installs from working as expected [1]. There may be other issues lurking as this is an under-used piece of functionality. Your usage seems fine. [1] When disk images are specified they automatically become the exclusive set of usable disks. The bug I found earlier marks all disks, including the disk image, as unusable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How do *you* use Fedora?
On Thu, 2013-04-04 at 08:59 -0400, Matthew Miller wrote: > On Wed, Apr 03, 2013 at 08:29:21AM -0600, Pete Travis wrote: > > equated to the memory requirements for the running environment, especially > > for cloud guests. @minimal requires less memory to install than a full > > desktop - but does anyone want to run Fedora with less memory than that, or > > is doing so venturing out of reasonable guidelines and into > > proof-of-concept adventureland? > > Yes, people want to run Fedora in VMs with less memory than that. (Key > demographic: large computer science classes.) Would those classes be installing the VMs themselves, or would the instructor/assistant do that beforehand? If the latter, this is a perfect case for anaconda's install-to-a-disk-image-file capability and makes little sense to handle by doing dozens of interactive installations. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: well!
On Tue, 2013-03-12 at 20:17 +0100, Till Maas wrote: > On Tue, Mar 12, 2013 at 12:47:07AM -0400, Digimer wrote: > > On 03/12/2013 12:41 AM, Charles Zeitler wrote: > > >i don't like giving up control over my machine (partitioning), > > >so i won't be upgrading to Fedora 18. > > >i'll watch the web site for a return to sanity. > > > > > >charles zeitler > > > > Setting aside the drama, you can manually partition F18. > > Unless anaconda crashes (live image) or does not recognise the > partitions (DVD image). :-/ > Reference: https://bugzilla.redhat.com/show_bug.cgi?id=905669 Got a bug link for the DVD issue? > > Btw.: Ideas how to install F18 anyhow are welcome. > > > Regards > Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Thu, 2013-01-17 at 07:46 +1030, William Brown wrote: > On Wed, 2013-01-16 at 13:17 -0700, Kevin Fenzi wrote: > > On Wed, 16 Jan 2013 12:18:37 -0500 > > Josef Bacik wrote: > > > > > I'm waiting until Anaconda settles down before I pursue btrfs in > > > Fedora again. Things change too much and Btrfs is too reliant on the > > > anaconda part working properly to even bother trying to push it > > > through at this point. Thanks, > > > > Well, I hope we are entering a period of bugfixing and incremental > > improvement in anaconda since we have the new code in now. ;) > > > > FWIW, I installed with btrfs with the f18 installer and it worked fine. > > (encrypted volume with / and /home subvolumes). I kept /boot as ext4 > > due to a anaconda issue, which I think has already been fixed. > > > > So, you might want to talk to anaconda folks and get their feedback... > > > > kevin > > Did the root volume (/) Go into it's own subvolume, or is root just > in /? > > If root isn't placed into a subvolume, say /root then mounted > as /dev/sda1 subvolid=255 / lets say, you can't snapshot the root fs, > which defeats the whole point of using btrfs . In F18 every btrfs mountpoint you create gets a subvolume unless you use kickstart custom partitioning and don't use subvols. > > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On Wed, 2012-11-21 at 14:01 -0600, David Lehman wrote: > On Wed, 2012-11-21 at 12:09 -0600, Ian Pilcher wrote: > > On 10/19/2012 10:01 AM, David Lehman wrote: > > > This is the main piece of functionality that's still missing: allocating > > > devices from preexisting VGs. > > > > > > You can create and destroy lvm devices. You can reuse existing LVs, > > > optionally reformatting them. You can encrypt or decrypt them. What you > > > cannot do is allocate new LVs from old VGs. That's sort of the last item > > > on the TODO list. > > > > It looks like this is still the case in beta RC1, right? > > Yes. I've just completed testing of patches for this stuff. It was > decided that it's too late to try to get them into the Beta. I can > provide you with an updates image that adds the functionality if you are > interested. See https://bugzilla.redhat.com/show_bug.cgi?id=860677#c10 > > David > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On Wed, 2012-11-21 at 12:09 -0600, Ian Pilcher wrote: > On 10/19/2012 10:01 AM, David Lehman wrote: > > This is the main piece of functionality that's still missing: allocating > > devices from preexisting VGs. > > > > You can create and destroy lvm devices. You can reuse existing LVs, > > optionally reformatting them. You can encrypt or decrypt them. What you > > cannot do is allocate new LVs from old VGs. That's sort of the last item > > on the TODO list. > > It looks like this is still the case in beta RC1, right? Yes. I've just completed testing of patches for this stuff. It was decided that it's too late to try to get them into the Beta. I can provide you with an updates image that adds the functionality if you are interested. David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 2012-11-08 at 20:47 +, "Jóhann B. Guðmundsson" wrote: > On 11/08/2012 08:40 PM, David Lehman wrote: > > No. It is an inevitable consequence of the feature set demanded of the > > Fedora OS installer. > > > > If thing A must be able to set up and configure thing B and thing B > > changes in ways directly related to said configuration, how can you > > reasonably expect thing A to continue to be able to configure thing B > > without corresponding changes? Magic? > > I'm all for magic but I would expect specific configuration package(s) > and or a configuration template tailored for the component being install > which the installer might use or the package himself would simply do it > post install. > > Are there any specific use case where that would not suffice? One example of such a configuration package used to be system-config-firewall. Where is it now? What would happen if the installer were still calling "lokkit" to set up the firewall? It wouldn't work because the way that's handled has changed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 18 Beta to slip by two weeks, Beta release date is now Nov 27
On Thu, 2012-11-08 at 17:20 +, "Jóhann B. Guðmundsson" wrote: > On 11/08/2012 05:14 PM, Stephen John Smoogen wrote: > > On 8 November 2012 10:06, "Jóhann B. Guðmundsson" > > wrote: > >> On 11/08/2012 04:37 PM, Matthew Garrett wrote: > >>> On Thu, Nov 08, 2012 at 04:32:29PM +, "Jóhann B. Guðmundsson" wrote: > >>> > Or if I rephrase why could not the community continue to use > Anaconda in it's form that it existed in F17 until the "new > installer" was *completly* done? > >>> Because nobody in the community did the work to make the F17 Anaconda > >>> work in F18? > >>> > >> This also touches on "Who's responsible for an feature" > >> > >> Just recently FESCO decided *for* Kay that he was responsible to ensure the > >> migration related docs and what not kept working for the name change of > >> configuration files that takes place in systemd ( which was not even a > >> feature ) Applying the same logic here the Anaconda developers themselves > >> would have been responsible keeping the "old code" working until the new > >> one > >> was ready to completely replace it. > >> > > Your problem is that you are assuming a lot of things without actually > > doing any legwork to find out what anaconda does. Anaconda does a lot > > of probing of hardware which changes when kernels change. Anaconda > > requires changes when dracut changes APIs. Every release requires > > changes in what is blacklisted and what is not blacklisted. It > > requires dealing with the usual multiple changes in python apis and > > such. It has other changes due to EFI or secure boot or other > > features. None of them are trivial and doing them in parallel is > > usually not possible. > > Not that your response is relate to who's responsible for making those > changes, but is that not a fundamental flaw in the installer and it's > design? No. It is an inevitable consequence of the feature set demanded of the Fedora OS installer. If thing A must be able to set up and configure thing B and thing B changes in ways directly related to said configuration, how can you reasonably expect thing A to continue to be able to configure thing B without corresponding changes? Magic? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda is totally trashing the F18 schedule (was Re: f18: how to install into a LVM partitions (or RAID))
On Thu, 2012-11-01 at 13:01 +, "Jóhann B. Guðmundsson" wrote: > On 11/01/2012 12:22 PM, Michael Scherer wrote: > > Maybe having some kind of dependencies between feature could also be a > > idea. Anaconda requires dracut to not change, so we need a way to > > express this, and a way to avoid changes at the same time. The same goes > > for a python upgrade or lots of things. > > It would be good if any of the Anaconda developers could comment what > external components can affect Anaconda and to what extend atleast if > I'm not mistaken these external components can affect Anaconda > > Kernel > Dracut > Systemd > NetworkManager > Changes in comps/packaging group ( rpm/yum? ) lvm mdadm btrfs-progs -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On Mon, 2012-10-29 at 16:15 +0100, Dario Lesca wrote: > Il giorno lun, 29/10/2012 alle 09.05 -0500, David Lehman ha scritto: > > Just select that device and enter the desired mountpoint without > > changing the filesystem type or activating the "Reformat" > > checkbutton. > > Where is the "Reformat" checkbutton? If your version of anaconda is too old to have a "Reformat" checkbutton that is one less thing for you to worry about in this procedure. It was not introduced until after TC6. > > sorry, but I do not see (see screenshot) > > Thanks > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On Mon, 2012-10-29 at 01:06 +0100, Dario Lesca wrote: > Il giorno mar, 16/10/2012 alle 13.22 -0500, David Lehman ha scritto: > > Repeat for swap. (Hint: enter "swap" as the mountpoint > > when adding the device initially) > > > Ok, thanks, this steps work with a TC6. > > There is a method to use and mount a previous partition (es. /home > or /opt) without format it? Just select that device and enter the desired mountpoint without changing the filesystem type or activating the "Reformat" checkbutton. > > Many thanks > > -- > Dario Lesca - sip:da...@solinos.it > (Inviato dal mio Linux Fedora 17 Gnome3) > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On Fri, 2012-10-26 at 09:36 -0500, Ian Pilcher wrote: > On 10/25/2012 10:46 AM, David Lehman wrote: > > It is planned (but at risk) for the beta and a must-have for GA. > > If it's a must-have for GA, but it isn't in the beta, how does it get > tested? Before it goes in it will be discussed by the installer team and qa and rel-eng and whoever else needs to be involved and a decision will be made as to whether to include it. > > -- > > Ian Pilcher arequip...@gmail.com > Sometimes there's nothing left to do but crash and burn...or die trying. > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for anaconda LVM/RAID support
On Sun, 2012-10-07 at 12:10 +0200, Milan Broz wrote: > On 10/07/2012 02:36 AM, Ian Pilcher wrote: > > I'm sure that this information is somewhere on the Fedora Wiki, but my > > search-fu apparently isn't up to the task of finding it. > > > > What are the plans for LVM and/or software RAID support? > > > > Currently (F18 Beta TC2), it seems to be impossible for those of us who > > have fully allocated our storage to either (or both) of these > > technologies to install Fedora 18 at all. > > Seems disk encryption (LUKS) is impossible to configure in TC2 as well > (neither with LVM nor without LVM). > Usually the installer crashes when trying any custom change, which seems > to be known bug according to https://fedoraproject.org/wiki/Anaconda/Work_List Block device encryption support was added the same week as this post. > > Actually, I though beta should be feature complete for testing > (ok, 2 days left still :-), did I miss some approved plan to remove extended > storage features (like iSCSI) and LVM, RAID and LUKS installation > from Fedora graphical installer support for F18? LVM and MD support are both present and have been since the time of this post. > > Al it seems to head to "write your kickstart script manually if you need such > things". > > It means F18 GUI installation will be completely unusable for people > requiring enterprise features but unable to write own kickstart themselves. Such people need to either hire a sysadmin or fire their current one. If you're doing things sufficiently advanced as to require enterprise storage functionality you should have the capability to write a simple, well-defined, well-documented plain text configuration file. Come on. > > Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Anaconda is giving birth to Blivet
The anaconda package is going to be rearranged somewhat for F19. The package is going to be split into three pieces. The main anaconda package will contain only the pyanaconda python module, while the install-time bits and their dependencies will be split out into a sub-package. This will enable other projects that use the pyanaconda module to install it without having to also install all of the installer's runtime dependencies. Finally, the current anaconda storage module will be split out into a new package: blivet. Blivet will be a python module providing system storage configuration functionality. It is expected to require anaconda -- at least initially. To be clear, blivet is a library -- not an application. The main functionality offered by blivet includes: - detection of existing system storage layout - model a set of storage configuration changes in memory before committing them to disk - create/destroy, resize, activate/deactivate devices and filesystems The split will occur early in the F19 development cycle. More information will come as things develop. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On Fri, 2012-10-19 at 18:24 -0500, Ian Pilcher wrote: > On 10/19/2012 10:01 AM, David Lehman wrote: > > You can create and destroy lvm devices. You can reuse existing LVs, > > optionally reformatting them. You can encrypt or decrypt them. What you > > cannot do is allocate new LVs from old VGs. That's sort of the last item > > on the TODO list. > > Is this functionality planned for the beta? GA? F19? It is planned (but at risk) for the beta and a must-have for GA. David > > As I said up-thread, I believe that this information should be much more > widely disseminated. > > -- > > Ian Pilcher arequip...@gmail.com > Sometimes there's nothing left to do but crash and burn...or die trying. > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On Thu, 2012-10-18 at 23:12 -0500, Ian Pilcher wrote: > On 10/18/2012 05:02 PM, Adam Williamson wrote: > > I'm not sure what 'indication' you're expecting, exactly. AIUI, existing > > RAID arrays and VGs should just show up in the list of existing > > filesystems on the left-hand side of the custom partitioning screen. (In > > a recent enough Beta TC, of course, Alpha is ancient stuff now). If they > > don't, that's a bug. Do you have a case where they don't? If so, it > > should just be reported as a bug. > > > > They didn't the last time I checked, which I believe was beta TC2. > > Just checked again in a test VM and I don't see any way to use the free > space in the existing VG. (vgdisplay reports 7.74 GiB free of 19.48 > GiB.) > <> > When I attempt to add a 6GB "mount point" for /, I get a "not enough > free space on disks" error. > > So how's it supposed to work? This is the main piece of functionality that's still missing: allocating devices from preexisting VGs. You can create and destroy lvm devices. You can reuse existing LVs, optionally reformatting them. You can encrypt or decrypt them. What you cannot do is allocate new LVs from old VGs. That's sort of the last item on the TODO list. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On Wed, 2012-10-17 at 14:28 +0200, Richard Marko wrote: > Previous structured partitioning dialog was much better compared to > this. Why > it was removed in favor of this confusing thing? to keep you on your toes, of course -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: f18: how to install into a LVM partitions (or RAID)
On Tue, 2012-10-16 at 15:29 +0200, Dario Lesca wrote: > Hi, I have download the last Fedora-18-Beta-TC4 to do some tests > http://dl.fedoraproject.org/pub/alt/stage/18-Beta-TC4/Fedora/x86_64/iso/Fedora-18-Beta-TC4-x86_64-netinst.iso > > How to install it on a empty disk and use LVM (or create a software > RaID)? > > From the new disk manager anaconda panel I did not understand how to > create a new LVM partition and root and swap volume. > 1. Click the + button near the bottom of the screen. 2. Enter '/' for mountpoint and whatever size you want. 3. Hit Confirm or Add or whatever the dialog button is. 4. Select the new mountpoint on the left side of the screen. 5. Click the + on the right side of the screen to edit the device options. 6. Select your desired device type from the available options, which will include LVM. Repeat for swap. (Hint: enter "swap" as the mountpoint when adding the device initially) Various tips: Both the size and mountpoint entries in the "Add Mountpoint" dialog have tooltips, so hover the mouse pointer on them if you are in doubt as to how to specify these things. If you want the device you are adding to grow to occupy as much space as is possible, leave the size field blank when adding the device initially. When editing a defined device, if you want to make it as large as possible, specify a size greater than the available space. The installer will grow the device as close to your requested size as possible. This also works when adding a new device. Devices are not treated as "growable" once they have been defined, so if you define one device with a blank size and then try to define another without adjusting the first one, it will probably fail due to insufficient free space. This makes sense if you think about it, so don't file a bug for it. > Is this features not yet supported or I have lost some HOWTO? There's a very brief HOWTO above. I am hoping to produce a basic beginners' guide at some point, but time is scarce. > > Many thanks > > -- > Dario Lesca - sip:da...@solinos.it > (Inviato dal mio Linux Fedora 17 Gnome3) > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Booting Fedora from LVM with grub2
On Fri, 2012-03-23 at 10:19 -0500, Michael Cronenworth wrote: > David Lehman wrote: > > I was able to complete an install of F17-Alpha just now with all lvm. I > > had to force the use of MSDOS disklabel instead of GPT (used parted's > > mklabel command on tty2 while the anaconda prerelease warning was on > > screen on tty6) > > Does the anaconda option "nogpt" no longer exist? It still exists. Since I was doing custom partitioning, however, anaconda would not have modified my existing disklabel. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Booting Fedora from LVM with grub2
On Thu, 2012-03-22 at 19:41 +0100, Jochen Schmitt wrote: > Hallo, > > because I have read, that grub2 should be able to boot from LVM. I have > done the > following test in a VM > > 1.) Fresh install of Fedora 16. Unfortunately, I can't create a disk > which contains olny > a volume group, so I have taken the default partition schema to install > Fedora.. I was able to complete an install of F17-Alpha just now with all lvm. I had to force the use of MSDOS disklabel instead of GPT (used parted's mklabel command on tty2 while the anaconda prerelease warning was on screen on tty6), then I used custom partitioning to create a single partition on disk as an lvm pv. I then created logical volumes for root, swap, and home. The rest of installation went smoothly, as did the reboot. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17 bootloader error
On Wed, 2012-02-15 at 11:41 -0600, Mike Chambers wrote: > When trying to do test install against F17Alpha TC2, during partition > layout, I get error below... > > "you have not created a bootloader stage1 target device" > > I have F16 installed on here, and even reformatted the disks to GPT > before I installed F16. So using same partitions as installed like I > always do should just work. So hoping this a install issue and not a > "me" issue LOL. If you are using a GPT disklabel on a BIOS/non-EFI system with grub2 you will need a "BIOS Boot" partition of 1MB, preferably as the first partition on the disk. This error message sucks -- I know. It will hopefully be a bit clearer in time for beta. Dave > > > Below are links to the error and my partition layout (the top harddrive > is Win 7) > > Error... > > http://miketc.net/bootloader.jpg > > Partition Layout... > > http://miketc.net/partitions.jpg > > > -- > Mike Chambers > Madisonville, KY > > "Best little town on Earth!" > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does anyone still need to create legacy HFS filesystems?
On Fri, 2012-02-03 at 02:43 +, Matthew Garrett wrote: > On Thu, Feb 02, 2012 at 06:25:50PM -0600, David Lehman wrote: > > > My understanding is that the so-called "Apple Bootstrap" filesystem > > required for ppc Macs to boot is HFS. That's what anaconda uses for it. > > If we could be using HFS+ instead, fine. > > Is that created with hfsplus-utils or with parted? We use hformat, which I think is from hfsutils, so probably not what you are talking about. Sorry for the noise. > > -- > Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Does anyone still need to create legacy HFS filesystems?
On Fri, 2012-02-03 at 00:15 +, Matthew Garrett wrote: > There's various issues with the hfsplus utilities we ship at the moment, > including the fact that fsck.hfsplus crashes on 64-bit. I'd like to > update this to the latest upstream, but code to generate legacy HFS (ie, > pre-HFS+) filesystems has been dropped. > > HFS+ was introduced in MacOS 8.1 in 1998, and support for writing or > creating HFS was removed in 10.6 in 2009. I can't think of any reason > why anyone would really need the ability to create HFS these days, but > wanted to get some feedback from others before dropping it. Does anyone > object? My understanding is that the so-called "Apple Bootstrap" filesystem required for ppc Macs to boot is HFS. That's what anaconda uses for it. If we could be using HFS+ instead, fine. Dave > > -- > Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS on LVM causes long fedora-storage-init run?
On Fri, 2011-10-07 at 10:31 -0500, Richard Shaw wrote: > I am, however, running BTRFS on main main partitions on top of LVM > (since anaconda as of F15 still creates an LVM setup regardless of > filesystem?) FYI as of F16 there is a checkbox on the "what type of partitioning do you want?" screen (near the bottom) that enables or disables the use of LVM in automatic partitioning. All you have to do is disable it before proceeding if you do not want LVM. David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Anaconda forced to create a BIOS boot partition, but not boot on Lenovo S205
On Tue, 2011-09-27 at 10:30 +0800, Liang Suilong wrote: > I bought a new notebook for my jobs, Lenovo IdeaPad S205 (AMD E-450 > APU), building in MeeGo modified by Linpus. There is no BIOS in it, > just using UEFI. And there is no BIOS compatibility mode. So I must > use EFI GRUB. As we knew, Fedora 15 LiveUSB can not be booted on S205. > There is a bug on Lenovo > S205. http://forums.fedoraforum.org/showthread.php?t=262907 > > > I try to install Fedora 16 Beta RC2. I know there is many bugs before > Final GA. Luckily, the installation process runs smothly. After > rebooting my machine, UEFI can not load boot loader on HDD, skipping > HDD to boot USB or PXE. And then, I found Anaconda must create a BIOS > boot partition that size is about 1MB and an FAT partition for EFI If anaconda says you need a BIOS boot partition then anaconda believes your system is a BIOS system -- not EFI. You should open a bug report and include the following log files from within the installer's runtime environment: /tmp/anaconda.log /tmp/syslog /tmp/program.log /tmp/storage.log Thanks. > system is following. Later, I try to install Ubuntu 11.10 Beta 2. > Their grub2 can support UEFI and GPT partition table normally. > However, BIOS boot partition does not appear in Ubuntu installer. I > make sure that Fedora 16 choose GPT for me. I am just allowed to > create primary partition on my HDD. > > > I could not assure whether this is a bug on Anaconda or GRUB 2. Maybe > I should file a bug report on Bugzilla. But I do not understand why > Anaconda need to create a BIOS boot partition on UEFI-only system. > This is my most important question. I do do not really get accustomed > to using Ubuntu. I love Fedora very much. > > > I just hope I can get replies soon. > > > Liang Suilong > > > -- > Fedora && Debian User, former Ubuntu User > My Page: http://www.liangsuilong.info > Fedora Project Contributor -- Packager && Ambassador > https://fedoraproject.org/wiki/User:Liangsuilong -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 Alpha i386 does not install in VMWare
On Fri, 2011-08-26 at 23:13 -0700, a...@clueserver.org wrote: > I have tried installing Fedora 16 alpha (i386 version) on VMWare player > and it dies starting up the installer. > > It also dies trying to install on my CTL 2GO pad. (Atom based tablet.) Same type of death as the vmware? > > Any ideas why? If you have less than 768M of memory you could have problems unpacking the initrd and/or starting the installer. David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GPT in Fedora 16
On Thu, 2011-08-25 at 17:11 -0700, Adam Williamson wrote: > On Thu, 2011-08-25 at 16:17 -0600, Andrew McNabb wrote: > > While installing Fedora 16 Alpha, I ran into some problems that turned > > out to be caused by the installer formatting with a GPT rather than an > > MBR partition table. > > > > I would like to understand the change and its implications, and I have > > unsuccessfully tried to track down more information. I haven't been > > able to find anything in the Fedora 16 Alpha Release Notes or the Grub2 > > feature page. The only definitive reference I've been able to find is > > the comment "x86 uses GPT disklabels by default on all machines, even > > non-EFI" on the Anaconda/Changes wiki page. > > > > There seem to be some complications associated with the change. For > > example, Windows can only support GPT on UEFI machines, so dual-booting > > appears to be unsupported (I could not find an option for MBR partition > > tables in the installer). > > > > Where should I look for more information? Thanks. > > To boot to a GPT disk from BIOS (rather than EFI) you need a BIOS boot > partition. If you use one of the automatic partitioning methods, rather > than manual partitioning, F16's installer will create one for you. If > you choose manual partitioning on a BIOS system and don't create a BIOS > boot partition, anaconda will pop up a (somewhat cryptic) warning. This is changing from a suggestion to a requirement, based on the fact that grub2 will not even try to install itself without the bios boot partition. > > If you're installing alongside an existing copy of Windows I believe > anaconda ought to leave the disk label alone (MSDOS) anyway, though I'm > not sure we've tested that. It should only write a new one if you're > blowing away any existing partitions on the disk, I think. (IMBW on this > one). This is correct. It's also true that if you create an msdos/mbr partition table on your disk prior to installation and then choose any option except for "Use All Space" (or "clearpart --all" in kickstart) anaconda will not destroy your existing partition table. > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora > http://www.happyassassin.net > -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
