Re: Intended question - was {Re: Forgot name of Debian "configuration" {wrong word?} file}
On 06/16/2019 11:03 AM, David Wright wrote:
On Sat 15 Jun 2019 at 08:15:24 (-0500), Richard Owlett wrote:
On 06/14/2019 06:10 AM, Richard Owlett wrote:
I can't remember the name of the file which identifies the
association between a directory (i.e. \home) and which physical
partition it is on. The file I'm looking for also identifies which
partition is used for swap.
The filename I had forgotten was /etc/fstab .
Background:
I have one laptop explicitly set aside for experimenting with Debian
in order to determine *MY* ideal system. To this end I may have a half
dozen copies of Debian to chose from at boot.
For my purposes, the Debian installer has two annoyances:
1. swap area designation.
Everything is fine on the 1st installation.
On following installations, when the existing swap partition is
is to be used its UUID is changed. This causes grief for the
other installations by making swap area appear missing. My
personally preferred solution is to activate swap only of the
initial installation. For subsequent installs actually requiring
a swap partition, I edit its /etc/fstab .
It's rather easy to work around this problem in one of two ways (at least):
Ways on order of {# users}**N { N < world_population} ;/
With a reasonable amount of memory (not a problam nowadays), just tell
the d-i to leave the existing swap file alone and do without one. Then
manually add the old UUID into the new installation's /etc/fstab
*ROFL* !!!!
Been doing that forever. However, had not done it recently.
I had forgotten the filename was "/etc/fstab" ;<
and /etc/initramfs-tools/conf.d/resume when it's up and running.
Never hear of that file. Will research after sending this message.
(If you're only installing as an experiment in installation,
I'm not experimenting with the installation process, but with what I
want the result to be.
I suspect
you won't even need to bother, because you'll be overwriting it shortly.
Does top show much use of swap anyway?)
Not a parameter of my experiment's protocol.
As I do not "know" how much swap space I require, I provide swap space
based on conservative estimates of _typical_ requirements. That
logically leads to my preference for a SINGLE large swap vs multiple
small swap areas. *YMMV* !!!
or, even easier,
Use a LABEL to indicate the swap partition in all your own
/etc/fstab files, eg:
LABEL=swan10 none swap sw
and in /etc/initramfs-tools/conf.d/resume.
The d-i will of course overwrite the swap partition UUID/LABEL
as usual, but it's trivial to reset your LABEL at the end.
When the d-i reaches the UTC question at the end, switch to VC2
and type (with the appropriate values):
# /target/sbin/swaplabel -L LLLLLL /dev/sdXN
before answering the UTC question. The newly installed system
will boot via its fresh UUID, but all your old systems will
carry on using your LABEL as usual. (I assume that if you're
going to keep the new system for any length of time, you will
be editing its /etc/fstab anyway, and can set your usual LABEL
there, as in the example above.)
I can't parse that.
2. Grub configuration.
The installer is egotistical enough to think that what is being
installed will always be the preferred version. NOT!
You've been flogging this dead horse for at least seven years now.
Horse ain't dead.
Common sense dictates that anyone installing a new system wants it
to boot up by default.
You have neglected to *GROK* my goals ;/
Some of my experiments are un-bootable.
Anything else would be like sending the final
copy of your magnum opus to the publisher only for them to distribute
an old draft. OSes aren't like marmalade, where you have to use up
the old jar before opening a new one.
My solution is install Grub only on the initial install and NO
boot loader on subsequent install. After completing one (or more)
additional installs, I boot the first install and run update-grub.
VM's had been suggested ;}
What for; to avoid having to type <down><down><down><return> when booting?
No
require my failures to be deterministic !!!!!!!!!!!!!!!!!!!!!
VM's are intrinsically unknown quantities.
Reply to: