Anaconda-devel November 2008

anaconda-devel@lists.stg.fedoraproject.org

29 participants
80 discussions

autostep and encrypted root password
by Jeffrey Bastian 10 Feb '09

10 Feb '09

If kickstarting a RHEL 5.y system, and the kickstart file contains autostep rootpw --iscrypted $1$..... then the kickstart will stop and ask for the root password. If using a plain text root password, it autosteps through the root password screen as expected. See https://bugzilla.redhat.com/show_bug.cgi?id=471122#c4 for a patch for RHEL 5.3 Beta. Below is a similar patch for anaconda-11.4.1.56-1. Jeff --- kickstart.py.ORIG 2008-11-11 15:35:29.000000000 -0600 +++ kickstart.py 2008-11-11 15:39:42.000000000 -0600 @@ -1185,6 +1185,11 @@ dispatch.skipStep("installtype") dispatch.skipStep("bootdisk") + # if the root password is already encrypted, we cannot fill in + # the password field on the accounts screen, so skip it + if flags.autostep and self.id.rootPassword["isCrypted"]: + dispatch.skipStep("accounts") + dispatch.skipStep("bootdisk") dispatch.skipStep("betanag") dispatch.skipStep("regkey")

2 7

[PATCH] removal of libdhcp
by David Cantrell 21 Dec '08

21 Dec '08

No patch attached because it's quite large. I apologize for the length, but considering this replaces a library and introduces a new struct it meant a new file and changing calls everywhere. http://dcantrel.fedorapeople.org/anaconda/iface/ iface.h - Header file explaining the iface API. iface_t structure replacing pumpNetIntf and networkDeviceConfig, and all of the functions. iface.patch - The changes, it's about 90% complete at this point. *.txt - Explanations and notes. This patch removes anaconda's use of libdhcp, which also means removing libdhcp4client and libdhcp6client. For static network configuration, I am using libnl. To gather current network interface information, I am using libnl. To control IPv6 autoconf, I read/ write /proc since that's all we can do right now. For DHCP and DHCPv6, I run dhclient and dhcp6c, respectively. I'd like everyone to have a look at iface.h and the patch file. It's not complete yet, so I probably know about the obvious things (the FIXMEs and the useless debugging printfs and the incomplete isys.py code and so on). The goal with iface.patch is to get us closer to using NetworkManager in stage 1 and stage 2. I envision the NM changeover to be just as large, but hopefully by then we will have decided to nuke certain parts of loader entirely. Completely eliminating libdhcp and friends will be a nice step. There are some other things that need discussion as well. mkinitrd currently uses libdhcp, for example. This had me thinking we could generate libisys in an anaconda-devel package for things like mkinitrd, but I'm just brainstorming. Maybe I should put the iface code elsewhere? I dunno. At any rate, mkinitrd needs to be not left out. Work in progress, comments welcome. -- David Cantrell <dcantrell(a)redhat.com> Red Hat / Honolulu, HI

8 28

PATCH: allow installing grub on the MBR if /boot is on mdraid.
by Hans de Goede 11 Dec '08

11 Dec '08

Hi All, This patch removes a special case when /boot (or / without a separate /boot) is on mdraid. For some reason we only allow installing grub to the mdX device then instead of allowing both the mbr of the 1st disk and the device holding /boot. I've searched through the anaconda history and this special handling of mdraid /boot has been there since before Feb. 2002, it was inherited from before booty was introduced and it does not seem to make sense. Either we cannot have /boot on mdraid at all (in all cases except for raid1) or we can have /boot on dmraid (in case of raid1) and then it does not matter if the bootstrap of grub starts on the mbr or on the first sector of a partition. This fixes 217176, note that is a RHEL4 bug but this patch is against master as it still happens there too. Next is fixing this for RHEL5 and then RHEL4. Regards, Hans diff --git a/fsset.py b/fsset.py index c9cd098..b726985 100644 --- a/fsset.py +++ b/fsset.py @@ -1522,10 +1522,6 @@ MAILADDR root ret['boot'] = (bootDev.device, N_("EFI System Partition")) return ret - if bootDev.getName() == "RAIDDevice": - ret['boot'] = (bootDev.device, N_("RAID Device")) - return ret - if iutil.getPPCMacGen() == "NewWorld": ret['boot'] = (bootDev.device, N_("Apple Bootstrap")) n = 1

4 11

Unified instalaltion media for ia32 and x86_64 (Intel compatible)
by Milan Keršláger 01 Dec '08

01 Dec '08

Hi, I would be glad if there will be only one installation media (something as we have now for x86_64). The user then will pick pure 32 or 64 or mixed 32+64 bit environment installation. This may save a lot of bandwithw and make 32->64 transition more easy and smooth for average user. Milan Kerslager -- Milan Kerslager http://www.pslib.cz/ke/ http://www.nti.tul.cz/wiki/Milan.Kerslager

3 2

[PATCH] Make the function in getActualSize and lvm_dialog_gui.py the same.
by Joel Granados Moreno 28 Nov '08

28 Nov '08

Hi list. As discussed with Radek, I added some changes to the getActualSize funciton in the VolumeGroupRequestSpec class. This will make the function in lvm_dialog_gui.py equal to the one in the VG request. I know that the code could have probably been reduced to one function and for that function to be called from the VG request and the lvm dialog. But I chose to change the code as little as possible (since this is RHEL5) Tested in the usual lvm partitioning cases and it seems to work just fine. Regards.

2 2

Re: [PATCH] make sure that we calculate a vg size that is less than the total parition size.
by Joel Granados 27 Nov '08

27 Nov '08

----- "Radek Vykydal" <rvykydal(a)redhat.com> wrote: > Joel Granados wrote: > > ----- "Radek Vykydal" <rvykydal(a)redhat.com> wrote: > > > > > >> Joel Granados Moreno wrote: > >> > >>> Hi list: > >>> > >>> Here is my second wack at solving this issue (468944). It is > VERY > >>> > >> ugly. but I felt corned and see no other way out. The bug ocurrs > >> when the pv size (partition size) is a multiple of the pe size. > This > >> means that when you clamp the pv size in the vg size calculation > there > >> will be no difference between the unclamped and the clamped value. > > >> This means that we are calculating the vg available size as the sum > of > >> the total sizes of all the pvs (partitions) that compose the vg, > which > >> is not accurate. So to make sure that the vg size is less than > the > >> total sum of the pv sizes (partition sizes) I take away 1 pe. Its > >> ugly I know... > >> > >>> > >>> > >> When calculating VG size available for LVs we don't count space > used > >> for > >> metadata in. > >> Most of the time, clamping will protect us. > >> Moreover, in Fedora subtracting of one PE after clamping protects > us > >> for > >> sure > >> (though it is probably overkill). This subtracting was patched in > rhel > >> 5.3 > >> (commit 68ab7d2823836ee90), but not fw ported to Fedora. > >> > >> > sorry, commit 68ab7d282383 doesn't exitst, the right hash is > a68ab7d282383, but you found it... > >> So subtracting one PE in rhel 5.3 as in the patch, should solve > the > >> bug > >> case, but as it > >> happens here only when clamped size is equal to partition size, it > >> could > >> appear in another corner case when the partition size is clamped > only > >> by > >> > > > > This is true. and it probably does. But I think that the > probabilities of the partition table being in such a state are quite > low. And the commit that you mentioned fixed bug 217913, which would > come back if we were to subtrace 1 pe at that point. > > > > > > 217913 concerned bad computing of VG size in UI for > preexisting partitions, that means the function computeVGSize. > IMO, the correct patch of 217913 should have been > the if clause for preexisting VGs that you added in your patch: > > + if self.origvgrequest.preexist and > self.origvgrequest.preexist_size: > + availSpaceMB = > lvm.clampPVSize(self.origvgrequest.preexist_size, curpe) > + else: > > > > that is: in dialog (in computeVGSize), > use size of preexisting VG, and don't compute anything > (do it as in VolumeGroupRequestSpec.getActualSize). > With this portion of patch added, things I suggested (subtracting > one PE after clamping in any case, or subtracting some amount before > clamping) > wouldn't break 217913 as well as your conditional subtracting of PE > doesn't. Ok, I see your point. I'll add this one line change to the size calculation in VG request and test further. See what happens :). I don't expect anything serious. > >> size less then is needed > >> for metadata - then we wouldn't subtract the PE. I think > subtracting > >> some reserve > >> (but what size?) for metadata from partition size before clamping, > is > >> > >> better in this sense. > >> > > > > It may be safer, or it may take us back to bug 217913 > > > as I said above, with if branch for preexisting VGs, it wouldn't > > > >> Or, subtracting one PE in any case, like in Fedora. > >> Also, it is patched here only for interactive case, and not for > >> VolumeGroupRequestSpec.getActualSize > >> > > > > Which in this case will not break anything because if the VG already > existed the value that is in the VGRequest will be used. Only if the > VG is new will we use the new code. And after the new VG is created, > VG.getActualSize will return whatever the new function calculated. > > > > > >> used in ks case. > >> > >> > here I am talking about kickstart case. I'm not saying that it would > break something, but > that the fix of computing (be it yours or extra PE subtraction or > whatever) > should be added to VolumeGroupRequestSpec.getActualSize which is used > in > ks case, too, > because the special case of your bug could occur in ks I think > (when creating VG with one PV of partition with size same as clamped > size, > size for LV --grow can be computed wrongly). > But I agree it is just another (maybe even less probable) corner > case. I think that adding the extra condition in the VG request will catch these problems. > > To sum up: > The thing is that we are using duplicate code in 2 functions: > VolumeGroupRequestSpec.getActualSize, and its > copy VolumeGroupEditor.computeVGSize used in UI, > which differs only in that it takes PE size set in dialog as > argument. > I think that both functions should be same in other respects: > 1) compute the size value in the same way > 2) use preexisting VG size if dealing with preexisting VG > You make them same wrt 2) in your patch, and I'd like to > see them same wrt 1) too (in ideal world). > > > So to my comments to the patch are: > - it fixes only the corner case of the bug (not others when PV size is > only > a little bigger than clamped size - which would extracting of safe > amount before > clamping or PE after clamping do) > - it is only for UI case (not ks case) - but yes, the bug is for UI > case, and I > am not sure if I should or want create reproducer for ks case;) > - but given the stage of cycle we are in, the patch seems ok to me to > fix the bug with minimal risks. > > (Apologies for long comment, I am doing it also as a notice in case we > hit > other corner cases in future.) > > Radek > What I want to do is to put the "take a way 1 PE in case the clamped size and the calculated size are the same. in both the lvm dialog and the VG request. I'm really not confortable just taking away 1 PE always and would rather not consider it unless something else breaks (which is totally possible.) I'll review the patch once more test and see what happens. Regards. > > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/anaconda-devel-list -- Joel Andres Granados Red Hat / Brno Czech Republic

