For the next iteration of the LiveCD I would suggest omitting the netinstall option. This has caused a rather large support load on the fora (or forums if you prefer) from people who can't get it to work.
As netinstall is really most useful with a "perfect" network connection or local archive, and can be tricky to get right, it is just confusing a lot of the LiveCD "market segment". More sophisticated users will just grab the netinstall CD or use images/boot.iso. Removing it would also leave more room for useful apps.
Phil
On 06/04/2010 01:35 PM, Phil Schaffner wrote:
For the next iteration of the LiveCD I would suggest omitting the netinstall option. This has caused a rather large support load on the fora (or forums if you prefer) from people who can't get it to work.
I'm more in favor of improving the available docs rather than dropping the option. But then again, I am not active on the fora, only on IRC. Where we had our share of calls for support ( and thanks to one of those calls was the problem with the first release spotted and led to a fix).
Manuel
Manuel Wolfshant wrote on 06/04/2010 08:04 AM: ...
I'm more in favor of improving the available docs rather than dropping the option. But then again, I am not active on the fora, only on IRC. Where we had our share of calls for support ( and thanks to one of those calls was the problem with the first release spotted and led to a fix).
I'm all for improving the docs in any case. That should go to -docs if we're going to discuss it.
Phil
On 04/06/2010 13:40, Phil Schaffner wrote:
Manuel Wolfshant wrote on 06/04/2010 08:04 AM: ...
I'm more in favor of improving the available docs rather than dropping the option. But then again, I am not active on the fora, only on IRC. Where we had our share of calls for support ( and thanks to one of those calls was the problem with the first release spotted and led to a fix).
I'm all for improving the docs in any case. That should go to -docs if we're going to discuss it.
in addition to improving docs, it would also be quite cool to pre-populate the questions asked by the netinstaller with same sane defaults. I've looked at doing that in the past and had it working for 5.4; but we decided not to go ahead since we didnt have the time to QA the process properly.
Now that we have some dedicated QA hardware where we can simulate a lot of the network stuff, it might be worth bringing that patch back in and adopting it.
- KB
On 06/04/2010 06:57 PM, Karanbir Singh wrote:
On 04/06/2010 13:40, Phil Schaffner wrote:
Manuel Wolfshant wrote on 06/04/2010 08:04 AM: ...
I'm more in favor of improving the available docs rather than dropping the option. But then again, I am not active on the fora, only on IRC. Where we had our share of calls for support ( and thanks to one of those calls was the problem with the first release spotted and led to a fix).
I'm all for improving the docs in any case. That should go to -docs if we're going to discuss it.
in addition to improving docs, it would also be quite cool to pre-populate the questions asked by the netinstaller with same sane defaults.
As far as I have seen while being in #centos, most beginners' questions (in the context of netinstall) were more or less similar to "what should I put in the 'mirror' and 'path' fields ?". Can we patch anaconda so as to prepopulate those two without overloading any particular mirrors (maybe using somehow the output of mirrorlist ) ?
Manuel
As far as I have seen while being in #centos, most beginners' questions (in the context of netinstall) were more or less similar to "what should I put in the 'mirror' and 'path' fields ?". Can we patch anaconda so as to prepopulate those two without overloading any particular mirrors (maybe using somehow the output of mirrorlist ) ?
I swear I have always wished for this, Fedora does this now so there is likely no technical reason a static pointer to the mirror list can't be used unless a 'list' requires a newer version of Anaconda. The only downside to using a static url would be all the netinstall's pointing to the same mirror.
One of the reasons I always make sure I have a kickstart available to avoid all that typing...
jlc
On Sat, 5 Jun 2010, Manuel Wolfshant wrote:
in addition to improving docs, it would also be quite cool to pre-populate the questions asked by the netinstaller with same sane defaults.
As far as I have seen while being in #centos, most beginners' questions (in the context of netinstall) were more or less similar to "what should I put in the 'mirror' and 'path' fields ?". Can we patch anaconda so as to prepopulate those two without overloading any particular mirrors (maybe using somehow the output of mirrorlist ) ?
Anaconda is not Debian's netinstall approach, lacking retries, invisible remote archive failovers, and diagnostic logging comprehensible to said newbies. Additionally, Debian avoids much of the mirror skew issue by staging updates to a daily lump, and having much better 'apt-get update' detail coherency as a result.
The next question in #centos from beginner is 'why did my install across the internet fail' and
If they are only willing to D/L one CD, let it be CD 1, and devote effort to grafting in a 'minimal install' option tha has all dependencies at hand [more on this in a mement as to '6]
Otherwise you all are in the business of inventing a robust paralle local media install method beside anaconda
It's been done in upstream derived RPM space -- Greg Kurtzer's 'cinch' for cAos was one, but that tool is suited for a very small class of installs at best
Also, as I read the '6 beta thinking from inside ['notting' as I recall], the single CD size installer is just too small, and CD images are on the way out
I am sure a local limited case installer can be done -- but what does it have to do with ending up with a system based on the upstream?
-- Russ herrold
On 06/05/2010 05:23 AM, R P Herrold wrote:
On Sat, 5 Jun 2010, Manuel Wolfshant wrote:
in addition to improving docs, it would also be quite cool to pre-populate the questions asked by the netinstaller with same sane defaults.
As far as I have seen while being in #centos, most beginners' questions (in the context of netinstall) were more or less similar to "what should I put in the 'mirror' and 'path' fields ?". Can we patch anaconda so as to prepopulate those two without overloading any particular mirrors (maybe using somehow the output of mirrorlist ) ?
Anaconda is not Debian's netinstall approach, lacking retries, invisible remote archive failovers, and diagnostic logging comprehensible to said newbies. Additionally, Debian avoids much of the mirror skew issue by staging updates to a daily lump, and having much better 'apt-get update' detail coherency as a result.
The next question in #centos from beginner is 'why did my install across the internet fail' and
If they are only willing to D/L one CD, let it be CD 1, and devote effort to grafting in a 'minimal install' option tha has all dependencies at hand [more on this in a mement as to '6]
Otherwise you all are in the business of inventing a robust paralle local media install method beside anaconda
True. But it's already quite difficult for me to explain why all other major Live CDs have NTFS and mp3 support out of the box; the additional lack of install support proved more than once the drop which made colleagues of mine to choose Ubuntu as distro for home usage, despite being familiar with Centos from work. Yes, I know, the first reaction is "their loss". But it's a pity we loose users and .. well, they still come to me for support :)
On Sun, 6 Jun 2010, Manuel Wolfshant wrote:
True. But it's already quite difficult for me to explain why all other major Live CDs have NTFS and mp3 support out of the box; the additional lack of install support proved more than once the drop which made colleagues of mine to choose Ubuntu as distro for home usage, despite being familiar with Centos from work. Yes, I know, the first reaction is "their loss". But it's a pity we lose users and .. well, they still come to me for support :)
I still don't see any of this this as valid reasons.
1. NTFA and mp3 - patents are and remain clear blockers to the upstream, and CentOS at its supported core, is a slavish rebuild of its upstreams publicly available sources ...
2. You hold the ability to say: Sorry, as it is not CentOS, I cannot freely support it, any more than I would freely support any other closed source product. Would you like an estimate for my anticipated support time costs?
A person cannot do everything; indeed a person cannot even do several things * first* and well. I suspect all here have real world lives with friends, and with luck families (parents and back, spouses, and children and down in age). Also the life span each of us has is not unlimited; the days are still limited to 24 hours here
It may even be that one has to * pay* for food, shelter, vacations, and more (GASP). Here that costs real funds
Time spent working for free on a poor fit tool to make it fit use case it is not designed for, carries a cost; geek-like people rarely consider IF a thing should be done, and leap straight to proving their geek-hood by showing they CAN do the impossible. At least in your case, Wolfy, I know you are a 'knight geek of the round table'. You no longer need to work on side tools for free to prove your mettle ;)
It is all right to say: 'no thank you' to your offer to let me work for you for free when that question comes
-- Russ herrold
On 06/06/2010 09:06 PM, R P Herrold wrote:
On Sun, 6 Jun 2010, Manuel Wolfshant wrote:
True. But it's already quite difficult for me to explain why all other major Live CDs have NTFS and mp3 support out of the box; the additional lack of install support proved more than once the drop which made colleagues of mine to choose Ubuntu as distro for home usage, despite being familiar with Centos from work. Yes, I know, the first reaction is "their loss". But it's a pity we lose users and .. well, they still come to me for support :)
I still don't see any of this this as valid reasons.
- NTFA and mp3 - patents are and remain clear blockers to
the upstream, and CentOS at its supported core, is a slavish rebuild of its upstreams publicly available sources ...
100% correct and I am not going to debate on this issue. The only fact that I want to emphasize, from my personal experience is that the end users do not care about patents. (And around here, most of them do not care about licenses either, but that's food for another thread). What they aim is to have a good "experience". I cannot " sell " them our LiveCD as recovery tool for their damaged Windows systems when the CD lacks NTFS support. So guess what ? We go either ultimatebootcd or... ubuntu.
- You hold the ability to say: Sorry, as it is not CentOS, I
cannot freely support it, any more than I would freely support any other closed source product. Would you like an estimate for my anticipated support time costs?
Theoretically that is correct. In practice in 25 years I've never ever attempted to charge my coworkers even when helping them with personal [computer related] issues
At least in your case, Wolfy, I know you are a 'knight geek of the round table'. You no longer need to work on side tools for free to prove your mettle ;)
I do not want to prove anything. I just want a better experience for users. And for myself. And in this particular case, we talk about allowing potential users to have a better experience by allowing them to use the LiveCD as install CD ( by doing exactly what the netinstall / CD1 do). From my point of view, the patch suggested by Z00dax should be added to all 3 discs. Yes, I know, under certain circumstances ( way too often unfortunately) network installs are painful and people come crying on IRC (and probably on all other avenues of help, too). But I strongly think that ditching the network install is not the answer. The answer is to properly document the problems (and the answers) and helping the users out of their problems.
PS: the above paragraph was written even I still wear my BOFH jacket.
Manuel Wolfshant wrote:
On 06/06/2010 09:06 PM, R P Herrold wrote:
On Sun, 6 Jun 2010, Manuel Wolfshant wrote:
True. But it's already quite difficult for me to explain why all other major Live CDs have NTFS and mp3 support out of the box; the additional lack of install support proved more than once the drop which made colleagues of mine to choose Ubuntu as distro for home usage, despite being familiar with Centos from work. Yes, I know, the first reaction is "their loss". But it's a pity we lose users and .. well, they still come to me for support :)
I still don't see any of this this as valid reasons.
- NTFA and mp3 - patents are and remain clear blockers to
the upstream, and CentOS at its supported core, is a slavish rebuild of its upstreams publicly available sources ...
100% correct and I am not going to debate on this issue. The only fact that I want to emphasize, from my personal experience is that the end users do not care about patents. (And around here, most of them do not care about licenses either, but that's food for another thread). What they aim is to have a good "experience". I cannot " sell " them our LiveCD as recovery tool for their damaged Windows systems when the CD lacks NTFS support. So guess what ? We go either ultimatebootcd or... ubuntu.
I do not think that the official CentOS LiveCD should provide software packages that are not present in the official repository. Doing such a thing would be misleading for the end-user.
- You hold the ability to say: Sorry, as it is not CentOS, I
cannot freely support it, any more than I would freely support any other closed source product. Would you like an estimate for my anticipated support time costs?
Theoretically that is correct. In practice in 25 years I've never ever attempted to charge my coworkers even when helping them with personal [computer related] issues
I produced documentation about how to create a LiveCD. Adding features like NTFS, mp3 or Flash support is rather simple. However, I do not want to be involved in a patent case on my free time. I have better things to do. If someone wants to involve himself/herself with the task of supporting a CentOS 'plus' LiveCD, then I would gladly offer assistance. Up to now, it didn't receive such offers.
I also seldom get requests from end-user to help them customize a LiveCD for their particular needs. While I offer them help for a fee, I do not feel like being non-supportive. Helping the whole Internet community for free is something else than giving free support to my coworkers.
From my point of view, the patch suggested by Z00dax should be added to all 3 discs. Yes, I know, under certain circumstances ( way too often unfortunately) network installs are painful and people come crying on IRC (and probably on all other avenues of help, too). But I strongly think that ditching the network install is not the answer. The answer is to properly document the problems (and the answers) and helping the users out of their problems.
A rather simple documentation about the LiveCD network installation option is published with the release notes: http://wiki.centos.org/Manuals/ReleaseNotes/CentOSLiveCD5.5
Maybe a new thread could be created in centos-docs to point the need for a better documentation about the network installation process in general?
-- Patrice
R P Herrold wrote on 06/04/2010 10:23 PM:
On Sat, 5 Jun 2010, Manuel Wolfshant wrote:
...
As far as I have seen while being in #centos, most beginners' questions (in the context of netinstall) were more or less similar to "what should I put in the 'mirror' and 'path' fields ?". Can we patch anaconda so as to prepopulate those two without overloading any particular mirrors (maybe using somehow the output of mirrorlist ) ?
Pre-populating the mirror fields is, like improving docs, a good thing, but really a separate issue from including a netinstall option on the LiveCD. A more valuable option IMHO would be the install-LiveCD-to disk via whatever mechanism, but that too may be a separate discussion.
...
The next question in #centos from beginner is 'why did my install across the internet fail' and
Similar questions come from forum users. That to me is the real killer disadvantage of netinstall - it is just not going to work well for a significant fraction of users, even if the mirror fields are optimally populated, leading to frustration and a bad initial experience with CentOS. Having it as a LiveCD option seems to be an implicit endorsement that this is a viable way to install. More savvy users will know the pros and cons of netinstall, particularly assuming they read the (improved) docs, and can easily grab the small ISO image if they want it.
Phil
Am 05.06.10 01:10, schrieb Manuel Wolfshant:
As far as I have seen while being in #centos, most beginners' questions (in the context of netinstall) were more or less similar to "what should I put in the 'mirror' and 'path' fields ?". Can we patch anaconda so as to prepopulate those two without overloading any particular mirrors (maybe using somehow the output of mirrorlist ) ?
For those cases http://mirror.centos.org/ now(!) should be enough, we give those ips out depending on which region you are in. Those in Asia, South America or Africa could have a slightly problematic user experience, though.
I don't think mirrorlist can be used at that stage, as it clearly is asking that before network really is up, IIRC. But I may remember incorrectly.
Ralph
Ralph Angenendt wrote:
Manuel Wolfshant wrote:
As far as I have seen while being in #centos, most beginners' questions (in the context of netinstall) were more or less similar to "what should I put in the 'mirror' and 'path' fields ?". Can we patch anaconda so as to prepopulate those two without overloading any particular mirrors (maybe using somehow the output of mirrorlist ) ?
For those cases http://mirror.centos.org/ now(!) should be enough, we give those ips out depending on which region you are in. Those in Asia, South America or Africa could have a slightly problematic user experience, though.
I don't think mirrorlist can be used at that stage, as it clearly is asking that before network really is up, IIRC. But I may remember incorrectly
If I understand correctly, the 'mirror' and 'path' fields during network installation could be prepopulated by patching the current CentOS anaconda package. Then, a newly generated set of files used by the netinstall and the LiveCD iso images [1] would automatically feature those predefined fields.
Then, my question is: when are we going to see this updated anaconda and network installation files?
[1]: http://isoredirect.centos.org/centos/5/os/i386/isolinux/
-- Patrice
On 06/06/2010 01:20 PM, Patrice Guay wrote: If I understand correctly, the 'mirror' and 'path' fields during network
installation could be prepopulated by patching the current CentOS anaconda package. Then, a newly generated set of files used by the netinstall and the LiveCD iso images [1] would automatically feature those predefined fields.
right
Then, my question is: when are we going to see this updated anaconda and network installation files?
like i said in my last email, we had this working for 5.4, so bringing it in for 5.6 would be a good target. we just need to test it well.
- KB
On 06/04/2010 05:35 AM, Phil Schaffner wrote:
For the next iteration of the LiveCD I would suggest omitting the
One more related installer suggestion, is zyx-liveinstaller. This is just me shilling my own project that has yet to gain serious traction, but I still find rebootless livecd installation very cool, and it is just 100kb or so.
Executive Summary: Like traditional fedora livecd installer, except instead of copying just the readonly livecd filesystem image to the target and then rebooting, it uses devicemapper mirror tricks to copy that image, as well as the live ram overlay into a new normal filesystem on disk, which is then already running for real, sans the need to reboot. Only 'real' difference is that until the next reboot, your rootfs is accessed via a dm-linear layer.
It's definitely far from enterprise-level polished, but it survived v2 of sugar-on-a-stick, without any serious issues (though I fear without any significant usage either). And it has extreme user warnings about beta quality.
Anyway, just a reminder that it exists, and may well prove useful and/or nifty for some number of centos livecd users.
The latest f13 build (v0.2.4) should work fine on the later versions of centos-5.X, or let me know if it doesn't.
To test out with an existing livecd, you can just download the rpm from f13_updates_ or my site, install it, and run zyx-liveinstaller from the commandline or system tools menu. There is zyx-liveinstaller-cli as well.
Also, if the following files exist, they will be used to 'theme' a bit-
/etc/zyx-liveinstaller.install.txt /etc/zyx-liveinstaller.banner.png
Cheers,
-dmc
netinstall option. This has caused a rather large support load on the fora (or forums if you prefer) from people who can't get it to work.
As netinstall is really most useful with a "perfect" network connection or local archive, and can be tricky to get right, it is just confusing a lot of the LiveCD "market segment". More sophisticated users will just grab the netinstall CD or use images/boot.iso. Removing it would also leave more room for useful apps.
Phil
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
Douglas McClendon wrote:
One more related installer suggestion, is zyx-liveinstaller. This is just me shilling my own project that has yet to gain serious traction, but I still find rebootless livecd installation very cool, and it is just 100kb or so.
Executive Summary: Like traditional fedora livecd installer, except instead of copying just the readonly livecd filesystem image to the target and then rebooting, it uses devicemapper mirror tricks to copy that image, as well as the live ram overlay into a new normal filesystem on disk, which is then already running for real, sans the need to reboot. Only 'real' difference is that until the next reboot, your rootfs is accessed via a dm-linear layer
The main issue I see regarding a live installation process is the fact that the LiveCD has been stripped from several files in order to reach the 700MB target. Language and documentation files are removed to give some space for OpenOffice.org. As a result, the LiveCD environment is different from the one obtained via the normal installation process. While this should not make a difference for English-speaking users, others may be confused by the missing files. This could result in more load for the support channels as they will have to explain why package xyz installed via the LiveCD is different from the same package installed via RPM.
-- Patrice
On 06/06/2010 07:29 AM, Patrice Guay wrote:
Douglas McClendon wrote:
One more related installer suggestion, is zyx-liveinstaller. This is just me shilling my own project that has yet to gain serious traction, but I still find rebootless livecd installation very cool, and it is just 100kb or so.
Executive Summary: Like traditional fedora livecd installer, except instead of copying just the readonly livecd filesystem image to the target and then rebooting, it uses devicemapper mirror tricks to copy that image, as well as the live ram overlay into a new normal filesystem on disk, which is then already running for real, sans the need to reboot. Only 'real' difference is that until the next reboot, your rootfs is accessed via a dm-linear layer
The main issue I see regarding a live installation process is the fact that the LiveCD has been stripped from several files in order to reach the 700MB target. Language and documentation files are removed to give some space for OpenOffice.org. As a result, the LiveCD environment is different from the one obtained via the normal installation process. While this should not make a difference for English-speaking users, others may be confused by the missing files. This could result in more load for the support channels as they will have to explain why package xyz installed via the LiveCD is different from the same package installed via RPM.
I didn't know, but am not surprised, that you've had to make those kind of cuts (fedora has held a pretty tight line and avoided such cuts, but also can't squeeze in openoffice). Fair enough.
-dmc
-
Douglas McClendon -
Joseph L. Casale -
Karanbir Singh -
Manuel Wolfshant -
Patrice Guay -
Phil Schaffner -
Phil Schaffner -
R P Herrold -
Ralph Angenendt