Siduction Forum

> Wisst ihr zufällig, wann in Siduction (Debian Sid) KDE Plasma 6.7.2 eintrifft?
Nach < https://packages.debian.org/sid/plasma-desktop> und
 
$ apt policy plasma-desktop|cat
plasma-desktop:
  Installiert:           4:6.7.2-1
  Installationskandidat: 4:6.7.2-1
  Versionstabelle:
 *** 4:6.7.2-1 500
        500 https://deb.debian.org/debian sid/main amd64 Packages
        100 /var/lib/dpkg/status
     4:5.27.5-2 500
        500 https://deb.debian.org/debian bookworm/main amd64 Packagesist KDE Plasma doch schon auf Stand  6.7.2-1,
was habe ich bei Deiner Frage nicht vestanden?
 
 
 

Mesa, Python etc. sind auch gefährliche Komponenten. Die werden aber immer sofort aktuell gehalten.
Ich frage mich nur, warum es immer nur beim KDE Desktop selbst solange dauert und alles andere ist praktisch sofort verfügbar.

Uh, gute Frage.
Wir bewegen uns in diesem Fall genauso schnell wie debian.
Ergo es kommt, wenn es nach debian unstable hochgeladen wird.
Wir warten auch darauf, einfach
Geduld walten lassen.

Wisst ihr zufällig, wann in Siduction (Debian Sid) KDE Plasma 6.7.2 eintrifft?
Mesa, Kernel und andere Software ist immer Top Aktuell, nur neue KDE Plasma Versionen dauern immer ewig bei Siduction.

Now that you solved it, here is another method for debugging the initramfs creation:

sudo sh -x /usr/sbin/update-initramfs -c -k 7.1.4-1-siduction-amd64 2>&1 | grep -B 5 -A 2 d0a9d5f0This command should have revealed, where the information is coming from. Anyway, I am glad
the problem has finally found its solution!
PS.:
> One problem spersists: WHEN do we get the honor to use Siduction 2026? :-)
Great question, I wonder whether good old pyfll plays nice with brand new python3.14?

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.