On Sun 16 Jun 2019 at 14:17:21 (-0500), Richard Owlett wrote:
> 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} ;/
Eh?
> > 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" ;<
I'm surprised, then, that you haven't written a shell script for the
process, in view of the number of Debian installations you must have
performed over the years. (The script could also remember the filename
for you.)
> > and /etc/initramfs-tools/conf.d/resume when it's up and running.
>
> Never hear of that file. Will research after sending this message.
It's just the file that's consulted in building the initramfs, which
tells the system where it was written to during hibernation.
> > (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.
A Debian installation is produced by the installation process, so
what's your point? I'm assuming you're not a d-i developer who's
working on how the d-i actually goes about installing a system.
> > 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.
I don't care. My point is that any reasonably endowed modern PC is
unlikely to do any swapping during your "installation/result
experiment" (whatever terminology you want to call it) as they have
so much memory. My old 500MB desktop doesn't, nor did its 384MB
predecessor (used from potato through squeeze).
> 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* !!!
But your use case isn't typical: you're talking about installing
systems that you said might not even boot, let alone do productive
work after installation. So zero is a reasonable size.
> > 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.
I don't see how you can install Debian several times a day and yet not
understand most of that. You must be intimately familiar with the d-i,
LABELs, UUIDs, getting a shell on VC2, the UTC clock question (ie about
the last occasion in the installation process when it's possible to
use VC2), /target, and /dev/sdXN device terminology. All that remains
is LLLLLL, which stands for whatever "acceptably unique" or "reasonably
unique" (terms you've used in the past) LABEL you might put on the
swap partition with swaplabel.
What specifically are you finding difficult to parse?
> > > 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.
And the authors of the d-i and Grub couldn't care in the least
about your experiments or your goals. Besides, how are those authors
meant to recognise people like you, guess their preferred default
disk, partition etc, when presented with any particular system?
How would they know whether the method that's been used for booting
up until now is capable of booting the new system being installed?
And if their guesses were incorrect, they'd be accused of installing
broken systems that won't boot. Get a grip.
> > 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
Then what *would* be the benefit of a VM? Why did you bring it up
in this thread?
> require my failures to be deterministic !!!!!!!!!!!!!!!!!!!!!
>
> VM's are intrinsically unknown quantities.
I wouldn't know. I've never set one up.
Cheers,
David.
