DSGVO – wir stoppen Google-Analytics nach einem Test des Verhaltens unserer Leser zu Cookie- und GA-Hinweisen …

Liebe Leser des Blogs,
wie viele andere schlagen wir uns gerade mit dem Thema DSGVO (bzw. EU GDPR) herum. Ein Thema ist dabei Google Analytics, kurz [GA]. Auch wir haben bislang in diesem Blog ein Plugin verwendet, um mittels GA feststellen zu können, wie oft unser Blog besucht wird und welche Artikel unsere Besucher am meisten interessieren. Wir haben dies bislang für legitim und auch sinnvoll gehalten. Nun hat sich unsere Meinung aber geändert.

Wie reagiert der Besucher von Websites auf Cookies und Google Analytics, wenn er die Wahl hat?

Das Gute an der DSGVO (EU GDPR) ist, dass man sich auch als Webseiten-Betreiber ein paar unangenehmen Fragen stellen muss. Eine Frage, die ich selber immer wieder verdrängt habe, ist:

Wie reagiert eigentlich der/die Besucher/in einer Web-Site, wenn er/sie entscheiden kann, ob Cookies verwendet werden und ob sein Verhalten mittels GA auf der Site getrackt wird oder nicht?

Wir machen uns dabei folgenden Aspekt zu wenig klar: Web-Site-Betreiber leisten ja eigentlich dem geschäftsbedingten Daten-Sammeltrieb von Google Vorschub, indem sie/wir vermeintlich zum eigenen Vorteil einen attraktiven und gut funktionierenden Service von Google nutzen. Gerade in im Falle von Google Analytics geht es aber nicht nur um unsere eigenen Daten. Die nachfolgende Frage drängt sich auf:

Kann man testen, wie der User oder Leser auf Google Analytics reagiert, wenn er rechtzeitig informiert wird - und eine Option hat? Antwort: Ja, das kann man - und sollte es im Vorfeld der DSGVO auch tun. Wir haben eine Woche lang - eher unfreiwillig - einen solchen Test gemacht. Hier ist unsere Geschichte, die uns selbst gestern ein wenig ungläubig auf GA-Daten zum Blog blicken ließ ...

Erfahrung mit unseren Lesern, einem Cookie/Google-Analytics-Banner und GA-Opt-Out im Verlauf einer Woche

Am 01. Mai habe ich mich aufgrund der DSGVO mit verschiedenen Plugins und Cookie-Bannern auseinandergesetzt. Zudem mit Plugins, die ein Google-Analytics-Opt-Out durch den Leser ermöglichen. In den Blog integriert wurde dann einerseits ein Cookie-Banner-Plugins der italienischen Regierung, das wir als gut erachtet hatten (s.u.). Auf diesem Banner wiesen wir auf Google Analytics hin. Zusätzlich kam auch ein Opt-Out-Plugin bzgl. Google Analytics zum Zuge.

Eine Woche später mussten wir folgenden, für uns doch ziemlich überraschenden Effekt konstatieren:

Laut Auswertung der "Google Analytics"-Statistik ging die Anzahl der Besucher dieses Blogs am 02.05. angeblich von durchschnittlich 150 Besuchern pro Tag schlagartig auf 3 oder 4 pro Tag herunter. Tendenz im Laufe der Woche fallend. Gestern war es nur noch 1 Besucher am ganzen Tag.

Irgendwie nicht lustig ... Ein wenig Studium des Programmablaufs machte aber deutlich, dass das ein Scheineffekt war/ist - allerdings ein interessanter. Denn ein Gegentest zeigte, dass die veränderte Google-Analytics-Statistik etwas über die Haltung und Meinung unserer Besucher aussagt.

Die Auswirkung restriktiver und besucher-freundlicher Cookie-Banner

Wir gehen nach einer zwischenzeitlichen Analyse davon aus, dass der beobachtete GA-Effekt auf eine gewollte Wechselwirkung des Cookie-Banner-Plugins mit dem üblich "Google Analytics"-Skript in den Webseiten zurückzuführen ist. Das sog. "EU-Cookie-Law"-Plugin bietet nämlich als eines von wenigen eine Option an, die ich für absolut fair und richtig halte und deshalb aktiviert hatte:

Das Cookie-Banner-Plugin unterbindet in Webseiten integrierte Skripte, die ja potentiell weitere Cookies setzen und lesen könnten, so lange, bis eine explizite User-Zustimmung zur Cookie-Nutzung erfolgt ist.

Das verhindert technisch nun auch nicht jede Art von Benutzer-Analyse: Bereits der PHP-Code der Seite könnte ja Session-Cookies und auch (verschlüsselte) Cookies mit weiteren tiefergehenden Informationen zum Besucher aufgrund von Browser-Informationen setzen und zumindest im Zuge von Seitenwechseln bestimmte Dinge auswerten. Viele WordPress-Plugins und Themes etwa setzen eigene (relativ harmlose) Cookies zur dynamischen Ablaufsteuerung, z.B. im Zusammenhang mit Bildgalerien. Detailliertere Auswertungen des Nutzerverhaltens setzen aber Javascript oder andere Skripts am Client (Browser/App) und bestimmte Cookie-Typen mit unterschiedlichen Informationen voraus.

Deshalb bietet das Plugin der italienischen Regierung die Option, cookie-fähige Skripte zu unterbinden, die auf der Client-Seite - also im Browser - ausgeführt werden. Das betrifft u.a. JS, Flash. Und natürlich Google Analytics; kaum überraschend setzt das GA-Skript ja gleich mehrere (3) Cookies.

Fairness gegenüber dem Besucher von Webseiten

Aus unserer Sicht spiegelt die Option des italienischen Cookie-Banners den Geist der DSGVO wieder... Der User soll nicht nur informiert werden, sondern auch ein wenig Einfluss auf das Geschehen haben, wenn seine Daten betroffen sind.

Stimmt der Besucher des Blogs durch Klicken auf den angebotenen Button zu, so ist das alles kein Problem. Das Script für Google Analytics läuft dann regulär ab; das Verhalten des Users auf der besuchten Seite wird direkt registriert und kann vom Inhaber der Seite auch live mitverfolgt werden. Was aber, wenn der Besucher den Button bzw. das gesamt Cookie-Banner aus guten Gründen ignoriert? Eine Folge ist, dass das Mini-Skript von Google Analytics dann nie zum Zuge kommt ....

Der vorsichtige User ignoriert Cookie-Banner systematisch ...

Nun ist das bewusste Ignorieren des Cookie-Banners eine völlig verständliche Reaktion. Ich selbst wähle dieses Handlungsmuster laufend - u.a. und im Besonderen auch auf Seiten von Suchmaschinen-Herstellern. Ein Motiv ist dabei:
Warum sollte ich etwas zustimmen, das nicht explizit einer Wahl sondern eher einer reinen Kenntnisnahme entspricht? Und warum sollte ich etwas zustimmen, bei dem ich die Folgen nicht abschätzen kann?

Implizit müsste ein derart vorsichtiger Benutzer dabei davon ausgehen können, dass dann eben auch nichts außer einfachen Session-Cookies zum Tragen kommt. In Wirklichkeit ist dies leider nur bei einem kleinen Teil von Web-Sites der Fall. Das Cookie-Informations-Banner wird meist nur aus Alibi-Gründen angezeigt; das Nicht-Anklicken des OK-Buttons hat vielfach keine Wirkung im Sinne einer Cookie-Blockade. Im Fall unseres Cookie-Banners war das jedoch anders.

Gegentests

Ich habe am gestrigen und heutigen Nachmittag dann mal getestet, was passiert, wenn ich die Sperre von Scripts über das Cookie-Banner wieder deaktiviere. Na, ihr erratet es schon:

An beiden Tagen wurden sofort wieder etwa 15 Besucher des Blogs innerhalb von jeweils ca. 30 Minuten Testzeitraum registriert. Das konnte ich live in unserem GA-Account verfolgen. Am Nachmittag ist das auf unserem Blog Durchschnitt. Damit ist die Theorie wohl richtig, dass unsere (intelligenten!) Besucher das Cookie-Banner entweder schlicht ignorieren oder systematisch eine ebenfalls angebotene Opt-Out-Alternative gewählt haben.

Konsequenz 1

Eigentlich sind Banner,

  • die ein Zustimmung zu Cookies anfordern und
  • die zulassen, dass clientseitig ablaufende Skripts im Hintergrund mehr als einfache Session-Cookies zur Steuerung des Seitenablaufs setzen, wenn der User das Banner ignoriert,

eine Farce. Wie gesagt: Ich selbst erwarte wider besseren Wissens, dass keine Zustimmung durch Button-Klick bedeutet, dass auch nichts passiert.

Aus meiner Sicht dienen die von GA dynamisch gesetzten Cookies jenseits meiner persönlichen statistischen Interessen aber auch weiterreichenden Anliegen von Google (s.u.)! Es wäre also gegenüber unseren Lesern nicht fair, das GA-Skript nicht zu unterbinden, wenn der User das Cookie-Banner und seinen Button absichtlich ignoriert.

Konsequenz 2

Ignorieren die meisten unserer Besucher aber das Cookie-Banner tatsächlich absichtlich, so wird bei fairer Einstellung des Cookie-Banners Google Analytics für uns, vermutlich aber auch für andere völlig nutzlos. Das hat uns die Erfahrung der letzten Woche eindeutig gezeigt.

Die "neuen" Google-Bedingungen für die Nutzung von Google Analytics

Hinzu kam, dass man aufgrund der DSGVO als Nutzer von Google Analytics nun ja auch den neuen Google-Bedingungen für die Nutzung von Analytics zustimmen muss. Hmmmm - ausgedruckt sind das 13 Seiten, die Google da unverschämterweise nur in Form eines kleinen Popups anbietet, bei dem man sich dann den Mittelfinger wund-scrollt. Allein das sollte einen schon misstrauisch machen.... Zudem erhielt ich die neuen Nutzungsbedingungen in unserem Google-Account nur auf Englisch angeboten - obwohl Google natürlich sehr wohl erkannte, dass ich mich aus Deutschland auf der GA-Verwaltungsseite angemeldet hatte.

Ich muss nach einer längeren Lektüre leider sagen,

  • dass ich die neuen (englisch verfassten) Bedingungen mindestens genauso skeptisch sehe wie die von mir in diesem Blog zuletzt so kritisierten Nutzungsbedingungen von Facebook
  • und dass ich die Google-Bedingungen z.T. - wegen der ausgesprochen verklausulierten Anwaltssprache - als noch unverständlicher einstufe.

Es wird Leser meines früheren Artikels zu Facebook nicht wundern, dass auch bei Google eine Art "third-party-partners" (s. den Link unten) auftaucht - selbige heißen bei Google aber "Third-Party-Subprocessors" und "Affiliates". Die spielen natürlich auch im Kontext der GA-Daten-Erfassung eine interessante Rolle. Letztere wiederum lässt sich allerdings nur über weitere sekundäre (und lange) Dokumente erschließen. Ehrlich: Das nervt!... schon auf Englisch, es würde das aber sicher auch auf Deutsch tun.

Mir scheint, die EU GDPR hat offenbar durchaus das Potential, das Geschäftsmodell bestimmter Informationskraken durch eine bessere Information von Nutzern in Frage zu stellen - und die Anwälte von Facebook, Google und Co. leisten nun ganze Arbeit, um Otto-Normal-Verbraucher mit wirklich schwer verdaulichen Text-Kaskaden von bestimmten Schlussfolgerungen abzuhalten. Gewollt oder nicht ...

Im Fall von Google Analytics stößt man dann noch auf eine spezielle Anforderung: Man muss zustimmen, dass Google das Recht hat, Daten aus dem EWR/EU-Raum heraus zu befördern - speziell in die USA. Ich habe das mit meinen begrenzten Englisch-Kenntnissen zumindest so verstanden und meine, Punkt 10.1 ff. der neuen Google-"Terms" lässt hier keine andere Interpretation zu. Dieser Datentransfer dient dann u.a. der Versorgung von "Googles "Affiliates and Subprocessors" in solchen Staaten außerhalb der des EWR/EU-Raums. Dem soll ich als Google-"Customer" zwingend zustimmen.

Tja Leute, warum sollte ich das angesichts einer sich abschottenden amerikanischen Wirtschaft eigentlich tun?

Und ehrlich gesagt, die Termini "Affiliates" und "Subprocessors" gefallen mir gar nicht ... speziell, wenn ich für ein besseres Verständnis noch weitere Papiere und Bedingungen studieren soll. Durch einen späteren Abschnitt und durch Appendix 1 wird übrigens klar, dass die exportierten Daten dann natürlich auch die erfassten Daten der Besucher einer Website umfassen. Zumindest nach meinem Verständnis. Vielleicht sollte google dazu mal Stellung beziehen.

Klar auch, dass in dem Augenblick, wo die Daten Server auf amerikanischem, chinesischem, russischem oder sonstigem Nicht-EU-Boden erreichen, dort womöglich der lokalen Rechtsprechung bzgl. des Umgangs mit unseren/euren Daten unterliegen.

Konsequenz 3

Die neuen Nutzungsbedingungen von Google kann ich nicht guten Gewissens und schon gar nicht ohne vorherige Anwaltskonsultationen mittragen. Der ganze Text ist eine einzige Zumutung. Entscheidend ist dabei aber, dass es hier nicht nur um meine, sondern auch um eure Daten geht.

Liebes Google: Verlangt vom Nutzer eures GA-Services in Zukunft lieber eine angemessener Gebühr und haltet dafür die Daten dann ausschließlich auf EU-Servern vor. Und gebt sie (dann) explizit und grundsätzlich nicht an "Affiliates und Third Party Sub-Processors" weiter! Bitte sucht euch gefälligst auch Übersetzer, die das zugehörige Anwalts-Englisch in klare, für jeden Kunden nachvollziehbare Landessprache übersetzen.

Es ist für mich - wie bei Facebook auch - leider überhaupt nicht nachvollziehbar, was mit meinen und den erfassten Daten meiner Leser passiert, sobald diese Daten - offenbar absehbar und gewollt - die EU verlassen. Sorry, aber dabei gehe ich angesichts der Entwicklung in einigen Staaten weg von demokratisch verfasster Rechtsstaatlichkeit zunächst mal vom Schlimmsten aus. Gegenüber Eingriffen staatlicher Eingriffen nützt nämlich auch eine ISO 27000 nichts, auf die Google hinweist.

