(This has ended up hard to read; I hope it's not my tablet that's messed up the message threading, but apologies in advance if it is)
On 27 July 2015 3:19:50 AM AEST, James <wirel...@tampabay.rr.com> wrote: >Bruce Schultz <brulzki <at> gmail.com> writes: > >> > >> Matthew Marchese <maffblas...@gentoo.org> writes: > > >> I see that you've found stager. I'd like you to share > your thoughts >> on what a perfect installer Gentoo could do. > > A successful gentoo installer will: > > Be multi-faceted so that many different, but common > installation outcomes are not only possible, but are > automated to the point of extreme convenience for folks to > use them, as they choose. Let's face it no matter what we do, > most noobs will not use Gentoo. But, those folks with some > level of experience and competence will use gentoo; many more > if there is an automated (base)installation. After all, when > google or others corporations install and use gentoo, do you > think they have folks spend 1-2 days using the handbook? NO, > their gentoo(derivative) has an automated installation. > > > So a base-installer for your [category 1] is the > most important part. So in that train of thought, > WE, should parse out all of the good parts of many > different installers and installation schemes, as a part > of the research and leverage as to what exists that can > be leveraged or emulated, Debian included. OpenSuse has > (13.2) has a slick install that allows for btrfs without > lvm or mdadm. That was the default pathway. I've read that > you can end up with a full raid install if you choose the > "advanced" pathway. I'm still researching that one. Then > there is 'Calculate Linux' that more than one gentoo dev > uses routinely to install Gentoo. There are many pathways > to streamline the installation of Gentoo. Many, for onerous > reasons believe that is a bad idea. > > There is plenty of existing installation code that sets up > MBR and ext*; so that's a no brainer on how to do that. Newer > technologies, like btrfs are tricky. Why do you think btrfs is tricky? The last few systems I have installed on have been btrfs based, and once you add the subvolume= option in fstab & the boot command line its no more tricky than any other install, IMO. > > > In my opinion, there's really 3 parts to the install > process, and I think it helps to distinguish > between > them. I think a complete installer program has to address > all 3, but each task could be > modularised. > > > 1. The low level decisions, like disk partitioning, raid > and disk mirroring, filesystem choices > like ext4, btrfs, > zfs, or some other. For a VM, the choices here might include > creating a > new LVM volume or btrfs subvolume > > Gentoo is not going to formally support ZFS as has been > stated before. However supporting ZFS by others is well > documented and some maverick could easily extend the > gentoo-base installer for a target system (after your > Category-1) where ZFS is installed. Just not officially > gentoo. (I only added zfs because the previous post mentioned it) > > > 2. Installing system files, which is not much more than > untaring the stage3, and low level > system configuration > of make.conf settings, choice of profile, locale & timezone > settings, > users & passwords, networking, choice of syslog & > from, etc > > Category-2 This is a pretty easy part to automate. Many > have stated that all of this information could be gathered > up before the actual installation (batched) begins and > parsed out at the appropriate time during the actually > (automated) installation. Agreed. But what is missing is a common interface for passing the details from the category 1 to category 2; whether that is a config file or some other mechanism > > All of Category 1 as well as some parts of Category-2 are > what I refer to as the base-install. After that point is > when you make key decisions like workstation vs server vs > embedded vs tablet. > > > 3. Higher level system configuration to get to a finalised > state >This is the part of the traditional Gentoo handbook I do > agree with. This is the part of the installation where noobs > begin to actually learn gentoo, or at least those parts > necessary for routine administration and usage. This is part > of the handbook that is trivial for experience *nix folks > as most are familiar with more than one package manager or > software installation semantic. > > > Most of these sorts of noobs (folks that struggle with > maintaining a *nix system) are never going to profile > low level kernel code or compare one file system against > another, so why make it mandatory to master category 1 in > order to install, use and enjoy gentoo? Currently, the lack > of a gentoo installer is exactly that:: a blocker to noobs. > That's not my issue:: the devs are using 'mis-direction' here > to prohibit the creation of a slick-smooth-unattended-useful > base-install semantic for those with moderate *nix skills, > imho. YMMV. That's my issue. Dont belive me? Just go to > gentoo-dev and read the flack that MaffBlaster caught > on the list, merely for discussion a new installation > semantic. Hence the focus on 'stage-4' install code. > > > > (Of course, there's quite a bit of blurring between > the stages.) > > Yes, understood, we're talking at a high-level of abstraction > here. > > > I'm not so interested in 1, but gentoo really shines > here because there are no restrictions. > But there are > so many options that it makes it a big task to tackle, > unless you pare it down > and focus on a few typical use > cases like a standard desktop install. > > OK, well this is where we part company. If you really believe Maybe not so fast.... what I mean is that, for my needs, I'm comfortable to boot into a sysrescue cd to run fdisk & mkfs in a terminal and install from there, and I'd most likely keep doing that way even if the were an installer. It the configuration after untaring the stage that I find tedious and error prone, and therefore why the category 2 is more interesting to me. That's not to say that I'm opposed to a cat 1 installer, and I agree that it would make it easier to introduce 'noobs' to gentoo. However, to be reliable, an installer has to be able to limit the options to cover typical, well known configurations, otherwise it would end up in a mess of unsupported corner cases. Generally I won't recommend gentoo to my friends, even if they are linux-savy. I think many people see a Linux distribution as a whole, and are happy to reinstall a different distro or version if some part of the install doesn't work. However, I view Linux as a collection of pieces and the gentoo approach to managing a system supports that world view. > this and all we end up with is a competitive distro install > with buntu, what's the point? Critics are going to seize > on this and say see, your recruiting the idiots and ricers > from buntu to come to gentoo for indentured support. Like > them, that's not really the target of my goals. I do think > some will learn a sufficient amount about gentoo and using > *nix in general that they will stick around and benefit > the community. I'm not entirely sure of your point here? I don't think Ubuntu users are a target for gentoo, and the majority of new users attracted by an installer may not hang around past a few world updates. Gentoo won't be suited to everyone's tastes, no matter how easy it is to install. > > I think a solid base-install that is automated benefits > the folks that already know their way around *nix and > they can quickly benefit form the source code build out > tools very, very quickly. If somebody does not know the > difference between C and C++, I'm not for catering to their > needs. But the lack of a good, automated installer for the > basics does run off many accomplished *nix folks who could > then the gentoo community tremendously, imho. > > If somebody wants to build a firewall, a stealth sniffer > (no ether traces, a bridge, an embedded system product, a > workstation with openrc and lxqt or wayland, a cluster (in > house hardware) or a cloud (outsourced hardware) then that > is where we need to distinguish gentoo's installation. It > becomes a tool for those with expertise to rapidly install > the base-system and then do things you cannot do with buntu. > > > Note:: I use the term 'base' to distinguish from 'default' > which is the terminology chosen for gentoo's profile > system of choices. They are similar, but I believe that > a base-install is less than a default system on a given > architecture. This is a concept that I am still trying to > refine for categories of systems like tablets, embedded > and other kinds of minimal hardware types of systems. It's > a different issue for a different thread. > > > > Part 2 is where it would be good to have a standardised > approach, along the lines of > debian's debootstrap > utility. Something that takes a target directory and installs > all the > files needed to build a bare-bones system inside > it. Its actually not that difficult > to write a shell script > to achieve this, which is probably why there are so many > > posted around the interests. But something standardised > could be the basis of a gui > installer, or the center of > a container installer such as the lxc-gentoo script or > > whatever the docker equivalent is. > > What you are talking about here, to me, can be part of > your category-3. In fact, I modify what you have written > to only (2) parts Step-1(base-install) and Step-2 (Final > Target). Step-2 does not need to be automated by gentoo > officially imho. It's mostly a few config questions and > a collect of packages. You can actually auto this right > now. Just create your own 'profile' on top of a default > installation and use ansible. I still see a difference between step 2 & 3. So, step-2 (or category 2 / part 2 / I'd like to use stage2 but already has a meaning in gentoo)... I see this as starting at the point where you untar the stage3 and ending at the point where you have a base system ready to run. Sure, this is inherently scriptable and there are multiple scripts to be found, but they are all inconsistent and tailor to specific needs. Usually for my needs, I want to set make.conf to point to my bin-pkg repository and install a minimum of packages to help with configuration, such a git and puppet or cf-engine. I'm not sure if ansible needs to be installed, but it would need at least to have the network and ssh configured. I have done many more gentoo installs into a chroot than I have onto a bare metal system, and the category 2 as described above is meant to automate a base install to a chroot. Of course, a bare metal install by the gentoo handbook includes installing to a chroot, so this is common to category 1 and 2 installers. A category 1 installer could take different forms: - a gui installer, which walks you through the install options to set up disk partions options, then calls the category 2 installer, maybe installs extra desktop packages and finally installs grub or another bootloader. - whatever the latest container flavour of the month install script, calls to the cat 2 installer to install the base system and adds the specific container management configuration to the host system - a simple chroot installer What's missing is the consistency of the interface or hooks between category 1&2 Category 3, I think we can agree, is outside the scope of any gentoo installer project. > MuffBalster said the first part is the easiest part; > that is to go back to supporting (stage-4) installs. Lot > of subtle intricacies with 'stage-4' but I'll give you my > take so you can see where the devs are rolling. > > If you have expertise and have created one utopian install > for a highly targeted need, then a stage-4 installation > semantic will allow you to quickly clone that work and build > many more similar system, in a fully automated fashion. So > for Clustering, cloud, google, large institutions or > consultants with advanced skills, it become a defacto private > installation sematic where the inner circle and those with > a strong set of admin/programming skills prosper. Maybe an > inner circle? The noobs are still filtered out. Those in > the middle to do gain from the knowledge and expertise of > the inner core of devs. Is that the way it should be? Not > for me to decide. I'd just like some help with newer file > systems (btrfs), gpt, grub2, and such issues in Step-1. > > Those that have painted my position to be recruiting the > masses of noobs from buntu, are using mis-direction to > prevent the large number of moderate-skilled gentoo community > from the benefits of a streamlined installation. The > fact is that gentoo had a very useful, mostly automated > installation, and it was abandoned because of the catering > to the noob issues. But they did not have to abandon the > STEP-1 needs of those with sufficient *nix skills to benefit > from installation automation. > > > The 3rd task is more in the realm of tools such as ansible > or puppet. > > > Step 3 already exists in rudimentary form:: > > Both Sephan and Alan have posted on using ansible for > gentoo installs. It's just not polished to the point of > being an installer, imho. There are many other formulas, > playbooks and such for installing gentoo, but they are > cumbersome, imho. Folks stop short of finishing them, > as is their right to do so. Once you go down the path of > applying noob_polish to the installation semantic, it does > become an unsustainable nightmare, or at least that is the > propaganda:: which I am neutral on. I need to dig into ansible one day... The difference is all about where you draw the lines, as they so often blur together. I guess the best way to describe my 'category 2' concept would be to call it a gentoo version of debian's debootstrap [snip] > > I disagree. If the base-install is automated then the > second half of customizations are trivial to automate or > following the handbook to learn gentoo, as it is very easy > and straight-forward. Once you do that part a few times, > it's a collection of configs and ebuilds that are easy to > master and automate. > ... > > If I seem 'conciliatory' to those opposed to the install > software development, it's because I put in some time > looking at the issue from their prospective. Your breaking > apart of the installation ssemantics did help me focus on > the Step-1 issue; which is the point and what need to be > automated, imho. I find step 1 is the part that differs the most for me, as most of my hardware are reasonably different, and I install to hardware so irregularly that I usually try something slightly different. But my systems tend to be fairly consistent when it comes to the contents of the root file system, is the step 2 level, and that's where I see the value of automation. I think I get your points though that a category 1 installer: a. helps guide through complex hardware install options b. (given your cluster focus) enables consistent configuration across identical hardware systems > > > Last Zinger:: SystemD created quit a stir on this list right > down to the heart of gentoo's soul as a distro. I believe > that was healthy. When I go round the net, that is still > the single biggest issue where gentoo get's respect from > all corners (except Lennart's hottub parties)...... Not touching that one ;) > > I just which we, gentoo as a distro, were embracing and > automating the installation of BTRFS, like we pursued > systemd. BTRFS is a game changer and many advanced folks > and institutions are using it. It's a bear. So, I'd settle > (be very happy) if out of these installer threads we just > end up with an automated way to complete a BTRFS, raid-1 > system that includes a completed fstab, gpt and grub2 > issues in some sane and automated way. WE can still filter > out the noobs........OK? Ahh, I think get your stance against noobs now > > > > PEACE? :) > James -- :b
