Etiona things my Flidas is the development version

Are you actually running Trisquel 8? The following command can tell:
$ lsb_release -d

Seems that I am:
Trisquel GNU/Linux 8.0, Flidas

That said, there is Belenos running on another partition on the same HDD.

That one replies:
Trisquel GNU/Linux 7.0, Belenos

But it's suffering deficiencies of its own ...

Flidas is functioning well for me; is it possible to execute the following modified script instead ?
sudo sed -i 's/belenos/etiona/' /etc/apt/sources.list && sudo apt update && sudo apt full-upgrade

There's an extra comma which appears to assign homework in your post ...

While waiting for your helpful reply, I've been puzzling abou ppa-purge.

I tried this command:
sudo ppa-purge ppa us.archive.trisquel.info/trisquel

To which ppa-purge replies:
Updating packages lists
PPA to be removed: ppa ppa
Warning: Could not find package list for PPA: ppa ppa

Local research in the grub menu reveals two alternative packages to start:
Linux-Libre 3.13.0-165-lowlatency
and
Linux-Libre 3.13.0-33-lowlatency

But I couldn't locate them.

A couple of lifetimes ago, we regularly purged old packages when our HDD's became full,
but this octogenarian cannot remember where they were.

Thank you. I searched the forum's archives for some time but so many folks know
what a PPA is that they never had to tell the outsiders. I've had my nose buried
in text processing for over three years now.

Here's what seems to be the appropriate intermediate step:
sudo sed -i 's/belenos/flidas/' /etc/apt/sources.list && sudo apt update && sudo apt full-upgrade

Good thing; I ran that command, which produced a great commotion for a couple of hours as seemingly
everything was getting changed ...

I noticed a few complaints:
"etc/ImageMagick could not be removed ... not empty" ... much later it did get emptied,

"etc/console-setup could not be removed ... not empty ... You betcha it wasn't empty:

/etc/console-setup$ ls
cached.kmap.gz <== highlighted in red compose.GEORGIAN-PS.inc compose.ISO-8859-13.inc.dpkg-new compose.ISO-8859-3.inc compose.ISO-8859-8.inc.dpkg-new remap.inc compose.ARMSCII-8.inc compose.GEORGIAN-PS.inc.dpkg-new compose.ISO-8859-14.inc compose.ISO-8859-3.inc.dpkg-new compose.ISO-8859-9.inc remap.inc.dpkg-new compose.ARMSCII-8.inc.dpkg-new compose.IBM1133.inc compose.ISO-8859-14.inc.dpkg-new compose.ISO-8859-4.inc compose.ISO-8859-9.inc.dpkg-new Uni2-Fixed16.psf compose.CP1251.inc compose.IBM1133.inc.dpkg-new compose.ISO-8859-15.inc compose.ISO-8859-4.inc.dpkg-new compose.KOI8-R.inc vtrgb
compose.CP1251.inc.dpkg-new compose.ISIRI-3342.inc compose.ISO-8859-15.inc.dpkg-new compose.ISO-8859-5.inc compose.KOI8-R.inc.dpkg-new vtrgb.dpkg-new compose.CP1255.inc compose.ISIRI-3342.inc.dpkg-new compose.ISO-8859-16.inc compose.ISO-8859-5.inc.dpkg-new compose.KOI8-U.inc vtrgb.vga compose.CP1255.inc.dpkg-new compose.ISO-8859-10.inc compose.ISO-8859-16.inc.dpkg-new compose.ISO-8859-6.inc compose.KOI8-U.inc.dpkg-new vtrgb.vga.dpkg-new compose.CP1256.inc compose.ISO-8859-10.inc.dpkg-new compose.ISO-8859-1.inc compose.ISO-8859-6.inc.dpkg-new compose.TIS-620.inc
compose.CP1256.inc.dpkg-new compose.ISO-8859-11.inc compose.ISO-8859-1.inc.dpkg-new compose.ISO-8859-7.inc compose.TIS-620.inc.dpkg-new compose.GEORGIAN-ACADEMY.inc compose.ISO-8859-11.inc.dpkg-new compose.ISO-8859-2.inc
compose.ISO-8859-7.inc.dpkg-new compose.VISCII.inc compose.GEORGIAN-ACADEMY.inc.dpkg-new compose.ISO-8859-13.inc compose.ISO-8859-2.inc.dpkg-new compose.ISO-8859-8.inc compose.VISCII.inc.dpkg-new

Later, it still wasn't empty:

/etc/console-setup$ ls
cached.kmap.gz <== red compose.CP1256.inc compose.ISIRI-3342.inc compose.ISO-8859-14.inc compose.ISO-8859-2.inc compose.ISO-8859-6.inc compose.KOI8-R.inc remap.inc vtrgb.vga compose.ARMSCII-8.inc compose.GEORGIAN-ACADEMY.inc compose.ISO-8859-10.inc compose.ISO-8859-15.inc compose.ISO-8859-3.inc compose.ISO-8859-7.inc compose.KOI8-U.inc Uni2-Fixed16.psf compose.CP1251.inc compose.GEORGIAN-PS.inc compose.ISO-8859-11.inc compose.ISO-8859-16.inc compose.ISO-8859-4.inc compose.ISO-8859-8.inc compose.TIS-620.inc Uni2-Fixed16.psf.gz <== red
compose.CP1255.inc compose.IBM1133.inc compose.ISO-8859-13.inc compose.ISO-8859-1.inc compose.ISO-8859-5.inc compose.ISO-8859-9.inc compose.VISCII.inc vtrgb

Those two files that are highlighted in red look ominous ...

I ran sudo apt-get autoremove ==> which produced the following response:

Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt-get -f install' to correct these.
The following packages have unmet dependencies:
indicator-applet : Depends: libpanel-applet-4-0 (>= 3.2.1) but it is not installable
kubuntu-debug-installer : Depends: libqapt2 (>= 1.9.60) but it is not installable
E: Unmet dependencies. Try using -f.

So I dutifully ran sudo apt-get -f install which produced another great flurry of activity,
seemingly repeating a lot of actions previously performed, but this time with little fuss.

After all was said & done, I attempted a Software-Updater run, only to be met with the
complaint that no software sources are available. That's where it now stands: flidas is
"sort of" installed, but the login screen is goofy and impossible to read while entering
my P/W ... eventually accepted. Shut down is unresponsive, and the bottom tray is absent.

We'll see. This is coming to you from the other flidas installation on the same laptop.

...

Update. All the intended new flidas stuff is still belenos and completely broken. Would
I be better off to reformat that 20GB partition ? It's the "other one" that's not
flagged as a boot partition in GParted. They're both on the same hard drive, but I've
determined which one with this:
/media/george/c968ef7e-9665-4ac3-ab35-4cdb8daf1475/etc/console-setup <== this is where I put
the red-flag-marked data; since moved to the Data drive.

MB inquired, constructively: What is the content of your /etc/apt/sources.list?

#deb cdrom:[Trisquel 7.0 _flidas_ - Release amd64 (20141102)]/ belenos main
# Trisquel repositories for supported software and updates
deb http://us.archive.trisquel.info/trisquel/ flidas main
deb-src http://us.archive.trisquel.info/trisquel/ flidas main
deb http://us.archive.trisquel.info/trisquel/ flidas-security main
deb-src http://us.archive.trisquel.info/trisquel/ flidas-security main
deb http://us.archive.trisquel.info/trisquel/ flidas-updates main
deb-src http://us.archive.trisquel.info/trisquel/ flidas-updates main
#deb http://us.archive.trisquel.info/trisquel/ flidas-backports main
#deb-src http://us.archive.trisquel.info/trisquel/ flidas-backports main

The present flidas trisquel installation on which I'm writing this uses:

# deb cdrom:[Trisquel 7.0 _belenos_ - Release amd64 (20141102)]/ belenos main
# Trisquel repositories for supported software and updates
deb https://mirror.fsf.org/trisquel/ flidas main
deb-src https://mirror.fsf.org/trisquel/ flidas main
deb https://mirror.fsf.org/trisquel/ flidas-security main
deb-src https://mirror.fsf.org/trisquel/ flidas-security main
deb https://mirror.fsf.org/trisquel/ flidas-updates main
deb-src https://mirror.fsf.org/trisquel/ flidas-updates main
# deb http://es.archive.trisquel.info/trisquel/ belenos-backports main
# deb-src http://es.archive.trisquel.info/trisquel/ belenos-backports main
# deb http://oldarchive.trisquel.info/trisquel [version with Kompozer] main

It would appear that so long as I'm careful, I can edit the former sources.list
(top) to reflect the updated repositories in the latter sources.list (bottom).