1 0

Re: [PATCH] make sure that we calculate a vg size that is less than the total parition size.
by Joel Granados 27 Nov '08

27 Nov '08

----- "Radek Vykydal" <rvykydal(a)redhat.com> wrote: > Joel Granados Moreno wrote: > > Hi list: > > > > Here is my second wack at solving this issue (468944). It is VERY > ugly. but I felt corned and see no other way out. The bug ocurrs > when the pv size (partition size) is a multiple of the pe size. This > means that when you clamp the pv size in the vg size calculation there > will be no difference between the unclamped and the clamped value. > This means that we are calculating the vg available size as the sum of > the total sizes of all the pvs (partitions) that compose the vg, which > is not accurate. So to make sure that the vg size is less than the > total sum of the pv sizes (partition sizes) I take away 1 pe. Its > ugly I know... > > > > > When calculating VG size available for LVs we don't count space used > for > metadata in. > Most of the time, clamping will protect us. > Moreover, in Fedora subtracting of one PE after clamping protects us > for > sure > (though it is probably overkill). This subtracting was patched in rhel > 5.3 > (commit 68ab7d2823836ee90), but not fw ported to Fedora. > > So subtracting one PE in rhel 5.3 as in the patch, should solve the > bug > case, but as it > happens here only when clamped size is equal to partition size, it > could > appear in another corner case when the partition size is clamped only > by This is true. and it probably does. But I think that the probabilities of the partition table being in such a state are quite low. And the commit that you mentioned fixed bug 217913, which would come back if we were to subtrace 1 pe at that point. > size less then is needed > for metadata - then we wouldn't subtract the PE. I think subtracting > some reserve > (but what size?) for metadata from partition size before clamping, is > > better in this sense. It may be safer, or it may take us back to bug 217913 > Or, subtracting one PE in any case, like in Fedora. > Also, it is patched here only for interactive case, and not for > VolumeGroupRequestSpec.getActualSize Which in this case will not break anything because if the VG already existed the value that is in the VGRequest will be used. Only if the VG is new will we use the new code. And after the new VG is created, VG.getActualSize will return whatever the new function calculated. > used in ks case. > > Radek > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/anaconda-devel-list -- Joel Andres Granados Red Hat / Brno Czech Republic

