Hallo zusammen,
ich wollte die Idee von @tuxnix aufgreifen und meine separate /home Partition (/dev/sda6) auflösen und das home Verzeichnis unterhalb von / anlegen. Den gewonnenen Speicherplatz von /dev/sda6 möchte ich anschließend mit /dev/sda8 vereinen.

So sieht es im Moment aus:
lsblk -f

NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 931,5G 0 disk
├─sda1 8:1 0 579M 0 part
├─sda2 8:2 0 145,9G 0 part
├─sda3 8:3 0 500M 0 part /boot
├─sda4 8:4 0 1K 0 part
├─sda5 8:5 0 120G 0 part /
├─sda6 8:6 0 80G 0 part /home
├─sda7 8:7 0 10G 0 part [SWAP]
└─sda8 8:8 0 574,5G 0 part /blender

Ich würde Ganze in zwei Schritten angehen:

1. anlegen eines /myhome Verzeichnisses unter /

2. Inhalt von der /home Partition nach /myhome kopieren

3. unmounten der /home Partition im laufenden System

4. umbenennen vom /myhome nach /home

5. auskommentieren von /home in der Datei /etc/fstab
   reboot
   schauen was passiert

6. reboot
   7 booten mit gparted usb stick von @Greg

7. beide Partitionen mit gparteted vereinen.

Geht das Ganze gegen den Baum?
Danke für eure Hilfe
LG

@Henrikx
Lob höre ich immer gerne. Dankeschön. Positives feedback motiviert.
Außerdem trommele ich hier auch ein wenig in eigener Sache, damit ich, falls das mal nötig sein sollte auch dann mal Kritik zu hören bekomme. 😉

Du darfst gerne mein Skript testen. Sag einfach bescheid. Mit @Greg zusammen hat das ganz ganz viel gebracht. (Danke dir nochmal an dieser Stelle)
Ich hab es nur von Gitlab einstweilig wieder gelöscht weil daran noch gearbeitet werden muss und ich keinen Stress damit haben möchte.
Außerdem fand ich es erst einmal viel wichtiger, dass es noch ein paar mehr Spickzettel gibt.

Ich bin gegen einen offizielle Arch Linux Installer. Selbst wenn und gerade dann, wenn er irgendwann mal alles macht und kann.
Mehr und mehr, vertrete ich die Meinung, dass der größte Unterschied von Arch Linux zu andern Distributionen der User selbst ist.

So viel wird einem ja gar nicht abverlangt wenn man Arch selbst installiert. Man ist dann noch lange kein Admin oder Informatiker. Aber um nochmal den Autovergleich zu strapazieren. Man lernt dabei eben nicht nur theoretisch, dass irgendwann Benzin nach zu füllen ist, man lernt bei der Arch Installation so etwas (im Vergleich) wie etwa, wie man dann auch den Tankdeckel konkret öffnet und hat dann sogar auch schon den passenden Schlüssel in der eigen Hand, für denn Fall, dass man auch mal an eine Tankstelle muss.

Shei9Xoo schrieb Skripts haben meistens den Nachteil, dass sie nicht interaktiv agieren und damit nur einen begrenzten Einsatz ermöglichen. Damit kann man vielleicht sein eigenes System schnell generieren, es ist aber nicht universell einsetzbar.

Genau das ist der Punkt. Und genau diesen Punkt mache ich mir dabei auch zu nutze. 😉

Entscheidend ist ja der Weg unnd die Methode die man wählt. Der User möchte ein neues System auf seinem Rechner:
a) Er wählt ein Programm mit dem Namen "Installationsprogramm" das alles kann. Dann drückt er Buttons oder macht irgendwelche programm-spezifischen Eingaben und das Programm macht den Rest.
Er braucht noch nicht einmal eine Vorstellung davon zu haben, was er will oder was hinterher herauskommen soll. Ist das Programm gut, wird dabei immer etwas herauskommen was den Namen Installation verdient hat. Im bestenn Fall hat der User dann ein funktionierendes System. Er selbst hat aber lediglich den Umgang mit diesem einen Tool gelernt. In den Foren wird dann heiß darüber diskutiert welchen Knopf man drücken muss, oder ob man im Programmablauf an passender Stelle mit y oder n antwortet. Aber weiter kommt damit niemand.

b) Der User macht sich zuerst einmal Gedanken darüber, was er denn am Ende haben möchte und erst danach wählt das passende spezifische Werkzeug für das gewünschte Ergebnis.
Gleichzeitig sind die scripts die er benutzt so transparent, dass er jederzeit nachvollziehen kann was da geschieht und kann sie falls einmal nötig auch selbst abändern. Jedenfalls bleibt das Verfahren so nah an der eigentlichen Materie, dass keine Entfremdung eintritt.