MB also cautioned: And, of course, you want to backup your data.

There is a /home folder on that partition, and I've already moved its contents
to my Data partition, which the etiona/DVD installer ought not touch ... right?

Way back when, I used to install trisquel from a flash drive, but if I have to
re-learn a from-the-ground-floor-up procedure, it might as well be from a DVD,
I guess ...

There's no CDROM drive on this computer, so I'm attempting an intermediate install of flidas over the present
belenos which resides on /dev/sda3.

I'm using a thumb drive which is all set to install trisquel 8 (belenos) but I need to know when, during that
process, the installer gives me the option of chosing into which partition the new OS is to go.

If left to my own devices, I'd reformat that partition to the present ext4 with GParted first, so the installer
will spot that as the most likely place and let me know with its own identification of the suitable place that
I will understand is really /dev/sda3.

MB will wonder why I didn't chose the DVD route ... I tried swapping this computer's extra 1 TB drive that is
in the CDROM slot, making the DVD on a different computer, and putting that computer's CDROM drive in place
of the empty CDROM slot on this computer. I was then faced with more things to fix up, and that cloudied the
process too much. I did find out that GParted sees the 1 TB drive's partitions the same in computer A as in
computer B. That's encouraging, not like watching the news on different TV channels.

More than five years ago, I was stumped by the installer's insistance that I set the / root
partition and that I do so from the partition menu:
https://trisquel.info/en/forum/how-can-i-make-master-boot-record-without-resorting-windows

When I initiate the "something else" process; I get to the stage where I set the device for boot
loader installation. Long ago I chose the equivalent of /dev/sda but that wasn't correct then.

I now chose /dev/sda3 because that's where the former belenos operating system was, and now it is
to be flidas. I need a clean install of flidas before going on to etiona. Installer still insists
that I use the partition menu to define the root system.

I don't have the slightest recollection what I did to surmount this hurdle, and my minimal notes
from the period don't jog my aged memory.

I tried using GParted to define the /dev/sda3 partition as root, but that has no effect.

Please indulge me with a straight answer: How do I go about setting the root system in /dev/sda3 ?

MB declared:
At the partitioning step, you define a filesystem to be mounted at /, the
root of the file hierarchy, which is therefore mandatory.

I went back to GParted after reformatting /dev/sda3 and added the root designation,
but the installer doesn't recognize that when I choose /dev/sda3 as the partition
to which to install flidas.

That's not what I did in 2015, but I can't find a trace or hint as to what that was.

Reformatting the entire HDD is not an option; I didn't have to do that when I added
/dev/sda3 in 2015. I just made room in the data partition, I think.

MB reminded me: I was referring to the partitioning step of Trisquel's installer, after you
choose the "Something else" type of installation: everything can be done there.

More specifically:
1. If you have already used GParted to identify for certain the target partition by reformatting it,
you must choose to format it again while installing the trisquel upgrade; I was using the casper-
created thumb drive this morning.
2. Chose "Something else" (or all will be lost !).
3. Select the target partition from the menu at the bottom of the window ... mine was sda3.
4. Double-click the format ? button above the graphical image of the drive's partition structure.
5. Check the root (/) selection in the now-plain-as-day partition menu;
be sure that you are not asking the installer to change any other partitions.
6. Now you are off & running with the rest of the installation, but when you get to the keyboard-
selection page, be sure to let the installer select the keyboard ... it will keep asking you to
strike selected keys until that selection is correct.

In my case, I chose to put belenos back where it was before it got trashed by fumble fingers.

Now my target for etiona is the previously very shy belenos on the parasitic 1.0 TB drive that
resides on a caddy in what had been the CDROM drive slot. That'll make the caddy portable; it
uses the USB bus just like the external USB ports.

Just when I thought I was off to the races ... and after making sure that Software Updater is satisfied, I ran
sudo do-release-upgrade -d
to which the console replied:
Checking for a new Trisquel release
Please install all available updates for your release before upgrading.

So I re-booted, again checking that Software Updater is satisfied, and ran
sudo do-release-upgrade
with the same reply.

It looks as though I'll have to create a Trisquel_9.0 thumb drive, reformat the target partition (this time
sdb1) and repeat the no-longer-obscure steps outlined in my previous post.

This particular installation of flidas has not been troubled by defects like the original belenos was.

sudo apt-get update ==>
Hit:1 https://mirror.fsf.org/trisquel flidas InRelease
Hit:2 https://mirror.fsf.org/trisquel flidas-security InRelease
Hit:3 https://mirror.fsf.org/trisquel flidas-updates InRelease
Reading package lists... Done

sudo apt-get upgrade ==>
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
calendar-google-provider iceowl-extension
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.

I ran these two command immediately before
sudo do-release-upgrade
with & without the "-d" in my previous post.

Magic Banana is clairvoyant as usual ...
Since my previous posting I burned a trisquel_9 DVD, made a trisquel_9 flash drive from that
and attempted trisquel_9 installs at least three times, the last leaving me with an unbootable
laptop telling me:
error: symbol 'grub_calloc' not found ... Entering rescue mode ... grub rescue>
after which I reformatted the target partition /dev/sdb1 and reinstalled trisquel_8 from an old
flash drive to arrive at the perfect starting place for Magic Banana's immediately preceding suggestion.

Broken again ...
The suggested script was started:
sudo sed -i 's/flidas/etiona/' /etc/apt/sources.list && sudo apt update && sudo apt full-upgrade
But it froze the 'puter after about 450 steps ... no mouse ... no keyboard ... so I'm starting it again:
sudo sed -i 's/flidas/etiona/' /etc/apt/sources.list && sudo apt update && sudo apt full-upgrade

Magic Banana wondered:
I still do not understand why you do a fresh install of Trisquel 8 rather than Trisquel 9.

That was tried several times, even into a blank partition ... useless state afterwards every time.

Most recently,
sudo sed -i 's/flidas/etiona/' /etc/apt/sources.list && sudo apt update && sudo apt full-upgrade
which ran pretty well after restarting, but with abundant warnings, etc ...

After which the same old error appeared on bootup instead of the grub menu ==>
error: symbol 'grub_calloc' not found ... Entering rescue mode ... grub rescue>

This time I made use of the portability of that 1.0 TB drive residing on the caddy in the CDROM slot;
I pulled it out until the installation process is ready for prime time. Now I can boot up again,
albeit into flidas, not etiona.

Alas, all I can install etiona from is the flash drive; but that resulted in the same debacle.

The Trisquel_9 installation is on a hard drive in the removable caddy in the CDROM bay,
and it has to be removed prior to bootup before grub behaves normally. It appears that
I will have to hot plug the caddy in order to apply Magic Banana's fix to the bug.

Others facing this dilemma should check with the manufacturer of their computers before
attempting this enforced bypass of a mis-configured grub.

Magic Banana interjected:
There should be no need to fiddle with the hardware, as long as you can boot a live system.
Maybe that means my Trisquel_9 installation flash drive ...