Da mein Cookie-Banner aus rechtlichen Gründen natürlich auch auf Google Analytics hinweisen müsste, sehe ich als Voraussetzung einer nachfolgenden aktiven Zustimmung des Lesers auch das Verständnis der Folgen einer Akzeptanz von GA-Cookies als zwingend notwendig an. Nun verstehe ich aber nicht mal selbst Googles Bedingungen ... Das kann ich meinen Lesern nicht zumuten.

Der einwöchige Testlauf hat zudem deutlich gezeigt, dass zumindest die Leser dieses Blog die angeforderte explizite Zustimmung wohl aus guten Gründen nicht geben wollen und werden - was ich sehr gut verstehe!

Fazit

GA wird nach der DSGVO faktisch völlig sinnlos, wenn man mit seinen Lesern und potentiellen Kunden fair umgehen will - und eine explizite Zustimmung zu Cookies zur Bedingung für das Ablaufen wenn GA-Scripts macht. Ist vielleicht gut so, denn die Folgen der neuen Bedingungen für die Nutzung von GA kann ein Webseitenbetreiber eigentlich nicht ohne aktives Involvieren seiner Leser mittragen. Und meine Leser haben mir im Laufe der letzten Woche hierzu eine eindeutige Antwort gegeben.

Deshalb stellen wir Google Analytics auf diesem Blog im Interesse unserer Leser ab. Das entsprechende Konto bei GA wurde gekündigt. Leider behält sich Google das Recht vor, im Sinne von staatlich verordneter Datenvorratshaltung die bislang erfassten Daten noch eine Weile vorrätig zu behalten. Auch ein interessanter Punkt - aber ich mag meinen Blutdruck nicht weiter strapazieren ...

Gerne könnt ihr mich per E-Mail zu diesem Thema kontaktieren.

Hinweis: Dieser Beitrag wurde am 08.05.2018 und 15.05.2018 textlich und inhaltlich bearbeitet. Am 15.05. wurden zudem etliche Rechtschreibfehler beseitigt.
Eränzung 15.05.2018: Möglicherweise fand der Beitrag ja auch bei Google-Mitarbeitern Interesse. So hatte ich am 07.05.2018 und am 08.05.2018 mehrfach Zugriffe auf mein Xing-Profil von Google-Mitarbeitern zu verzeichnen. Anonym natürlich ... Liebe Leute von Google, wenn es etwas zu sagen oder zu besprechen gibt oder ich mich gar bzgl. der neuen Nutzungsbedingungen getäuscht haben sollte, dann schreibt mich bitte unter Nennung von Namen an. Ich bin auch gerne bereit, eure Meinung hier zu präsentieren.

Links

Leaving Facebook … – I
Bruce Schneier über Facebook, Cambridge Analytica und die Daten-Sammel-Industrie
https://www.kuketz-blog.de/das-kranke-www-stop-using-google-web-services/
https://traffic3.net/wissen/webanalyse/google-analytics-datenschutz
https://www.blogmojo.de/google-dsgvo/#5_google_analytics

Leaving Facebook … – I

At the beginning of this year I got advice from several people to become a customer of Facebook. I thought this could be interesting - what would it feel like? Especially, as I am biased - against data collectors ... And I knew the GDPR of the EU (DSGVO in Germany) would come soon ... Would be interesting to see how FB would react ...

My wife - a Norwegian citizen - is very active on Facebook and Instagram. One reason is that she, of course, is interested in current developments in her home country. My grandchildren are on Instagram. Some friends are on Facebook - mostly as private persons. So, there are obviously some points that at least count for other people in favor of FB. Among other things: FB offers "free" communication services. And it offers information spreading - on fast time scales. Yeah, well known ... A fundamental question, however, is: Information spreading to whom?

As some people may have noticed: I have left Facebook two days ago - for good. As I have no other platform, yet, I want to explain my decision here.

Personal Experience - a summary

I have tried and used FB now for 4 months. My personal opinions and conclusions are:

  • FB comprises a totally unproductive bubble world on a headline level.
  • It costs you a lot of time and delays productivity of whole societies.
  • Instagram appears to make children and teens addicted. A whole generation is literally wasting its youth with FB products.
  • In a way Facebook undermines the business of serious news agencies.
  • It is manipulative and provokes you to publish opinions - without any filter.
  • It is definitely a machinery aggregating detailed profile information on individuals of big parts of the world's population.

So, FB, for me is at least as bad as expected - if not worse. But last things first.

The new terms and regulations as part of FB's reaction to the EU GDPR

At least after the EU's GDPR (https://www.eugdpr.org/) FB became relatively clear about what information it gathers on you. By providing you - at least in principal - with information on new terms and rules. Which you must accept, if you want to continue using FB services.

They are, however, not so clear about how they earn money with their services - and who really gets your data. Should make you suspicious. Despite all efforts to create a certain impression: FB is NOT a welfare company. So, take your time and read the new terms very carefully ... No, its no fun; if printed, its a lot of pages in tiny letters ...

Whilst you read keep in mind that FB already transferred 1,5 to 1,8 billion data records on non EU-customers to the US - where the information provision is not regulated as it soon will be in the EU.

"Data Policy" information - how to find it
So how do you as a EU citizen get to information of how FB uses data about and on you:

To see the full extent you have to move to your account, down to the left side - Link "impressum/terms/NetzDG". Then you get to a page with the old rules; but at the top there is a warning about imminent changes - and a link to the new rules. Click there - navigate a bit - yes, there is a link for a printable version on the left side. Get the whole stuff printed on at least 7 pages in a quite tiny font size. Read ... and get reminded of the Windows 10 user conditions.

My short summary is - and please correct me, if you find something which you think cannot be interpreted the way I see it:

What data, where from?
FB gathers all information on you which it can get - from all types of sources, including other persons and services besides FB's own applications. About what you do, where you do it, when, and not surprisingly for data analysts, how you do it (when you interact with their pages, e.g. via mouse or finger movement, scrolling analysis, ...).

They collect detailed information about all devices you use and - as far as possible - also on processes running there as well as on configuration settings. They collect data that identify these devices and their settings in a unique way - and which identify, thereby, also you as a person, your location and parts of your behavior, plus your relation to your Internet providers. They use face recognition techniques if allowed on your device or if you accepted conditions to do so whilst using a FB product. FB clearly says that it combines all this gathered information. Across all of their products you may use (FB, Instagram, Whatsapp, Oculus, ...). Not excluding other secondary sources and resources - as "partners" on whose websites you may have been.

Partners
And because FB is such a welfare oriented company it also does the following; I quote:

"We use the information (including your activities off our Products, such as websites you visit and ads you see) to help advertisers and other partners measure the effectiveness and distribution of their ads and services, and understand the types of people who use their services and how people interact with their websites, apps and services."

Please note the "off" (2 fs !) in the first sentence. And the remarkable word "partners". Hmm, there are "partners" and there are "third-party partners" as we soon learn. Notably, FB does not mention any money here. And of course not, where FB and their "partners" pay tax for all this "help".

