Re: shame on me (was: Re: No fool like an old fool (debian installation probs))
On Tue 02 May 2023 at 12:10:48 (+0200), DdB wrote:
> I notice, that, even though i did change the name of the sda2 partition,
> the PARTLABEl remained unchanged.
It's rather confusing that gdisk (my preferred partitioner, which
I use outside the installer) refers to the PARTLABEL as the
partition's name rather than label:
Command (? for help): c
Using 1
Enter name: Kirk01
Command (? for help): i
Using 1
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 13005F6E-6289-4AB9-B36E-8689CF983EF5
First sector: 2048 (at 1024.0 KiB)
Last sector: 2930277134 (at 1.4 TiB)
Partition size: 2930275087 sectors (1.4 TiB)
Attribute flags:
Partition name: 'Kirk01'
and the symlinks¹ are:
S:disk/by-partuuid/13005f6e-6289-4ab9-b36e-8689cf983ef5
S:disk/by-path/pci-:00:1d.7-usb-0:5:1.0-scsi-0:0:0:0-part1
S:disk/by-partlabel/Kirk01
S:disk/by-id/wwn-0x5000c5001a769150-part1
S:disk/by-id/ata-ST31500341AS_9VS3AMF3-part1
S:disk/by-uuid/beca0527-b041-4597-a585-9356f32b63a7
I'm too old to type UUIDs except by copy/paste or by completion,
and they make my head spin, so I try to use LABELs and PARTLABELs
wherever possible. It's always been a disappointment that Grub
can't write LABELs automatically in grub.cfg, so I have a little
script that translates the UUIDs into LABELs using the information
in /run/udev/data/b8:* (b259:* for my SSD). I have to rerun it
after kernel and Grub upgrades.
¹ I have a suspicion that the system is tardier about updating
the PARTLABEL symlinks than some of the others, after you
change them with the {f,g,sg}disk program. But it's only a
hunch: where it matters (ie the actual system disk), I reboot.
Cheers,
David.
Re: shame on me (was: Re: No fool like an old fool (debian installation probs))
DdB wrote: ... > I notice, that, even though i did change the name of the sda2 partition, > the PARTLABEl remained unchanged. > This proves my previous post wrong and i am sorry for the confusion, > this may have caused. You were correct all along. > DdB yes, but i also recall you saying something about zeroing a device and if you did that by accident to an entire device and not just a partition (that didn't have the boot/uefi stuff on it) then that would indeed clear any labels. so sometimes without a clear record of what has been done you do find yourself looking at a new device label and it's not fun to correct if all of your scripts and procedure are set up another way. songbird
shame on me (was: Re: No fool like an old fool (debian installation probs))
Am 02.05.2023 um 05:50 schrieb David Wright: > On Tue 02 May 2023 at 02:21:20 (+0200), DdB wrote: >> Am 01.05.2023 um 21:38 schrieb David Wright: >>> And PARTLABELs aren't interfered with even by the installer. >> >> This at least i can contradict for a fact. > > So is this post the rebuttal, or are you posting the evidence elsewhere? > >> VM is functional with known >> and documented partlabels, then the installer handles partitions >> (reformat is permitted) and the UUID's AND the PARTUUIDS were changed, >> which was a huge surprise. I cannot recall, how my impression was formed, as i did more than a dozen trial installations in the last 3 days, not all of which i kept. But a recent verification proves me wrong: from original host: > sudo blkid | grep nvm > /dev/nvme0n1p1: UUID="F497-DC20" TYPE="vfat" PARTLABEL="EFISYS" > PARTUUID="1b3d99f5-b568-4445-8a09-854bb0ed1583" > /dev/nvme0n1p2: UUID="1a4db22f-65e4-476a-b7e3-8f9f91cf0b8b" TYPE="ext4" > PARTLABEL="buster-main" PARTUUID="69941f2a-6d75-4662-b6ae-3e98425ff463" > /dev/nvme0n1p3: UUID="ec317602-8175-46b1-bced-7be335f59a01" TYPE="ext4" > PARTLABEL="SOS" PARTUUID="5f04ff28-c5e4-47c4-b9a5-c4820bb01f6a" > /dev/nvme0n1p4: LABEL="bpool" UUID="9675743913905685606" > UUID_SUB="6515248399914718640" TYPE="zfs_member" PARTLABEL="bpool" > PARTUUID="c391b3ac-4460-4dd6-92e7-3ff8def7b07b" > /dev/nvme0n1p5: LABEL="rpool" UUID="2471356229651970105" > UUID_SUB="13336611508289702781" TYPE="zfs_member" PARTLABEL="rpool" > PARTUUID="de2e5e4e-382c-4c5b-b2fd-60fcc2a71229" > /dev/nvme0n1p6: UUID="dd0919fe-8575-483c-b90a-20c7ff65e43a" TYPE="swap" > PARTLABEL="swap" PARTUUID="da10bfac-a3e4-4847-a53f-7d0547801b91" > /dev/nvme0n1: PTUUID="9c76aed7-574b-48b6-9309-62d74e5303cb" PTTYPE="gpt" from the simulating vm (ancient snapshot): > sudo blkid | grep sda > /dev/sda1: UUID="F497-DC20" TYPE="vfat" PARTLABEL="EFISYS" > PARTUUID="1b3d99f5-b568-4445-8a09-854bb0ed1583" > /dev/sda2: UUID="1a4db22f-65e4-476a-b7e3-8f9f91cf0b8b" TYPE="ext4" > PARTLABEL="buster-main" PARTUUID="69941f2a-6d75-4662-b6ae-3e98425ff463" > /dev/sda3: UUID="b9548515-9271-4d3f-91f0-d06b47375107" TYPE="ext4" > PARTLABEL="SOS" PARTUUID="5f04ff28-c5e4-47c4-b9a5-c4820bb01f6a" > /dev/sda4: PARTLABEL="bpool" PARTUUID="c391b3ac-4460-4dd6-92e7-3ff8def7b07b" > /dev/sda5: PARTLABEL="rpool" PARTUUID="de2e5e4e-382c-4c5b-b2fd-60fcc2a71229" > /dev/sda6: UUID="1fcd07ac-9764-4970-99dd-5d133b95ec67" TYPE="swap" > PARTLABEL="swap" PARTUUID="da10bfac-a3e4-4847-a53f-7d0547801b91" from the current vm (with bullseye in it): > /dev/sda1: UUID="F497-DC20" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFISYS" > PARTUUID="1b3d99f5-b568-4445-8a09-854bb0ed1583" > /dev/sda2: UUID="017cf209-aff6-45ec-a45e-bd293a34c49c" BLOCK_SIZE="4096" > TYPE="ext4" PARTLABEL="buster-main" > PARTUUID="69941f2a-6d75-4662-b6ae-3e98425ff463" > /dev/sda3: UUID="b9548515-9271-4d3f-91f0-d06b47375107" BLOCK_SIZE="4096" > TYPE="ext4" PARTLABEL="SOS" PARTUUID="5f04ff28-c5e4-47c4-b9a5-c4820bb01f6a" > /dev/sda4: PARTLABEL="bpool" PARTUUID="c391b3ac-4460-4dd6-92e7-3ff8def7b07b" > /dev/sda5: PARTLABEL="rpool" PARTUUID="de2e5e4e-382c-4c5b-b2fd-60fcc2a71229" > /dev/sda6: UUID="a2739581-96b5-45e6-91a0-d63695b61770" TYPE="swap" > PARTLABEL="swap" PARTUUID="da10bfac-a3e4-4847-a53f-7d0547801b91" I notice, that, even though i did change the name of the sda2 partition, the PARTLABEl remained unchanged. This proves my previous post wrong and i am sorry for the confusion, this may have caused. You were correct all along. DdB
Re: No fool like an old fool (debian installation probs)
On 5/1/23 17:13, DdB wrote: Am 01.05.2023 um 19:46 schrieb David Christensen: Reading the above plus your previous post "Looking for inspiration/advice/best practices on system upgrade", it seems that you are making things too complicated. I would pick one machine, disable/ disconnect/ uninstall all of the drives except optical, install a zeroed 2.5" SATA SSD, make a decision regarding BIOS/MBR (legacy) vs. UEFI/GPT, run the Setup utility and configure CMOS/NVRAM settings accordingly, boot the Debian installer, pick "Install", partition the SSD manually with a 1 GB ESP (if doing EUFI/GPT), a 1 GB boot partition (ext4), 1 GB or larger swap partition, and a 12 GB root partition (ext4), at the "Choose software" page select "SSH server", select "standard system utilities", and deselect everything else. After reboot, you should have a working Debian instance. I am sorry, i do not really understand, what you want to point to. Your suggestions are coming without even knowing, what my needs and options are, and involve alternatives that look unnecessary in my view. Just to give you an idea: my OS partitions are 20 GB and that seems to be a little too small, i had to delete stuff in order to keep the systems in good shape. I did abandon MBR years ago, and look with some bemusement at the many places, whare that old technology still lingers. Physical un-/plugging at the machines always involves getting external help, due to a handicap. Maybe your feeling is correct and i am in fact complicating things, i don't know. OTOH, i am dealing with 2 dozen disks, server grade HW, DUAL-CPU EPYC, 128 GB ECC RAM, nvme-ssd, aso. My understanding is, that precautions are in order to keep the system(s) up and running and useable for someoone, who is bad at typing. I have installed many debian VM's before, all of them with a desktop, and many of them are in use while i am investigating, how to replace/upgrade the host OS. Do you get the idea? But thanks for voicing your concerns, somthing i am trying to understand and consider. Just keep in mind, that if a problem arises, i might not be able too deal with, i will be cut off from everything, no paper based calendar even exists. So i am careful. DdB It seems like you are trying to solve several issues at the same time: 1. How to install Debian onto a computer. 2. How to upgrade a Debian 10 computer to Debian 11 when that computer supports a multitude of applications, services, and data. Solving #2 is predicated upon solving #1. I wanted to help you solve #1, so that you would be able to solve #2 -- e.g. by providing a destination for you to move applications, services, and data off the Debian 10 computer. As for your needs and options, we can only respond to the information that you provide. If a suggestion looks unnecessary, it is reasonable to ask "why?". What suggestion of mine do you find unnecessary? Choosing the size for a given partition/ volume/ file system has always been a non-trivial problem. My 12 GB root solution works for my use-cases. If a 20 GB root file system has been too small for you, then of course you can substitute a larger number into my suggestion. Another option would be to use LVM and resize as required. Thank you for letting us know that our suggestions should avoid hardware modification. In my previous post, please interpret "disable/ disconnect/ uninstall all of the drives except optical" to mean "use the Setup utility to disable all of the drives except optical". Thank you for letting us know what hardware components you have. For purposes of this thread, it is simplest to address one computer at a time. Please tell us what components it is built from, the role(s) of the computer in question, and what users/ applications/ services/ data it supports. What is "aso"? (Automated System Operations?) Regarding "precautions are in order to keep the system(s) up and running and useable for someoone, who is bad at typing", one definition of "project management" is: a. Identify where you are at. b. Identify where you want to be. c. Make a plan that takes you from (a) to (b). Plan testing prior to execution, continuity of service during plan execution (or known outage windows), validation afterwards, and rollback are desirable features of a project plan, but achieving them for a large and complex project is difficult. An obvious strategy is to decompose the scope of work into smaller projects, each requiring smaller and simpler plans. I suggest that your first priority should be making a disaster plan for "if a problem arises, i might not be able too deal with, i will be cut off from everything". A laptop, a portable USB install of Debian, and good backups come to mind. David
Re: No fool like an old fool (debian installation probs)
On Tue 02 May 2023 at 02:21:20 (+0200), DdB wrote: > Am 01.05.2023 um 21:38 schrieb David Wright: > > And PARTLABELs aren't interfered with even by the installer. > > This at least i can contradict for a fact. So is this post the rebuttal, or are you posting the evidence elsewhere? > VM is functional with known > and documented partlabels, then the installer handles partitions > (reformat is permitted) and the UUID's AND the PARTUUIDS were changed, > which was a huge surprise. OK, just so that it's clear, you have a disk with documented PARTLABELs, and after installing an OS with the d-i, the UUIDs and PARTUUIDs have been altered. You /seem/ to then be saying that /this/ is evidence that the PARTLABELs have been altered. Is that your contradiction? If the PARTUUIDs are altered, it would be interesting to know what you are doing in the partitioner step of the d-i. Your posts have only mentioned reformatting partitions, not repartitioning disks. > Just knowing about this, i can deal with the situation, but i think, > this is based on a false understanding of how a persistent > identification should be dealt with. Cheers, David.
Re: No fool like an old fool (debian installation probs)
Am 01.05.2023 um 21:38 schrieb David Wright: > And PARTLABELs aren't interfered with even by the installer. This at least i can contradict for a fact. VM is functional with known and documented partlabels, then the installer handles partitions (reformat is permitted) and the UUID's AND the PARTUUIDS were changed, which was a huge surprise. Just knowing about this, i can deal with the situation, but i think, this is based on a false understanding of how a persistent identification should be dealt with. my 2 cents DdB
Re: No fool like an old fool (debian installation probs)
Am 01.05.2023 um 19:46 schrieb David Christensen: > Reading the above plus your previous post "Looking for > inspiration/advice/best practices on system upgrade", it seems that you > are making things too complicated. > > > I would pick one machine, disable/ disconnect/ uninstall all of the > drives except optical, install a zeroed 2.5" SATA SSD, make a decision > regarding BIOS/MBR (legacy) vs. UEFI/GPT, run the Setup utility and > configure CMOS/NVRAM settings accordingly, boot the Debian installer, > pick "Install", partition the SSD manually with a 1 GB ESP (if doing > EUFI/GPT), a 1 GB boot partition (ext4), 1 GB or larger swap partition, > and a 12 GB root partition (ext4), at the "Choose software" page select > "SSH server", select "standard system utilities", and deselect > everything else. After reboot, you should have a working Debian instance. I am sorry, i do not really understand, what you want to point to. Your suggestions are coming without even knowing, what my needs and options are, and involve alternatives that look unnecessary in my view. Just to give you an idea: my OS partitions are 20 GB and that seems to be a little too small, i had to delete stuff in order to keep the systems in good shape. I did abandon MBR years ago, and look with some bemusement at the many places, whare that old technology still lingers. Physical un-/plugging at the machines always involves getting external help, due to a handicap. Maybe your feeling is correct and i am in fact complicating things, i don't know. OTOH, i am dealing with 2 dozen disks, server grade HW, DUAL-CPU EPYC, 128 GB ECC RAM, nvme-ssd, aso. My understanding is, that precautions are in order to keep the system(s) up and running and useable for someoone, who is bad at typing. I have installed many debian VM's before, all of them with a desktop, and many of them are in use while i am investigating, how to replace/upgrade the host OS. Do you get the idea? But thanks for voicing your concerns, somthing i am trying to understand and consider. Just keep in mind, that if a problem arises, i might not be able too deal with, i will be cut off from everything, no paper based calendar even exists. So i am careful. DdB
Re: No fool like an old fool (debian installation probs)
Am 01.05.2023 um 10:33 schrieb Michel Verdier:
> Le 1 mai 2023 DdB a écrit :
>
>> Any suggestions/questions/hints from the power-users in here?
>> ... would be wildly appreciated ...
>
> When installing you have to stop on your first problem. The others could
> be created from it. It's longer but easier to cope with. So give us full
> details on your first problem or choice you don't understand.
>
>
Thank you for being this clear.
In the meantime i changed my plan somewhat (as stated earlier, i am now
willing to defer the resolution of the PARTUUID topic till later, in
order to see, if the upgraded GNOME will be able to serve me well, just
as the buster one did). Also, i wanted to be certain, that i will be
able to deal with the zfs upgrade.
Today, i found, that GNOME extensions are causing quite a bit of
trouble. The cause being, that the one extension, i have been using very
extensively ("Quick-Toggler") has been orphaned and is way out of sync
with current gnome-shell. That really hurts, as it had already been a
replacement for another extension, that had been orphaned in jessie
IIRC. - This is already the second time, that i have to find adjustments
in my workflow after an upgrade, due to changing functionality and lack
of compatibility. ... makes me somewhat unhappy, as i have been involved
quite a bit in software rollout processes and we cared very much for
(paying) customer satisfaction. Ofc, this could be different in a
project based on the workforce from volunteers.
But it got even worse:
The site extensions.gnome.org let me know, that it cannot sync
extensions with my gnome-shell, because of a version mismatch. So i read
up a bit to understand, what is going on, and found the most concice
description here: (1)
Funny little detail: Ubuntu is suffering way less, because their
distribution is based on more recent version than debian stable is.
At least i saw some guy posting a video on youtube showing, how he
upgraded gnome-shell to experimental thereby creating a frankendebian,
something, i thought was an absolute no-go!
So i could not resolve the issue (You need to update
gnome-browser-connector to at least version 42.0), because the version
from debian is something like 10.1 or so.
Once again, i am happy to just playing around, not touching the
workhorse, that is still on buster, until i find a safe way forward.
zfs seems to be working fine on bullseye, the dev from the Quick-Toggler
published, that he abandonned the software due to his switch to KDE a
few years back.
Now, i am considering, if i should investigate the other desktops before
making a decision?
(1)
https://bugs.launchpad.net/ubuntu/+source/chrome-gnome-shell/+bug/1983851
Very sad, that the upgrade turns out to be rather difficult for a human
being like me, that is more or less isolated in his basement with no
friends sharing the passion for computing, or debian - for that matter.
So this is my todays report. Confused and undecided, i will head over to
get some rest now.
Ofc, i am curious to learn, how the crowd of "standard users" is dealing
with gnome extensions atm.
Re: No fool like an old fool (debian installation probs)
On Mon 01 May 2023 at 13:08:56 (+0200), DdB wrote: > One explanation of my choice to stick with PARTUUID's: > In my overall stategy of using my computer, i am sometimes copying (dd) > whole partitions into a backup, a secondary partition or a VM, which can > easily lead to difficulties, if the same LABELS were used, which can be > changed, but reside INSIDE the partition itself, whereas PARTUUID's > reside in the GPT, which is not affected on partition copy operations. PARTLABELs also reside in the GPT. > Thus my choice was related to convenience, avoiding some adjustments > after partition copy operations. Only the installer interferes with the > so called "persistent" PARTUUID's, which i regard as being offensive (or > ignorant - for that matter). And PARTLABELs aren't interfered with even by the installer. > I am going to fix that later (on my machine), returning to my preferred > fstab format of using PARTUUID whereever appropriate. Your choice, of course. This post is just FTR. Cheers, David.
Re: No fool like an old fool (debian installation probs)
On 4/30/23 18:11, DdB wrote: Hello list, after receiving so much good advice, i finally made up my mind and began playing through the installation (debian bullseye, current stable) in my simulation-VM in order to learn about the pitfalls to avoid. After more than a dozen tries, i am running out of fuel, because i am continuously running into problems, that i would have preferred to circumvent. At first, i picked a debian (debian-11.6.0-amd64-DVD-1.iso), as the 11.7 release was not yet out), and installed from there, choosing the Expert Install. The main reason was, that i was expecting to be invited into customizing the system picking software to install by hand. But at first, i ran into a multitude of problems with the partitioning tool, even though the system was already properly configured (GPT + EFISYS + OS + Swap + several other partitions booting in UEFI style). For example, when i allow the use of the swap partition, it gets reformatted and another PARTUUID is assigned to it, leading to failures booting other systems from that disk. OTOH Disallowing its use for the time being leads to install failures due to the 4GB of RAM apparently not being enough for that VM. Another problem, similar but distinctly different happens around the OS partition. Whenever i gave it to the installer, it reformatted it while changing the PARTUUID, again leading to failures in the boot process of the other partitions... Until i discovered this workaround: Assign the partition to ext4 and the mountpoint / but not allowing to delete its content (as that would induce the reformatting). Instead, after finishing partitioning, i asked for a shell and from there manually deleted ONLY THE DATA from the partition(s) used. Then installation progressed further. BTW: Apparently, this was the only way to keep the PARTUUID, as deleting the data by overwriting with zeroes lead to the installer overwriting the fs structures making another mke2fs necessary. But the worst of all, was the software selection: Even though i asked for debconf priority low, i got only a few checkboxes to pick from. And choosing GNOME did automatically install software i neither need nor want. But omitting GNOME from the list lead to a system failing to boot with tons of messages stating the absense of all kind of gnome parts. So, just in order to make some progress, i had to willingly and temporarily kill the bootability of other partitions in order to have the install terminate without failures. At that point, i decided to try the netinstall, as it is now available with release 11.7 and i did expect there to be more choices. And when even that one failed to boot without GNOME, i even did check the sha512sum to make sure, i was using the proper one. - I did! Now, i am confused. Many years ago, the expert installer was very difficult to use and did provide very many choices (and liberties to spoil the fun). Now, i dont seem to be able at coming to the stage, where i can seriously test more complicated things (like multi-boot, zfs, and other things) that make up my current host in its buster version. It is quite obvious, that i am lacking SOME kind of understanding, because what i am trying to accomplish should really be quite easy, but i am only experiencing troubles. Oh, as a side note: As a nicety of my setup, i can use bash scripts, that work well from my main OS, or from the simulation VM which can be used to test functionality before it is rolled out to the host. That is why, i am relying/insisting on absolutely identical PARTUUIDs inside that VM. Now, i am really curious as to how to get to a proper system without having to go through the baby-steps beginning with debootstrap, and all the millions of configuration steps, that i did not even bother to list. I am really interested to understand, in which way i am creating all those problems for myself. Could it be related to the fact, that i am accessing the net fom a VPN? - I don't think so. Any suggestions/questions/hints from the power-users in here? ... would be wildly appreciated ... DdB On 5/1/23 04:08, DdB wrote: > Am 01.05.2023 um 10:23 schrieb Michel Verdier: >> To install without gnome I select the task ssh server then after I >> manually select what I want, and a WM if needed. >> >> > Thank you for encouraging me. A good night sleep did help as well. > Following your advice, i retried a fresh install. This time round, i did > permit the reformatting of everything, and just noted a new todo to > resolve that later. But ... > > The install succeeded, an sshd is running ON a machine with GNOME and > all its (un-) pleasant surprises like: firefox, openoffice, and much > more. But i know for sure, that i deselected it and only left Desktop + > ssh server. I guess, that means, that the installer chose gnome as its > preferred desktop. > > Ok, i will go on from here, as i certainly want a DE + GNOME, only the > standard tools, i wouldnt have all of them. > > ==
Re: No fool like an old fool (debian installation probs)
On Mon, May 01, 2023 at 01:08:56PM +0200, DdB wrote: > Am 01.05.2023 um 10:23 schrieb Michel Verdier: > > Le 1 mai 2023 DdB a écrit : > > > >> But omitting GNOME from the list lead to a system failing to boot with > >> tons of messages stating the absense of all kind of gnome parts. > > > > To install without gnome I select the task ssh server then after I > > manually select what I want, and a WM if needed. I believe Michel actually means "I deselect all of the Debian Desktop type stuff, and then select ssh server". > Thank you for encouraging me. A good night sleep did help as well. > Following your advice, i retried a fresh install. This time round, i did > permit the reformatting of everything, and just noted a new todo to > resolve that later. But ... > > The install succeeded, an sshd is running ON a machine with GNOME and > all its (un-) pleasant surprises like: firefox, openoffice, and much > more. But i know for sure, that i deselected it and only left Desktop + > ssh server. I guess, that means, that the installer chose gnome as its > preferred desktop. If you leave "Debian Desktop" selected, the installer chooses a Desktop Environment for you. And guess which one it chooses by default? That's right: GNOME. Assuming you're using a standard installer image, and not one that has a DE in its name. I have no idea why this confusing default auto-selection exists, but it does.
Re: No fool like an old fool (debian installation probs)
Le 1 mai 2023 DdB a écrit : > Any suggestions/questions/hints from the power-users in here? > ... would be wildly appreciated ... When installing you have to stop on your first problem. The others could be created from it. It's longer but easier to cope with. So give us full details on your first problem or choice you don't understand.
Re: No fool like an old fool (debian installation probs)
Le 1 mai 2023 DdB a écrit : > But omitting GNOME from the list lead to a system failing to boot with > tons of messages stating the absense of all kind of gnome parts. To install without gnome I select the task ssh server then after I manually select what I want, and a WM if needed.
Re: No fool like an old fool (debian installation probs)
On Mon 01 May 2023 at 03:11:56 (+0200), DdB wrote: > For example, when i allow the use of the swap partition, it gets > reformatted and another PARTUUID is assigned to it, leading to failures > booting other systems from that disk. The easy way to avoid that problem is to use LABEL rather than (PART)UUID, because any time after the partitioner has run, while it's installing more of the system, you can reset the LABEL back to how you had it. # /target/sbin/swaplabel -L whatever /dev/sdXn You can set the LABEL for the new system at leisure, because the UUID that the installer used will still be working. (I parenthesised (PART)UUID because I thought the installer set and used UUIDs, not PARTUUIDs; but honestly, I might not notice if any PARTUUIDs got reset: I only use LABELs and PARTLABELs myself.) > OTOH Disallowing its use for the > time being leads to install failures due to the 4GB of RAM apparently > not being enough for that VM. I can install bullseye and bookworm-RC1 standard software (no DE) on an i386 laptop with ½GB memory using no swap, so that surprises me. > Another problem, similar but distinctly different happens around the OS > partition. Whenever i gave it to the installer, it reformatted it while > changing the PARTUUID, again leading to failures in the boot process of > the other partitions... Until i discovered this workaround: Assign the > partition to ext4 and the mountpoint / but not allowing to delete its > content (as that would induce the reformatting). Instead, after > finishing partitioning, i asked for a shell and from there manually > deleted ONLY THE DATA from the partition(s) used. Then installation > progressed further. I presume your setupp (with VMs etc) is much more complex that my own, so I can't understand why the booting process of one partition would be affected by not identifying a different system on the same machine… > BTW: Apparently, this was the only way to keep the PARTUUID, as deleting > the data by overwriting with zeroes lead to the installer overwriting > the fs structures making another mke2fs necessary. … and I don't know which data you would be zeroing. > But the worst of all, was the software selection: Even though i asked > for debconf priority low, i got only a few checkboxes to pick from. And > choosing GNOME did automatically install software i neither need nor want. > > But omitting GNOME from the list lead to a system failing to boot with > tons of messages stating the absense of all kind of gnome parts. > > So, just in order to make some progress, i had to willingly and > temporarily kill the bootability of other partitions in order to have > the install terminate without failures. > > At that point, i decided to try the netinstall, as it is now available > with release 11.7 and i did expect there to be more choices. And when > even that one failed to boot without GNOME, i even did check the > sha512sum to make sure, i was using the proper one. - I did! Yes, sorry, I don't use DEs. You might be able to find discussions in the past list archives about what's installed when you select Debian desktop environment without any DE from the list below. > Now, i am confused. Many years ago, the expert installer was very > difficult to use and did provide very many choices (and liberties to > spoil the fun). Now, i dont seem to be able at coming to the stage, > where i can seriously test more complicated things (like multi-boot, > zfs, and other things) that make up my current host in its buster version. That sounds as if you're harking back to the days when part two of installation was running dselect after a reboot. That was tedious. Since etch, it's been very much more straightforward. > It is quite obvious, that i am lacking SOME kind of understanding, > because what i am trying to accomplish should really be quite easy, but > i am only experiencing troubles. I think you might have to explain more about the overall configuration of your systems: I find it difficult to see how these booting processes interact with one another. I have PCs with up to three systems on them (buster/bullseye/bookworm), sharing /home and swap (and obviously ESP), but they depend on each other beyond the fact that each will mount the others' root filesystems (readonly) as a convenience. > Oh, as a side note: As a nicety of my setup, i can use bash scripts, > that work well from my main OS, or from the simulation VM which can be > used to test functionality before it is rolled out to the host. That is > why, i am relying/insisting on absolutely identical PARTUUIDs inside > that VM. (PART)LABELs instead? > Now, i am really curious as to how to get to a proper system without > having to go through the baby-steps beginning with debootstrap, and all > the millions of configuration steps, that i did not even bother to list. > > I am really interested to understand, in which way i am creating all > those problems for myself. Could it be related to the
