-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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..
2.) An full update of the Systen (yum update)
3.) Create a /bootx directory
4.) Copy the content of /boot into /bootx
5.) unmount /boot
6.) Remove /boot from /etc/fstab
7.) Clean all content of the ummountet /boot partition
8.) Rename /bootx into /boot
9. Make a grub2-install /dev/sda to install grub2 again
10. Make a cd /boot/grub2; grub2-mkconfig -o grub.cfg to generate the rigth entries in the grub configuration file.
11. Reboot the system succesfully.
I would like to know, if this works for other people too.
Additionally, It may be nice, if we can modifiy anaconda in the way, that you can create a paritition schema which contains only one volume group and allow to install grub2 as a bootloader in this case.into the MBR.
Of corse, this will not suppoert by the legacy grub release.
Best Regards:
Jochen Schmitt
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.
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?
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.
Am 23.03.2012 16:19, schrieb Michael Cronenworth:
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?
you have to boot with "noefi" as kernel-param to get rid of this whole GPT/EFI crap and end in a successful customized disk layout
this took me THREE HOURS last monday to get a machne setup with 3 raid1 (/boot, / and /data), really poor have a OS installer not supporting /boot on a mirrored RAID leading in a unbootable system if the wrong disk fails in the year 2012
the F16 error message is useless, so i burned F15 again, got a better error message which brought the "noefi" option by google and since it was a DVD-RW after the first setup upgrade to F16
anaconda is really one of the most hated things of me since many years and because F17 alpha falls back on text-installation while manual partitioning is rmeoved in text-mode currently more than ever
On 03/23/2012 11:26 AM, Reindl Harald wrote:
Am 23.03.2012 16:19, schrieb Michael Cronenworth:
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?
you have to boot with "noefi" as kernel-param to get rid of this whole GPT/EFI crap and end in a successful customized disk layout
this took me THREE HOURS last monday to get a machne setup with 3 raid1 (/boot, / and /data), really poor have a OS installer not supporting /boot on a mirrored RAID leading in a unbootable system if the wrong disk fails in the year 2012
the F16 error message is useless, so i burned F15 again, got a better error message which brought the "noefi" option by google and since it was a DVD-RW after the first setup upgrade to F16
anaconda is really one of the most hated things of me since many years and because F17 alpha falls back on text-installation while manual partitioning is rmeoved in text-mode currently more than ever
/boot on RAID is related to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=500004 which I opened 3 years ago.
Things have only gotten worse since.
I can create virtually any type of layout when installing Ubuntu/Debian but not so with Fedora.
Two things that would be useful are /boot on md0 array and creating RAID-1 arrays with just one disk (degraded, other disk to be added later).
You can do all of these things manually outside of anaconda and then just tell anaconda to use existing setup. But that is not very user friendly.
.
On Fri, Mar 23, 2012 at 12:08:42PM -0400, Gerry Reno wrote:
You can do all of these things manually outside of anaconda and then just tell anaconda to use existing setup. But that is not very user friendly.
I had similar problems trying to set up a basic RAID 1 (not /boot) guest. I found Anaconda is full of bugs and wierdness once you stray into the custom partitioning code.
Apparently kickstart is a better way to do this.
Perhaps, like Ubuntu's installer, the graphical part of Anaconda should concentrate on doing the simple stuff, and leave everything else to kickstart non-graphical installations.
Rich.
On Sun, Mar 25, 2012 at 11:41:18PM +0200, Kevin Kofler wrote:
Richard W.M. Jones wrote:
Perhaps, like Ubuntu's installer, the graphical part of Anaconda should concentrate on doing the simple stuff, and leave everything else to kickstart non-graphical installations.
I don't think that would be a good idea, at all.
Ummmmmm ... okay.
Any particular reason? Any other plans to make the current situation better?
Rich.
Richard W.M. Jones wrote:
Ummmmmm ... okay.
Any particular reason?
Kickstarts are not very user-friendly nor convenient (unless you have several machines to install with identical installs, which is what they were invented for).
Any other plans to make the current situation better?
Even QA-wise, I don't think making such a feature kickstart-only would improve the situation at all, it'd reduce the testing it gets by a lot.
Kevin Kofler
On Mon, 2012-03-26 at 21:16 +0200, Kevin Kofler wrote:
Richard W.M. Jones wrote:
Ummmmmm ... okay.
Any particular reason?
Kickstarts are not very user-friendly nor convenient (unless you have several machines to install with identical installs, which is what they were invented for).
Any other plans to make the current situation better?
Even QA-wise, I don't think making such a feature kickstart-only would improve the situation at all, it'd reduce the testing it gets by a lot.
It's worth bearing in mind there's a giant anaconda UI rewrite still pending, which entirely redesigns the storage configuration GUI. One of the other major changes is that it makes all installations kickstart-driven. The GUI will just produce a kickstart file, which anaconda will then process to perform the actual install.
It's not a direct response to any of the points raised so far, but it's worth bearing in mind while you're having this argument that F18 anaconda is going to look drastically different from F17 anaconda.
Adam Williamson wrote on 27.03.2012 20:14:
[...] It's worth bearing in mind there's a giant anaconda UI rewrite still pending, which entirely redesigns the storage configuration GUI. One of the other major changes is that it makes all installations kickstart-driven. The GUI will just produce a kickstart file, which anaconda will then process to perform the actual install.
Just out of curiosity: Your description makes me assume that the installer in the future still don't do things like partitioning, formating or installing a basic set of packages in the background while the user (which has a high latency/response time) is asked questions about the root password to use, users accounts to create or which timezone the system is in?
Just wondering, because the Ubuntu installer does things like that, which makes the installation a little bit quicker.
CU knurd
Am 28.03.2012 09:25, schrieb Thorsten Leemhuis:
Adam Williamson wrote on 27.03.2012 20:14:
[...] It's worth bearing in mind there's a giant anaconda UI rewrite still pending, which entirely redesigns the storage configuration GUI. One of the other major changes is that it makes all installations kickstart-driven. The GUI will just produce a kickstart file, which anaconda will then process to perform the actual install.
Just out of curiosity: Your description makes me assume that the installer in the future still don't do things like partitioning, formating or installing a basic set of packages in the background while the user (which has a high latency/response time) is asked questions about the root password to use, users accounts to create or which timezone the system is in?
if this ever happens anaconda has to be considered as broken by design
the currently active bugs has to be fixed instead remove capabilities at all
* no way to make /boot as RAID1 without "noefi"-kernel-param there has to be really a clear useable option to have /boot and / as RAID1 without any bios/efi-partition around - if a disk dies in a RAID1 the machine has to be bottable or considered as broken by design for endusers have to call me for support
* if i ceate 3 partitions i xcpect that they get /dev/sda1 /dev/sad2 /dev/sda3 in exactly the order i create them instead switch the second one to /dev/sda1 after create the third
On Wed, Mar 28, 2012 at 4:16 AM, Reindl Harald h.reindl@thelounge.net wrote:
if this ever happens anaconda has to be considered as broken by design
Harald, I've tried to be patient with your recent posts to the devel list, but you don't seem to get the message (or you're actively choosing to ignore it), so I'm going to say it again as clearly as I can. The universe of Fedora development doesn't revolve around you. Development involves a fair amount of group consensus, but as in any meritocracy -- people are more likely to have their opinions valued and listened to when they're willing to take an active role in the process, rather than playing Monday-morning quarterback (an American term, sorry) or complaining about things after the fact.
the currently active bugs has to be fixed instead remove capabilities at all
Who died and put you in charge of the anaconda team? Do they now answer to you? Making demands like this is more likely to get you ignored than to have a positive effect.
How about rather than demanding (or trying to project your own views on the team's motives), you take a more active role in submitting bug patches or helping out in some other positive way? I've had the opportunity to rub shoulders with many of the people on the anaconda team over the past couple of years, and I've never once heard any of them suggest that they want to remove capabilities and not fix bugs. I understand that sometimes features or capabilities change (the change in btrfs support in the F17 installer as a hot-button example), but I don't ascribe any malice or ill-intent to the anaconda team for making that change. I also know that the anaconda team has a vision for how they'd like anaconda to evolve. I could guess (based on your past mailing list posts) that you don't want any fundamental shifts in the way anaconda works, but I'd rather not guess as to your wants or desires either. The reality is that anaconda is in the middle of a major rewrite, and there are going to be quite a few changes before things are done.
If you're serious about making anaconda better and are willing to work to help on it, I'm sure the anaconda team would appreciate your help. Otherwise, please try to be patient with changes and imperfections as they work through the rewrite. I can assure you that they're trying their hardest to find the right balance of time between fixing bugs in the older code and writing new code.
Again, I'm sorry to have to put this so bluntly, but I feel it needed to be said.
-- Jared Smith
Am 28.03.2012 17:58, schrieb Jared K. Smith:
On Wed, Mar 28, 2012 at 4:16 AM, Reindl Harald h.reindl@thelounge.net wrote:
if this ever happens anaconda has to be considered as broken by design
Harald, I've tried to be patient with your recent posts to the devel list, but you don't seem to get the message (or you're actively choosing to ignore it), so I'm going to say it again as clearly as I can. The universe of Fedora development doesn't revolve around you. Development involves a fair amount of group consensus, but as in any meritocracy -- people are more likely to have their opinions valued and listened to when they're willing to take an active role in the process, rather than playing Monday-morning quarterback (an American term, sorry) or complaining about things after the fact.
sorry but WHY do you strip the context of my message
Richard W.M. Jones wrote:
Perhaps, like Ubuntu's installer, the graphical part of Anaconda should concentrate on doing the simple stuff, and leave everything else to kickstart non-graphical installations
this would mean you have from DVD only a "click, click" default install and for every setup wihich is not default you have to deal with kickstart
do you really think this is a good idea and improvement of the installer in any way?
complaining about things after the fact
and that is why i wrote the mail to not complain AFTER the fact like systemd last year - i do not really understand your problem with this message of me in the context - really!
On 03/28/2012 09:46 PM, Reindl Harald wrote:
and that is why i wrote the mail to not complain AFTER the fact like systemd last year - i do not really understand your problem with this message of me in the context - really!
You keep ranting based on assumptions. Someone has asked a question. Just wait for a reply first. Don't pile on top. Before pressing send, reread to make sure you don't appear to be demanding and shouting. You continue to behave in a obnoxious way in the users list as well as others have pointed out there too.
Rahul
Am 28.03.2012 18:55, schrieb Rahul Sundaram:
On 03/28/2012 09:46 PM, Reindl Harald wrote:
and that is why i wrote the mail to not complain AFTER the fact like systemd last year - i do not really understand your problem with this message of me in the context - really!
You keep ranting based on assumptions. Someone has asked a question. Just wait for a reply first.
ah - i am not permitted to say my opinion of a very very bad idea before i become green light - from whom does this green light come and how is it marked that i see it next time?
Don't pile on top. Before pressing send, reread to make sure you don't appear to be demanding and shouting. You continue to behave in a obnoxious way in the users list as well as others have pointed out there too.
can you please quote what extactly was "obnoxious" the last days? seems for me that some people are really over sensitive
was it this? if yes - why?
you need first to understand: http://slacksite.com/other/ftp.html
most clients these days are using PASV because active ftp will not work if the client is behind a router which has to forward random ports, so you have to configure the packet-filter on the server as follows _______________
"/etc/sysconfig/iptables-config" is your friend
if your machine is behind a NAT router: IPTABLES_MODULES="nf_conntrack_ftp nf_nat_ftp"
if your machine has as public IP: IPTABLES_MODULES="nf_conntrack_ftp"
or was it this? if yes - why?
usually bash writes down .bash_history on close try it out with "cat ~/.bash_history" and you will not see the entries of your current session!
so if you have more than one bash-instance open all of them writing down their history and the last one wins
if you mean the ONE theard with Joe Zeff after his "not all people are using GNOME" in context of "system-config-*" - sorry, but these are default tools of fedora since forever and sometimes one is reaching a point where i consider him as not smart to say it polite
On Wed, Mar 28, 2012 at 12:16 PM, Reindl Harald h.reindl@thelounge.net wrote:
sorry but WHY do you strip the context of my message
Because my reply wasn't about the content of your message. My reply was all about the *tone* of your email. I know that language barrier is part of the problem here, but the tone of your email messages often comes across as demanding and condescending.
-- Jared Smith
Am 28.03.2012 21:09, schrieb Jared K. Smith:
On Wed, Mar 28, 2012 at 12:16 PM, Reindl Harald h.reindl@thelounge.net wrote:
sorry but WHY do you strip the context of my message
Because my reply wasn't about the content of your message. My reply was all about the *tone* of your email.
there was simply NOTHING wrong in the tone of my mail because it is the same one i usually communicate with many people over more than 10 years about technical things and nobody has a problem exepct mailing lists
maybe the tone was minimal rude because i do absolutely not understand why anyone can have the idea "hey let us remove the whole custom partitioning and replace with kickstart only" to solve problems with it
well if i burn down the house my problem with a wrong color is solved, but i doubt it does not help really :-)
I know that language barrier is part of the problem here, but the tone of your email messages often comes across as demanding and condescending.
that may be your interpretation
i only try to be clear and as specific as possible by pointing out for me very clear mistakes, bugs and wrong directions and if people starting to judge every single word because it does not fit "their tone" we drive far away from any sense
maybe i have often not enough patience by people not understand what i try to tell them
don't get me wrong, but after using Fedora since FC3 on servers and desktops, currently on more than 25 machines with all sort of things (multimedia, desktop, database, router, firewall, httpd, vpn, fileserver, voice-over-ip, dns, dhcp, ftp and some other services while develop all backends and most websoftware internal and for customers) i am pretty sure that there are really few people out there using the distribtuion in so many different setups, and even - not many are free to make each infrastructure decision involved too
maybe this overall point of view of so many parts of a linux-system is the reason for my missing patience and sometimes not knowing how to explain someone who is only interested in a small specific part what i am saying because i can not explain over and over the full bandwith and where things act together AND do this in a foreign language
sorry, but thats me
On Wed, 2012-03-28 at 22:16 +0200, Reindl Harald wrote:
Am 28.03.2012 21:09, schrieb Jared K. Smith:
On Wed, Mar 28, 2012 at 12:16 PM, Reindl Harald h.reindl@thelounge.net wrote:
sorry but WHY do you strip the context of my message
Because my reply wasn't about the content of your message. My reply was all about the *tone* of your email.
there was simply NOTHING wrong in the tone of my mail because it is the same one i usually communicate with many people over more than 10 years about technical things and nobody has a problem exepct mailing lists
I've heard at least a dozen people say they've gone to the trouble of explicitly killfiling your mails. That really isn't a sign that there's nothing wrong with your tone.
On Wed, 28 Mar 2012 22:16:25 +0200 Reindl Harald h.reindl@thelounge.net wrote:
maybe the tone was minimal rude because i do absolutely not understand why anyone can have the idea "hey let us remove the whole custom partitioning and replace with kickstart only" to solve problems with it
That's not what I understood from Adam's description, which was:
It's worth bearing in mind there's a giant anaconda UI rewrite still pending, which entirely redesigns the storage configuration GUI. One of the other major changes is that it makes all installations kickstart-driven. The GUI will just produce a kickstart file, which anaconda will then process to perform the actual install.
Now my understanding of that doesn't include anything about removing custom partitioning. It's all about splitting up the functionality of anaconda into two distinct parts - the GUI configuration part, which I would expect still to contain custom partitioning, and a back-end that implements the configuration, where the configuration is passed to it in the form of a kickstart file (either the output of the GUI part, or a kickstart file prepared earlier by the user).
My understanding is based entirely on Adam's description since I'm not involved in anaconda development, but it strikes me as being a good thing as it would split one large process into two, presumably smaller ones, which would help solve the problem of running anaconda on machines with less memory.
Paul.
On Mar 29, 2012 8:00 AM, "Paul Howarth" paul@city-fan.org wrote:
On Wed, 28 Mar 2012 22:16:25 +0200 Reindl Harald h.reindl@thelounge.net wrote:
maybe the tone was minimal rude because i do absolutely not understand why anyone can have the idea "hey let us remove the whole custom partitioning and replace with kickstart only" to solve problems with it
That's not what I understood from Adam's description, which was:
It's worth bearing in mind there's a giant anaconda UI rewrite still pending, which entirely redesigns the storage configuration GUI. One of the other major changes is that it makes all installations kickstart-driven. The GUI will just produce a kickstart file, which anaconda will then process to perform the actual install.
Now my understanding of that doesn't include anything about removing custom partitioning. It's all about splitting up the functionality of anaconda into two distinct parts - the GUI configuration part, which I would expect still to contain custom partitioning, and a back-end that implements the configuration, where the configuration is passed to it in the form of a kickstart file (either the output of the GUI part, or a kickstart file prepared earlier by the user).
My understanding is based entirely on Adam's description since I'm not involved in anaconda development, but it strikes me as being a good thing as it would split one large process into two, presumably smaller ones, which would help solve the problem of running anaconda on machines with less memory.
That's my understanding as well so it's not removing functionality but rather the underlying mechanism and implementation of them. This is good because it will allow a consistent outcome whether using the GUI, a kickstart file or something else like media and appliance creator and likely considerable simplification of the code too.
Peter
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
That's my understanding as well so it's not removing functionality but rather the underlying mechanism and implementation of them. This is good because it will allow a consistent outcome whether using the GUI, a kickstart file or something else like media and appliance creator and likely considerable simplification of the code too.
I don't think we've removed any functionality in this new UI. And yeah, it will certainly allow for more consistency and much simpler code. We're eliminating a whole lot of old, crufty, hand-written UIs here.
- Chris
Am 29.03.2012 09:00, schrieb Paul Howarth:
On Wed, 28 Mar 2012 22:16:25 +0200 Reindl Harald h.reindl@thelounge.net wrote:
maybe the tone was minimal rude because i do absolutely not understand why anyone can have the idea "hey let us remove the whole custom partitioning and replace with kickstart only" to solve problems with it
That's not what I understood from Adam's description, which was:
It's worth bearing in mind there's a giant anaconda UI rewrite still pending, which entirely redesigns the storage configuration GUI. One of the other major changes is that it makes all installations kickstart-driven. The GUI will just produce a kickstart file, which anaconda will then process to perform the actual install.
see the mail below
yes, i confused Adam and Richard because both @redhat.com and both spoke about Kickstart, and this message below is as clear as it can be and matches 100% to my answer - my reply to the wrong person was the result of reply not instantly and try to wait what happens
-------- Original-Nachricht -------- Betreff: Re: Booting Fedora from LVM with grub2 Datum: Sun, 25 Mar 2012 09:32:02 +0100 Von: Richard W.M. Jones rjones@redhat.com Antwort an: Development discussions related to Fedora devel@lists.fedoraproject.org An: Development discussions related to Fedora devel@lists.fedoraproject.org
On Fri, Mar 23, 2012 at 12:08:42PM -0400, Gerry Reno wrote:
You can do all of these things manually outside of anaconda and then just tell anaconda to use existing setup. But that is not very user friendly.
I had similar problems trying to set up a basic RAID 1 (not /boot) guest. I found Anaconda is full of bugs and wierdness once you stray into the custom partitioning code.
Apparently kickstart is a better way to do this.
Perhaps, like Ubuntu's installer, the graphical part of Anaconda should concentrate on doing the simple stuff, and leave everything else to kickstart non-graphical installations.
Now my understanding of that doesn't include anything about removing custom partitioning. It's all about splitting up the functionality of anaconda into two distinct parts - the GUI configuration part, which I would expect still to contain custom partitioning, and a back-end that implements the configuration, where the configuration is passed to it in the form of a kickstart file (either the output of the GUI part, or a kickstart file prepared earlier by the user).
This is basically correct, though I doubt the kickstart-based action is going to be all that noticable to the user. From an implementation perspective, it certainly is very appealing though.
My understanding is based entirely on Adam's description since I'm not involved in anaconda development, but it strikes me as being a good thing as it would split one large process into two, presumably smaller ones, which would help solve the problem of running anaconda on machines with less memory.
The memory consumption was largely based upon merging the initrd and the stage2 image into one very large initrd that had to be in memory. However, we've made additional changes that split it back up (though, not in an annoying way like it used to be) that means much less stuff needs to be kept in memory.
- Chris
Jared K. Smith wrote:
Because my reply wasn't about the content of your message. My reply was all about the *tone* of your email. I know that language barrier is part of the problem here, but the tone of your email messages often comes across as demanding and condescending.
Harald is simply frustrated by Fedora changes which in his view are clearly not for the better, and I can fully understand that, given that I find myself agreeing with him every so often. Something that looks like an improvement to a developer might actually be a regression in users' view.
The tone of his messages is purely and simply a result of the frustration.
Kevin Kofler
On 03/29/2012 04:39 AM, Kevin Kofler wrote:
Jared K. Smith wrote:
Because my reply wasn't about the content of your message. My reply was all about the *tone* of your email. I know that language barrier is part of the problem here, but the tone of your email messages often comes across as demanding and condescending.
Harald is simply frustrated by Fedora changes which in his view are clearly not for the better, and I can fully understand that, given that I find myself agreeing with him every so often. Something that looks like an improvement to a developer might actually be a regression in users' view.
The tone of his messages is purely and simply a result of the frustration.
I am not surprised by your excuse but I don't buy that at all. He comes off as rude in other mailing lists as well including the users list where he talks down on anyone who does things in a different way. If someone is so frustrated by Fedora that they feel compelled to behave this way, then they should pick something more suitable for them.
Rahul
Just out of curiosity: Your description makes me assume that the installer in the future still don't do things like partitioning, formating or installing a basic set of packages in the background while the user (which has a high latency/response time) is asked questions about the root password to use, users accounts to create or which timezone the system is in?
Just wondering, because the Ubuntu installer does things like that, which makes the installation a little bit quicker.
This is the direction we are heading, though it's uncertain yet whether this part will be in F18 or will have to get put off until F19. Just getting a new, relatively bug-free UI in is a lot of work for a single release.
- Chris
Chris Lumens wrote:
Just out of curiosity: Your description makes me assume that the installer in the future still don't do things like partitioning, formating or installing a basic set of packages in the background while the user (which has a high latency/response time) is asked questions about the root password to use, users accounts to create or which timezone the system is in?
Just wondering, because the Ubuntu installer does things like that, which makes the installation a little bit quicker.
This is the direction we are heading, though it's uncertain yet whether this part will be in F18 or will have to get put off until F19. Just getting a new, relatively bug-free UI in is a lot of work for a single release.
How is that possible to implement with a: 1. Show GUI, write kickstart. 2. Process kickstart. design?
Kevin Kofler
How is that possible to implement with a:
- Show GUI, write kickstart.
- Process kickstart.
design?
We're not literally going to have one program that you use to construct a kickstart file, write the file out, and then spawn a separate program do to the processing of. We are using kickstart as the data store internally (via pykickstart) and having one program operate on it. The only writing will be towards the end of installation, where we spit out /root/anaconda-ks.cfg.
A lot of these tasks like figuring out authentication information and adding extra users can be prompted for while filesystems are being created, then actually take effect and augment the ksdata after packages are laid down. They will be reflected in the final anaconda-ks.cfg. Some other tasks may not map to existing kickstart at all (yet).
- Chris
On Thu, Mar 29, 2012 at 7:18 PM, Chris Lumens clumens@redhat.com wrote:
How is that possible to implement with a:
- Show GUI, write kickstart.
- Process kickstart.
design?
We're not literally going to have one program that you use to construct a kickstart file, write the file out, and then spawn a separate program do to the processing of. We are using kickstart as the data store internally (via pykickstart) and having one program operate on it. The only writing will be towards the end of installation, where we spit out /root/anaconda-ks.cfg.
A lot of these tasks like figuring out authentication information and adding extra users can be prompted for while filesystems are being created, then actually take effect and augment the ksdata after packages are laid down. They will be reflected in the final anaconda-ks.cfg. Some other tasks may not map to existing kickstart at all (yet).
- Chris
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
If we go for doing something like that, is there any reason to keep firstboot around? Couldn't we stuff the actions done in firstboot into anaconda with this newer asynch design?
On 03/29/2012 10:15 PM, Conan Kudo (ニール・ゴンパ) wrote:
On Thu, Mar 29, 2012 at 7:18 PM, Chris Lumens <clumens@redhat.com mailto:clumens@redhat.com> wrote:
> How is that possible to implement with a: > 1. Show GUI, write kickstart. > 2. Process kickstart. > design? We're not literally going to have one program that you use to construct a kickstart file, write the file out, and then spawn a separate program do to the processing of. We are using kickstart as the data store internally (via pykickstart) and having one program operate on it. The only writing will be towards the end of installation, where we spit out /root/anaconda-ks.cfg. A lot of these tasks like figuring out authentication information and adding extra users can be prompted for while filesystems are being created, then actually take effect and augment the ksdata after packages are laid down. They will be reflected in the final anaconda-ks.cfg. Some other tasks may not map to existing kickstart at all (yet). - Chris -- devel mailing list devel@lists.fedoraproject.org <mailto:devel@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/devel
If we go for doing something like that, is there any reason to keep firstboot around? Couldn't we stuff the actions done in firstboot into anaconda with this newer asynch design?
Well, there are some reasons on each side there, and it certainly merits further discussion.
Personally, I've got some skepticism about running firstboot-style plugins in the installer. For those that need that (and they are out there), it's a whole lot easier to put things like that in the packageset and have them run at firstboot than to get them into the running install image. But if we decide it's worth it, that's probably a problem we could engineer around, too.
On Mon, 2012-03-26 at 10:24 +0100, Richard W.M. Jones wrote:
On Sun, Mar 25, 2012 at 11:41:18PM +0200, Kevin Kofler wrote:
Richard W.M. Jones wrote:
Perhaps, like Ubuntu's installer, the graphical part of Anaconda should concentrate on doing the simple stuff, and leave everything else to kickstart non-graphical installations.
I don't think that would be a good idea, at all.
Ummmmmm ... okay.
Any particular reason? Any other plans to make the current situation better?
Your mail didn't really go very far towards making the situation better, though, did it? Saying that manual partitioning is 'full of bugs and weirdness' without any actual description of any specific bug or weirdness, or link to any bug report, is hardly a candidate for Most Helpful Post Of The Year...
devel@lists.stg.fedoraproject.org