@FrankM
halli hallo,
ein vorschlag von mir dazu.
das root ist nach dem o.g. prozedere nun auf der nvme platte. kernel und konsorten sind weiterhin auf der sd/emmc. Weil der uboot nur das findet. Soweit so gut. Wenn mit laufendem root nun ein neuer kernel und konsorten erzeugt werden, müssen die auf sd/emmc, weil sonst nicht verwendet.
Das lässt sich am einfachsten erledigen, indem man sd/emmc als boot in das root mounted. Das ist quasi ein einblenden. Wie auch immer man das erledigt (fstab, autofs/manuell/etc/pp/sucht euch was aus). Dann arbeitet der ganze prozess immer schon auf dem ziel und legt keine kopien an.
gruß
Danke @kosmonaut-pirx , ich habe da schon ein paar Mal drüber nachgedacht und heute Morgen auch kurz ein paar Tests gemacht, aber da bin ich irgendwie zu blöd für 
Da ich aktuell auch nicht vor habe, den Kernel zu updaten lass ich es erst mal so. Würde mich aber freuen, wenn jemand eine funktionierende Lösung hat.
Das steht aktuell in der Datei /etc/fstab
LABEL=boot /boot/efi vfat defaults,sync 0 0
@FrankM
naja, dein fstab entry mounted nur nach /boot/efi. D.h. irgendwoher kommt das /boot parent schon. Gehört vielleicht zum root dazu, das weiß ich aber nicht. Und ich gehe mal davon aus, dass dein kernel unter /boot liegt und nicht unter /boot/efi
als ein beispiel: hier einmal meine partitionstabelle:
code_textGerät Anfang Ende Sektoren Typ-UUID UUID Name Attr.
/dev/mmcblk0p1 64 8063 8000 0FC63DAF-8483-4772-8E79-3D69D8477DE4 D44AD46E-C52B-4CB4-9C75-7CC0F6AACFF7 loader1
/dev/mmcblk0p2 8064 8191 128 0FC63DAF-8483-4772-8E79-3D69D8477DE4 C9C0BC0D-6DAC-4A00-B35F-7222CDD9AEA9 reserved1
/dev/mmcblk0p3 8192 16383 8192 0FC63DAF-8483-4772-8E79-3D69D8477DE4 465252D7-4F2C-4476-826C-609F1060C307 reserved2
/dev/mmcblk0p4 16384 24575 8192 0FC63DAF-8483-4772-8E79-3D69D8477DE4 464A9658-E15B-4ACA-8DD9-7B105807324C loader2
/dev/mmcblk0p5 24576 32767 8192 0FC63DAF-8483-4772-8E79-3D69D8477DE4 D22AE41D-5CEE-4BF0-B35D-ED193830B54A atf
/dev/mmcblk0p6 32768 262143 229376 EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 277BAD52-9EB3-4A1E-842C-C584A1822F2B boot
/dev/mmcblk0p7 262144 876543 614400 0FC63DAF-8483-4772-8E79-3D69D8477DE4 0E38AF18-077C-4AE2-89E1-DD2680E47C6D root LegacyBIOSBootable
/dev/mmcblk0p8 876544 15269854 14393311 0FC63DAF-8483-4772-8E79-3D69D8477DE4 A56E8046-FCAD-5243-9A87-D7DED604866E
sieht vermutlich überall ähnlich aus. dazu ein paar notizen:
bei mir ist das fstab dann entsprechend
UUID=928fbf89-87f9-45c0-8f26-d6b6ad15e9f3 /boot ext4 noatime 1 2
UUID=e62dbec1-7b17-4242-b133-1a98d1aaf32b / ext4 noatime 0 1
LABEL=boot /boot/efi vfat defaults,sync 0 0
erster eintrag ist da wo der kernel liegt (ja die uuids passen nicht zu denen aus o.g. liste), zweiter eintrag ist das sys root, und dritter eintrag wie bekannt. Damit hat man das /boot gefüllt mit dem, was der uboot "sieht"
gruß
Vielen Dank für den Tipp. Ich habe da heute Morgen mal mit rumgespielt, jetzt ist die Installation kaputt
Ein Image vom Kamil, bionic-minimal, was ich schon von Anfang an nur benutze sieht wie folgt aus.
rock64@rockpro64:~$ sudo blkid
/dev/mmcblk0: PTUUID="57682308-b92c-4d66-ae74-9f0ad2059819" PTTYPE="gpt"
/dev/mmcblk0p1: PARTLABEL="loader1" PARTUUID="58c8a80d-a7fb-4b74-a7fc-414be0a692ff"
/dev/mmcblk0p2: PARTLABEL="reserved1" PARTUUID="91b9a739-2540-423a-a1b0-2da8a1645c11"
/dev/mmcblk0p3: PARTLABEL="reserved2" PARTUUID="2d4c9c31-153f-43da-a9d9-8ed60581b2c4"
/dev/mmcblk0p4: PARTLABEL="loader2" PARTUUID="df727104-fb01-4622-b983-612af8220f6a"
/dev/mmcblk0p5: PARTLABEL="atf" PARTUUID="ca76f1f0-b226-471c-b181-71b2370c64b1"
/dev/mmcblk0p6: SEC_TYPE="msdos" LABEL="boot" UUID="2C5B-5CAF" TYPE="vfat" PARTLABEL="boot" PARTUUID="4c5e58d7-b449-49d7-ae30-e519c8c206cb"
/dev/mmcblk0p7: LABEL="linux-root" UUID="d4e1b4d0-338c-42ec-86f2-6890d3e61eea" TYPE="ext4" PARTLABEL="root" PARTUUID="4f0eec35-c6c0-420a-b56f-86b75901d1f1"
/dev/nvme0n1: LABEL="TEST" UUID="378c1065-8e5b-462c-8773-57e258720299" TYPE="ext4"
zram mal rausgelöscht. Das war der Zustand, nachdem ich das Rootsystem auf die NVMe SSD gelegt hatte und neugestartet habe.
Sieht dann so aus
rock64@rockpro64:~$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 992M 0 992M 0% /dev
tmpfs 200M 452K 199M 1% /run
/dev/nvme0n1 229G 1.3G 216G 1% /
tmpfs 996M 0 996M 0% /dev/shm
tmpfs 5.0M 4.0K 5.0M 1% /run/lock
tmpfs 996M 0 996M 0% /sys/fs/cgroup
/dev/mmcblk0p6 112M 4.0K 112M 1% /boot/efi
tmpfs 200M 0 200M 0% /run/user/1000
Ich habe dann versucht, die partition7 nach /boot einzuhängen, das funktionierte auch so weit.
Dann habe ich natürlich auf /boot das ganze Filesystem eingehangen. Bringt nix. Hmm!?!?
Habe dann versucht das Ganze nach /media zu mounten und zusätzlich den Ordner boot von der Partition7 nach /boot.
# Ganze Partition in /media einbinden:
UUID=bbf85ecb-cc61-40ed-ba7b-d7b804ee845e /media ext4 defaults 0 0
# Ordner "boot" zusätzlich in /boot einbinden:
/media/boot /boot none bind 0 0
Das funktionierte so weit auch gut, reboot war einwandfrei. Mit df -h sah auch alles gut aus. Dann einen anderen Kernel installiert, sah immer noch gut aus, nach dem Neustart war das System platt. Seltsamerweise irgendwas mit der MMC-Karte!?
Nein, das ist nicht mein Spezialgebiet 
@FrankM
hm..
Dann habe ich natürlich auf /boot das ganze Filesystem eingehangen. Bringt nix. Hmm!?!?
was meinst du damit, das ganze filesystem? wenn du partition p7 so mountest, solltest du die kernel/initrd/dtb geschichte sehen. Da fehlt dann das efi dingens, weil das von der anderen partition p6 kommt. kA ob man das braucht.
in p7 bzw /boot ist dann das extlinux, was alles beschreibt. was da jetzt nicht passt, schwer zu sagen von ausserhalb. klar müssen vmlinuz (oder wie auch immer genannt) initrd (wie auch immer gen..) und dtb (wie auc..) noch da sein.
für den rest steht man grad auf dem schlauch, was nicht tun sollte. im prinzip ist das alles logisch
I only recently found this forum and I like it because it has usefull information for me.
In writing I'm better in English than in German, but reading in German in no problem, so I can understand your posts. I hope you can understand my post in English.
I have a rockpro64 with nvme-card and I managed to put root on it, according to your post above. I have tried to put LVM on my nvme-card and put root on a logical volume on LVM but then I cannot boot anymore. I think the system needs a module to manage LVM at boot, but I don't know how to do that. Do you have a suggestion or a solution?
Hello @ftim ,
first i don't know many about lvm. But i think you will need the kernel-modul.
modprobe lvm-mod
give an error, not found....
When i look into kernel config i found nothing. Please ask Ayufan on IRC or in the forum to build the next release with this module.
hello,
most likely a module will not do it, I guess. Assume the kernel wants to "load" the root. It needs to know lvm functionality for this, in case the root is in a lvolume. Unfortunately, that module is located in (exactly) that lvolume.
In my understanding, here's where the initrd comes into play. But i might be wrong
regards
Für dies Kernal: Linux rockpro64 4.4.167-1213-rockchip-ayufan-g34ae07687fce #1 SMP Tue Jun 18 20:44:49 UTC 2019 aarch64 GNU/Linux
Booten von der NVMe Platte nicht möglich.
Ich folgte die folgende Schritte. Leider funktioniert es nicht. Es gibt einen Fehler in Boot.
Ohne RAID oder LVM config.
Specs:
Rockpro64
Marvel PCIe 88se9230 karte
SANDISK SSD 120 GB