From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <gentoo-dev+bounces-75233-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
by finch.gentoo.org (Postfix) with ESMTP id 7873459CAF
for <garchives@archives.gentoo.org>; Sun, 10 Apr 2016 08:17:36 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id 61FFF21C068;
Sun, 10 Apr 2016 08:17:29 +0000 (UTC)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by pigeon.gentoo.org (Postfix) with ESMTPS id 5B78321C015
for <gentoo-dev@lists.gentoo.org>; Sun, 10 Apr 2016 08:17:25 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <lnx-gentoo-dev@m.gmane.org>)
id 1apAYb-0005QJ-Pu
for gentoo-dev@lists.gentoo.org; Sun, 10 Apr 2016 10:17:21 +0200
Received: from ip98-167-165-199.ph.ph.cox.net ([98.167.165.199])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-dev@lists.gentoo.org>; Sun, 10 Apr 2016 10:17:21 +0200
Received: from 1i5t5.duncan by ip98-167-165-199.ph.ph.cox.net with local (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00
for <gentoo-dev@lists.gentoo.org>; Sun, 10 Apr 2016 10:17:21 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: gentoo-dev@lists.gentoo.org
From: Duncan <1i5t5.duncan@cox.net>
Subject: [gentoo-dev] Re: usr merge
Date: Sun, 10 Apr 2016 08:17:15 +0000 (UTC)
Message-ID: <pan$2dfef$fff96954$dfeb2d38$95477ad8@cox.net>
References: <20160407154636.GA26596@whubbs1.gaikai.biz>
<CAGfcS_=81Rh0eOzW7z6Wvshid+jNx+3_7v2f=WiHbjGi5iipBA@mail.gmail.com>
<b717674a-feb4-4979-90fc-31f6f3fd57eb@gentoo.org>
<5706A7A6.3080402@iee.org>
<CAGfcS_m1Cu8+Sc7gw04bDysdfsZAC_PV-tf3GjV0GDk1A_rSqg@mail.gmail.com>
<CAGDaZ_ppOCqCrmkqGJgHaifiyq-N+FPEA8DEa63W20W-FK0nKg@mail.gmail.com>
<57070bbd.9a48620a.a07cf.3177@mx.google.com>
<57070c95.0714320a.ed102.1995@mx.google.com> <570718F5.3040904@iee.org>
<pan$81936$9f9ce2e$877510db$86956aa8@cox.net>
<20160409124425.GA3128@vidovic.ultras.lan>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: ip98-167-165-199.ph.ph.cox.net
User-Agent: Pan/0.141 (Tarzan's Death; GIT fb7f2ee)
X-Archives-Salt: f0afcdf4-a50f-41e4-bc0c-a7d9b8dd5454
X-Archives-Hash: 3b7dde9f0a1eaea88d7214d842d66c82
Nicolas Sebrecht posted on Sat, 09 Apr 2016 14:44:25 +0200 as excerpted:
> On Fri, Apr 08, 2016 at 07:58:35AM +0000, Duncan wrote:
>
>> > I would also re-iterate, as I'm sure you're aware .. there ARE
>> > differences between sbin and bin .. unless of course you spend all
>> > your time in a Rooted VM where it doesn't matter if you accidentally
>> > trash your system. Some of us maintain a sensible user/superuser
>> > distinction for a variety of reasons, and simplifying your filesystem
>> > to suit some particular package style doesn't really sound like good
>> > reasoning for causing a lot of headaches for maintainers and a distro
>> > overall.
>>
>> But... the real important distinction in terms of user vs. superuser
>> executables is file ownership and permissions, not the directory
>> they're in.
>
> No. With a lightweight / I can install systems with two root filesystems
> that I rsync once I'm sure there's no regression. If one won't boot
> after an upgrade, I can just reboot and select the other root filesystem
> in grub.
>
> This is much more easy than anything else.
Actually I do precisely that, with / itself, which here includes pretty
much everything the package manager installs (with the exception of a few
things in /var that need to be writable in normal operation, that are
symlinked to /home/var as my / is normally read-only mounted), including
the package database itself, so everything stays in sync with the package
database tracking it, on the same filesystem. =:^)
$ df /
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/sda5 8192M 2819M 5132M 36% /
That's the working-copy. It's actually a two-device btrfs raid1, 8 GiB
per device (8 GiB partition on each of two SSDs). That already gives me
device redundancy.
The first backup is another 8 GiB, again actually two-device btrfs raid1,
8 GiB per device, on another partition on each of those ssds. That gives
me fat-finger and broken update redundancy.
The second backup is an 8 GiB reiserfs on spinning rust, giving me both
filesystem type redundancy because btrfs is still stabilizing, and a
second backup in case disaster strikes when I'm actually updating the
primary backup, taking out both it and the working copy.
All three are independently bootable from grub2 as installed on all three
devices, using the working copy /boot on one of the ssds, the primary
backup /boot on the other ssd, or the secondary backup /boot on the
spinning rust. /home similarly has a working copy raid1 btrfs on the
ssds, a primary backup on the ssds, and a reiserfs secondary backup on
spinning rust. There are further backups on USB tho I don't keep them as
current so if I actually had to fall back to them I'd have some work
ahead of me.
Actually, I don't even have to switch to the grub2 commandline to switch
between the three, either. They're all selectable directly from my
customized grub2 menu, as is init=/bin/bash, systemd emergency and rescue
mode, etc. Of course I can go grub commandline if needed, but it's not
needed for those entries as they're already available in the menu I've
setup. And of course the grub installation and corresponding /boot I use
is selectable directly from the BIOS.
What's nice about this is that the 8 GiB root is plenty big enough to
hold the entire working system, including all manpages, the X and KDE
install, etc, so not only do I have full documentation to work with while
I'm recovering my broken root, but I have a full X and kde-plasma, which
with /home or one of its backups gives me a fully customized kde install
as well. So I can load up X/kde-plasma, and fire up youtube for full-
monitor viewing say some club music videos to keep me awake on the 42-
inch, while I work from one of the backups to recover the working copy
with multiple konsole terminals on the 48-inch below it, and the system
performance graphs display on the 21-inch off to the side.
Try doing all /that/ in recovery mode from your "lightweight" / backup.
=:^)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman