fedora installer by abilities = ugly wood

45 views
Skip to first unread message

Oleg Artemiev

unread,
Feb 20, 2017, 9:16:03 AM2/20/17
to qubes...@googlegroups.com
once uefi detected in BIOS - no chance to make it install non-uefi
version of grub - no chance to continue w/o special efi partition

btrfs partitioning has no option to tweak raid level for data and
metadata - only both. Custom partitioning made non intuitive and
uncomfortable.

and comparing to open suse installer fedora one is woody moron -
nothing has changed in last 3 years to get better w/ fedora installer.


finally I've to install by hands at least in half - prepare all
partitioning, mount points, bootloader configuration and then just
mount (and omit to install bootloader from installation gui) those in
installer.


--
Bye.Olli.
gpg --search-keys grey_olli , use key w/ fingerprint below:
Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E
Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal.com/tag/

Chris Laprise

unread,
Feb 20, 2017, 4:01:40 PM2/20/17
to Oleg Artemiev, qubes...@googlegroups.com
On 02/20/2017 09:16 AM, Oleg Artemiev wrote:
> once uefi detected in BIOS - no chance to make it install non-uefi
> version of grub - no chance to continue w/o special efi partition
>
> btrfs partitioning has no option to tweak raid level for data and
> metadata - only both. Custom partitioning made non intuitive and
> uncomfortable.

I agree that anaconda Fedora installer isn't very good (to say the
least). But I'd also say that what you're asking it to do is rather
advanced and I think unnecessary.

The idea that you have to treat SSDs as fragile has not withstood the
test of time. In fact, SSDs are widely regarded as /more/ durable than
HDDs now. And I don't know of any Qubes Btrfs users (incl. myself) who
employ special drive geometries or other complicated setups to save SSDs
from wear.

With that said, I have found it impossible to get anaconda to do
anything with LUKS+Btrfs beyond the default, one-partition setup. Even
specifying a single existing Btrfs root partition is probably going to
fail. IMHO, the only way to get Btrfs running with Qubes is to do a
plain install with the Btrfs option---Anything else must be done as
adjustments after installation.


Chris

Oleg Artemiev

unread,
Feb 20, 2017, 8:18:10 PM2/20/17
to Chris Laprise, qubes...@googlegroups.com
On Mon, Feb 20, 2017 at 4:01 PM, Chris Laprise <tas...@openmailbox.org> wrote:
> On 02/20/2017 09:16 AM, Oleg Artemiev wrote:
>>
>> once uefi detected in BIOS - no chance to make it install non-uefi
>> version of grub - no chance to continue w/o special efi partition
>>
>> btrfs partitioning has no option to tweak raid level for data and
>> metadata - only both. Custom partitioning made non intuitive and
>> uncomfortable.
>
>
> I agree that anaconda Fedora installer isn't very good (to say the least).
> But I'd also say that what you're asking it to do is rather advanced and I
> think unnecessary.
"necessary" is prerogative of human, not program. Fedora installer
makes me fill like I'm disabled person. )
Comparing to open suse installer - it is worser then ever.

> The idea that you have to treat SSDs as fragile has not withstood the test
> of time. In fact, SSDs are widely regarded as /more/ durable than HDDs now.
I've bought my hdd 3-4 years ago (don't remember exactly). Newer ssd
may be better.
My one.. I just want to pay 1 day for installation and then keep this
for years. So why not to think twice and make setup that will be just
better in resource utilization?

> And I don't know of any Qubes Btrfs users (incl. myself) who employ special
> drive geometries or other complicated setups to save SSDs from wear.
Okay, now you may memorize me ;) I always attempt to get some extra
customization from my PC. =)

> With that said, I have found it impossible to get anaconda to do anything
> with LUKS+Btrfs beyond the default, one-partition setup.

> Even specifying a
> single existing Btrfs root partition is probably going to fail.
I've got installed Qubes 3.2 for testing purposes on a hdd only w/o
encryption just right now w/ root on btrfs. It is possible via fedora
installer, but I except:
*) had to kill efi partition - not to confuse stupid asus n56vz bios
*) bootloader configuration - I had to install grub2 non efi rpm
manually + install grub mnually . Thanks - documentation is pretty
accessible from mobile phone - I install grub rarely so was in need on
some reference for my dual boot. :)

