:: Re: [DNG] /usr to merge or not to m…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Alessandro Selli
Fecha:  
A: dng
Asunto: Re: [DNG] /usr to merge or not to merge... that is the question
On 28/11/18 at 09:08, Rick Moen wrote:
> Quoting Alessandro Selli (alessandroselli@???):
>
>>  Can you name me one distribution other than Red Hat (which in
>> fact is not a desktop-friendly distribution) that does not allow one to
>> "do their own partition setup"?
> I'm curious, Alessandro: Is RHEL now completely hostile to custom
> filesystem setup?



 I haven't dealt with a RH installation for a looong time, however I did
witness to an incident that happened at a former employer of mine years
ago.  We let a classroom to RH Italy for them to held a course of
theirs.  Of course they had to install the latest RHEL on it's PCs (I
don't remember if it was a RHEL6 or one of the early 7s).  The PCs had a
storage controller that could be operated either in SATA/AHCI or in RAID
mode, the already present Windows installation was using the only HD
present as a plain SATA device.  We installed a second HD on each PC and
told the RH sysadmin who came to prepare the machines to install the
RHEL system only on the second HD, leaving the first one intact (the
Windows installation was needed other classes).  The RH sysadmin first
said "Of course, no problem" and got himself busy with the installation,
but after less than two minutes he went: "Oh shit!".  Before I knew what
had happened I understood at week end I was going to be busy
reinstalling Windows, applications and the courseware material on that
PC.  He then explained me what had happened.  He had never installed
RHEL on such a PC, with a RAID-capable controller with two HDs before,
and he expected the installation program, Anaconda, to ask him on what
disk to perform the install.  Instead Anaconda the very first thing it
did, before he was asked anything about the preferred HD/partitioning
layout, was to automatically put the two HDs in a RAID setup, and went
ahead on it's own setting up RAID metadata and superblocks on them. 
Before he could stop it the Windows disk was made unbootable and had to
be recovered (reinstalled, actually).

  I do not expect an OS that does not even let you chose on what disk to
perform the install will let you choose a filesystem layout that is not
the recommended one, that is LVM across all the available devices.

  However I haven't performed a RHEL installation since RHEL5, and then
my job was to hack the Kickstart files to customize the install process
to the customer's specifications.


> A long time ago (like maybe RHEL3), Red Hat built
> into its Anaconda installer an ncurses-oriented 'guided' partitioning
> tool that was guilty of both concealing information (suppressed display
> of any extended partition, though logical partitions within it were
> displayed) and also unacceptably overrode the installing admin's
> judgement (e.g., rearranging following its own criteria the filesystems
> to be created).



  Looks like with RHEL7 things have not improved any:


https://www.claudiokuenzler.com/blog/691/custom-partitioning-rhel-red-hat-enterprise-linux-7-setup-installation

Custom partitioning on new Red Hat Enterprise Linux 7 setup
<https://www.claudiokuenzler.com/blog/691/custom-partitioning-rhel-red-hat-enterprise-linux-7-setup-installation>

Thursday - Jan 26th 2017 - by Claudio Kuenzler
<https://www.claudiokuenzler.com/about.php> - (0 comments)
<https://www.claudiokuenzler.com/blog/691/custom-partitioning-rhel-red-hat-enterprise-linux-7-setup-installation>


Unbelieveable how annoying this RHEL 7 installation wizard is! Try to
setup manual partitioning with a mix of primary partitions and logical
volumes - and RHEL will not boot. Even worse: Although I created the
root partition first, somehow the wizard switched it with the swap
partition making swap on /dev/sda1 instead of /dev/sda2 (where I wanted
it to be).

Solution to this: Boot from Knoppix (yes, seriously) and manually create
the partitions with parted. Once this was done, rebooted from the RHEL
image. On the "Installation Destination" submenu I selected "I will
configure partitioning" and then clicked on the blue Done button.


> First time I encountered the latter misbehaviour, I
> exercised my vocubulary in several languages on the topics of theology
> and biology,



  LOL!


> further commented 'Sod _this_ for a lark', cancelled out of
> that subscreen, switched to Ctrl-Alt-F2, and used /sbin/fdisk instead.



  That *might* still work, but I wouldn't bet a dime on it.


> Just offhand, I'm betting that a similar approach may still be fruitful,
> though I've not needed to deal with the darned thing in quite a while.
>
> Years later, based partly on that lesson, I started leaning towards a
> preference for using a best-of-breed live distro for partitioning and
> mkfs'ing all of my filesystems _before_ using the desired distro
> installer. FWIW, I found the Siduction live CD ideal for this purpose.
> (Siduction is the surviving fork of an innovative distro, Sidux, that
> was a quarterly CD ISO release based on Debian Sid + stabilisation
> packages.) My thought is: If you find a maintenance bootable image
> that is reliably perfect for filesystem creation/layout, maybe you
> should rely on it. Sometimes, specialised tools justify themselves.
>
>>   And again, I do get the technical reasons that have datacenter and
>> cluster sysadmins prefer a merged filesystem....
> FWIW, I suspect that the premise (from an upstream poster) is pretty
> much rubbish, analogue to Usenet's infamous 'the lurkers support me
> in e-mail' rejoider, and of null information value either way.
>
> I suspect the aforementioned datacentre and cluster admins are the same
> lunkheads who think default Docker configurations are the right way to
> build Internet infrastructure.



  Of course they are, otherwise they wouldn't have made them the default
settings!  😈



Alessandro


--
Alessandro Selli <alessandroselli@???>
VOIP SIP: dhatarattha@???
Chiave firma e cifratura PGP/GPG signing and encoding key:
BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE