RAINBOF: je to velký zvíře no, nestačí ti třeba gitea? Teďka to má už i ekvivalent github actions :)

RAINBOF: mělo by jít udělat na hostovi uživatele git a tomu dát do authorized keys command ssh dockergit.

THERIDANE: jinej port beru jako plan b
(zatim se mi gitlab nepovedlo presvedcit k tomu aby to fungovalo dobre zda se ze ne na to neni uplne pripraven)

RAINBOF: Nejjednodušší je nastavit pro gitlab jinej SSH port. Pro uživatele je to transparentní, dostane remote URL ve správným formátu když si ji z webu zkopíruje, atd.

Ale jde to i jak píšeš pomocí ssh proxy, která de facto dělá mirror uživatele git@host a git@container. Ale je to hodně práce navíc :)

RAINBOF: presmerovat a obslouzit jinym ssh serverem...

Mam gitlab v dockeru, gitlab by se rad vystavil na portu 22 kde ale samozrejme mam ssh hostitele coz bych tak rad nechal. Je nejak mozny uzivatele git@ presmerovat jinym ssh serverem ?

Někdy se na potíže s bootem hodí REFind nebo v grubu:
linux (hd0/sd1)/boot/vmlinux- root=/dev/sda1
initrd (hd0/sd1)/biit/initrd
boot
...
ty prikazy jsou orientacni a boj s volume jsem vzdal
ve prospech prostych diskovych oddilu.
Hodne, v grubu, pomaha klavesa tabulator

ZBYNEK: Není tomu tak, ostatně viz screenshot. Při bootu se pomocí systemd generátoru vygenerují z fstabu patřičné služby a ta, která odpovídá tomu efi mountu se nenastartuje. Ve výchozí konfiguraci to ovšem zabrání úspěšné aktivaci local-fs.target a to zastaví celý boot. Vše je vidět v logu.

KARIBIKCZ: Což nemá žádný vliv na bootování, jenom systém nebude moct při updatech aktualizovat grub

RATTKIN: předpokládám, že `/boot/efi` se ze starého disku neklonovalo, tudíž ten nový /dev/nvme1n1p1 má jiné UUID než starý /dev/nvme0n1p1. Je tedy potřeba provést aktualizaci /etc/fstab (konkrétně opravit řádek pro mount /boot/efi)

RATTKIN: minimálně si stěžuje na disk 7149 8FFC a na /boot/efi, což by pro ten boot mohlo mít nějaký význam ...

grub jsem nainstaloval, ještě asi nějaká chyba LVM?

RATTKIN: grub je v pohodě a co je v efi ho nezajímá.
Co je na /dev/nvme1n1p2, root fs nebo neco jiného ? Napadá mě, že někde máš referenci na staré rozložení disků místo uuid, takže neví co otevřít. Jaké záznamy máš v /etc/fstab a v /etc/crypttab ? A během toho bootu, nevyblije to nějakou chybu, ze které by šlo poznat, na čem to selže?

KOLCON: já potřebuji standardní Ubuntu, jinak mi s tím v práci neporadí.

Praktická rada : vyser se na tu mrdku grub a použij systemd-boot, ušetříš si spoustu nervů

RATTKIN: EFI potřebuje kromě souborů na disku ještě nastavit ("do CMOS"), které ty soubory má používat. (pokud pod rootem spuštíš ten efibootmgr bez parametrů, tak ti vypíše, co tam je.)
Nevím jak to dělá grub (já jedu rovnou přez EFI), ale je možné, že se do toho nastavení taky dívá - projdi si jeho konfiguráky, co v nich vlastně má.

posílám starý disk a nový disk.
1.2 GB boot oddíl jsem klonoval gparted, encrypted přes dd. Obsah EFI oddílů je stejný, na windows je ještě adresář microsoft.
Pořád bootuju linux jen do minimal grub-like
Můžu to nějak klonovat jinak? Záloha + obnovení? Ani nevím jestli chyba vznikla klonováním, nebo čím.