Re: Intended question - was {Re: Forgot name of Debian "configuration" {wrong word?} file}
On Sun 16 Jun 2019 at 22:50:28 (-0400), Felix Miata wrote:
> Richard Owlett composed on 2019-06-16 14:17 (UTC-0500):
> > David Wright wrote:
>
> >> or, even easier,
>
> >>Use a LABEL to indicate the swap partition in all your own
> ...> I can't parse that.
>
> I recommend learning to use LABELs on all your filesystems. They are massively
> easier for humans to work with than UUIDs. You get to assign them in
> accordance
> with how your brain functions, e.g.:
That's right.
[…]
> In case you're wondering about the above naming logic, m12 is simply the last
> three characters of the disk's serial number, something to reduce possibility
> of label duplication when swapping disks around, or cloning.
I write permanent 4-letter names on my disks with a marker
pen. Computers too. The partitions are just 2-digit suffixes.
Names makes it easier to remember that PC wasp contains
disks faye and chad, for example.
> Labeling makes output lines in blkid longer, but that enables making parsing
> much
> easier for most human brains. Labels can be especially helpful with multiboot
> in
> constructing custom boot stanzas much shorter and more easily parsable
> compared
> to those generated by grub-mkconfig, e.g.:
>
> menuentry "Debian 10 Buster" {
> search --no-floppy --set=root --hint-baremetal=ahci0,gpt8 --label
> m12p08deb10
> linux /vmlinuz root=LABEL=m12p08deb10 noresume
> initrd /initrd.img
> }
Thanks for the example. It's long been a disappointment that
there's no GRUB_DISABLE_LINUX_LABEL=true parameter in
/etc/default/grub. For years I've post-processed grub.cfg
with a shell script to replace the UUIDs with LABELs by
using data from /run/udev/data/b* (and making a few other
tweaks). But I can see I ought to be doing more pruning.
Cheers,
David.
Re: Intended question - was {Re: Forgot name of Debian "configuration" {wrong word?} file}
On Sun, Jun 16, 2019 at 9:06 PM David Wright
wrote:
> On Sun 16 Jun 2019 at 14:17:21 (-0500), Richard Owlett wrote:
>
> > > 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?
>
He's claiming that his needs are the same as the rest of humanity to the
n-th power.
> > 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* !!!
>
I'll pass David on the left here ;-)
Knoppix proved years ago that you can run the whole damn thing out of RAM
back when 512K was big.
In datacenters in recent years, if a server is swapping, a problem ticket
is opened and alarm raised. Just because
the OS can handle it easily, nevertheless it's still a negative indicator.
I just took possession of a free used Dell
PowerEdge R610 for home, retiring after 5 years hard time in chilled rooms.
It has 96GB RAM. I could run NASA out of that much RAM ;-)
>
> Cheers,
> David.
>
Re: Intended question - was {Re: Forgot name of Debian "configuration" {wrong word?} file}
Le 17/06/2019 à 04:50, Felix Miata a écrit : I recommend learning to use LABELs on all your filesystems. They are massively easier for humans to work with than UUIDs. You get to assign them in accordance with how your brain functions, e.g.: # LABEL=m12P01esp /boot/efi vfatcodepage=437 0 0 LABEL=m12p02swapswapswapdefaults 0 0 LABEL=m12p03usrlcl /usr/local ext4noatime,data=ordered 0 2 (...) In case you're wondering about the above naming logic, m12 is simply the last three characters of the disk's serial number, something to reduce possibility of label duplication when swapping disks around, or cloning. Adding a prefix or suffix to avoid label collisions is a good practice. However IMO a label should be associated to the contents, not to the container (disk or partition) at least on fixed disks. I do not care that a given filesystem is in partition X on disk Y, all that matters to me is that it contains the home directory for system 'foo' (for instance) -> foo_home.
Re: Intended question - was {Re: Forgot name of Debian "configuration" {wrong word?} file}
Richard Owlett composed on 2019-06-16 14:17 (UTC-0500):
> David Wright wrote:
>> or, even easier,
>>Use a LABEL to indicate the swap partition in all your own
...> I can't parse that.
I recommend learning to use LABELs on all your filesystems. They are massively
easier for humans to work with than UUIDs. You get to assign them in accordance
with how your brain functions, e.g.:
#
LABEL=m12P01esp /boot/efi vfatcodepage=437
0 0
LABEL=m12p02swapswapswapdefaults
0 0
LABEL=m12p03usrlcl /usr/local ext4noatime,data=ordered
0 2
LABEL=m12p04home/home ext4
noatime,acl,user_xattr,data=ordered 0 2
LABEL=m12p05stw /disks/stw ext4noatime,acl,user_xattr,nofail
0 0
LABEL=m12p06s150/disks/s150 ext4noatime,acl,user_xattr,nofail
0 0
LABEL=m12p07s151/disks/s151 ext4noatime,acl,user_xattr,nofail
0 0
LABEL=m12p08deb10 / ext4noatime,errors=remount-ro
0 1
LABEL=m12p09Ubionic /disks/buntuext4noatime,acl,user_xattr,nofail
0 0
LABEL=m12p10mint19 /disks/mint ext4noatime,acl,user_xattr,nofail
0 0
In case you're wondering about the above naming logic, m12 is simply the last
three characters of the disk's serial number, something to reduce possibility
of label duplication when swapping disks around, or cloning.
Labeling makes output lines in blkid longer, but that enables making parsing
much
easier for most human brains. Labels can be especially helpful with multiboot in
constructing custom boot stanzas much shorter and more easily parsable compared
to those generated by grub-mkconfig, e.g.:
menuentry "Debian 10 Buster" {
search --no-floppy --set=root --hint-baremetal=ahci0,gpt8 --label
m12p08deb10
linux /vmlinuz root=LABEL=m12p08deb10 noresume
initrd /initrd.img
}
The exercise might even make the string /etc/fstab more memorable. :-D
--
Evolution as taught in public schools is religion, not science.
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
Re: Intended question - was {Re: Forgot name of Debian "configuration" {wrong word?} file}
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 swapsw
> >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 LL /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 LL, which stands for whatever "acceptab
Re: Intended question - was {Re: Forgot name of Debian "configuration" {wrong word?} file}
On Sun, Jun 16, 2019, 2:17 PM Richard Owlett wrote: > > I'm not experimenting with the installation process, but with what I > want the result to be. > Those are 2 sides of the same coin. > >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 Once again you contradict yourself. Sentence 1 states that you are experimenting but Sentence 2 complains that you don't know. 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* !!! > > I can't parse that. > You said you were going to look into fstab. That's how you parse that :-) > > You've been flogging this dead horse for at least seven years now. > > Horse ain't dead. > "It's dead Jim" - Dr. Leonard McCoy, Star Trek > No > require my failures to be deterministic ! > That was proven impossible in the 1930s by Alonzo Church and Alan Turing. :-) VM's are intrinsically unknown quantities. > Never, ever say that to Linus Torvalds. Or Lennart Poettering. :-) >
Re: Intended question - was {Re: Forgot name of Debian "configuration" {wrong word?} file}
On 6/16/2019 9:17 PM, 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} ;/
>
>>
>> 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 LL /dev/sdXN
Or use a preseed file with something like:
d-i preseed/late_command string ...
Or as kernel boot parameter.
>> 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.
>
D-i allows customisation of the system to be installed to your liking by
use of 'kernel boot parameter' or a 'preseed' file.
--
John Doe
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 swapsw
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 LL /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 when booting?
No
require my failures to be deterministic !
VM's are intrinsically unknown quantities.
Re: Intended question - was {Re: Forgot name of Debian "configuration" {wrong word?} file}
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): 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 and /etc/initramfs-tools/conf.d/resume when it's up and running. (If you're only installing as an experiment in installation, I suspect you won't even need to bother, because you'll be overwriting it shortly. Does top show much use of swap anyway?) or, even easier, Use a LABEL to indicate the swap partition in all your own /etc/fstab files, eg: LABEL=swan10 none swapsw 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 LL /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.) > 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. Common sense dictates that anyone installing a new system wants it to boot up by default. 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 when booting? Cheers, David.
Re: Intended question - was {Re: Forgot name of Debian "configuration" {wrong word?} file}
On 06/15/2019 09:22 AM, Pascal Hambourg wrote: Le 15/06/2019 à 15:15, Richard Owlett a écrit : 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 I agree this is annoying. The Debian installer is not the only one doing this. 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 . Other workarounds exist : - If you have plenty of disk space, create a separate swap for each installation. Or no swap if you don't need it (enough RAM and no hibernation). I had wondered about something like that. I think I'm more comfortable with one "largish" partition than several small ones. - Use LVM logical volumes instead of plain partitions. When the swap is in a logical volume, the installer uses its persistent device name (actually a symlink) /dev/mapper/vgname-lvname instead of its UUID. So changing the UUID does not disrupt anything. Also, IMO having multiple test installations is a good use case for LVM as it allows to create, resize and delete volumes of arbitrary sizes unlike partitions which require sufficient contiguous disk space or moving partitions around. I never noticed anything that attracted my attention to LVM. I will have to do more reading. 2. Grub configuration. The installer is egotistical enough to think that what is being installed will always be the preferred version. NOT! AFAICS, most installers (Linux and others) do the same. 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. IMO installing GRUB with each system is desirable so that grub.cfg is generated, as update-grub uses foreign grub.cfg files to properly retrieve boot parameters. The only thing I've read about multiple GRUBs has been comments on this list - nothing intentionally organized. As most of the programming I've done was back when 8085 was new tech, I strongly favor minimal resources. In legacy mode, you can install GRUB in different locations : main GRUB in the disk MBR and others in partition boot records. But in legacy mode the installer does not allow to select a location and name, so at worst if will overwrite the previous GRUB installed by Debian (if using the same EFI partition) and at best if will overwrite the EFI boot entry (if using a different EFI partition). It would be nice if the installer could offer to define a custom identifier for the boot loader. All my stuff is legacy.
Re: Intended question - was {Re: Forgot name of Debian "configuration" {wrong word?} file}
Le 15/06/2019 à 15:15, Richard Owlett a écrit : 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 I agree this is annoying. The Debian installer is not the only one doing this. 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 . Other workarounds exist : - If you have plenty of disk space, create a separate swap for each installation. Or no swap if you don't need it (enough RAM and no hibernation). - Use LVM logical volumes instead of plain partitions. When the swap is in a logical volume, the installer uses its persistent device name (actually a symlink) /dev/mapper/vgname-lvname instead of its UUID. So changing the UUID does not disrupt anything. Also, IMO having multiple test installations is a good use case for LVM as it allows to create, resize and delete volumes of arbitrary sizes unlike partitions which require sufficient contiguous disk space or moving partitions around. 2. Grub configuration. The installer is egotistical enough to think that what is being installed will always be the preferred version. NOT! AFAICS, most installers (Linux and others) do the same. 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. IMO installing GRUB with each system is desirable so that grub.cfg is generated, as update-grub uses foreign grub.cfg files to properly retrieve boot parameters. In legacy mode, you can install GRUB in different locations : main GRUB in the disk MBR and others in partition boot records. But in legacy mode the installer does not allow to select a location and name, so at worst if will overwrite the previous GRUB installed by Debian (if using the same EFI partition) and at best if will overwrite the EFI boot entry (if using a different EFI partition). It would be nice if the installer could offer to define a custom identifier for the boot loader.
Intended question - was {Re: Forgot name of Debian "configuration" {wrong word?} file}
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. TIA 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 . 2. Grub configuration. The installer is egotistical enough to think that what is being installed will always be the preferred version. NOT! 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 ;}
