Siduction Forum

Hi! Thank you for your help!
$ ls -la /dev/disk/by-uuidShows NO old UUID

cat /etc/default/grub

returned VERY INTERESTING result

Just look at the very first line! How did the new UUID get there? It goes BEFORE the commented line "# If you change..." How did it get there?

f367fdb7-62c0-4ecf-83de-c645d598287c# If you change this file or any /etc/default/grub.d/*.cfg file,
# run 'update-grub' afterwards to update /boot/grub/grub.cfg.
# For full documentation of the options in these files, see:
#  info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR='siduction'
GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=f367fdb7-62c0-4ecf-83de-c645d598287c systemd.show_status=1"
GRUB_CMDLINE_LINUX=""

# If your computer has multiple operating systems installed, then you
# probably want to run os-prober. However, if your computer is a host
# for guest OSes installed via LVM or raw disk devices, running
# os-prober can cause damage to those guest OSes as it mounts
# filesystems to look for things.
#GRUB_DISABLE_OS_PROBER=false

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE/GOP/UGA
# you can see them in real GRUB with the command `videoinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

GRUB_DISABLE_SUBMENU=y
So I removed the UUID from the first line, and could smoothly update grub. So, update-grub works now.
Still cannot update initramfs.
update-initramfs: Generating /boot/initrd.img-7.1.4-1-siduction-amd64
cryptsetup: ERROR: Couldn't resolve device
    UUID=d0a9d5f0-05ea-4b68-b279-015c623e387f
The old UUID presents inside the /proc/cmdline
file as a RESUME parameter. The problem is how to update this file? Shall I switch to the root environment or how? Shall I somehow restart systemd?
I HAVE JUST MADE A GREAT DISCOVERY To update the cmdline we must to REBOOT the comp! So
1. the mdadm error disappeared
2. initramfs updated smoothly!
3. Tons of time and tunings were saved!
THANK YOU SO MUCH!
PS One problem still persists: WHEN do we get the honor to use Siduction 2026? :-)

@alexsid
Just to be sure: What's the output of

$ ls -la /dev/disk/by-uuidWe have to find the source of the d0a9d5f0-05ea-4b68-b279-015c623e387f UUID.

And in order to rule out hidden characters ("\r", etc.) in /etc/default/grub:
$ cat /etc/default/grub if that doesn't reveal too much personal information.

Quote from: NochEinNeuer on 2026/07/19, 20:50:56Oder sind die heutigen SSD so gut das man sich darüber keine Sorgen mehr machen muss das eine das zeitliche segnet?

Ich fange mal "hinten" an. Nein, du musst dir keine Sorgen machen, ganz wirklich nicht. Ich hatte mal einen Kollegen, von dem der Bruder hatte einen Bekannten, dessen Chef sein Neffe der hatte eine SSD, die ewig gehalten hat.


Ich hoffe, du liest weiter und hast die versteckte Botschaft begriffen. Heutige SSDs haben durchaus im normalen privaten Einsatz eine Lebensdauer von 5-10 oder mehr Jahren. Das hängt von etlichen Faktoren ab. Hier mal ein Artikel von SANDISK zu der Thematik. Bringt dir dieses Wissen bezüglich Datenverlust mehr Sicherheit? Ich verrate es dir: Nein! (aber bitte nicht weitersagen). Egal, wie hoch die Lebensdauerangaben und die Garantien seitens der Hersteller sind, sie basieren auf Wahrscheinlichkeiten. In der Praxis kannst du eine niegelnagelneue SSD einbauen, mit Daten befüllen und am nächsten Tag: ritsch-ratsch alle Daten weg, SSD defekt. So ist das halt mit Wahrscheinlichkeiten, zufälligen Prozessen etc.

Quote... Wenn sich das ganze auf zwei Platten aufteilt dann sinkt die Wahrscheinlichkeit auf 50% das es die mit /home betrifft.

