From the changelog:
* Sun Nov 07 2004 Jeremy Katz katzj@redhat.com - 10.2.0.0-1 - Switch to python 2.4
Does switch mean "now works with", or "now requires"?
There's so many other things that look tasty in the changelog that I'm tempted to use some snapshot of the devel version of anaconda for our FC3-derived release. But perhaps I should be disuaded. :)
On Tue, 2004-11-30 at 12:22 -0500, Matthew Miller wrote:
From the changelog:
- Sun Nov 07 2004 Jeremy Katz katzj@redhat.com - 10.2.0.0-1
- Switch to python 2.4
Does switch mean "now works with", or "now requires"?
Well, the build "requires" it in that I've changed things from python2.3 to python2.4. Those are probably relatively easy to change back. And then there were some deprecated things I've removed.
There's so many other things that look tasty in the changelog that I'm tempted to use some snapshot of the devel version of anaconda for our FC3-derived release. But perhaps I should be disuaded. :)
What bits in particular interest you? There are definitely some things there that aren't overly well tested (changing from dietlibc -> glibc for example). At the same time, most of the more innocuous changes are also present on rhel4-branch.
Jeremy
On Tue, Nov 30, 2004 at 01:14:54PM -0500, Jeremy Katz wrote:
What bits in particular interest you? There are definitely some things there that aren't overly well tested (changing from dietlibc -> glibc for example). At the same time, most of the more innocuous changes are also present on rhel4-branch.
Better handling for out-of-space, the serial console fixes. Nothing really huge. Well, if rescue mode always crashes over the network, that might be huge. I'll check out the rhel4 branch -- thanks for the suggestion.
On Tue, 2004-11-30 at 13:24 -0500, Matthew Miller wrote:
On Tue, Nov 30, 2004 at 01:14:54PM -0500, Jeremy Katz wrote:
What bits in particular interest you? There are definitely some things there that aren't overly well tested (changing from dietlibc -> glibc for example). At the same time, most of the more innocuous changes are also present on rhel4-branch.
Better handling for out-of-space, the serial console fixes. Nothing really huge. Well, if rescue mode always crashes over the network, that might be huge. I'll check out the rhel4 branch -- thanks for the suggestion.
Should all be on rhel4-branch. Although there's a few niggling warts with bug fixes there that I need to clean up. But within the next day or so, it should be back to stable :)
And to answer the unanswered question, yes, FC4 is going to depend on python 2.4. One of my goals is to start replacing some of our hacky methods of doing things with bits of functionality that have been added in newer versions of python. anaconda_log should just the new python logging stuff, iutil.exec* should be replaceable with subprocess, and a few other things like that. Patches for any of the above (or other things people would like to see) are gladly accepted.
On a related note -- what things would other people like to see going in. Features, bugs, changes to functionality... I have some thoughts of what direction I want to go in, but a lot of the first pass stuff I want to do is more related to clean-ups for easier maintenance than anything else.
Jeremy
On a related note -- what things would other people like to see going in. Features, bugs, changes to functionality... I have some thoughts of what direction I want to go in, but a lot of the first pass stuff I want to do is more related to clean-ups for easier maintenance than anything else.
I'd love to be able to do this: http://www.redhat.com/archives/anaconda-devel-list/2004-November/msg00033.ht...
So I don't have to rebuild my kickstart server on an Opteron.
- Matt
On Tue, Nov 30, 2004 at 02:14:11PM -0500, Jeremy Katz wrote:
On a related note -- what things would other people like to see going in. Features, bugs, changes to functionality... I have some thoughts of what direction I want to go in, but a lot of the first pass stuff I want to do is more related to clean-ups for easier maintenance than anything else.
I'd kinda like it if installclasses could be completely defined in comps.xml.
Maybe that's crazy talk.
On Tue, 2004-11-30 at 14:30, Matthew Miller wrote:
On Tue, Nov 30, 2004 at 02:14:11PM -0500, Jeremy Katz wrote:
On a related note -- what things would other people like to see going in. Features, bugs, changes to functionality... I have some thoughts of what direction I want to go in, but a lot of the first pass stuff I want to do is more related to clean-ups for easier maintenance than anything else.
I'd kinda like it if installclasses could be completely defined in comps.xml.
Maybe that's crazy talk.
I think so. I think installclasses should be defined elsewhere and comps should be more tightly constrained to be groups/hierarchy information only. Also the comps format is going to need to deal with archs in some more precise way going forward.
If we can make it happen quickly I'd like to work on merging the comps format into the xml repomd format.
-sv
On Tue, Nov 30, 2004 at 02:39:51PM -0500, seth vidal wrote:
I'd kinda like it if installclasses could be completely defined in comps.xml. Maybe that's crazy talk.
I think so. I think installclasses should be defined elsewhere and comps should be more tightly constrained to be groups/hierarchy information only. Also the comps format is going to need to deal with archs in some more precise way going forward.
Okay. I guess I don't particularly care that it's comps.xml per se. Just "not in anaconda proper" -- it seems more like a "distribution config file" than a part of the installer. (I know there's the override thing (thanks!), but why not go all the way?)
Hmm. I'm having deja vu.... Yeah, there was a conversation about this last May, and looks like Jeremy had thought about it considerably already.
https://listman.redhat.com/archives/anaconda-devel-list/2004-May/msg00050.html
So yeah, I'm for that. :)
On Tue, 2004-11-30 at 14:55 -0500, Matthew Miller wrote:
Hmm. I'm having deja vu.... Yeah, there was a conversation about this last May, and looks like Jeremy had thought about it considerably already.
https://listman.redhat.com/archives/anaconda-devel-list/2004-May/msg00050.html
So yeah, I'm for that. :)
And all of the questions I had at the end of that mail still apply :)
Jeremy
On Tue, 2004-11-30 at 14:30 -0500, Matthew Miller wrote:
I'd kinda like it if installclasses could be completely defined in comps.xml.
Maybe that's crazy talk.
Progeny comes to mind again, They have a project in hand to divide a Linux distro into components.
eg base component, KDE component, BU component.
They're building on Debian and FC.
On a related note -- what things would other people like to see going in. Features, bugs, changes to functionality... I have some thoughts of what direction I want to go in, but a lot of the first pass stuff I want to do is more related to clean-ups for easier maintenance than anything else.
What do you think about dumping the hdlist format and possibly allowing an updates-accessible path for installs?
But something less obscured than that odd hack that's in rhel3?
-sv
On Tue, 2004-11-30 at 14:38 -0500, seth vidal wrote:
On a related note -- what things would other people like to see going in. Features, bugs, changes to functionality... I have some thoughts of what direction I want to go in, but a lot of the first pass stuff I want to do is more related to clean-ups for easier maintenance than anything else.
What do you think about dumping the hdlist format and possibly allowing an updates-accessible path for installs?
The first is at least on my "consider" list. There are some issues to work out (things like keeping track of CDs, package ordering to avoid "excessive" CD swapping) but they're not unsolvable problems. Updates are a harder problem for a few reasons. I'd rather attack the set of problems in steps and get one set done in one release and then do updates later. The big question deciding whether it happens or not are a) what the FC4 schedule ends up being and b) how much a few other things eat into my time
But something less obscured than that odd hack that's in rhel3?
There's a reason that hack was never moved off of the branch :)
Jeremy
The first is at least on my "consider" list. There are some issues to work out (things like keeping track of CDs, package ordering to avoid "excessive" CD swapping) but they're not unsolvable problems. Updates are a harder problem for a few reasons. I'd rather attack the set of problems in steps and get one set done in one release and then do updates later. The big question deciding whether it happens or not are a) what the FC4 schedule ends up being and b) how much a few other things eat into my time
Fair enough. As i posted to the f-c-l and rpm-metadata lists maybe those are a couple of options for solving the removable media problem.
We could couple pkgorder with a script for making the media tagging for the metadata and we could then organize the packages on the discs from that.
The prereq info is included in the primary.xml so we could work from there to figure out ordering, I think. I need to learn more about how the ordering works for pkgorder anyway.
How does it work? -sv
On a related note -- what things would other people like to see going in. Features, bugs, changes to functionality... I have some thoughts of what direction I want to go in, but a lot of the first pass stuff I want to do is more related to clean-ups for easier maintenance than anything else.
Jeremy,
When I installed FC3 from burned ISO's, I had bad media (didn't run media check). When anaconda ran across a corrupt RPM on CD 3, it asked me over and over if I wanted to retry, but it never offered me an option to reboot or retrieve said RPM via HTTP so the rest of the install could proceed. I hit Ctrl-Alt-F1, Ctrl-Alt-Del to reboot until I could get the media fixed. I would like to see a more user-friendly approach when corrupt RPMs are found.
Thanks.
/Brian/
On Tue, 2004-11-30 at 14:41 -0500, Brian Long wrote:
On a related note -- what things would other people like to see going in. Features, bugs, changes to functionality... I have some thoughts of what direction I want to go in, but a lot of the first pass stuff I want to do is more related to clean-ups for easier maintenance than anything else.
When I installed FC3 from burned ISO's, I had bad media (didn't run media check). When anaconda ran across a corrupt RPM on CD 3, it asked me over and over if I wanted to retry, but it never offered me an option to reboot or retrieve said RPM via HTTP so the rest of the install could proceed. I hit Ctrl-Alt-F1, Ctrl-Alt-Del to reboot until I could get the media fixed. I would like to see a more user-friendly approach when corrupt RPMs are found.
We only set up the network on network installs. Doing more than that makes things quite a bit more complicated. Retrying is about the only option you have. Adding "abort installation" is an option but you're no better off then than if you hit the reset button, so I'm not sure what the real advantage is.
Jeremy
When I installed FC3 from burned ISO's, I had bad media (didn't run media check). When anaconda ran across a corrupt RPM on CD 3, it asked me over and over if I wanted to retry, but it never offered me an option to reboot or retrieve said RPM via HTTP so the rest of the install could proceed. I hit Ctrl-Alt-F1, Ctrl-Alt-Del to reboot until I could get the media fixed. I would like to see a more user-friendly approach when corrupt RPMs are found.
We only set up the network on network installs. Doing more than that makes things quite a bit more complicated. Retrying is about the only option you have. Adding "abort installation" is an option but you're no better off then than if you hit the reset button, so I'm not sure what the real advantage is.
To make Linux more user-friendly, it shouldn't retry forever. :) It should keep a retry count per RPM and if the user retries 3 times, it pops up a dialog saying the installation has failed and they should restart.
Or even better, it could offer the option to skip the RPM. Depending on the groups selected for installation, a corrupt -devel RPM not getting installed is not a big deal. In fact, any RPM not "mandatory" in comps.xml could be skipped (I imagine). The rest of the install would proceed as normal and maybe populate a file that firstboot could read and try to install the corrupt RPMs once networking is enabled. Just an idea.
/Brian/
On Wed, Dec 01, 2004 at 08:23:51AM -0500, Brian Long wrote:
To make Linux more user-friendly, it shouldn't retry forever. :) It should keep a retry count per RPM and if the user retries 3 times, it pops up a dialog saying the installation has failed and they should restart.
I kinda want it to retry forever on a network install.
Or even better, it could offer the option to skip the RPM. Depending on the groups selected for installation, a corrupt -devel RPM not getting installed is not a big deal. In fact, any RPM not "mandatory" in comps.xml could be skipped (I imagine). The rest of the install would proceed as normal and maybe populate a file that firstboot could read and try to install the corrupt RPMs once networking is enabled. Just an idea.
The whole RPM transaction set would need to be recomputed....
On Wed, Dec 01, 2004 at 09:17:28AM -0500, Matthew Miller wrote:
On Wed, Dec 01, 2004 at 08:23:51AM -0500, Brian Long wrote:
To make Linux more user-friendly, it shouldn't retry forever. :) It should keep a retry count per RPM and if the user retries 3 times, it pops up a dialog saying the installation has failed and they should restart.
I kinda want it to retry forever on a network install.
Or even better, it could offer the option to skip the RPM. Depending on the groups selected for installation, a corrupt -devel RPM not getting installed is not a big deal. In fact, any RPM not "mandatory" in comps.xml could be skipped (I imagine). The rest of the install would proceed as normal and maybe populate a file that firstboot could read and try to install the corrupt RPMs once networking is enabled. Just an idea.
The whole RPM transaction set would need to be recomputed....
The ability to swap the damaged cd, or get the rpm through other means (usb/firewire disk, network) would be much appreciated.
Regards, Luciano Rocha
On Tue, 2004-11-30 at 14:14 -0500, Jeremy Katz wrote:
On a related note -- what things would other people like to see going in. Features, bugs, changes to functionality... I have some thoughts of what direction I want to go in, but a lot of the first pass stuff I want to do is more related to clean-ups for easier maintenance than anything else.
The build system is pretty scary right now. (Disclaimer: My knowledge is circa FC2)
I had to add cracklib checking to the root password screen for a customer awhile back. I had to patch buildimage and friends to unpack my python-crack package and also patch it to not delete python-crack's relevant files. It would be really nice if I could feed buildimage a list of packages and files to allow in various images. Or even better, there could be a hook where I could post process the contents of the image before it is finalized, or something else.
-- Darrin
On Tue, Nov 30, 2004 at 03:19:15PM -0500, Darrin Thompson wrote:
I had to add cracklib checking to the root password screen for a customer awhile back. I had to patch buildimage and friends to unpack my
Speaking of which, that's not a bad suggestion. Maybe with a "yes, I really want a terrible password" checkbox.
On Tue, 2004-11-30 at 15:42 -0500, Matthew Miller wrote:
On Tue, Nov 30, 2004 at 03:19:15PM -0500, Darrin Thompson wrote:
I had to add cracklib checking to the root password screen for a customer awhile back. I had to patch buildimage and friends to unpack my
Speaking of which, that's not a bad suggestion. Maybe with a "yes, I really want a terrible password" checkbox.
Patches that get submitted are looked at and considered but it's hard for me to do that if they're not sent :-)
Jeremy
On Tue, 2004-11-30 at 15:19 -0500, Darrin Thompson wrote:
The build system is pretty scary right now. (Disclaimer: My knowledge is circa FC2)
It hasn't changed much really since Red Hat Linux 7.0 or so.
I had to add cracklib checking to the root password screen for a customer awhile back. I had to patch buildimage and friends to unpack my python-crack package and also patch it to not delete python-crack's relevant files. It would be really nice if I could feed buildimage a list of packages and files to allow in various images. Or even better, there could be a hook where I could post process the contents of the image before it is finalized, or something else.
The big problem is that it's just a huge chunk of work, especially to do without regressions. Adding new deps is a rare enough occurrence that it just hasn't been high on the list of priorities, especially as the number of people that use it is extremely low.
Jeremy
On Tue, 2004-11-30 at 22:15 -0500, Jeremy Katz wrote:
Adding new deps is a rare enough occurrence that it just hasn't been high on the list of priorities, especially as the number of people that use it is extremely low.
I was afraid of that. :-)
If I could make only one change to the build system it would be to make the shell scripts run with set -e.
If I could make a second change, it would be to make the build system _shut_ _up_ when it's working correctly.
Not sure if I'm motivated enough to make these patches, so don't anyone hold their breath... But it's nice to know there's an opening.
-- Darrin
On Tue, Nov 30, 2004 at 02:14:11PM -0500, Jeremy Katz wrote:
On a related note -- what things would other people like to see going in. Features, bugs, changes to functionality... I have some thoughts of what direction I want to go in, but a lot of the first pass stuff I want to do is more related to clean-ups for easier maintenance than anything else.
Well, as I've mentioned already, I'd like to be able to use anaconda to create a virtual image in a dir to serve it via NFS to a diskless client. I think it would be a nice (and logical) addition to the Stateless Linux effort.
On Tue, 2004-11-30 at 22:39 -0500, Dimitrie O. Paun wrote:
On Tue, Nov 30, 2004 at 02:14:11PM -0500, Jeremy Katz wrote:
On a related note -- what things would other people like to see going in. Features, bugs, changes to functionality... I have some thoughts of what direction I want to go in, but a lot of the first pass stuff I want to do is more related to clean-ups for easier maintenance than anything else.
Well, as I've mentioned already, I'd like to be able to use anaconda to create a virtual image in a dir to serve it via NFS to a diskless client. I think it would be a nice (and logical) addition to the Stateless Linux effort.
Replying to this got lost in the noise of other things I've got going on at the moment... but this functionality is already at least sort of there. Look at running anaconda with --rootpath /path to install packages under /path. I got a few patches from jrb when he was working on the Stateless stuff to get it working better, so he might have a better idea of where it currently stands (cc'd). It's existed basically forever as an aid for debugging, though.
Jeremy
On Tue, Nov 30, 2004 at 11:08:30PM -0500, Jeremy Katz wrote:
at the moment... but this functionality is already at least sort of there. Look at running anaconda with --rootpath /path to install packages under /path.
I've just tried to use anaconda with the --rootpath option. It's not bad, but I think it's still not usable as a regular application to create these virtual roots. Here are a few of my observations:
1. it still does hardware detection: [root@dimi ~]# anaconda --graphical --rootpath=/home/dimi/dev/kogaion/virtualroot.anaconda --method=http://dimi/FC3/ * Display mode = g * Method = http://dimi/FC3/ Probing for video card: ATI Radeon 9600 Probing for monitor type: Dell 1901FP (Digital) Probing for mouse type: Skipped mouse probe.
2. it still asks for langauge, keyboard settings instead of just using the current ones, like any regular X app
3. I can not close the window. I have to literaly kill the app with kill(3) or xkill.
4. It still tries to mess with my disks: * moving (1) to step partitionobjinit * pv is /dev/hda2 in vg VolGroup00, size is 80866181120 * vg VolGroup00, size is 80866181120 * lv is VolGroup00/LogVol00, size of 79255568384 * lv is VolGroup00/LogVol01, size of 1577058304 * running vgchange failed: 1280. disabling lvm
5. I don't think asking about timezones is appropriate in this context, it should use the current one.
6. It still messes with my filesystems, once the installation starts: * moving (1) to step confirminstall * moving (1) to step install * moving (1) to step enablefilesystems * moving (1) to step migratefilesystems * moving (1) to step setuptime * moving (1) to step preinstallconfig * No pcic controller detected * Needed lvm2 for None * Needed lvm2 for None * moving (1) to step installpackages * setting file_context_path to /etc/selinux/targeted/contexts/files/file_contexts
7. These are all very scary. Is it messing up my host system? * failed to unlink /var/lib/rpm/__db.001: [Errno 2] No such file or directory: '/home/dimi/dev/kogaion/virtualroot.anaconda/var/lib/rpm/__db.001' * failed to unlink /var/lib/rpm/__db.002: [Errno 2] No such file or directory: '/home/dimi/dev/kogaion/virtualroot.anaconda/var/lib/rpm/__db.002' * failed to unlink /var/lib/rpm/__db.003: [Errno 2] No such file or directory: '/home/dimi/dev/kogaion/virtualroot.anaconda/var/lib/rpm/__db.003' * failed to unlink /var/lib/rpm: [Errno 21] Is a directory: '/var/lib/rpm' * moving (1) to step postinstallconfig * No pcic controller detected * self.hostname = localhost.localdomain * rhgb installed, adding to boot loader config
8. It fails after installing all the .rpms: * moving (1) to step firstboot * moving (1) to step instbootloader Traceback (most recent call last): File "/usr/src/build/475969-i386/install//usr/lib/anaconda/gui.py", line 1074, in handleRenderCallback self.currentWindow.renderCallback() File "/usr/src/build/475969-i386/install//usr/lib/anaconda/iw/progress_gui.py", line 242, in renderCallback self.intf.icw.nextClicked() File "/usr/src/build/475969-i386/install//usr/lib/anaconda/gui.py", line 789, in nextClicked self.dispatch.gotoNext() File "/usr/src/build/475969-i386/install//usr/lib/anaconda/dispatch.py", line 171, in gotoNext self.moveStep() File "/usr/src/build/475969-i386/install//usr/lib/anaconda/dispatch.py", line 239, in moveStep rc = apply(func, self.bindArgs(args)) File "/usr/src/build/475969-i386/install//usr/lib/anaconda/bootloader.py", line 114, in writeBootloader rootDev = fsset.getEntryByMountPoint('/').device.getDevice() AttributeError: 'NoneType' object has no attribute 'device'
I got a few patches from jrb when he was working on the Stateless stuff to get it working better, so he might have a better idea of where it currently stands (cc'd).
Cool, it would be nice if we can get anaconda to have a "regular app" mode so we can use it out of the box to create images for diskless clients. After playing around with the --rootpath option, I am now convinced that I had the right intuition about anaconda being the solution to the image creation problem. From afar, it seems that a bit of hacking can turn it into the perfect utility.
Now, I'm willing to put my money where my mouth is, and pitch in to help get anaconda there. I just want to: A. Make sure that we're all on the same page, and we agree that this is the way to go. B. I'm not duplicating work that you guys are doing as part of the Stateless Linux effort.
Dimitrie O. Paun wrote:
On Tue, Nov 30, 2004 at 11:08:30PM -0500, Jeremy Katz wrote:
at the moment... but this functionality is already at least sort of there. Look at running anaconda with --rootpath /path to install packages under /path.
I'd like to see a way of completely decoupling the hard disk imaging in anaconda. With the -rootpath option and no hard disk imaging, I don't see the point of keeping Kickstart Configurator around. You'd use the same tool to build a kickstart file that you use install an anaconda based system with. It seems that, if the rest of the python based system tools were built carefully, they could be used to easily extend anaconda in a meaningful two for the price of one kind-of way. A new config tool could be put in the dispatch.py file. Hooks for these tools in Anaconda sound like a way enhancing support for the goal of a read only root in Stateless Linux.
You know I'd almost like to see the package install completely decoupled too. If I create a standard that this group of machines have this set of packages installed because of their role as a "Thick client" http://fedora.redhat.com/docs/stateless/index.html#sn-overview-clients, then I could use the proposed anaconda to configure /etc for the chunk of code in /usr. I would then run the installer once to build /usr, and then run the installer multiple times to build various /etc options in each computer's role.
I've just tried to use anaconda with the --rootpath option. It's not bad, but I think it's still not usable as a regular application to create these virtual roots. Here are a few of my observations:
- it still does hardware detection:
[root@dimi ~]# anaconda --graphical --rootpath=/home/dimi/dev/kogaion/virtualroot.anaconda --method=http://dimi/FC3/
- Display mode = g
- Method = http://dimi/FC3/
Probing for video card: ATI Radeon 9600 Probing for monitor type: Dell 1901FP (Digital) Probing for mouse type: Skipped mouse probe.
- it still asks for langauge, keyboard settings instead of just using the current ones, like any regular X app
I would think this is ok. Anaconda still has to understand it's operating environment.
I can not close the window. I have to literaly kill the app with kill(3) or xkill.
It still tries to mess with my disks:
- moving (1) to step partitionobjinit
- pv is /dev/hda2 in vg VolGroup00, size is 80866181120
- vg VolGroup00, size is 80866181120
- lv is VolGroup00/LogVol00, size of 79255568384
- lv is VolGroup00/LogVol01, size of 1577058304
- running vgchange failed: 1280. disabling lvm
These may be geared to the Stateless Linux push. If the partitioning is pushed off to the very last step of anaconda before the install takes off, then there may be some other advantages. One, it may be easier to support the decoupling of running the installer without imaging hard disks. (I don't recall right now, if there was a --test option that turned off imaging disks.) Two, if the package selection is performed right before imaging hard disks, then some actual numbers could be fed into partition.py verses these hard coded guesses: checkSizes = [('/usr', 250), ('/tmp', 50), ('/var', 384), ('/home', 100), ('/boot', 75)]
- I don't think asking about timezones is appropriate in this context, it should use the current one.
Again I'd rather see the disk issue solved. I'd rather put up with this because it completely separates anaconda from code variations for a "running system" verses "anaconda for a real install". I would imagine this would add to additional testing. This is the same reason 2. above seems ok to me.
<snip>
I got a few patches from jrb when he was working on the Stateless stuff to get it working better, so he might have a better idea of where it currently stands (cc'd).
Cool, it would be nice if we can get anaconda to have a "regular app" mode so we can use it out of the box to create images for diskless clients.
Or other creative uses. ;-)
Greg
On Sun, Dec 05, 2004 at 11:35:42PM -0700, Greg Morgan wrote:
I'd like to see a way of completely decoupling the hard disk imaging in anaconda.
Agreed.
- it still asks for langauge, keyboard settings instead of just using the current ones, like any regular X app
I would think this is ok. Anaconda still has to understand it's operating environment.
It can do so automatically. Imagine if every program, when started, would ask for the lang and keyboard. That would be silly, the user session already has a default language (BTW, hwo do you get to that, is it just $LANG?).
- It still tries to mess with my disks:
- moving (1) to step partitionobjinit
- pv is /dev/hda2 in vg VolGroup00, size is 80866181120
- vg VolGroup00, size is 80866181120
- lv is VolGroup00/LogVol00, size of 79255568384
- lv is VolGroup00/LogVol01, size of 1577058304
- running vgchange failed: 1280. disabling lvm
These may be geared to the Stateless Linux push.
It may be, and it's all good, but it should be skipped altogether in --rootpath mode.
Again I'd rather see the disk issue solved. I'd rather put up with this because it completely separates anaconda from code variations for a "running system" verses "anaconda for a real install".
I see no reason to put up with it, really. Anaconda has an internal variable what holds this info, that can be initialized from a ks file. It should be trivial to simply initialize it from the current running environment (but again, how do we ge to it?).
On Tue, 2004-11-30 at 22:39 -0500, Dimitrie O. Paun wrote:
On Tue, Nov 30, 2004 at 02:14:11PM -0500, Jeremy Katz wrote:
On a related note -- what things would other people like to see going in. Features, bugs, changes to functionality... I have some thoughts of what direction I want to go in, but a lot of the first pass stuff I want to do is more related to clean-ups for easier maintenance than anything else.
Well, as I've mentioned already, I'd like to be able to use anaconda to create a virtual image in a dir to serve it via NFS to a diskless client. I think it would be a nice (and logical) addition to the Stateless Linux effort.
I think Paul mentioned this already but you can do:
yum --installroot=/some/path groupinstall Base Core
and get similar results.
You might consider it.
-sv
On Wed, Dec 01, 2004 at 12:44:58AM -0500, seth vidal wrote:
I think Paul mentioned this already but you can do:
yum --installroot=/some/path groupinstall Base Core
and get similar results.
Thanks, that seem pretty cool. However, one reason I wanted to use anaconda was for the nice graphic screen where users can select/deselect apps.
Speaking of which, on my system (FC3) the groups are bunched together in the following categories: Desktops Applications Servers Development System
Is this information in the comps.xml file, or is it hardcoded someplace?
Also "yum grouplist" does not list 'Base' or 'Core', which means thare are some hidden groups. I guess they would be all the mandatory groups, right? Any way to get at them?
On Wed, 2004-12-01 at 02:05 -0500, Dimitrie O. Paun wrote:
Speaking of which, on my system (FC3) the groups are bunched together in the following categories: Desktops Applications Servers Development System
Is this information in the comps.xml file, or is it hardcoded someplace?
It's the <grouphierarchy> part of the comps file
Cheers,
Jeremy
On Tue, 2004-11-30 at 13:24 -0500, Matthew Miller wrote:
On Tue, Nov 30, 2004 at 01:14:54PM -0500, Jeremy Katz wrote:
What bits in particular interest you? There are definitely some things there that aren't overly well tested (changing from dietlibc -> glibc for example). At the same time, most of the more innocuous changes are also present on rhel4-branch.
Better handling for out-of-space, the serial console fixes. Nothing really huge. Well, if rescue mode always crashes over the network, that might be huge. I'll check out the rhel4 branch -- thanks for the suggestion.
Progeny has a fork too; for what you're doing with bu linux it would be worth a look.
anaconda-devel@lists.stg.fedoraproject.org