Yeah, ... And of course your data may be used in projects and research in the context of "general social welfare, technological advancement, public interest, health and well-being". Unfortunately, you have to assume that FB itself defines the meaning and borders of all these nice words ... especially "public interest". These expressions are not explained and left open - what an arrogance!

Then we learn throughout paragraph III that YOU as a user should think carefully about whom you share information with - because you may loose control over your data. Oooops ... in the end data protection is still my own responsibility - and shit happens as we all know ....

Third-party partners
And then (2 pages later) comes a very nice and very fine distinction:
The "third-party partners." And, within this context, we almost cannot believe it:

"We don't sell any of your information to anyone, and we never will. We also impose strict restrictions on how our partners can use and disclose the data we provide. Here are the types of third parties we share information with ...".

You can almost see the lawyer who has written this. From the context it should become clear that this is only about "third-party partners" - and maybe not a general statement on other types of (direct) "partners". Otherwise, FB would have to explain, where all the billions do come from, every year, ... I would say - an unexplained business is a kind of dubious business.

Another pretty creepy part in this paragraph is the following - see the lines under "Measurement partners": "We share information about you with companies that aggregate it to provide analytics and measurement reports to our partners."

Wow ... Read it again and again ... It is not (!) Facebook that aggregates - it is some other companies! Meaning these other companies first get personal data about you which they then (!) aggregate and provide back to FB's partners. You see the funny lawyer again, which I mentioned above. I hope the EU data protection authorities have a very close look into this type of information provided by FB.

And then again the welfare attitude:
"We also provide data and content to research partners and academics to conduct research that advances scholarship and innovation that support our business or mission, and enhances discovery and innovation on topics of general social welfare, technological advancement, public interest, health and well-being."

Didn't you always want to become a subject for some special analysis? Hey, you can get famous - somewhere in some data lab ...

Cooperation with law enforcement
Pretty nice also some passages about sharing data with law enforcement institutions: Here we learn that the exchange of data is based on "good-faith belief" on FB's side. You do not believe it? Read paragraph VIII of the whole mess yourself. And good luck, if you, e.g., happen to be Russian or Chinese ...

Addendum, 04/28/2018: What is not written in the new Data Policy

As with other business it is interesting, too, what is not written down explicitly. In this case in the FB document on "Data Policy".

E.g., you do not get information on who are "partners" - and what makes a "partner" a partner of FB. Also, the definition of a "third-party partner" is pretty unclear. So, in the end you do not know where your data end up - or who under which conditions employees of partners and third-party partners get access to them.

The other remarkable thing is: It is not written where FB stores your data and what they do for data protection - technically and otherwise. You may assume from newspaper articles that your data should be located on servers within the EU, especially in Ireland. But, you have no guarantee for this.

You may nail the whole mess down with some simple questions: How can you as a EU citizen be sure that there, e.g., is no copy of all your collected data on a Russian FB server - and/or that there is no Russian "partner" or "third-party partner", who is allowed to get your personal data for "aggregation" and "research" in the "public interest" of Russia? My copy of the present "Data Policy" of FB does not seem to exclude such a type of scenario - if I assume that there are some Russian partners of FB. Are there? I would like to know .. Of course, I have learned that the data would not be "sold" to third-party partners or authorities ... but maybe just given - in "good-faith belief" ...

A last remarkable thing is that you do not find a single description about variants and functionality of AI and deep learning algorithms FB or their aggregating partners or third-party partners use. So, besides not knowing where your data end up, you neither get to know in which way and for which special purpose your data get analyzed.

Conclusion

Facebook is and remains creepy. Its information on what customer data they gather and what they in general do with it is partially quite open and partially very obscure and evasive. In my opinion. Some paragraphs in the "Data Policy" open up a legal void - with much room for interpretation.

Taking it all together, I see a fundamental lack of understanding at FB what data privacy really means - and how it should be described for customers. But there is one thing I must admit: FB warns you - in a way - that you should be careful about what you share on Facebook.

You should take this warning seriously. And read a comment of the well known security expert and researcher Bruce Schneier on the whole information gathering industry around FB and others; his comment was published on CNN:

Bruce Schneier on Facebook and CA

Read also about the EU GDPR and its intentions:
https://www.eugdpr.org/


See also:

www.heise.de/newsticker/meldung/Wegen-der-DSGVO-Facebook-verschiebt-Daten-von-1-5-Milliarden-Nutzern-aus-Irland-4027584.html
https://www.heise.de/newsticker/meldung/Wegen-der-DSGVO-Facebook-verschiebt-Daten-von-1-5-Milliarden-Nutzern-aus-Irland-4027584.html
https://www.reuters.com/article/us-facebook-privacy-ireland/eus-top-court-asked-to-probe-facebook-u-s-data-transfers-idUSKBN1HJ1D5
https://www.zdnet.de/88331745/dsgvo-facebook-verschiebt-15-milliarden-nutzerkonten-in-die-usa/
https://www.newsslash.com/n/12074-dsgvo-facebook-verschiebt-nutzerdaten-zum-schutz-von-nicht-europaeern
https://www.zeit.de/wirtschaft/2018-03/plattformkapitalismus-internetplattformen-regulierung-facebook-cambridge-analytica

Upgrade-Zeit – Vorsorge durch Fallback-Installationen – II

Im letzten Beitrag
Upgrade-Zeit – Vorsorge durch Fallback-Installationen – I
hatte ich versucht darzustellen, wie man mehrere parallele, bootfähige Linux-Installationen auf einem Einzelplatzsystem (PC, Laptop) nutzen kann, um die Arbeitsfähigkeit im Fall von Update/Upgrade-Problemen zu sichern. Man arbeitet normalerweise auf einer "Hauptinstallation", die zu einer bestimmten Partition (z.B. "/dev/sdf7") gehört.

Eine Fallback-Installation auf einer separaten Partition (z.B. "/dev/sdf9") wird dagegen zu geeigneten Zeitpunkten als Abbild (Partitionskopie) eines funktionierenden Zustands der Hauptinstallation erzeugt und danach hinsichtlich von Updates extrem konservativ behandelt.

Updates/Upgrades werden grundsätzlich erst in einer dritten "Experimental-Installation" (z.B. auf "/dev/sdf3") für Experimente getestet, bevor sie in der Hauptinstallation nachgezogen werden.

Nutz- und Projektdaten des/der Anwender werden dagegen auf speziellen Datenpartitionen untergebracht, die man in den jeweiligen Installationen bei oder nach einem Bootvorgang auf vorgegebene Knoten des Verzeichnisbaumes mountet. Das geschieht auf Basis gleichartiger Einträge für die Datenpartition(en) in den "/etc/fstab"-Dateien der verschiedenen Installationen; z.B.

myexp:~ # cat /etc/fstab
...
UUID=24f67362-236e-49ea-ba38-31c1c2541630       /projekte       ext4    defaults 1 2 
....

Diese Einträge werden beim Kopieren der entstehen im Rahmen der Erstellung der Fallback- und Experimental-Installation als Kopie der Hauptinstallation automatisch übernommen.

Ablauf zur Erstellung und Nutzung der Fallback- und der Experimental-Installation

Der Ablauf zur Erstellung und Nutzung der verschiedenen Installationen (auf jeweils unterschiedlichen Partitionen) ist in folgender Abbildung dargestellt:

Die Kuchendiagramme deuten die (wachsende) Partitionsverteilung an. Wir gehen nachfolgend auf einige wichtige Punkte ein, die bei der Erstellung von Partitionskopien als Grundlage der Fallback- und Experimental-Installation zu beachten sind.

Erstimplementierung Hauptinstallation plus Rettungssystem/Minimalinstallation

Die Erst-Installation eines Linux-Systems (z.B. Opensuse Leap 42.2) erfolgt wie üblich aus dem Netz oder per DVD. Man richtet dann seine Datenpartitionen ein und legt zugehörige Mount-Einträge in der "/etc/fstab" fest. Unter Opensuse unterstützt einen dabei der YaST-Partitioner. Dann "gewöhnt" man sich an das neue System und führt erste sinnvolle Updates durch.

Für die Erstellung der Fallback-Installation wollen wir den Inhalt der Partition, die die Hauptinstallation in einem definierten Zustand enthält, in eine andere (freie) Partition kopieren. Eine Kopie des gemounteten Root-Filesystems kann und sollte aber nicht aus der laufenden Hauptinstallation heraus erstellt werden. Der Grund ist einfach: Während der Kopie würden im Hintergrund stattfindende Schreiboperationen beim Kopieren nicht konsistent abgebildet werden. Das gleiche Thema gibt es ja bereits für Backups.