Ganz so einfach ist es dann doch nicht. Die Wahrscheinlichkeit, dass es die zweite SSD erwischt, hilft dir hier nicht weiter. Angenommen, du hast zwei absolut identische SSDs, die du absolut identisch nutzt und beide haben eine Lebensdauer von genau je 5 Jahren. Dann werden (theoretisch) beide SSDs gleichzeitig nach genau 5 Jahren ausfallen. Nimmst du 3 SSDs, so tritt der Ausfall auch nach 5 Jahren ein. Alle SSDs altern und sterben unabhängig voneinander - jede stirbt für sich allein. Kann man nachlesen, zum Beispiel in Systemanalyse Band 2, 3. Auflage von 1974 von G. Wunsch und H. Schreiber (gibts gebraucht bei Amazon oder in meinem Bücherregal bei meiner Studienliteratur). In der Praxis ist das allerdings viel komplexer. Zum Beispiel gibt es auch mal externe "Einflüsse", die die Lebensdauer einer SSD bzw. aller SSDs spontan beenden können, wie ein Blitzeinschlag in der Umgebung und Überspannungen im Netz oder ein Erdbeben und das Haus plumpst auf den Rechner ... Kurz: Eine separate SSD für deine Heimat-Dateien bringt in der Praxis nichts.
Was kannst und/oder solltest du nun machen? Zunächst ist es keine gute Idee, wenn die SSD so langsam randvoll ist. Irgendwann sind auch die Reservezellen einer SSD aufgebraucht und dann gehts ans Eingemachte. Du wirst also kaum umhin kommen, Speicher freizugeben oder auf neue Speichermedien auszulagern. Ist natürlich aktuell nicht der perfekte Zeitpunkt für den Kauf von Speicher, egal welchen Typs. Das wir sich aber auch nicht kurzfristig ändern. Also entweder Pornosammlung löschen oder in den sauren Apfel beißen und eine neue SSD kaufen; alternativ kann auch eine gebrauchte Festplatte noch gute Dienste leisten. Für ein Datengrab mit der Fotosammlung, den gerippten CDs, der Rezeptsammlung, den Manuals, den 3D-Druckdateien, den Rechnungen und Anwaltsschreiben usf. muss man kein superschnelles Medium vorhalten.

Quote... Wie handhabt/ seht Ihr das?

Gegen Datenverlust hilft nur (mindestens) ein Backup. Ein Datenverlust kann dich nunmal immer und überall erwischen. Und bitte kein Backup auf einer SSD im selben Rechner! Ich hatte mal ein Mädel kennengelernt, die ihre Masterarbeit auf ihrem Notebook geschrieben hatte. Auf meinem Rat hin hat sie ihre Dateien mit den letzten Versionsständen auf einem externen Medium, hier einem USB-Stick, gesichert. Dieser kleine Knubbel blieb allerdings immer am Notebook angesteckt. Und es kam, wie es kommen musste: Das Notebook ging verlustig (das ist nochmal eine eigene Story) und Masterarbeit inkl. "Backup" waren damit weg, Termin zur Abgabe nicht haltbar usf.
Welche Daten, mit welcher Backup-Strategie, auf welchen Medien, an welchen Orten usw. du deine Daten sicherst, kannst letztlich nur du selbst entscheiden. Manche geben die Verantwortung und damit die Kontrolle an Cloud-Dienste ab. Ich selbst sichere auf altmodischen Festplatten im Raid-Verbund auf einem Synology-NAS. Wichtig sind doch nur die eigentlichen Daten (Fotos, Dokumente etc.), Konfigurationsdaten (auch /etc) und evtl. eine Liste der installierten Pakete. Backups kann man automatisieren, so dass auch langsame Speicher kein Problem sind; man muss ja nicht daneben sitzen bleiben.

Quote... Was zumindest anfangs ins Geld geht.

Da wirst du kaum drumherum kommen. Aber auch mal Festplatten aus vertrauenswürdiger Quelle ins Auge fassen (S.M.A.R.T. Daten prüfen).
   

Quote... Dagegen steht das man somit zwei Festplatten braucht.

Kein Problem, dass man mehrere Festplatten benötigt, Linux kann sogar mit drei Festplatten/SSDs umgehen; oder mit vier ....

edlin

I deleted
/etc/default/grub.ucf-dist and /etc/fstab.save

so now
sudo grep -r d0a9d5f0-05ea-4b68-b279-015c623e387f /etc/*
returns nothing.

The file
/etc/default/grub
contains the following line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=f367fdb7-62c0-4ecf-83de-c645d598287c systemd.show_status=1"
But sudo update-grub returns

/usr/sbin/grub-mkconfig: 1: /etc/default/grub: f367fdb7-62c0-4ecf-83de-c645d598287c#: not found
with the # at the end

I have no idea where that mark # emerged from

cat /etc/initramfs-tools/conf.d/resume

returns the right UUID

RESUME=UUID=f367fdb7-62c0-4ecf-83de-c645d598287c
sudo update-initramfs -u

returns the same old UUID

update-initramfs: Generating /boot/initrd.img-7.1.4-1-siduction-amd64
cryptsetup: ERROR: Couldn't resolve device
    UUID=d0a9d5f0-05ea-4b68-b279-015c623e387f
I HAVE NO ENCRYPTED DRIVES, Volumes etc!!!
Where to look for the error?

Yes, I can reinstall the system to get rid of all the errors at once, but on that route I would not aquire new knowledge. But I need help. Cannot find anything useful in the Internet.

Quote from: NochEinNeuer on 2026/07/19, 20:50:56...
Oder sind die heutigen SSD so gut das man sich darüber keine Sorgen mehr machen muss das eine das zeitliche segnet?
Bin mal auf Eure Meinungen gespannt.

Entschuldigung sie, bitte, für Englisch.

Modern SSD's do fail, and when they fail, it is like a light bulb failure. Instantly, and totally.

The speed of the SSD is wonderful -- install your complete operating system and software on the SSD, including all configurations. On a separate hard disk drive, or better, on a mirrored pair of hard disk drives, i.e. with BTRFS, make your data directories -- DOCS, MUSIC, IMAGES, VIDEOS, etc. Then, use symlinks to link these directories to the /home/user folder on the SSD.

With this method, you have all the speed of the SSD for working with your OS and software packages, and the security of all your data on the hard disk drives.

@Teriarch: I understand. I've generated such 'mock' packages myself from time to time.
So just my thanks to you. I've stored the package for anyone interested in it and/or maybe you can renew a short time download URL, when someone asks.

Quote from: Teriarch@unklarer
Happy now?

Perfekt!

@ro_sid

> I also experienced no error or problem in the running system.
Coincides with my observation on the ISO image (I don't use it elsewhere). 
> May be @towo can be 'persuaded' 😉 to put your package into the 'fixed' repo. [A Debian solution would be better, of course.]
That's a lot to ask for. The sidewalk solution works because version 3.11-1 will automagically get overwritten as soon as
Debian update  3.11-1 comes in without notice (because the remote system detects a signing violation issue with my
package and prioritizes its own version 3.11-1). If towo puts version 3.11-1 on his server, the package management
might prefer his copy over the Debian update.  On the other hand you cannot change the
version without additional 'Provides:' in the control file, since other packages might directly depend on that version.

Since the version change obviously has no impact, my guess is, they simply forgot. There is nothing special
about the included python scripts.

Quote from: NochEinNeuer on 2026/07/19, 20:50:56die wichtigen/ persönlichen Daten, also prinzipiell /home, auf eine eigene Platte zu speichern.

In deinem /home sind nicht nur die wichtigen persönlichen Daten (im Sinne produktiver Anwendungsdaten, auch etwas hochtrabend Dokumente genannt), sondern vor allem auch deine persönlichen Desktop- und Anwendungseinstellungen. Es ist schon sinnvoll, diese auf der schnellen SSD zu lassen. Wenn der Platz knapp wird, kannst du die reinen Produktivdaten auf eine HDD auslagern, klar.

Quote from: NochEinNeuer on 2026/07/19, 20:50:56Wenn alles auf einer Platte ist, und diese ist defekt dann ist alles futsch. Ok, wenn das Backup aktuell ist halb so schlimm. Wenn sich das ganze auf zwei Platten aufteilt dann sinkt die Wahrscheinlichkeit auf 50% das es die mit /home betrifft.

Das klingt nach Russischem Roulette. Ein aktuelles Backup deines /home, möglichst mehrfach, ist immer Pflicht!

Quote from: NochEinNeuer on 2026/07/19, 20:50:56Oder sind die heutigen SSD so gut das man sich darüber keine Sorgen mehr machen muss das eine das zeitliche segnet?

Kein Speichermedium lebt ewig. Die Wahrscheinlichkeit, dass es eine aktuelle SSD in den ersten Jahren erwischt, ist gering, aber nicht Null. Ich würde mich niemals auf "hält schon noch" verlassen, was meine Daten angeht.

Quote from: NochEinNeuer on 2026/07/19, 20:50:56Wie handhabt/ seht Ihr das?

Ich habe alle Daten auf einer 1-TB-SSD zum Arbeiten und mache mindestens einmal täglich (also abends) ein Backup von /home auf mehrere HDDs, die in der Wohnung verteilt sind. Schlimmstenfalls neue SSD kaufen und einbauen, System neu installieren, Backup einspielen. Dauert ab Einbau der SSD etwa eine Stunde, dann ist alles wieder so wie gestern abend (oder wann immer das letzte Backup gemacht wurde).

--ks

@alexsid
Let's try unklarer's suggestion:
/etc/default/grub.ucf-dist:GRUB_CMDLINE_LINUX_DEFAULT="quiet resume=UUID=d0a9d5f0-05ea-4b68-b279-015c623e387fgrub.ufc-dist is the maintainer's backup of your  config file during the installation of new grub.
Obviously you have a new one, so this one is not used, however, you could compare them just in case:
$ diff /etc/default/grub /etc/default/grub.ufc-distThe same goes for /etc/fstab and /etc/fstab.save.
/usr/sbin/grub-mkconfig: 1: /etc/default/grub: f367fdb7-62c0-4ecf-83de-c645d598287c#: not foundI am a little worried about the character '#' at the end of the 'not found' line. Can you check?
PS.:
And while we're at it: Your line
/etc/fstab.save:UUID=23CC34C6703D21EC /wd/ntfs auto defaults,nofail,x-systemd.automount 0 2d0a9d5f0-05ea-4b68-b279-015c623e387f swap          swap    defaults  0 0
doesn't make sense. There should be a line break between '0 2' and 'd0a0' and I am also missing
a UUID= after the missing line break.

@unklarer
Happy now?