2 1

[PATCH] make sure that we calculate a vg size that is less than the total parition size.
by Joel Granados Moreno 26 Nov '08

26 Nov '08

Hi list: Here is my second wack at solving this issue (468944). It is VERY ugly. but I felt corned and see no other way out. The bug ocurrs when the pv size (partition size) is a multiple of the pe size. This means that when you clamp the pv size in the vg size calculation there will be no difference between the unclamped and the clamped value. This means that we are calculating the vg available size as the sum of the total sizes of all the pvs (partitions) that compose the vg, which is not accurate. So to make sure that the vg size is less than the total sum of the pv sizes (partition sizes) I take away 1 pe. Its ugly I know... I tested a couple of lvm movearounds and eveything seemed ok. review appreciated. Regards.

2 2

Re: PATCH: allow installing grub on the MBR if /boot is on mdraid.
by Joel Granados 26 Nov '08

26 Nov '08

----- "Hans de Goede" <hdegoede(a)redhat.com> wrote: > Hi All, > But here we would be loosing the "RAID Device" message. It would be replaced by "First sector of boot partition", which is not bad thing, but I would still prefer to tell the user that its a "RAID Device". I would prefer to just add a line inside the if that adds the mbr and then returns. > diff --git a/fsset.py b/fsset.py > index c9cd098..b726985 100644 > --- a/fsset.py > +++ b/fsset.py > @@ -1522,10 +1522,6 @@ MAILADDR root > ret['boot'] = (bootDev.device, N_("EFI System > Partition")) > return ret > > if bootDev.getName() == "RAIDDevice": > ret['boot'] = (bootDev.device, N_("RAID Device")) =======Add this line to the if:======== ret['mbr'] = (bl.drivelist[0], N_("Master Boot Record (MBR)")) > return ret > > if iutil.getPPCMacGen() == "NewWorld": > ret['boot'] = (bootDev.device, N_("Apple Bootstrap")) > n = 1 > regards -- Joel Andres Granados Red Hat / Brno Czech Republic

2 2

PATCH: RHEL54 allow installing grub on the MBR if /boot is on mdraid.
by Hans de Goede 26 Nov '08

26 Nov '08

Hi All, Same patch as before but now for RHEL54 This patch removes a special case when /boot (or / without a separate /boot) is on mdraid. For some reason we only allow installing grub to the mdX device then instead of allowing both the mbr of the 1st disk and the device holding /boot. I've searched through the anaconda history and this special handling of mdraid /boot has been there since before Feb. 2002, it was inherited from before booty was introduced and it does not seem to make sense. Either we cannot have /boot on mdraid at all (in all cases except for raid1) or we can have /boot on dmraid (in case of raid1) and then it does not matter if the bootstrap of grub starts on the mbr or on the first sector of a partition. This fixes 217176, note that is a RHEL4 bug but this patch is against RHEL5 as it still happens there too. Next is fixing this for RHEL4. Regards, Hans diff --git a/fsset.py b/fsset.py index c0c2df6..91d5fa3 100644 --- a/fsset.py +++ b/fsset.py @@ -1609,10 +1609,6 @@ MAILADDR root log.warning("no boot device set") return ret - if bootDev.getName() == "RAIDDevice": - ret['boot'] = (bootDev.device, N_("RAID Device")) - return ret - if iutil.getPPCMacGen() == "NewWorld": ret['boot'] = (bootDev.device, N_("Apple Bootstrap")) n = 1

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel November 2008