Wir benötigen daher eine weitere unabhängige Minimalinstallation (ohne grafischen Schnickschnack) in einer separaten Partition. Das dortige System booten wir dann zum Erstellen von Kopien anderer nicht gemounteter Partitionen. Alternativ können wir zum Kopieren natürlich auch ein ein Linux-Live-System einsetzen. Für Opensuse Tumbleweed existieren entsprechende ISO-Images (siehe https://de.opensuse.org/openSUSE:Tumbleweed_installation).

Eine andere Alternative bietet ein Rettungssystem, wie es auf Installations-DVDs etlicher Distributionen vorhanden ist. Ein Rettungs- oder Live-System ist aber auch leicht zu erstellen (s. etwa http://www.system-rescue-cd.org/Download/, https://en.opensuse.org/SDB:Live_USB_stick, https://linux-club.de/wiki/opensuse/Installationsmedien_zu_openSUSE).

Hat man später bereits eine Experimental-Installation angelegt, so kann man natürlich auch die einsetzen, um die Partition der Hauptinstallation für eine Fallback-Installation auf eine andere Partition zu kopieren.

Partition für Kopie der Hauptinstallation erstellen

Eine Fallback-Installation entsteht am einfachsten durch Kopie der Partition mit der Hauptinstallation auf eine andere (Ziel-) Partition - und einige nachfolgende Schritte. Die Ziel-Partition muss man natürlich vor dem Kopiervorgang angelegt haben. Hierbei ist folgender Punkt wichtig:

Die Zielpartition muss mindestens die gleiche Größe haben wie die Original-Partition; die Zielpartition kann aber auch größer sein. Das gewährleistet man bei der Erstellung durch geeignete Wahl des Start- und Zielsektors (bzw. des Start- und End-Zylinders). Die Differenz - also die Anzahl der Sektoren (bzw. Zylinder) in der Zielpartition - sollte den gleichen Wert haben wie beim Original.

(Das Zusammenfallen von Partitionsgrenzen mit Zylindergrenzen ist ein Spezialthema für HDs mit MBR und sog. CHS-Adressierung; ich kann hier nicht darauf eingehen. Partitionierungstools achten in der Regel bei der Partitionsanlage auf eine entsprechende Optimierung. Auf Platten mit GPT-Partitionstabelle und LBA-Adressierung operiert man sehr viel einfacher mit Sektoren.)

Es gibt eine Reihe von Tools, um Partitionen aufzulisten, anzulegen und zu verändern. Für Opensuse hatten wir ja schon den "YaST-Partitioner" erwähnt. Interessanterweise bietet dieses Tool eine Dimensionierung neuer GPT-Partitionen über die Eingabe von Start/End-Zylinder an. Ein distributionsübergreifendes grafisches Tool ist "gparted" (welches auf dem CLI-Tool "parted" aufsetzt). gparted unterstützt natürlich GPT-HDs/SSDs und zeigt Start- und End-Sektoren für Partitionen an.

Daneben findet sich das CLI-Tool "fdisk", das inzwischen auch mit GPT-Disks umgehen kann. Speziell für GPT-HDs/SSDS ist das CLI-Tool "gdisk" gedacht. Auch mit gdisk können wir die Größe neuer Partitionen präzise über Angaben zu Sektoren festlegen.

Die Sektor-Information sieht z.B. für zwei gleich große Partitionen "dev/sdf3", "/dev/sdf7" einer Platte "/dev/sdf" unter fdisk wie folgt aus:

myexp:~ # fdisk -l /dev/sdf
Disk /dev/sdf: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 04AD1B2B-6934-444D-BD93-83FE4A3AE15C

Device         Start       End   Sectors  Size Type
...
/dev/sdf3  171960320 339742719 167782400   80G Linux filesystem
...
/dev/sdf7  507590656 675373055 167782400   80G Linux filesystem

Ich ziehe auf GPT-Platten für eine präzise Dimensionierung jedoch meist "gdisk" heran:

myexp:~ # gdisk -l /dev/sdf 
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdf: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 04AD1B2B-6934-444D-BD93-83FE4A3AE15C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 286739053 sectors (136.7 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       167766015   80.0 GiB    8300  primary
   ....
   3       171960320       339742719   80.0 GiB    8300  primary
   ....
   7       507590656       675373055   80.0 GiB    8300  primary
   8       675373056       675710975   165.0 MiB   EF00  primary
myexp:~ #
myexp:~ # gdisk /dev/sdf
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): i
Partition number (1-8): 7
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 85C6892A-D709-4A3F-9758-D521A7A11F68
First sector: 507590656 (at 242.0 GiB)
Last sector: 675373055 (at 322.0 GiB)
Partition size: 167782400 sectors (80.0 GiB)
Attribute flags: 0000000000000000
Partition name: 'primary'

Command (? for help): i
Partition number (1-8): 3
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 4C6C4872-1C36-465A-A09F-7CC0EF542E4D
First sector: 171960320 (at 82.0 GiB)
Last sector: 339742719 (at 162.0 GiB)
Partition size: 167782400 sectors (80.0 GiB)
Attribute flags: 0000000000000000
Partition name: 'primary'

Wie erstellt man nun eine weitere neue Partition mit identischer Größe? Wir machen das mal versuchsweise mit "gdisk"; dort gibt es dafür das Subkommando "n" (für "new"). Ein Blick in die man-Seiten zu "gdisk" zeigt übrigens auch, dass Änderungen erst dann wirksam werden, wenn wir unter gdisk abschließend den "w"-Befehl absetzen.

myexp:~ # gdisk /dev/sdf
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
... 
Found valid GPT with protective MBR; using GPT.
Command (? for help): n
Partition number (9-128, default 9): 
First sector (34-1000215182, default = 717672448) or {+-}size{KMGTP}: 
Last sector (717672448-1000215182, default = 1000215182) or {+-}size{KMGTP}: +167782400
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): 
Changed type of partition to 'Linux filesystem'

Command (? for help): p
Disk /dev/sdf: 1000215216 sectors, 476.9 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 04AD1B2B-6934-444D-BD93-83FE4A3AE15C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 1000215182
Partitions will be aligned on 2048-sector boundaries
Total free space is 118956653 sectors (56.7 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048       167766015   80.0 GiB    8300  primary
   ...
   3       171960320       339742719   80.0 GiB    8300  primary
   ...
   7       507590656       675373055   80.0 GiB    8300  primary
   8       675373056       675710975   165.0 MiB   EF00  primary
   9       717672448       885454847   80.0 GiB    8300  Linux filesystem

Command (? for help): i
Partition number (1-9): 9
Partition GUID code: 0FC63DAF-8483-4772-8E79-3D69D8477DE4 (Linux filesystem)
Partition unique GUID: 696C551B-591D-4411-A951-18D337F548D9
First sector: 717672448 (at 342.2 GiB)
Last sector: 885454847 (at 422.2 GiB)
Partition size: 167782400 sectors (80.0 GiB)
Attribute flags: 0000000000000000
Partition name: 'Linux filesystem'

Command (? for help): q

Man beachte hier die GUID, die eine Partition in eindeutiger Weise auf einem Device identifiziert. Die GUID ist von einer sog. "UUID" des Filesystems (s.u.) in einer Partition zu unterscheiden !

Schreibt man die geänderte Partitionstabelle im letzten Schritt tatsächlich mit "w" auf die Platte, informiert "gdisk" den laufenden Kernel nicht über die Änderungen! Das geschähe ohne weitere Maßnahmen erst bei einem Reboot. Will man das vermeiden, hilft das CLI-Kommando "partprobe", das zusammen mit dem Tool "parted" installiert wird.

myexp:~ # partprobe /dev/sdf 

es geht alternativ auch

myexp:~ # /sbin/blockdev --rereadpt /dev/sdf

Kopieren der Partition mit der Hauptinstallation mit Hilfe des CLI-Kommandos "dd"

Ein "geeigneter Zeitpunkt" zum Erstellen einer Kopie der Hauptinstallation ergibt sich im laufenden Betrieb im Zuge von Updates nach einer Phase zufriedenstellender täglicher Arbeit. Steht man vor einer Upgrade-Aktion für sein Linux-System, wird man die laufende Hauptinstallation in jedem Fall kopieren und daraus eine bootfähige Fallback-Installation herstellen.

Für eine bitweise Kopie ist der Einsatz des CLI-Kommandos "dd" am einfachsten. Siehe zu einer Einführung bzgl. "dd" etwa https://wiki.ubuntuusers.de/dd/ und https://wiki.archlinux.de/title/Dd). "dd" ist unter Linux ein wirkliches wichtiges Werkzeug, das man in Kombination mit "gzip" und "tar" nicht zuletzt auch für die Erzeugung von Updates nutzen kann! Man sehe sich also zu "dd" unbedingt mal die man-Seiten und auch unten angegebene Links an.

Nehmen wir an, unsere aktuell benutzte Hauptinstallation liegt auf einer Partition "/dev/sdf7". Auf der gleichen Platte befinde sich bereits eine Partition "dev/sdf9" gleicher Größe (man prüfe hierzu die Sektor- oder Zylinderanzahl in einem Partitionierungstool; s.o.). Aktuell gebootet worden sei eine Installation auf einer Partition "/dev/sdax" (x im Beispiel ungleich 7 oder 9) oder eben ein Live- oder Rettungs-System. Im gebooteten System erreicht man dann eine bitweise Kopie von "/dev/sdf7" auf "/dev/sdf9" per

myexp:~ # dd if=/dev/sdf7 of=/dev/sdf9 bs=1M

Zum Parameter "bs" siehe die man-Seiten! Auf einer optimal angebundenen SSD dauert ein solcher Kopier-Prozess für eine "80 GByte"-Partition deutlich weniger als 10 Minuten.

myexp:~ # dd if=/dev/sdf7 of=/dev/sdf9 bs=1M
81925+0 records in
81925+0 records out
85904588800 bytes (86 GB, 80 GiB) copied, 418.97 s, 205 MB/s

Die SSD operiert hier mit ca. 400 MB/s, da sie ja lesen und schreiben muss.

Haben wir damit schon unsere gewünschte "Fallback-Installation" erstellt? Da wir ja mit der Partition auch das dortige Filesystem samt Inhalten bitweise kopiert haben, könnte man meinen, dass mit der Kopie schon alles erledigt sei - und man nur noch den Bootmanager "Grub2" unter Einbeziehung aller verfügbaren OS-Installationen (z.B. mittels YaST2 >> Bootloader" neu schreiben lassen muss.

Das ist ein gewaltiger Irrtum!:

Warnung: Bitte schreibt nach Kopie einer Partition mit einer Betriebssysteminstallation nicht den Boot-Manager neu - und schon gar nicht unter Einbeziehung aller bootbaren Filesysteme.

Warum? Die Antwort gibt der nächste Abschnitt ...

Vermeidung gleicher UUIDs verschiedener Filesysteme nach dem Kopieren von Partitionen

Wenn wir eine Partition bitweise kopieren, wird der gesamte Inhalt (Filesystem + dessen Inhalte) 1:1 in die Zielpartition übertragen. Jedes Filesystem hat nun aber eine ID, die sog. "UUID", die in einem System eindeutig sein sollte.

Die UUID eine Filesystems ist eine (hoffentlich eindeutige) Kombination aus alphanumerischen Zeichen. S. die nachfolgende Abbildung:

Die UUID vorhandener Partitionen kann man sich mit vielen Partitionstools und auch dem Kommando "tune2fs" anzeigen lassen. Ein geeignetes Kommando für die Kommandozeile ist aber auch "blkid". Testet man unmittelbar nach unserem Kopiervorgang von "/dev/sdf7" auf "/dev/sdf9", so erhält man

myexp:~ # blkid | grep "sdf7\|sdf9"
/dev/sdf7: UUID="96c9a3bf-60fe-496e-801c-3a3047ac71a9" TYPE="ext4" PARTLABEL="primary" PARTUUID="85c6892a-d709-4a3f-9758-d521a7a11f68"
/dev/sdf9: UUID="96c9a3bf-60fe-496e-801c-3a3047ac71a9" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="6b579030-567a-4c7a-b705-34b55113d6d5"

Diese leider von uns selbst erzeugte Uneindeutigkeit hat nach dem Kopiervorgang noch keine unmittelbaren Folgen. Der Befund ist aber dennoch außerordentlich problematisch, denn es gilt:

Aktuelle Linux-Distributionen identifizieren zu mountende oder im Bootprozess anzusprechende Filesysteme (bzw. Partitionen) nämlich genau über die "UUID".

Siehe zu der Thematik auch: https://wiki.ubuntuusers.de/UUID/. Unter Opensuses "YaST Partitioner" gibt es hierzu übrigens eine Grundeinstellung, die man auch modifizieren kann:

Unter Linux steuert u.a. die Datei "/etc/fstab" bekanntermaßen das Mounten von Filesystemen - u.a. auch des root-Filesystems - in bestimmten Phasen des Systemstart mit. Werden nun die zu mountenden Filesysteme (Partitionen) in der Datei "/etc/fstab" tatsächlich durch UUIDs gekennzeichnet, können schon beim nächsten Bootvorgang ernsthafte Probleme auftreten; es gibt nach unserer Partitionskopie mittels "dd" ja zwei Filesysteme mit derselben UUID!

Noch schlimmer werden die Verhältnisse, wenn wir auch noch die Grub2-Konfiguration unter Einschluss aller bootbaren Installation updaten; das ist dann ein sicherer Weg in den Abgrund; mit Doppelmounts auf "/" und nachfolgenden Katastrophen ist zu rechnen!

Deshalb gilt:

Warnung: Bevor man irgendetwas nach dem bitweisen Kopieren einer Partition in einen andere auf dem Datenträger ein und desselben aktiven Systems unternimmt, sollte man unbedingt die UUID des kopierten Filesystems ändern, sowie die Einträge in den dortigen Dateien "/etc/fstab" und "/boot/grub(2)/grub.cfg" an die neue Situation anpassen.
Nur dann werden wir die kopierten Installationen auch ohne Probleme bootfähig zu bekommen! Auf keinen Fall sollte man vor Erledigung dieser Schritte im aktuell gebooteten System die Bootloader-Konfiguration neu schreiben lassen.

Ändern der UUID im Filesystem der kopierten Partition

Wie ändert man die UUID eines (kopierten) Filesystems? Hierzu braucht man zwei Schritte:

  • Schritt 1: Generieren einer neuen UUID mittels des Befehls "uuidgen"
  • Schritt 2: Ändern der UUID auf der kopierten Partition mittels des Kommandos "tune2fs device -U newUUID"

Wir führen das mal am Beispiel unseres kopierten Filesystem auf der Partition "/dev/sdf9" durch:

myexp:~ # uuidgen 
a65d6a9b-cc87-4af7-95bf-f407f463f344
myexp:~ # tune2fs /dev/sdf9  -U a65d6a9b-cc87-4af7-95bf-f407f463f344
tune2fs 1.42.11 (09-Jul-2014)
myexp:~ # blkid | grep "sdf7\|sdf9"
/dev/sdf7: UUID="96c9a3bf-60fe-496e-801c-3a3047ac71a9" TYPE="ext4" PARTLABEL="primary" PARTUUID="85c6892a-d709-4a3f-9758-d521a7a11f68"
/dev/sdf9: UUID="a65d6a9b-cc87-4af7-95bf-f407f463f344" TYPE="ext4" PARTLABEL="Linux filesystem" PARTUUID="6b579030-567a-4c7a-b705-34b55113d6d5"

Damit sind wir aber keineswegs fertig ...

Anpassen der Datei "/etc/fstab" und der "/boot/grub2/grub.cfg" im kopierten Filesystem

Bevor wir den Bootloader neu schreiben lassen, ändern wir zunächst die Dateieen "/etc/fstab" und zur Sicherheit auch der "/boot/grub2/grub.cfg" ab. Hierzu mounten wir das frisch kopierte Filesystem im aktuell gebooteten System - z.B. auf "/mnt" -und ersetzen in der dortigen "fstab" (also in der /mnt/etc/fstab") die Einträge mit der alten UUID:

myexp:~ # mount /dev/sdf9 /mnt
myexp:~ # cat /mnt/etc/fstab
UUID=d9a73a89-b89b-4fda-8c4c-9034e42d1274       swap    swap    defaults 0 0 
UUID=96c9a3bf-60fe-496e-801c-3a3047ac71a9       /       ext4    acl,user_xattr 1 1 
UUID=73B4-E5BA  /boot/efi       vfat    umask=0002,utf8=true 0 0 
UUID=24f67362-236e-49ea-ba38-31c1c2541630       /projekte       ext4    defaults 1 2 
....
....

Problematisch ist vor allem der zweite Eintrag, der noch die kopierte UUID beinhaltet! Diese UUID ändern wir nun mit Hile eines Editors unserer Wahl auf die neue - per uuigen generierte und per tune2fs zugeordnete - UUID ab:

# cat /mnt/etc/fstab
UUID=d9a73a89-b89b-4fda-8c4c-9034e42d1274       swap    swap    defaults 0 0 
UUID=a65d6a9b-cc87-4af7-95bf-f407f463f344       /       ext4    acl,user_xattr 1 1 
UUID=73B4-E5BA  /boot/efi       vfat    umask=0002,utf8=true 0 0 
UUID=24f67362-236e-49ea-ba38-31c1c2541630       /projekte       ext4    defaults 1 2 
....

Damit haben wir schon mal größeres Unglück verhindert. Eine Anpassung der "/etc/fstab" ist der wichtigste Schritt.

Ganz auf die sichere Seite gegenüber späteren manuell verursachten Fehlern kommen wir aber erst mit entsprechenden Änderungen in der Datei "/mnt/boot/grub2/grub.cfg" - oder aber einer Elimination der Datei für das (versehentliche) Schreiben des Bootloaders unter der neuen Installationm. .

In der "/mnt/boot/grub2/grub.cfg" finden sich Boot-Einträge der Form

menuentry 'openSUSE 42.2 (x86_64) (on /dev/sdf7)' --class suse --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-96c9a3bf-60fe-496e-801c-3a3047ac71a9' {
	insmod part_gpt
	insmod ext2
	set root='hd5,gpt7'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd5,gpt7 --hint-efi=hd5,gpt7 --hint-baremetal=ahci5,gpt7  96c9a3bf-60fe-496e-801c-3a3047ac71a9
	else
	  search --no-floppy --fs-uuid --set=root 96c9a3bf-60fe-496e-801c-3a3047ac71a9
	fi
	linuxefi /boot/vmlinuz-4.4.104-18.44-default root=UUID=96c9a3bf-60fe-496e-801c-3a3047ac71a9 ro resume=/dev/disk/by-uuid/d9a73a89-b89b-4fda-8c4c-9034e42d1274 splash=silent quiet showopts elevator=deadline intel_pstate=disable swapaccount=1 pti=on
	initrdefi /boot/initrd-4.4.104-18.44-default
}
submenu 'Advanced options ......
....
......

Würden wir diese "grub.cfg" (nach einem Booten der kopierten Installation) dummerweise direkt zur Implementierung des Bootloaders per "grub-install" nutzen, gäbe es ein vermeidbares Chaos.

In der Datei müssen wir deshalb natürlich alle Strings "96c9a3bf-60fe-496e-801c-3a3047ac71a9" ersetzen durch "a65d6a9b-cc87-4af7-95bf-f407f463f344". Das geht mit Editoren wie "kate" relativ gefahrlos.

Ein noch einfacherer Schritt zur Absicherung gegenüber späteren potentiellen Unglücken durch manuelle Befehle zum Schreiben des Bootloaders ohne vorherige Neugenerierung der "boot.cfg" ist, die Datei schlicht umzubenennen - und damit für versehentliche Installationen auszuschalten:

    
myexp:~ # mv /mnt/boot/grub2/grub.cfg /mnt/boot/grub2/grub_before_copy_180219.cfg_orig

Bootfähigkeit der neuen Installation herstellen

Natürlich schreiben wir den Bootloader aber eher von der funktionierenden "ursprünglichen" Hauptinstallation aus. Haben wir die "etc/fstab" in er kopierten Partition auf die neue UUID angepasst, können wir - ohne vorheriges Verändern des Grub2-Bootloaders - unser System getrost neu booten und dabei die ursprüngliche Hauptinstallation starten. Von dort aus nehmen wir nun eine Erweiterung des Bootloaders vor, so dass dei neue "Fallback"-Installation später im Grub2-Bootmenü mit angeboten wird.

Unter Opensuse nutzen wir dazu YaST's Bootloader-Modul:

Dieses Programm bietet 3 per Reiter (Tabs) erreichbare Konfigurationsseiten an. Die letzte ist für unsere Zwecke am wichtigsten und sieht wie folgt aus:

Hier müssen wir die Option "Fremdes OS testen" abhaken.

[Zu alternativen CLI-Kommandos "grub_mkconfig", "update-grub" (Ubuntu) bzw. "grub2-mkconfig" (Opensuse) und "grub-install" siehe den letzten Beitrag und die Doku eurer Distribution. Unter Opensuse Leap prüft "grub2-mkconfig" durch Aufruf des "os-prober"-Skripts fremde OS gleich mit und schreibt den gesamten Output defaultmäßig in die "/boot/grub2/grub.cfg".]

Danach finden wir in der Datei "/boot/grub2/boot.cfg" Einträge folgender Art zum Filesystem auf "/dev/sdf9" vor:

 
....
### BEGIN /etc/grub.d/30_os-prober ###
...
...
menuentry 'openSUSE 42.2 (x86_64) (auf /dev/sdf9)' --class suse --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-a65d6a9b-cc87-4af7-95bf-f407f463f344' {
	insmod part_gpt
	insmod ext2
	set root='hd5,gpt9'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd5,gpt9 --hint-efi=hd5,gpt9 --hint-baremetal=ahci5,gpt9  a65d6a9b-cc87-4af7-95bf-f407f463f344
	else
	  search --no-floppy --fs-uuid --set=root a65d6a9b-cc87-4af7-95bf-f407f463f344
	fi
	linuxefi /boot/vmlinuz-4.4.104-18.44-default root=/dev/sdf9
	initrdefi /boot/initrd-4.4.104-18.44-default
}
submenu 'Erweiterte Optionen für openSUSE 42.2 (x86_64) (auf /dev/sdf9)' $menuentry_id_option 'osprober-gnulinux-advanced-a65d6a9b-cc87-4af7-95bf-f407f463f344' {
	menuentry 'openSUSE 42.2 (x86_64) (auf /dev/sdf9)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.4.104-18.44-default--a65d6a9b-cc87-4af7-95bf-f407f463f344' {
		insmod part_gpt
		insmod ext2
		set root='hd5,gpt9'
		if [ x$feature_platform_search_hint = xy ]; then
		  search --no-floppy --fs-uuid --set=root --hint-bios=hd5,gpt9 --hint-efi=hd5,gpt9 --hint-baremetal=ahci5,gpt9  a65d6a9b-cc87-4af7-95bf-f407f463f344
		else
		  search --no-floppy --fs-uuid --set=root a65d6a9b-cc87-4af7-95bf-f407f463f344
		fi
		linuxefi /boot/vmlinuz-4.4.104-18.44-default root=/dev/sdf9
		initrdefi /boot/initrd-4.4.104-18.44-default
	}

Diese Einträge im Boot-Menü hat YaSTs Bootloader-Modul dann auch schon gleich auf der Platte verewigt. Sie werden beim nächsten Bootvorgang mit angeboten.

Damit haben wir unsere durch "dd" erzeugte "Fallback-Installation" auf "/dev/sdf9" bootfähig verankert.

Experimental-Installation und Upgrade

Eine Experimental-Installation" erzeugt man in einer weiteren Partition auf ganz ähnliche Weise wie oben beschreiben und macht auch diese nach UUID-Änderung und Anpassung der dortigen "/etc/fstab" bootfähig. Für die Experimentalinstallation kann man dann eine probeweises Upgrade vornehmen. (Im Beispiel von Opensuse Leap 42.2 auf Leap 42.3 ...).

Andere Einstellungen in der "/etc/fstab"

Das "Gefährliche" bestand bei unserem Vorgehen vor allem in der Duplizierung der UUID - und eventuellen diesbezüglichen Einstellungen in der "/etc/fstab". Natürlich kann man die Einträge in der "/etc/fstab" auch auf Basis konventioneller Laufwerksbezeichnungen ("dev/sdxn") vornehmen.
Der Yast-Partitioner bietet hierfür sogar eine Einstellungsoption an:

Einträge mit normalwer Bezeichnung sähen so aus:

 
/dev/sdf9       /       ext4    acl,user_xattr 1 1 

Dies befreit aber aus einer Vielzahl von Gründen nicht davon, die UUID des Filesystems trotzdem abzuändern.

SSDs - und Intervalle für Partitionskopien

Eine Kopie größerer Partitionen durchzuführen ist schreibintensiv. Nicht alle SSDs haben eine hinreichende Qualität, um solche Schritte oft durchführen zu können. Die SSD leidet darunter (wear leveling count). Man sollte die Erstellung einer neuen "Fallback-Installation" als Kopie der Hauptinstallation daher nur in größeren Zeitabständen vornehmen.

Hat man gute Erfahrungen mit Updates sowohl in der Experimental-Installation als auch auf der Hauptinstallation gemacht, spricht ja nichts dagegen, Updates auch auf der Fallback-Installation systematisch und kontrolliert nachzuziehen. Nur vor Upgrades erscheint mir die Anlage einer Fallback-Installation als Kopie der aktuellen Hauptinstallation unvermeidlich.

Ich hoffe, der eine oder andere hat beim Lesen ein paar Dinge aufgeschnappt, die er noch nicht kannte ...

Links

Übersicht GPT
https://en.wikipedia.org/wiki/GUID_Partition_Table
https://de.wikipedia.org/wiki/GUID_Partition_Table
https://www.thomas-krenn.com/de/wiki/GUID_Partition_Table

Übersicht Linux Partitioning Tools
http://dwaves.de/2017/05/23/linux-overview-partitions-difference-fdisk-gdisk-cfdisk-parted-gparted/

Partition Alignment
https://www.thomas-krenn.com/de/wiki/Partition_Alignment

UUID ändern
http://www.sudo-juice.com/how-to-change-the-uuid-of-a-linux-partition/

Backups mit dd
https://www.linux.com/learn/full-metal-backup-using-dd-command
https://wiki.archlinux.de/title/Image-Erstellung_mit_dd
https://www.thegeekstuff.com/2010/10/dd-command-examples/
http://www.linux-community.de/Archiv/Tipp-der-Woche/Mit-dd-schnell-Festplattenimages-erstellen
https://www.thomas-krenn.com/de/wiki/Dd_unter_Linux