Possible bug in d-i handling of swap partition
I have two use cases which demonstrate the problem.
First Environment:
I have a laptop exclusively dedicated to being a test platform of
various Debian configurations [Jessie 8.6.0 currently]. I have
limited connectivity, therefore all installs are done from a
purchased set of DVDs. At any time there may exist up to 4
installs available, each in its own partition. As only one
install is active at any time, a single swap partition should be
adequate.
*HOWEVER* each install "touches" the swap partition changing its
UUID.
This causes a problem with using the chronologically earlier in
stall. Systemd looks for a swap partition with a specific UUID.
The triggered diagnostic takes ~2 minutes while I'm
w-a-i-t--n---g for the system to boot. I've NOT investigated
whether or not the system actually finds and uses the intended
swap partition or not. For THAT PARTICULAR LAPTOP I doubt there
are any consequences as for my particular use I doubt any use of
swap occurs. I suspect a workaround might be editing /etc/fstab
all previous installs when a new install is done.
Second Environment:
On a second machine [the laptop being out of service due to
hardware problems] I attempted to install Debian to a USB flash
drive for demonstrating Debian to friends on their machines and
testing used machines before purchasing.
The was no problem until the partitioning phase. It allowed me to
create a ext2 partition on the flash drive for use a / . It
allowed me to create a second partition and to designate it as a
swap partition.
*HOWEVER* the confirmation screen about writing changes to disk
essentially said it was going to *TRASH* the existing install of
Debian on the machines hard-drive by formatting the hard disk's
swap partition [i.e. changing its UUID].
I see no conceivable reason to mess with a perfectly fine install
when installing to an unrelated device.
Thank you
Reply to: