[Erledigt] Neue UUID nach Kernelupgrade

[Staphylea]

Hallo,

nun bastel ich schon ein paar Tage nach Prozessor Wechsel (Intel Celeron 430 --> Intel Core Duo (775 Socket)) an einem neuen Kernel. Vom 3.16.4 Backports auf den aktuellen 3.18.4.
Natürlich hab ich versucht aus dem Generic soviel rauszuschmeisen wie möglich. Soweit läuft nun auch alles.

Was mich etwas irritiert ist das zuerst nur die btrfs Platte (sdc) eine neue/andere UUID bekommen hat. Weshalb? warum? Von wem?

Heute hab ich nun vom 3.18.4 auf den 3.18.5 mit der config vom 3.18.4 (olddefconfig durchgeführt) "geupdatet". Inzwischen haben auch die / und die swap partition neue UUIDs.
System startet trozdem, was mich zwar einerseits freut, aber ich verseh es nicht. Vielleicht hat jemand eine ganz einfache Erklärung?

Ausgabe blkid:

Code: Alles auswählen

/dev/sda1: UUID="e902b023-febe-4b4a-a2c1-dd682c5bcc38" TYPE="ext4"
/dev/sda5: UUID="53ddfc51-ae5f-4f48-a741-06c86ad2a73c" TYPE="swap"

Auszug /etc/fstab:

Code: Alles auswählen

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=a915e9b5-c813-4f3b-a404-f35732589c1f /               ext4    errors=remount-ro 0       0
# swap was on /dev/sda5 during installation
UUID=c19b1a6d-22f7-4c74-bbc2-0941f28e9ec2 none            swap    sw              0       0
 

Auszug /boot/grub/grub.cfg:

Code: Alles auswählen

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Debian GNU/Linux, mit Linux 3.18.5' --class debian --class gnu-linux --class gnu --class os {
        load_video
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos1)'
        search --no-floppy --fs-uuid --set=root e902b023-febe-4b4a-a2c1-dd682c5bcc38
        echo    'Linux 3.18.5 wird geladen …'
        linux   /boot/vmlinuz-3.18.5 root=UUID=e902b023-febe-4b4a-a2c1-dd682c5bcc38 ro  quiet
        echo    'Initiale Ramdisk wird geladen …'
        initrd  /boot/initrd.img-3.18.5

Die btrfs Platte hat mit dem 3.18.5 Kernel (selbe config wie 3.18.4 !) nun wieder die gleiche UUID wie beim 3.16.4 Kernel.

Über Anregungen bzw. Erklärungen bin ich dankbar.

Vielen Dank
Staphylea

[rendegast]

Arbeitetest Du mit snapshots, wiederhergestellten Dateisystemen o.ä.?

Könnte mir denken, daß Imaging-Tools unter gewissen Umständen neue UUID vergeben,
damit beim Rebooten keine Verwechsung auftritt.

[Staphylea]

Moin,

sehe eben jetzt erst Deine Antwort, nein derartiges verwende ich nicht.
Sind insgesamt 4 HDs (3xSATA 1xIDE) jeweils ein FS (ext4 und btrfs) drauf kein RAID kein LVM.

Danke
Staphy

[rendegast]

Vielleicht hat jemand eine ganz einfache Erklärung?

Du hast einen Co-Admin? Der treibt Schabernack?

System gehackt? (Wobei ich an Stelle des Hackers sowas nicht machen würde, wäre dumm)
Läuft vielleicht anfällige Software als Einfallstor, wordpress? modifizierte php-Skripte?

Du hast ein Skript benutzt, daß die UUID durchwürfelt?
(als eine Abwandlung der obigen Idee eines cloning-Tools)




Der Kernel benutzt eine andere Byte-Order?
Wobei ich denke, daß dann vielleicht gar kein Mount möglich wäre.
Und dazu wäre auch nicht passend, daß die Dateisysteme peu-a-peu geändert werden.

Benutzt Du 3rd-Party-Patches?

Wie ist es mit dem 3.18 aus experimental?





Ein alter bug-Report für ubuntus update-manager
https://bugs.launchpad.net/ubuntu/+sour ... bug/504336
Der dort erwähnte 426027 scheint mir aber eher ein Problem mit udev zu sein (/dev/disk/-Links fehlen).

https://bugs.debian.org/570516
Von 2010, die uuid eines raid im Rahmen eines dist-upgrade

[Staphylea]

Ich denke ich habe eine Erklärung gefunden.

@rendegast:
System Hack, Scripte etc. schließe ich mal aus. Eher OwnBrainHack
Patches verwende ich wissentlich nicht.
Kurz gesagt, ich kann es nicht mehr reproduzieren. Danke das Du mir denoch Denkanregungen gegeben hast.


Fakt ist: Die UUIDs haben sich definitiv vom Installations Kernel ?? (glaube das war Wheezy 7.2 netinst ) zur jetzigen Situation geändert:
/etc/fstab:

Code: Alles auswählen

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
# UUID=a915e9b5-c813-4f3b-a404-f35732589c1f /               ext4    errors=remount-ro 0       0
# swap was on /dev/sda5 during installation
# UUID=c19b1a6d-22f7-4c74-bbc2-0941f28e9ec2 none            swap    sw              0       0 

Nun sieht es so aus:

Code: Alles auswählen

 UUID=e902b023-febe-4b4a-a2c1-dd682c5bcc38 /               ext4    errors=remount-ro 0       0
UUID=53ddfc51-ae5f-4f48-a741-06c86ad2a73c none            swap    sw              0       0

Ja ist noch die selbe Platte am selben IDE Port. /dev/sda1 auf / und /dev/sda5 ist swap

Erklärung: (Glaube ich zumindest)
UID16 war beim meinem 3.18.4 Kernel nicht aktiv

Code: Alles auswählen

cat /boot/config-3.2.0-4-amd64 | grep UID16
CONFIG_UID16=y
cat /boot/config-3.16.0-0.bpo.4-amd64 | grep UID16
CONFIG_HAVE_UID16=y
CONFIG_UID16=y
cat /boot/config-3.18.4 | grep UID16  
cat /boot/config-3.18.7 | grep UID16
CONFIG_HAVE_UID16=y
CONFIG_UID16=y

Auszug der Hilfe:

Code: Alles auswählen

Symbol: UID16 [=y]
     -->  Depends on: HAVE_UID16 [=y]  

HAVE_UID16 [=y] 
     -->  Selected by: X86_32 [=n] && !64BIT [=y] || IA32_EMULATION [=y] && X86_64 [=y] 

beim 3.18.4 stand " IA32_EMULATION [=n]" somit auch kein UID16 denn HAVE_UID16 war logischerweise "[=n]"

Wie das das nun beim 3.2.0-4-amd64 gelöst war weiß ich nicht. Vermutlich kam die Abhängigkeit zu HAVE_UID16 erst später habe die Changelogs jetzt nicht so verfolgt. Vielleicht weiß jemand etwas dazu.
Ansonsten betrachte ich das Thema für mich geklärt, denn die UUID sind zwar jetzt anders aber stabil egal mit welchem Kernel ich boote.

Thx
Staphy