Ich bin der Meinung, dass der interessierte User, der auch mal selbst Benzin nachfüllen möchte zumindest einmal im Leben die Installation selbst händisch gemacht haben sollte.
So schwer ist das ja nicht. Auch dafür gibt es die Spickzettel. Man muss gar nichts vorher wissen, man muss auch nicht vorher die ganze Wiki gelesen haben. Es genügt ein paar Befehle der Reihe nach ab zu tippen, genau so, wie sie da stehen.
Trotzdem hat man viel gelernt dabei. Man musste sich vorher entscheiden und sich ein wenig Gedanken darüber machen was das Ergebnis sein soll. Dies halte ich für den wichtigsten Unterschied dabei. Und man hat gleichzeitig ganz nebenbei erlebt, was die Befehle die man eintippt machen und sich damit auch das Werkzeug angeeignet, dass man hinterher universell gebrauchen kann.
Wie man Linux auf den Computer bringt, kann dem Computer egal sein. The Arch Way ist aber zusätzlich ein Weg, den User zu befähigen und nur so macht es hinterher auch Spaß sich im Forum mit ihm zu unterhalten.

Mein Installationsskript soll lediglich demjenigen, der die drei Befehle schon auswendig kann, die nächste Installation erleichtern.
Es gibt eine malis.conf Datei. Da trägt man die Einstellungen ein, die man bei jeder Installation braucht und die bei den meisten auch fast immer gleich bleibt.
An diesen Sachen ändert sich auch nur selten etwas und dann auch nur wenn man z.B. dauerhaft den Wohnsitz oder die eigene Muttersprache wechselt.

Zusätzlich stehen in dieser Datei die Pakete die man installiert haben möchte. Auch hier ändert sich für den konkreten user oft nur wenig. Meistens nimmt man für eine neue Installation die gleichen Programme wie bei der letzten Installation. Will man felxibel sein und einmal GNOME statt plasma, dann kann man sich diese Datei auch zweimal anlegen.

Der Rest läuft im Grunde genommen wie bei den Spickzettel ab.
Man startet eine bios-grub.sh für ein BIOS-System mit grub als bootloader und wenn man ein UEFI Rechner hat, startet man ein UEFI-grub.sh skript.
Beide greifen auf die malis.conf zurück, in der die Einstellungen stehen.

Natürlich muss ich noch an vielen Detais arbeiten, damit dieses Baukastensystem so einfach wie möglich ist und gleichzeitig hoch flexibel bleibt.
Es muss aber was meine Erewartung betrifft, nie ein offizielles Tool für Arch Linux werden.
Da ist dann der Name auch Program. "My Arch Linux Installer" soll für jeden der das möchte, zu dem eigenen Arch Linux Installer gemacht werden können.
Es ist ein Bausatz System. Das was du damit baust bleibt aber immer deine Sache.

Zu Anschauung mal hier die malis.conf. Viel dolles ist da gar nicht. Im Gegenteil es ist alles recht einfach und simpel.

#!/usr/bin/env bash

# Set your own values and save this file as 'malis.conf'

Device=sdb
Ucode=intel-ucode                           # amd-ucode, intel-ucode
Grafikdriver=xf86-video-intel               # xf86-video-amdgpu, xf86-video-intel, f86-video-nouveau
User=duda
UserGroups=(wheel audio video power)
Hostname=mypc

LocaleLANG=de_DE.UTF-8
VconsoleKey=de-latin1
VconsoleFont=lat9w-16
TimeZone=Europe/Berlin
LocaleGen=de_DE
                                            # Search for values with command:
Layout=de                                   # localectl list-x11-keymap-layouts |less
Model=thinkpad                              # localectl list-x11-keymap-models |less
Variant=deadgraveacute                      # localectl list-x11-keymap-variants |less
Options=                                    # localectl list-x11-keymap-options |less

Kernel=(linux)                              # linux, linux-lts, linux-hardened

Gui=(kwin plasma-desktop plasma-nm konsole sddm)                       
Dictionarys=()
Editor=(nano)
Office=()
Browser=()
Email=()
Others=(reflector)
Services=(acpid)

ActivateServices=(acpid avahi-daemon NetworkManager iwd systemd-timesyncd reflector.timer cups sshd sddm)

gerry_getto schrieb...und eine unverschlüsselte /boot ist in deinem Fall sicher genug.

Sollte bestimmt heißen:...und ein verschlüsseltes root ist in deinem Fall sicher genug!

@Greg
Ich finde deine Anleitung klasse und werde schauen ob ich das die Tage in der Wicki als Spickzettel herausgeben kann.
Hier schon mal vorab die allgemeine Bitte, den Spickzettel dann doch noch mal durch zu lesen wenn es soweit ist. (Nur nochmal zur Kontrolle, falls ich was übersehen sollte)
Die Einrichtung der Swap-Partition lasse ich aber dabei weg. (Die bliebe ja nach deiner Anleitung nach doch unverschlüsselt was dem "Schutzziel Vertraulichkeit" schaden tut.
Der Fragesteller hier, will ja auch gar keine Swap-Partition, sonst hätte ich hier schon eher was dazu gesagt.

Icecube63 schrieb Auch das ist normal, und nicht Manjaro-Spezifisch. Und das mit Grub glaub ich dir nicht, selbst wenn sie da was vorgegeben hätten wäre das ja einfach änderbar

Mag sein, dass das mit /run Arch-spezifisch ist. Aber nicht Linuxtypisch
https://de.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Hauptverzeichnisse


Das mit Grub ist aber so: https://de.manjaro.org/index.php?topic=7419.msg47873#msg47873

Das ist aber, wenn ich dich recht verstanden habe, ein Ubuntu-Grub. Wie schon gesagt wurde, Grub von Ubuntu kann kein Manjaro booten. Du musst also dieses Grub mit dem Manjaro-Grub überschreiben, indem Du bei der Installation von Manjaro sagst, daß dessen Grub nach sda installiert werden soll.

Man kann es womöglich ändern, aber Fakt ist, z. B. Ubuntu kann Manjaro-Grub nicht starten.

@Greg. Super! Das war der korrekte Befehl. Danke, sehr sehr hilfreich!
Mit pacman -S man-pages-de

So. Erst einmal allen ein gesundes neues Jahr.

@Greg, vielen Dank für deine ausführliche Hilfe. Ich bin noch am Tüfteln, wie ich das hinbekomme. Der erste Versuch ging jämmerlich in die Hose. Mein System wurde unbootbar. Deshalb, und weil es eigentlich noch jungfräulich war, habe ich es neu installiert. Jetzt beginnt Versuch Nummer 2. Nun bin ich an dem Punkt, wo ich neu boote. Ich berichte später.

Mist. Der zweite Versuch endete ebenfalls mit einer Kernel-Panik beim Booten.
Ich bin nun mit meinen Latein am Ende.
Wie kann ich nun, ohne eine Neuinstallation, den alten Kernel wieder herstellen? In einer chroot-Umgebung Linux neu installieren funktionierte nicht.

https://wiki.archlinux.org/index.php/EFISTUB#Using_a_startup.nsh_script

startup.nsh

vmlinuz-linux rw root=/dev/sdX [rootfs=myfs] [rootflags=myrootflags] [kernel.flag=foo] [mymodule.flag=bar] [initrd=\intel-code.img] initrd=\initramfs-linux.img

Danke, die Sache war, ist ja nicht ganz unerheblich, aber wie setze ich das um?
Wie finde ich /dev/sdX ?

Gehört das Script in den Guest oder in den Host?

Ist das ein Bug oder so gewollt von Archlinux bzw. Virtualbox?

@Greg
Behebt das dein qemu-kvm Problem auch?

Dirk schrieb

Minihawk schriebGummiboot ist ein immer noch genutzer Name

Seit fast 5 Jahren nicht mehr, nein.

Minihawk schriebAlso ist die Frage "Benutzt Du wirklich Arch" völlig fehl am Platze,

Nein, ist sie nicht. Aber um das ganze mal ein bisschen einzugrenzen, führe mal bitte uname -rms aus, und zeige die Ausgabe.

Kannst Du lesen? -> https://wiki.archlinux.de/title/UEFI_Installation "Systemd bootctl (ehemals Gummiboot)"

uname wirft folgendes aus: Linux 5.2.2-arch1-1-ARCH x86_64

@Greg: Danke für den Tipp, werd ich versuchen...

Ich habe das jetzt anders hingekriegt. Es ist, wie Du vermutest, so, dass Windows und Linux unterschiedliche EFI-Boot-Partitionen.
Meine "Lösung" ist wohl keine, aber funktioniert so lange, wie kein anderes Boot-Medium vorhanden ist (CD, wahrscheinlich auch bei STicks.

Ich habe einen Eintrag erstellt, der folgendermaßen lautet:

title Windows
efi /EFI/Microsoft/Boot/bootmgfw.efi

Wähle ich den WIndows-Eintrag aus, so wird zweimal angezeigt, dass der Pfad nicht stimmt, dann Windows gestartet, oder halt die CD, wenn eine im laufwerk steckt.

Ich finde es jedenfalls toll, dass es hier auch User gibt, die des Lesens mächtig sind und nicht auf Krawall gebürstet... Danke!

PS: So einfach klappt es bei mir wohl nicht. EFI-Partition bei Windows wohl irgendwie anders als bei Dir. Werde das wohl auch mal in der Virtualbox ausprobieren...