[19:10] <p01nt3r> nabend. habe gestern ubuntu-mate 18.04.1 neu als UEFI installiert. jetzt zeigt mir der nvram leider einen ubuntu-eintrag doppelt an: sudo efibootmgr -> http://paste.ubuntu.com/p/Skw3VsR88z/
[19:10] <le_bot> Title: Ubuntu Pastebin (at paste.ubuntu.com)
[19:12] <p01nt3r> nur "TS128GMTE110S" und "CT250MX500SSD1" besitzen eine GPT, da nur die beiden Laufwerke booten sollen. Der Rest ist noch MBR.
[19:13] <j0k> hm ... ist das nicht das selbe wie in Grub? Da hast Du ja auch einen Eintrag für das aktuelle Ubuntu und dann noch einen um ggf. mit älterem Kernel zu starten
[19:15] <p01nt3r> j0k, ich teste mal eben aus, ob unterschiedliche kernel gebootet werden.
[19:16] <p01nt3r> bg.
[19:20] <p01nt3r> j0k, die grub-einträge der jeweiligen boot-einträge des uefi-menüs sind identisch, bei beiden sehe ich: ubuntu, erweiterte optionen für ubuntu (bei beiden die gleichen kernel-versionen) sowie den boot-eintrag für das windows 10
[19:21] <tomreyn> ob's wirklich das gleiche ist siehst du mit efibootmgr --verbose
[19:22] <tomreyn> kannst dann entweder --remove-dups oder --delete-bootnum machen um eins davon zu löschen
[19:22] <p01nt3r> j0k, tomreyn: http://paste.ubuntu.com/p/NCG66WXWjC/
[19:22] <le_bot> Title: Ubuntu Pastebin (at paste.ubuntu.com)
[19:23] <p01nt3r> als unterschied sehe ich in den einträgen nur hinten einmal "shimx64.efi" und einmal "grubx64.efi"
[19:24] <tomreyn> shim ist die secure boot-kompatible variante
[19:24] <p01nt3r> tomreyn, das ist also normal?
[19:25] <tomreyn> bin mir nicht sicher ob man da standardmäßig zwei einträge angelegt bekommt von grub, aber es scheint an sich logisch
[19:25] <tomreyn> wäre natürlich toll wenn die unterschiedlich heißen würden
[19:25] <p01nt3r> tomreyn, wenn ich secure boot nicht verwende, kann ich den dann einfach so löschen?
[19:25] <tomreyn> ja
[19:26] <tomreyn> kannst es auch löschen und wiede rhin machen mit besserem namen, ganz wie du magst ;)
[19:27] <p01nt3r> es muss weg :-)
[19:27] <tomreyn> nur so krass fortgeschrittene funktionen wie "eintrag umbenennen" kann uefi halt nicht.
[19:27] <p01nt3r> die bootnum wäre in meinem fall dann "Boot0001"?
[19:28] <tomreyn> 0001 ja
[19:30] <tomreyn> ggf. willst du dann noch den anderen ubuntu-eintrag als erstes booten lassen, das geht per --bootorder
[19:30] <p01nt3r> ist es eig. normal dass die ESP-partition mit ext4 partitioniert wird?
[19:31] <tomreyn> nee
[19:31] <p01nt3r> wurde sie aber, wieso auch immer
[19:31] <tomreyn> partitioniert eh nicht, wenn dann formatiert, aber das sollte dein uefi gar nicht booten können
[19:32] <tomreyn> "mount" sagt auch dass es ext4 ist?
[19:33] <tomreyn> kann sein dass gparted das fälschlicherweise als ext4 anzeigt, das sind noch relikte aus der zeit als das tool versucht hat neben einem partitionierungs- auch ein formatierungstool zu sein.
[19:34] <p01nt3r> tomreyn, mount listet die gar nicht auf.
[19:35] <tomreyn> p01nt3r: un fstab?
[19:35] <p01nt3r> im gparted ist da auch ein ausrufezeichen dran
[19:36] <tomreyn> aber du hast davon schon gebootet?
[19:36] <p01nt3r> tomreyn, bin da gerade mit hier.
[19:36] <tomreyn> und in fstab ist die esp drin?
[19:38] <p01nt3r> tomreyn, scheinbar nicht
[19:38] <tomreyn> und was sagt file -s /dev/sd... für die efi-partition?
[19:39] <p01nt3r> kein lese-zugriff
[19:39] <tomreyn> sudo
[19:39] <tomreyn> wie hast du denn das installiert?
[19:40] <p01nt3r> tomreyn, sudo file -s  /dev/sda1 -> /dev/sda1: Linux rev 1.0 ext4 filesystem data, UUID=06c1b15d-02f6-4299-86fb-4a6d05eb93b1, volume name "root" (extents) (large files) (huge files)
[19:40] <tomreyn> falsche festplatte, sollte iegentlich sdb sein
[19:41] <tomreyn> zumindest laut den angaben im nvram
[19:42] <p01nt3r> die allererste (windows boot manager) ist ja eine nvme, deshalb ist die 2. (ssd) sda
[19:43] <p01nt3r> also das 2. laufwerk ist als sda bezeichnet, das 3. als sdb usw...
[19:43] <tomreyn> blkid -t PARTUUID=699078e3-69ac-4102-a29c-2733b7b6f56e
[19:44] <tomreyn> ...sollte dir sagen welche partition es aus linux.sicht ist
[19:45] <p01nt3r> -> /dev/nvme0n1p2: UUID="52DF-6FCD" TYPE="vfat" PARTLABEL="M-nM--M-^@M-MM-^K" PARTUUID="699078e3-69ac-4102-a29c-2733b7b6f56e"
[19:45] <tomreyn> aber ja, verstehe grundsätzlich was du meinst
[19:45] <tomreyn> so da haste deine esp
[19:46] <p01nt3r> tomreyn, wie bist du da jetzt drauf gekommen?
[19:46] <tomreyn> an sich sollte die auch in der fstab drin stehen, falls noch nicht dann solltest du das nachholen
[19:46] <p01nt3r> tomreyn, UUID=52DF-6FCD  /boot/efi       vfat    umask=0077      0       1
[19:47] <tomreyn> p01nt3r: die partitions-uuid ist ja in der -efibootmgr --verbose -ausgabe angegeben http://paste.ubuntu.com/p/NCG66WXWjC/
[19:47] <le_bot> Title: Ubuntu Pastebin (at paste.ubuntu.com)
[19:47] <tomreyn> blkid kann dir zu der partitions-uuid die anderen infos raussuchen, das hast du ja eben gemacht
[19:48] <p01nt3r> tomreyn, ich schlussfolgere: ubuntu hat seine uefi-boot sachen in die esp der nvme geschrieben.
[19:48] <tomreyn> klar, wenn es eine esp gibt dann nutzt der installer die
[19:49] <tomreyn> und hups, war dann wohl doch in der fstab drin, wa? :)
[19:49] <p01nt3r> auf der ubuntuusers seite konnte ich entnehmen, dass immer in diese (1.) esp geschrieben wird. ok. ich wollte aber eig. eine 2. auf der ubuntu ssd erstellen
[19:49] <tomreyn> und gemountet ist sie dann vermutlich auch
[19:49] <tomreyn> kannste zwar machen, aber die wird dann ignoriert
[19:50] <p01nt3r> tomreyn, ja, ich war davon ausgegangen, dass er die boot-geschichten auch in die esp der ubuntu-ssd schreiben würde.
[19:50] <tomreyn> das uefi nimmt immer die erste esp auf dem ersten speichergerät das es zu gesicht bekommt
[19:50] <tomreyn> (und nur die)
[19:50] <p01nt3r> tomreyn, was bedeutet das hinsichtlich des multiboot?
[19:50] <p01nt3r> bzw. dualboot
[19:50] <tomreyn> dass sich alle OS eine ESP teilen
[19:51] <p01nt3r> ist also vollkommen normal wa?
[19:51] <tomreyn> ja
[19:51] <p01nt3r> ich kann also diese komische ext4-esp auf der ubuntu-ssd gefahrlos ohne weiteres löschen?
[19:52] <p01nt3r> tomreyn, oder muss ich dann irgendwas noch anpassen?
[19:52] <k1l> p01nt3r: einer der vorteile von uefi ist eben, dass nicht mehr jede platte ihren eigenen bootloader braucht
[19:52] <tomreyn> du kannst auch versuchen die esp auf die ssd zu verschieben, aber dann musst du das uefi dazu bewegene die ssd als ersten storage zu sehen (es gibt da glaub ich ne bios-option die festlegt ob pci-storages vor anderen (ata-)storages initialisiert werden)
[19:53] <p01nt3r> k1l, fand ich aber auch immer ganz praktisch, wenn beim mbr z.b. grub dahin war konnte man das windows von der anderen platte noch starten, zumindest wenn die nur reinen win-bootcode enthielt
[19:53] <tomreyn> aber windows (ich vermute das ist das andere OS?) müsste dann da auch noch mit klar kommen
[19:53] <p01nt3r> wie verhilete sich das jetzt?
[19:53] <p01nt3r> verhielte, sry
[19:53] <tomreyn> und da wirds dann ja manchmal diffizil
[19:54] <tomreyn> wenn dein esp futsch ist dann bootet nix mehr, so verhält sich das jetz
[19:54] <p01nt3r> tomreyn, also hat es auch nachteile..
[19:54] <tomreyn> also externe storages gehen natürlich noch
[19:55] <tomreyn> gleiches gilt auch fürs nvram
[19:55] <tomreyn> ist das nicht mehr lesbar dann ist doof, neues mainboard her
[19:55] <p01nt3r> tomreyn, es macht also schon sinn, die gpt der nvme zeitnah zu sichern...
[19:56] <tomreyn> die partitionstabelle sichern?
[19:56] <tomreyn> schadet nicht, aber der zweck ist mir in dem zusammenhang jetzt unklar
[19:56] <p01nt3r> tomreyn, oder was würde man dann brauchen im notfall?
[19:57] <tomreyn> ne kopie von der esp und der partitionstabelle könnte helfen wieder zu booten wenn dich das nvme im stich lässt, ja
[19:58] <p01nt3r> tomreyn, was dann passieren würde per "sudo sgdisk -b backup.img"
[19:59] <tomreyn> das sichert die GPT weg, nicht die ESP
[19:59] <p01nt3r> wie bekomm ich die?
[19:59] <tomreyn> bräuchtest dann halt wenn schon beides
[20:01] <p01nt3r> tomreyn, z.b. per dd if=/dev/nvme0n1p2 of=esp.img
[20:02] <tomreyn> ja, oder /dev/disk/by-uuid/52DF-6FCD als quelle, wie du magst
[20:03] <tomreyn> oder /dev/disk/by-partuuid/699078e3-69ac-4102-a29c-2733b7b6f56e
[20:04] <p01nt3r> tomreyn, ergebnis wäre ja das gleiche.
[20:04] <tomreyn> oder /dev/disk/by-partlabel/esp - falls du die so gelabelt hast
[20:04] <tomreyn> ja, alles das gleiche
[20:05] <p01nt3r> tomreyn, auf askubuntu lese ich gerade, dass auch ein "sudo cp -R /boot/efi /path/to/backup" reichen würde, dann würde man das mitkopieren der leeren blöcke mit dd sparen.
[20:05] <tomreyn> kannst es auch noch on the fly komprimieren
[20:05] <p01nt3r> tomreyn, per: sudo tar cfz /path/to/backup/ESP_backup.tar.gz /boot/efi
[20:06] <p01nt3r> ich sichere meine daten eig. gerne im reinformat
[20:06] <p01nt3r> sprich unkomprimiert
[20:06] <tomreyn> p01nt3r: stimmt an sich, aber du musst dann noch die fstab wieder anpassen weil du das vfat neu machen musst und sich dann die fs-id ändert.
[20:06] <p01nt3r> tomreyn, bei dd nicht?
[20:07] <tomreyn> wenn du das ganze dateisystem kompierst dann behält es ja seine uuid
[20:08] <p01nt3r> oder ich pipe dd nach tar/gzip
[20:08] <tomreyn> tar brauchste da an sich nicht, und gzip bringt nicht so viel, besser bz oder xz
[20:10] <tomreyn> den vorteild ie fstabnicht anpassen zu müssen kommt aber natürlich auch nur dann zum tragen wenn du die fstab sicherst ;-)
[20:10] <tomreyn> aber auch wegen windows wäre es wohl gut die esp komplett zu sicher und nicht nur die dateien darauf
[20:11] <p01nt3r> tomreyn, das priorisieren der sata- bzw. pcie laufwerke wird bei meinem bios nicht gehen, da es nativ gar keine nvme unterstützt :-o
[20:11] <tomreyn> ich wette das legt sich mal gepflegt auf die vorderfront wenn du dem ne neue esp unterzuschieben versuchst
[20:12] <p01nt3r> naja so gross ist die ja auch nicht
[20:12] <tomreyn> wie booetet dein uefi denn dann von nvme?
[20:13] <p01nt3r> über eine adapterkarte
[20:13] <p01nt3r> habe das nvme-modul im bios nachgetragen und es neu reingeflashed
[20:14] <tomreyn> huiui
[20:14] <tomreyn> du machst ja sachen.
[20:14] <p01nt3r> :-)
[20:15] <p01nt3r> die software-lösung hat mir nicht zugesagt ^^
[20:15] <p01nt3r> dann wäre ich auch noch von refind oder ähnlichem abhängig
[20:17] <tomreyn> hast du da 2 verschiedene ssd's und drei verschiedene hdds drin in der kiste?
[20:17] <p01nt3r> tomreyn, jap
[20:18] <p01nt3r> tomreyn, nvme, 2 ssds, 2 hdds
[20:18] <tomreyn> dann wohl kein mirror-raid ;-)
[20:18] <p01nt3r> xD
[20:18] <tomreyn> ach die eine hdd ist das nvme, richtig, macht sinn
[20:18] <p01nt3r> ?
[20:19] <tomreyn> ich dachte du hättest drei hdds, aber eine davon ist das nvme
[20:19] <p01nt3r> tomreyn, jap, wd10ezex und hitachi hds72...
[20:21] <tomreyn> yo. na dann mal viel spaß beim basteln.
[20:21] <p01nt3r> tomreyn, das ist ein gigabyte z87-hd3 brett. das komische ist auch, dass grub nur die laufwerke erkennt, die ich in der boot priority überhaupt mit angebe (und nicht disable, dann sind sie für grub gar nicht da)
[20:22] <p01nt3r> tomreyn, eins noch - vor- nachteile bz zu xz?
[20:24] <tomreyn> ich glaub unter uefi packt der os-prober in ienigen fällen (weiß leider nicht wann) nur die systeme ins grub-bootmenü die grade gemountet sind. du musst also ggf. auch das windows-ntfs da mounten damit das klappt.
[20:24] <p01nt3r> tomreyn, und dann mache ich mich mal ran, den "shimx64.efi"-eintrag zu killen.
[20:25] <p01nt3r> tomreyn, das ist ne andere umgebung, da gehts um die laufwerks erkennung z.b. von einem grub, das vom usb-stick ausgeführt wird.
[20:26] <tomreyn> bz ist die ältere kompression, ist recht lahm und nicht allzu effektiv, aber allemal effektiver als gzip bei binärdaten. xz ist im normalfall noch ein stück langsamer, je nachdem mit welchen optionen es gestaret wird braucht es viel ram (großes dictionary) um effektiv zu kompromieren. und das ram muss dann auch beim entpacken wieder da sein.
[20:26] <p01nt3r> tomreyn, ich glaube, 100mb komprimiere ich einfach mal gar nicht.
[20:27] <tomreyn> oder so ;-)
[20:29] <p01nt3r> tomreyn, verdammt, hab den falschen gelöscht xD
[20:29] <tomreyn> \o/
[20:29] <p01nt3r> tomreyn, wie bekomm ich den 0000 wieder? xD
[20:30] <tomreyn> --create-only
[20:30] <tomreyn> mit den daten wie geht als weitere argumente
[20:31] <tomreyn> bin aber nicht sicher ob du den so wieder hinkriegst
[20:31] <tomreyn> die punkte in der ausgabe sind ggf. auch mal steuerzeichen
[20:31] <tomreyn> am ende noch --bootorder wieder anpassen
[20:32] <tomreyn> so wie sie vorher war
[20:33] <tomreyn> hab mal esp.xz von meiner 513 MB großen esp erstellt und komme mit xz -9 auf 164MN
[20:33] <tomreyn> aber ich hab da auch noch firmwareupdates aufm esp rumliegen
[20:33] <p01nt3r> tomreyn, brauch ich dann -L "Windows Boot Manager"?
[20:33] <tomreyn> *164MB
[20:33] <p01nt3r> nicht schlecht
[20:34] <tomreyn> -L brauchst du nicht, weißt ja was du angeben musst
[20:34] <p01nt3r> tomreyn, gib mir mal bitte die Zeile
[20:34] <tomreyn> aber wie gesagt, ich denke nicht dass du den windows-eintrag rekonstruiert kriegst
[20:34] <p01nt3r> oha
[20:35] <p01nt3r> was nun?
[20:35] <tomreyn> die empfohlene reparaturmethode von windows anwenden würd ich denken
[20:36] <tomreyn> dit is hier ein ubuntukanal ;-)
[20:36] <p01nt3r> jooo
[20:48] <p01nt3r> tomreyn, danke soweit!
[20:49] <tomreyn> bitte, ich bni dann auch mal raus...