Anaconda creates LVM names like: VolGroup00 LogVol00 Which are too long for many programs, like df: -----8<-------------------------------------------------------------- # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 56023060 7847584 45283700 15% / /dev/sda1 194442 19396 165007 11% /boot tmpfs 111264 0 111264 0% /dev/shm ----->8-------------------------------------------------------------- When it could use names like: vg00 lv00 and make things more readable for lot of people. Someone at #fedora channel told that he had done his own script to sanitize that output. I think that tells quite a lot about how annoying this is. To make things worse, you cannot change that in TUI installation and you cannot rename the root filesystem name without booting with alternate media.
Related bug 461682.
Then those other tools need to be changed to accomodate longer names. There's nothing that says we can't create names of those lengths, and they could alter the output formatting to take that into consideration. Besides, as you have rightly pointed out, longer and more descriptive names are what people expect. That's the direction we have chosen to go in.
a) Those people who like to have long names, probably don't use cli tools. b) If you do disagree, please let the users to decide what kind of names they want to use. Anaconda-tui should allow users to change the name. Do I recall incorrectly that gui allows renaming them during the installation?
Yes, GUI mode does allow renaming volume groups and logical volumes. No, the text interface will not be growing this support. It has no support for LVM at all (outside of displaying what already exists or what the automatic partitioning will create), and that will not be getting added.
That is more important in tui since it's commonly used in servers since they don't have gui hardware in machine room console. Servers also have longer lifespan and this affects to them more since LVM is targeted for complex filesystems and thus rather used in servers than in workstations. Workstations typically have only single root, but servers instead have more partitioned layout - for obvious reasons. I can understand that you oppose it since it's laborious to implement and char terminal makes it even harder, but you cannot claim that your feature set between gui and tui is just plain upside down. At least add support that anaconda doesn't *prevent* hacking it in F2 console and then picking them up with tui when done. I tried to do it and it wasn't that obvious, apparently it's impossible.
This is not at all the direction we want to go. We are working on simplifying text mode, not adding stuff to it. You really ought to be using VNC or kickstart install methods instead of text mode, since interactive text mode is going to be less useful from a partitioning perspective in the near future.
Do you really think that professional admins want to start fiddling with VNC problems and firewalls at that point when the shit hit the fan and company's crucial systems are down? You don't have kickstarts for systems that you have one or two per company, they don't work anyway with the new releases, after seven years of EL lifespan. This is UNIX ideology what we're speaking about, ideology that you're destroying.
Wait, what? A text interface to the installer is a part of unix ideology? That doesn't make any sense at all. The fact of the matter is that the graphical installer should be considered THE installer, and the text mode interface has been increasingly diverging from it as we add more and more advanced features. For at least as long as we've had LVM as the default, you haven't been able to do anything with it under the text installer. The more we add advanced features, the farther behind text mode gets. There are plenty of workable alternatives to text mode here, and there are certainly reasons why you might want to use kickstart even for a single machine (think reproducability of the install and version control). Anyway, this is drifting very far afield of the original report.
(In reply to comment #8) > Wait, what? A text interface to the installer is a part of unix ideology? > That doesn't make any sense at all. It doesn't? I can unveil a fact that UNIX is still a server operating system, regardless that someone called it 'global desktop' doesn't still quite cut it. Servers don't have GUI hardware nor armchair, since they are not used for such. Windows is still world's most popular desktop OS, Fedora is not Windows. Does it make *any* sense at all now? > the text mode interface has been increasingly diverging from it as > we add more and more advanced features. Yes, I've noticed that and hence this feature wish. > There are plenty of workable alternatives to text mode here, Like? Assuming that there is no GUI hardware and armchair? Assuming that you just want to get it running and you finalize it over ssh? > certainly reasons why you might want to use kickstart even > for a single machine I got the T-shirt already, I don't. User's choice, UNIX ideology - anyone? > Anyway, this is drifting very far afield of the original report. How it's drifting away when we're trying to address the reasons why one should be able to use LVM with system where it's designed for? Either I have not seen a comment that my reasoning would be wrong.
(In reply to comment #7) > Do you really think that professional admins want to start fiddling with VNC > problems and firewalls at that point when the shit hit the fan and company's > crucial systems are down? Have I wandered into Microsoft territory and nobody told me? Because really, they're pretty much the only people I've ever seen whose first response to nearly anything is to make you reinstall your OS (well, no, the first response is to restart. But reinstalling is second). There are very few scenarios - none that I can come up with, though I won't rule out the possibility that some exist - where the only or even the best response is to reinstall all your systems. Seriously, who does this? > You don't have kickstarts for systems that you have one or two per company, > they don't work anyway with the new releases, after seven years of EL lifespan. This is a Fedora bug, not a RHEL bug, but nevertheless - why not? In seven years, most companies and people replace at least one machine at least once. You don't think kickstart files are damn useful for ensuring that all your machines get installed the same way? And you really think it's so incredibly difficult to check the release notes when a new version comes out and update your kickstart file to reflect the changes that have been made? Fedora of course doesn't last nearly as long as RHEL does, but neither does kickstart change nearly as much as it does between RHEL releases, and even if you're reinstalling (instead of upgrading) every single release, it's still not some huge awful chore to check the changes to kickstart every six months. > (In reply to comment #8) > User's choice, UNIX ideology - anyone? Linux is not about choice. Quoth Ajax, > If I could only have one thing this year, it would be to eliminate that > meme from the collective consciousness. It is a disease. It strangles > the mind and ensures you can never change anything ever because someone > somewhere has OCD'd their environment exactly how they like it and how > dare you change it on them you're so mean and next time I have friends > over for Buffy night you're not invited mom he's sitting on my side > again. > [...] > But the chain of logic from "Linux is about > choice" to "ship everything and let the user chose how they want their > sound to not work" starts with fallacy and ends with disaster. Text mode is full of problems. It is prone to breaking, it is prone to falling behind the rest of the installer, it has incredibly limited screen real estate, it requires developers to spend twice as much time to implement any feature (which is exactly why it is so prone to falling behind). It takes time and effort to keep it up to date, time and effort that would be better spent actually fixing something that's broken rather than something that's just antiquated. Text mode doesn't need features, it needs to be simplified and defeaturized so that we can stop worrying about the bloody thing breaking.
(In reply to comment #10) > Text mode is full of problems. It is prone to breaking, it is prone to falling > behind the rest of the installer, it has incredibly limited screen real estate, > it requires developers to spend twice as much time to implement any feature > (which is exactly why it is so prone to falling behind). I can believe it's falling behind because it's not maintained. I'm not telling here anyone what they should or shouldn't do - but having two installers is surely duplicate work. > it has incredibly limited screen real estate It does, as everything happens in a tiny box at the center of the screen. Why not use the whole screen? > It takes time and > effort to keep it up to date, time and effort that would be better spent > actually fixing something that's broken rather than something that's just > antiquated. 80% or more of that software that I install from fedora, is antique code and I'd very much like to keep it that way, since they work. For EL antique is understatement and it's just how we like it to be. Installation is time wise the least used feature in distro's lifespan and for most it's the same does it look pretty or not as long it works. Current text mode is limited what it's purposed for. I wasn't that long ago when buggy X nvidia driver forced to use text mode install to be able to install at all. Text mode or simple scrolling console installation is mandatory, there are multiple cases when it's the only way to install some system. Anyway, I think I've stated every reasonable argument on my behalf and this ticket is the wrong place to have this conversation. If you want to keep arguing about his, we can take it into -devel list.
> 80% or more of that software that I install from fedora, is antique code and > I'd very much like to keep it that way, since they work. For EL antique is > understatement and it's just how we like it to be. Fedora is about driving innovation and pushing boundaries (see: http://fedoraproject.org/wiki/Foundations). anaconda is a part of Fedora. If old code is hindering progress, we don't really have to stick with it just because that's the way it's always been. Red Hat Enterprise Linux is about stabilizing those changes into a supportable product. Therefore, we need to make sure that what's in Fedora - whatever that may be - is supportable and meets the needs of our customers. Luckily, we have consulted with customers on this particular change so they will be aware of it. > Installation is time wise the least used feature in distro's lifespan and for > most it's the same does it look pretty or not as long it works. Current text > mode is limited what it's purposed for. And yet, an installer that does not work prevents someone from using the distribution for anything else. The more time we spent on the maintainance burden that is the current text mode installer, the less time we can spend on fixing bugs that prevent installation. And yes, there is a demonstrable maintainance burden here - we do spend time fixing the same bugs in two places, duplicating features requests in two places, and responding to feature requests for more text mode changes. These are all activities that take away from fixing the underlying problems or working on important new stuff. > I wasn't that long ago when buggy X nvidia driver forced to use text mode > install to be able to install at all. When the kernel is broken, do we suggest you use FreeBSD's kernel instead? When X is broken, do we suggest using an alternate display system? Of course not - that's just silly. Similarly, when anaconda is broken, suggesting that you use a very different body of code with very different limitations and features is also silly. That just doesn't makes sense. > Text mode or simple scrolling console installation is mandatory, there are > multiple cases when it's the only way to install some system. Still supported: - A limited text mode interface - Kickstart installs, through both text and graphical modes same as always - VNC, which works for computers without display hardware - The strange cmdline mode, which only does simple scrolling > Anyway, I think I've stated every reasonable argument on my behalf and this > ticket is the wrong place to have this conversation. If you want to keep > arguing about his, we can take it into -devel list. Indeed, this change has been discussed at length both internally and externally - on mailing lists, in meetings, with community members, with partners and customers. We've done a pretty decent job making people aware of what was going on, including having a test day devoted to finding problems with the change and working on release notes to publicize it. There's not really much point in continuing to discuss it, especially since we committed the code yesterday and built a new anaconda.
(In reply to comment #12) > When X is broken, do we suggest using an alternate display system? Yes you did. :-/