> IMHO, the only way to get Btrfs running with Qubes is to do a plain install with the
> Btrfs option
btrfs is just a switch for default partition type for new partitions I guess.

> ---Anything else must be done as adjustments after installation.
I prefer to do customisations at install time. After testing I'll
records btrfs stats, kill this one Qubes install, repartition and
encrypt by hands, then just make installation eat my point of view.
That's annoying, but I spent lots of time w/ computers to give up on
just ugly installer. ;)

Chris Laprise

unread,
Feb 20, 2017, 11:09:35 PM2/20/17
to Oleg Artemiev, qubes...@googlegroups.com


On 02/20/2017 08:18 PM, Oleg Artemiev wrote:
> On Mon, Feb 20, 2017 at 4:01 PM, Chris Laprise <tas...@openmailbox.org> wrote:
>> On 02/20/2017 09:16 AM, Oleg Artemiev wrote:
>>> once uefi detected in BIOS - no chance to make it install non-uefi
>>> version of grub - no chance to continue w/o special efi partition
>>>
>>> btrfs partitioning has no option to tweak raid level for data and
>>> metadata - only both. Custom partitioning made non intuitive and
>>> uncomfortable.
>>
>> I agree that anaconda Fedora installer isn't very good (to say the least).
>> But I'd also say that what you're asking it to do is rather advanced and I
>> think unnecessary.
> "necessary" is prerogative of human, not program. Fedora installer
> makes me fill like I'm disabled person. )
> Comparing to open suse installer - it is worser then ever.

I mean apart from what the installer can support, in your case (I've
read some of your other partitioning messages) it seems unnecessary.

>> The idea that you have to treat SSDs as fragile has not withstood the test
>> of time. In fact, SSDs are widely regarded as /more/ durable than HDDs now.
> I've bought my hdd 3-4 years ago (don't remember exactly). Newer ssd
> may be better.
> My one.. I just want to pay 1 day for installation and then keep this
> for years. So why not to think twice and make setup that will be just
> better in resource utilization?

IIRC, about any SSD post 2011 should be quite durable... so a Samsung
830 or similar vintage should have no particular worries about longevity.

>
>> And I don't know of any Qubes Btrfs users (incl. myself) who employ special
>> drive geometries or other complicated setups to save SSDs from wear.
> Okay, now you may memorize me ;) I always attempt to get some extra
> customization from my PC. =)
>
>> With that said, I have found it impossible to get anaconda to do anything
>> with LUKS+Btrfs beyond the default, one-partition setup.
>> Even specifying a
>> single existing Btrfs root partition is probably going to fail.
> I've got installed Qubes 3.2 for testing purposes on a hdd only w/o
> encryption just right now w/ root on btrfs. It is possible via fedora
> installer, but I except:
> *) had to kill efi partition - not to confuse stupid asus n56vz bios
> *) bootloader configuration - I had to install grub2 non efi rpm
> manually + install grub mnually . Thanks - documentation is pretty
> accessible from mobile phone - I install grub rarely so was in need on
> some reference for my dual boot. :)
>
>> IMHO, the only way to get Btrfs running with Qubes is to do a plain install with the
>> Btrfs option
> btrfs is just a switch for default partition type for new partitions I guess.

Yes, its just a switch, which anaconda will proceed to handle entirely
wrong should you have anything 'fancy' specified (existing Btrfs+LUKS,
multiple volumes, etc). Usually what happens when I specify Btrfs with
anything but defaults is anaconda forgets encryption step... Whoops!

>
>> ---Anything else must be done as adjustments after installation.
> I prefer to do customisations at install time. After testing I'll
> records btrfs stats, kill this one Qubes install, repartition and
> encrypt by hands, then just make installation eat my point of view.
> That's annoying, but I spent lots of time w/ computers to give up on
> just ugly installer. ;)
>

Just thought I'd offer my experience in case it saves you some time and
effort.

BTW, besides not supporting raid 5/6 (no big deal for me), the other
downside for using Btrfs is still free-space reporting. It still isn't
done in a realistic manner, IMO... you may need to keep 30-60GB free
space at all times to avoid the fs going into read-only mode.

Chris

Oleg Artemiev

unread,
Feb 21, 2017, 12:54:53 AM2/21/17
to Chris Laprise, qubes...@googlegroups.com
On Mon, Feb 20, 2017 at 11:09 PM, Chris Laprise <tas...@openmailbox.org> wrote:
>>> On 02/20/2017 09:16 AM, Oleg Artemiev wrote:
> I mean apart from what the installer can support, in your case (I've read
> some of your other partitioning messages) it seems unnecessary.
Yes, but when I installed opensuse last time I've seeb elegant
powerful interface - less things to do by hands.

>>> The idea that you have to treat SSDs as fragile has not withstood the
>>> test
>>> of time. In fact, SSDs are widely regarded as /more/ durable than HDDs
>>> now.
>>
>> I've bought my hdd 3-4 years ago (don't remember exactly). Newer ssd
>> may be better.
>> My one.. I just want to pay 1 day for installation and then keep this
>> for years. So why not to think twice and make setup that will be just
>> better in resource utilization?
> IIRC, about any SSD post 2011 should be quite durable... so a Samsung 830 or
> similar vintage should have no particular worries about longevity.
nice to hear, but anyway - how long those "no particular worries" go?
I mean that ssd by design is less stable to writes than hdd.
Why not then to partition just that way when ssd will get less writes?
It's not something really hard to make custom partitioning (except you
can't do it via installer).
Last time I wanted something like this I made everything by hands in
console, then made anaconda reread disk,
then just binded mount points to everything that it shows.After that
it's okay to continue w/ setup.

> Usually what happens when I specify Btrfs with anything but
> defaults is anaconda forgets encryption step... Whoops!
hmm.. This time I've installed Qubes 3.2 for testing I didn't check
encryption at all - looks I'm lucky. %)

>>> ---Anything else must be done as adjustments after installation.
>> I prefer to do customisations at install time. After testing I'll
>> records btrfs stats, kill this one Qubes install, repartition and
>> encrypt by hands, then just make installation eat my point of view.
>> That's annoying, but I spent lots of time w/ computers to give up on
>> just ugly installer. ;)
> Just thought I'd offer my experience in case it saves you some time and
> effort.
Nice. Mebbe I'll try once.

> BTW, besides not supporting raid 5/6 (no big deal for me), the other
> downside for using Btrfs is still free-space reporting. It still isn't done
> in a realistic manner, IMO... you may need to keep 30-60GB free space at all
> times to avoid the fs going into read-only mode.
omg... Thank you - now it looks I don't want btrfs anymore. %) I
haven't used btrfs yet - just
wat I've read sounds promising. But pay 60Gigs for that - doesn't seem
to be what I want.
Better I'll go w/ custom lvm + some patching to get r/o root. :)

Chris Laprise

unread,
Feb 27, 2017, 6:20:10 PM2/27/17
to Oleg Artemiev, qubes...@googlegroups.com
On 02/21/2017 12:54 AM, Oleg Artemiev wrote:
> On Mon, Feb 20, 2017 at 11:09 PM, Chris Laprise <tas...@openmailbox.org> wrote:
>>>> On 02/20/2017 09:16 AM, Oleg Artemiev wrote:
>> I mean apart from what the installer can support, in your case (I've read
>> some of your other partitioning messages) it seems unnecessary.
> Yes, but when I installed opensuse last time I've seeb elegant
> powerful interface - less things to do by hands.

Agreed, they have good admin UIs.

>
>>>> The idea that you have to treat SSDs as fragile has not withstood the
>>>> test
>>>> of time. In fact, SSDs are widely regarded as /more/ durable than HDDs
>>>> now.
>>> I've bought my hdd 3-4 years ago (don't remember exactly). Newer ssd
>>> may be better.
>>> My one.. I just want to pay 1 day for installation and then keep this
>>> for years. So why not to think twice and make setup that will be just
>>> better in resource utilization?
>> IIRC, about any SSD post 2011 should be quite durable... so a Samsung 830 or
>> similar vintage should have no particular worries about longevity.
> nice to hear, but anyway - how long those "no particular worries" go?
> I mean that ssd by design is less stable to writes than hdd.
> Why not then to partition just that way when ssd will get less writes?
> It's not something really hard to make custom partitioning (except you
> can't do it via installer).

