Perfect timing for continuation of this thread.
My new ly builtPC (replacing Windows XP on a ancient Dell) is home and I'm
getting acquainted with a simple standard debian Linux installation that is
all-in-one-partition except for swap.
Now finalizing the partitioning design for the "real" debian install.
So the resumption of this thread, with tips on partitioning, UEFI and SSD is
most welcome !!
Ideas duly extracted from the messages for further consideration.
Steve
From: Russell via talk
To: D. Hugh Redelmeier ; GTALUG Talk ; D. Hugh Redelmeier via talk
Sent: Tuesday, April 17, 2018 8:20 AM
Subject: Re: [GTALUG] New Desktop PC -- debian Linux - Proposed 2 TB
HDDPartitioning;
On April 11, 2018 7:02:56 PM EDT, "D. Hugh Redelmeier via talk"
<talk@gtalug.org> wrote:
>| From: Giles Orr via talk <talk@gtalug.org>
>
>Clunk Clunk Clunk (I'm nodding my head).
>
>| I'm with Len - simplify if you can. Although Unlike him, I believe
>you
>| should have at least two (Linux) OS partitions - if one is messed up,
>you
>| can boot from the other to fix it. And I've also - more than once -
I also follow this practice. In fact in my current build, I'm looking at
overprovisioning my SSD using small fencing stripes. This would so as to be
able to gain several spaces on the disk which I could format in an emergency. I
can then recover a backup of the superblock and realign things. In theory
anyway.
>had to
>| tinker with two OSes (usually Debian vs. Fedora) to figure out which
>worked
>| best on a particular machine. So I always have at least two OS
Currently I have two versions of the same os on the same machine. One on M.2
Xpoint nvram and one on a standard SSD. I'm playing around with tweaking before
I do a final config. So far the Xpoint direct hw access appears 3x as fast as
the SSD while real world throughput shows up about twice as fast on the Xpoint,
recent INTEL cache fencing notwithstanding.
dd if=/dev/zero bs=1M count=1024 | md5sum
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 1.35008 s, 795 MB/s
cd573cfaace07e7949bc0c46028904ff -
795 is just under twice as fast as writing to the conventional SSD.
>
>I used to always have two / partitions for two separate OSes. When a
>new OS release came out, I always did a fresh install into the other /
>partition. This meant that the old system could still be run. Now
>I've gotten a bit lazy and do upgrades in place. Still, having space
>for a separate installation is comforting.
>
>Fedora seems to have been trustable with upgrades-in-place for a few
>years.
I'm currently on Fedora 27 with Gnome using the Nouveau driver. I usually
never automatically update but while I sort this new box and throughout the
Spectre stuff, updates are automatic. This release had both the gnome update
notifier and dnfdragora enabled by default which was confusing at first but I
got used to it.
>According to Lennart, debian has been trustable for a long long time.
I was frozen at 2.6 on Debian till 2010 or so. I didn't automatically upgrade
during that time but as I recall when I did there were few problems. Notably
the introduction of pulse audio and ongoing issues with xsane and colord
profiles. Although recently I switched back to RH for myself. I did this once
it looked like SElinux was sorted in respect of systemd. I made the switch,
mostly to align myself more in keeping with FOSS libraries.
>
>| And in the name of simplicity, each OS partition includes its
>| own /var, /usr, /usr/local ... the only separate partitions are swap
>and
>| /home, because I want that to be separate and accessible to each of
>the OS
>| partitions - and separate and not affected by OS upgrades.
>
>Superstitiously, I won't let different distros share a /home. I fear
>a conflicting set of config files. I don't know that this is a
>problem, I just don't really want to find out.
When I first started my switch from DOS to *nix, I was told you absolutely
don't want to run two versions of init on the same machine. I believe this is
why userland programming uses telinit. It seems to me that not letting
different distros share a home is a pretty sound idea, even if it is based on
superstition.
I forget the exact reasons I was given for always using telinit. However
given the fine granularity and ballistic nature of the bits and dword bytes, I
assume that it could be catastrophic to request pid1 and receive pid 1001. The
audit trail to follow for recovery would be hard to follow without being able
to distinguish the id as being from userland rather than kernelspace.
>
>For this reason, I don't tend to let /home fill the drive. I invent
>another filesystem to occupy any spa
