[GTALUG] New Desktop PC -- debian Linux - Proposed 2 TB HDDPartitioning;

Steve Petrie, P.Eng. apetrie at aspetrie.net
Wed Apr 18 09:44:08 EDT 2018


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 at gtalug.org> wrote:
  >| From: Giles Orr via talk <talk at 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 spare space.  Usually /space.

  I use /DATA, using caps is the way I remind myself, at a glance, that I created the space. 
  >
  >|  These days it
  >| seems you want a /boot partition though - but I'm not the one to
  >explain
  >| the ins and outs of that.
  >
  >I've not seen a use for a /boot partition.
  >
  >With UEFI booting, you need a separate EFI System Partition.  This
  >will be shared by all systems that boot off that drive.  This gets
  >mounted on the mount point /boot/efi.  It will be some variant of FAT
  >but the partition type will be distinct.
  >
  >Technically you can have more than one EFI System Partition on a drive
  >but don't do this.  I did this by accident and had a few problems.

  Out of curiosity, could you say what type of problems they were?

  >Windows cannot handle this case and firmware setup screens may be no
  >better.  I don't know of any upside.
  >---
  >Talk Mailing List
  >talk at gtalug.org
  >https://gtalug.org/mailman/listinfo/talk

  -- 
  Russell
  ---
  Talk Mailing List
  talk at gtalug.org
  https://gtalug.org/mailman/listinfo/talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gtalug.org/pipermail/talk/attachments/20180418/56f2eef1/attachment.html>


More information about the talk mailing list