Manufacturer SSD durability estimates have increased greatly, along with
the length of available warranties.

http://techreport.com/review/27436/the-ssd-endurance-experiment-two-freaking-petabytes/2

http://www.networkworld.com/article/2873551/data-center/debunking-ssd-myths.html

"Exhaustive studies have shown that SSDs have an annual failure rate
of tenths of one percent, while the AFRs for HDDs can run as high as
4 to 6 percent."


For comparison a Samsung 850 SSD is rated at 1.5 million hrs (EVO) and 2
million hrs (PRO) MBTF.... that's at least 50 percent more than a
premium HDD (although HDD mfgs stopped using MTBF several years ago,
probably because the SSDs were making them look terrible). The last time
I recall reports of a surge in SSD failures (about 6 years ago) it
wasn't even the flash that was at fault... the controllers were
overheating, which was a common problem with many brands that used
Sandforce controllers circa 2011.

The components and algorithms that determine the reliability of consumer
SSDs has changed a lot for the better. I don't think there is currently
reason to treat them as being in any way more fragile or wear-prone than
HDDs.

>> BTW, besides not supporting raid 5/6 (no big deal for me), the other
>> downside for using Btrfs is still free-space reporting. It still isn't done
>> in a realistic manner, IMO... you may need to keep 30-60GB free space at all
>> times to avoid the fs going into read-only mode.
> omg... Thank you - now it looks I don't want btrfs anymore. %) I
> haven't used btrfs yet - just
> wat I've read sounds promising. But pay 60Gigs for that - doesn't seem
> to be what I want.
> Better I'll go w/ custom lvm + some patching to get r/o root. :)

I certainly understand that. So far I'm being tolerant of this condition
of using Btrfs. They actually did improve the reporting somewhat with
the "filesystem usage" command, hoping it gets even better.

Just be aware that thin-provisioned LVM (it is /not/ traditional LVM) is
also relatively new and has issues.

Chris


Oleg Artemiev

unread,
Feb 27, 2017, 8:54:09 PM2/27/17
to Chris Laprise, qubes...@googlegroups.com
On Tue, Feb 28, 2017 at 2:20 AM, Chris Laprise <tas...@openmailbox.org> wrote:
> On 02/21/2017 12:54 AM, Oleg Artemiev wrote:
\>>> I mean apart from what the installer can support, in your case (I've read
Finally my terabyte evdo 840 didn't survive last installation when I
completely rewritten it.
it has gone after 5 years. And, damn, things get even easier - amount
of partitioning got
at least twice lower )) Anyway if I used it w/ btrfs or most writes
going to hdd - it should
be dead even later - last two years I was using Qubes w/ it w/o care
on regular rewrites on VM start stop.

>>> BTW, besides not supporting raid 5/6 (no big deal for me), the other
>>> downside for using Btrfs is still free-space reporting. It still isn't
>>> done
>>> in a realistic manner, IMO... you may need to keep 30-60GB free space at
>>> all
>>> times to avoid the fs going into read-only mode.
>>
>> omg... Thank you - now it looks I don't want btrfs anymore. %) I
>> haven't used btrfs yet - just
>> wat I've read sounds promising. But pay 60Gigs for that - doesn't seem
>> to be what I want.
>> Better I'll go w/ custom lvm + some patching to get r/o root. :)
> I certainly understand that. So far I'm being tolerant of this condition of
> using Btrfs.
> They actually did improve the reporting somewhat with the
> "filesystem usage" command, hoping it gets even better.
>
> Just be aware that thin-provisioned LVM (it is /not/ traditional LVM) is
> also relatively new and has issues.
Thank you - I'm not willing to use thin provsioning - it is repored to
slow down disk i/o in comparision to usual LVM.
Reply all
Reply to author
Forward
0 new messages