The bug fix runs just about the same whether I run it after hot plugging the 1.0 TB drive containing
Trisquel_9 (presumably - haven't actually seen it yet ...) or after starting with the Trisquel_9
flash drive, but the end result is the same: grub starts in rescue mode:
error: symbol 'grub_calloc' not found ... Entering rescue mode ... grub rescue>

Does it matter that the 1.0 TB drive is a Seagate SSHD ? That's the one that hosed my attempt
to dual boot with trisquel & windows some years ago.

This particular Solid State hard drive is a hybrid: solid state for stable data and rotary disk
for the dynamic stuff. It was working fine with Trisquel_8.

Maybe it also matters that the Trisquel_8 installation on /dev/sda1 cannot be selected from
the grub menu; maybe my grub password has been changed ...

I think so ... Here's how they went into the terminal:
sudo mount /dev/sdb1 /mnt

sudo dpkg-reconfigure grub-pc
One-at-a-time, not as a multi-line script.

Here's the last step's output:
GRUB install devices:
[ ] /dev/sda (500107 MB; [redacted])
[ ] /dev/sdb (1000204 MB; [redacted])
[*] - /dev/sdb1 (39844 MB; /)

There's no option to modify this last screen; fortunately, it's what I intended it to be.

BTW; I checked and found that grub had a new password; I copied it and used it at the next grub screen;
that's how I was able to boot into Trisquel_8 in order to respond now. That password is in the
Trisquel_7 /etc/grub.d file. Changing it had no effect; it remained as before, but it works.

I tried changing:
sudo mount /dev/sdb1 /mnt to sudo mount /dev/sdb /mnt
Instant complaints ... no go.

I tried while the * was on the middle suggestion:
[ ] /dev/sda (500107 MB; HITACHI_[redacted])
[*] /dev/sdb (1000204 MB; ST1000LM014-[redacted)
[ ] - /dev/sdb1 (39844 MB; /)

The fourth command elicits this response:
The grub-pc package is being upgraded. This menu allows you to select which devices you'd like grub-install to be automatically run for, if any.
Running grub-install automatically is recommended in most situations, to prevent the installed GRUB core image from getting out of sync with GRUB modules or grub.cfg.
If you're unsure which drive is designated as boot drive by your BIOS, it is often a good idea to install GRUB to all of them. Note: it is possible to install GRUB to partition boot records as well, and some appropriate partitions are offered here.
However, this forces GRUB to use the blocklist mechanism, which makes it less reliable, and therefore is not recommended.

Could that be the root of our problem?

Last step:
│ [ ] /dev/sda (500107 MB; HITACHI_[redacted])
[ ] /dev/sdb (1000204 MB; [redacted])
[*] - /dev/sdb1 (39844 MB; /)

There seems to be nothing I know how to do to force that "*" from the third box to the second box and still select

I'll try your suggestion, just while the "*" is in the second box, but that closes the series.

Here's what comes last on the terminal:
Installation finished. No error reported.
Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.15.0-124-generic
Found initrd image: /boot/initrd.img-4.15.0-124-generic
Found linux image: /boot/vmlinuz-4.4.0-194-generic
Found initrd image: /boot/initrd.img-4.4.0-194-generic
Found linux image: /boot/vmlinuz-4.4.0-119-generic
Found initrd image: /boot/initrd.img-4.4.0-119-generic
WARNING: Not using lvmetad with older version.
Found Trisquel GNU/Linux 8.0, Flidas (8.0) on /dev/sda1
Found Trisquel GNU/Linux 7.0, Belenos (7.0) on /dev/sda3
done

No mention of Etiona (9.0) which ought to be on /dev/sdb1

Upon restarting, the customary reply ensues:
error: symbol 'grub_calloc' not found ... Entering rescue mode ... grub rescue>

What I'm having to do in order to do this testing is to turn the T420 off, pull out the hard drive caddy from the CDROM
slot, restart into a previous version of the flidas operating system (the others hang on bootup), and then hot plug the
hard drive caddy back into the CDROM bay. The first of the suggested commands then mounts it.

Maybe I have another laptop-size Serial ATA hard drive somewhere; it won't be another hybrid SSHD.

Here's my morning saga:
1. Used Gparted to make a new ex4 partition out of sdb1 and the adjacent swap partition. It's now a 38GB data partition.
That enabled the startup of the T420 without any hassles.
2. Dug up a portable hard drive (salvaged from a defunct laptop long ago) that had Trisquel_7 on it, used Software Updater's
upgrade feature to install Trisquel_8 more-or-less seamlessly, and the T420 seemed to function OK.
3. After a few reboots needed to correct minor glitches such as no system tray, additional updates, update-grub, etc. the
dreaded:
error: symbol 'grub_calloc' not found ... Entering rescue mode ... grub rescue>
appeared on the last fateful reboot. Culprit: That 1.0 GB hybrid SSHD drive with no operating system on it ! Its main
problem is that the SS portion remembers ... seemingly forever ... all the stuff one doesn't want to happen.

Alas, the Trisquel_8 operating system on the T420's main HDD has only one update of trisquel that works.
Here's the breakdown:
Linux-Libre 4.4.0-194-generic ==> stalls on bootup (we discussed that some time ago)
Linux-Libre 4.4.0-143-generic ==> Tries to boot up, but I gave up after a ten-minute wait.
Linux-Libre 4.4.0-119-generic ==> Starts OK, remembers the original wallpaper and other settings.

Here's the grub situation with that external, USB-connected HDD after running update-grub from the internal HDD with that USB
drive in mounted status:
4.4.0-194-low-latency ==> stalls on bootup, just like Linux-Libre 4.4.0-194-generic above
3.13..0-165-low-latency ==> Takes ~10 minutes to boot up, another ~2 minutes for the tray to appear

But that's without the SSHD in its caddy plugged into the CDROM slot, which I can put in later for purposes of storage,
but never again in place during bootup.

A replacement ITB HDD is now on order at modest cost ...