Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - - -

Stran: [1] 2 3
1
Sítě / Re:Tunel z veřejné sítě na domácí PC s IPv6
« kdy: 21. 08. 2022, 11:52:51 »
Mělo by to jít udělat i bez VPN (ale stále musíte mít nějaký Linux s veřejnou IP - prodávají se tzv. "NAT VPS" za cenu třeba $1 měsíčně), jak píšete pomocí SSH (reverzní tunel), odkaz na anglický návod zde (možno přeložit pomocí překladače do ČJ). Kdyžtak dejte zpětnou vazbu na té stránce návodu.

2
Sítě / Router využívá procesor na 100 %
« kdy: 21. 08. 2022, 11:31:48 »
Dobrý den,

pokud webové rozhraní routeru ukazuje využití procesoru routeru často ke 100% (např. 99.5%) a zaznamenávám, že téměř denně se stane, že z Linux počítače neodpovídá ping na router (minimálně po dobu několika sekund), tak se chci zeptat co má zejména vliv na využití CPU routeru?
Může to být zapnuté QoS?
Kromě QoS a Wifi 20/40MHz (Asi obě frekvence zároveň), Control Sideband "Upper" (asi maximální výkon) tam není nic extra zapnuto.

Jde spíše o počet paketů za vteřinu a nebo spíše o využitou šířku pásma? (převážný datový přenos, který jde routerem je VPN tunel, který začíná na Linux počítači a končí v internetu)
Znáte nějaký příkaz pro Linux, který ukáže to, co potřebuju vědět, abych omezil konkrétní proces, který by to přetížení CPU routeru mohl způsobovat? Podotýkám, že dostupná šířka pásma routeru není zcela využita při tom vytížení. I proto nechci omezovat datový přenost procesů, ale spíše přijít zjistit, co konkrétně má největší vliv na ten CPU routeru. Naopak bych potřeboval aby bylo přenášeno více dat, router i připojení má na to kapacitu, ale router CPU nestíhá? Proč? Jak udělat abych přenesl více a router CPU byl méně vytížený?

https://linuxhint.com/network_usage_per_process/
sudo iptraf - zobrazuje IP adresy a počty paketů a jejich přenos dat (mě by zajímaly spíše procesy než IP)
sudo iftop - zobrazuje IP adresy a jejich přenos dat, ne pakety, ne procesy
sudo nethogs -as - zobrazuje procesy a jakousi hodnotu SENT(ODESLÁNO) (mohou být pakety) a received KB/sec (ta je ale podivně nízká na to, kolik proces skutečně posílá po síti)

děkuji předem za případné informace

3
Server / Re:ModRewrite přesměrování koliduje s Redirect 301
« kdy: 15. 02. 2022, 11:49:45 »
Možná by fungovalo nahradit:
Citace
Redirect 301 /Introductions /forumdisplay.php?1-Introductions
tímto:
Citace
RedirectMatch 301 ^/Introductions/?$ /forumdisplay.php?2-Introductions

Nevím zda jsou nutné ty speciální znaky

4
Server / ModRewrite přesměrování koliduje s Redirect 301
« kdy: 15. 02. 2022, 11:19:33 »
Dobrý den,

v .htaccess mám

RewriteRule [^/]+/([0-9]+)-[^/]+ /showthread.php?t=$1 [L,R=301]
Redirect 301 /Introductions /forumdisplay.php?1-Introductions

s tím, že z /Introductions/5-abc-def/ bych měl být přesměrován na /showthread.php?t=5-abc-def

to by fungovalo, ale to pravidlo Redirect 301 to nabourá (ať je umístěno nad tím nebo pod tím) a 301 pravidlo dostane přednost a přesměruje tedy /Introductions/5-abc-def/ na: /forumdisplay.php?1-Introductions

Máte prosím nápad jak by ta .htacces spravidla měla vypadat aby se to vzájemě neovlivňovalo?

5
Software / Re:Jak funguje LUKS keyfile a heslo?
« kdy: 16. 06. 2021, 17:28:36 »
vykašlat se na ten soubor s klíčem a použít klíč uložený v hlavičce, který je zašifrovaný uživatelskou frází.

Díky všem, asi máte na mysli příkaz, který uvádím níže, našel jsem zde:

Citace
# cryptsetup luksFormat /dev/sdX1
Enter passphrase for /dev/sdX1:
# cryptsetup luksOpen /dev/sdX1 secret
Enter passphrase for /dev/sdX1:
# mkfs.ext4 /dev/mapper/secret
# mkdir /secret;mount /dev/mapper/secret /secret/
# umount /secret;cryptsetup luksClose /dev/mapper/secret

6
Software / Jak funguje LUKS keyfile a heslo?
« kdy: 14. 06. 2021, 11:12:37 »
Dobrý den, četl jsem návod jak zašifrovat sekundární disk a připojovat ho automaticky při startu Linuxu. Používá keyfile na /etc/keyfile které může číst pouze root.
Jenže pokud je systémový disk nešifrovaný (nemá full disk encryption, ale třeba pouze /home) a někdo má fyzický přístup k PC/PC je zcizen, tak může tento keyfile použít a dešifrovat data sekundárního disku ne? V návodu používá příkaz:
sudo cryptsetup -v --type luks2 luksFormat /dev/sdb /etc/cryptkey

V manuálu cryptsetup uvádí: "you can give '-' as file name, which results in the passphrase being read from stdin" což mi říká, že asi nemůžu použít jak keyfile tak nějaké jednodušší heslo zároveň? Mám dojem, že u SSH klíčů je to tak, že můžu nastavit ještě navíc heslo, takže když někdo získá takový typ souboru/klíče s heslem tak je mu takový soubor více méně k ničemu když nemá super výpočetní kapacitu k prolomení hesla, u LUKS to takto není? Pokud je, jak tedy by měl vypadat cryptsetup příkaz aby použil super ochranu dlouhého klíče + navíc heslo nutné k použití souboru klíče?

7
Tak ten emergency mód/příkazová řádka byla tou /etc/fstab linkou
UUID=uuid_z_lsblk_f /boot/efi Fat32 defaults,noatime 0 2
po přidání # na začátek už boot funguje do grafického rozhraní, jen se 2x ptá na LUKS heslo...
a přestal mi fungovat internet na obou počítačích, asi něco s hostname nebo konfigurací sítě, že je identická...

8
Díky, tak jsem zkusil následovat Tvoje zmíněné rady a povedlo se dostat k bootování, ALE jen do příkazové řádky:

Ten efibootmgr už nainstalovaný byl
$ efibootmgr -v
Citace
BootCurrent: 0003
Timeout: 0 seconds
BootOrder: 0003,0005
Boot0001* HDDabc    PciRoot(0x0)/Pci(0x2,0x1)/Pci(0x0,0x1)/Sata(3,65535,0)N.....YM....R,Y.....ISPH
Boot0003* Generic USB3.0 Card Reader 000000001536   PciRoot(0x0)/Pci(0x8,0x1)/Pci(0x0,0x3)/USB(5,0)N.....YM....R,Y.....ISPH
Boot0004* SK hynix(systHDD) ...   PciRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/NVMe(0x1,AC-E4-2E-00-0A-8B-BA-ED)N.....YM....R,Y.....ISPH
Boot0005* SK hynix(systHDD) ...   PciRoot(0x0)/Pci(0x2,0x2)/Pci(0x0,0x0)/NVMe(0x1,AC-E4-2E-00-0A-8B-BA-ED)N.....YM....R,Y.....ISPH

sudo modprobe efivarfs
lsmod|grep -i efi
(nic)

$ ls /sys/firmware/efi
Citace
config_table  efivars  esrt  fw_platform_size  fw_vendor  runtime  runtime-map  systab

efibootmgr ale na rozdíl od normálního shellu nefungoval v chrootu a negunguje v něm ani modprobe efivarfs:

Citace
[manjaro /] # sudo modprobe efivarfs
modprobe: FATAL: Module efivarfs not found in directory /lib/modules/5.9.16-1-MANJARO
[manjaro /]# find /lib/modules -iname *"efivar"*
/lib/modules/5.4.100-1-MANJARO/build/include/config/efivar
/lib/modules/5.4.100-1-MANJARO/build/fs/efivarfs
/lib/modules/5.10.18-1-MANJARO/build/include/config/efivar
/lib/modules/5.10.18-1-MANJARO/build/fs/efivarfs

mimo chroot je to bez chyb. Takže tady si nejsem jistý jestli není problém, protože později to při bootu hlásilo EFI problémy.

Pak jsem našel příkaz (spuštění v normální shell), po kterém začal v chroot fungovat efibootmgr:
sudo mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars

nepamatuju si jestli modprobe efivars začal fungovat v chrootu, pochybuju.

a přestal si i stěžovat grub-install:
sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
Citace
Installing for x86_64-efi platform.
Installation finished. No error reported.

Pak jsem zkusil
[manjaro /]# ls /etc/mkinitcpio.d
linux510.preset  linux54.preset  linux58.preset.pacsave
[manjaro /]# mkinitcpio -p linux510
výstup bez chyb

pak:
# sudo update-grub
Citace
Generating grub configuration file ...
Found theme: /usr/share/grub/themes/manjaro/theme.txt
Found linux image: /boot/vmlinuz-5.10-x86_64
Found initrd image: /boot/intel-ucode.img /boot/amd-ucode.img /boot/initramfs-5.10-x86_64.img
Found initrd fallback image: /boot/initramfs-5.10-x86_64-fallback.img
Found linux image: /boot/vmlinuz-5.4-x86_64
Found initrd image: /boot/intel-ucode.img /boot/amd-ucode.img /boot/initramfs-5.4-x86_64.img
Found initrd fallback image: /boot/initramfs-5.4-x86_64-fallback.img
Adding boot menu entry for UEFI Firmware Settings ...
Found memtest86+ image: /boot/memtest86+/memtest.bin
done

Nepamatuju si že by předešlé updaty obsahovaly řádku "Adding boot menu entry for UEFI Firmware Settings ..."

někdo pak ještě spouštěl "grub-mkconfig -o /boot/grub/grub.cfg" ale nevím jestli je to vhodné, tak jsem nespustil..

exit

"efibootmgr -v" začal zobrazovat novou linku:
Boot0000* manjaro   HD(1,GPT,d..-..-..-..-...,0x1000,0x96000)/File(\EFI\manjaro\grubx64.efi)

Po restartu vidím v UEFI boot entry Manjaro, potvrdím, zadám LUKS heslo, pak si to stěžuje že nemá klíč a chce to heslo znovu a nakonec to skončí na příkazové řádce údržbového módu ze kterého se nemůžu dostat do normálního:

Zde jsem to vyfotil:
https://postimg.cc/gallery/QxqzDDF

Máte nějaké nápady co zkusit, nebo jsem to už příliš rozhasil? @k3dAR děkuji

9
pred update-grub v chrootu, mej pripojenej EFI oddil do "chroot"/boot/efi/

Nevím jestli jsem pochopil správně, zkusil jsem tohle:
Citace
sudo cryptsetup luksOpen /dev/nvme0n1p2 c;sudo mount /dev/mapper/c /mnt
mkdir /mnt/boot/efi 2>/dev/null;sudo mount /dev/nvme0n1p1 /mnt/boot/efi
for i in /dev /dev/pts /proc /sys; do sudo mount -B $i /mnt$i; done;sudo chroot /mnt
update-grub;exit;cd;sudo umount /mnt*;sudo cryptsetup luksClose c
(nvme0n1p1 je první fat32 oddíl pro EFI, a také 2 .efi soubory obsahuje)

Jinak na netu se psalo něco o "update-initramfs -u -k 4.10.0-38-generic" před update-grub, ale "bash: update-initramfs: command not found"
v /boot mám a používám kernel initramfs-5.10-x86_64.img

Pak jsem si uvědomil že starý disk ze kterého jsem kopíroval na tento nový nebyl instalovaný pod UEFI ale legacy a MBRMBR, možná že GRUB soubory neobsahují UEFI instrukce a je potřeba grub-install, v chroot:

# sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
Citace
Installing for x86_64-efi platform.
EFI variables are not supported on this system.
EFI variables are not supported on this system.
grub-install: error: efibootmgr failed to register the boot entry: No such file or directory.

exit
Když jsem to zkoušel mimo chroot (sudo mkdir /boot/efi;sudo mount /dev/nvme0n1p1 /boot/efi)
nvme0n1p1 = 1. boot partition pro efi. Tak si to stěžovalo "failed to get canonical path of `overlay'"

/etc/fstab NEobsahuje boot/EFI:
Citace
# <file system>             <mount point>  <type>  <options>  <dump>  <pass>
/dev/mapper/luks-9...-...-...-...-..... /              ext4    defaults,noatime 0 1
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0

Už jsem tam zkusil dát linku:
Citace
UUID=uuid_z_lsblk_f /boot/efi Fat32 defaults,noatime 0 2
ale stále to hledá jiné UUID kryptodisku

Napadá vás co zkusit dál? děkuji

10
zkus se podivat do /boot/efi/EFI/manjaro?/grub.cfg ;-)
v /mnt/boot/efi nic není, na EFI oddílu /mnt2/EFI/Manjaro je pak binární .efi soubor.
Zkusil jsem tedy znovu rsync ze starého oddílu na nový, tentokrát s --delete ale nepomohlo to, zde jak jsem to udělal:

  • nový PC:
    gparted, decrypt LUKS partition
    ls /dev/mapper|grep crypt
    sudo mount /dev/mapper/XY_crypt /mnt

    starý PC:
    sudo rsync -qaHAXS --delete / root@novypc:/mnt/
    Přihlášení nešlo, po editaci /etc/ssh/sshd_config a odkomentování, upravení PermitRootLogin yes; systemctl restart sshd
    to šlo, ale skončilo s chybami jako:
    "rsync: [generator] delete_file: unlink(proc/1257/task/1257/net/route) failed: Operation not permitted (1)"
    takže jsem udělal to @k3dAR doporučované "sudo mkdir /mnttmp;sudo mount --bind / /mnttmp/" na zdrojovém PC.
    a pak znovu rsync jen z /mnttmp/ "sudo rsync -qaHAXS --delete /mnttmp/ root@novypc:/mnt/"
    Evidentně to přenášelo data a po několika minutách skončilo
    po restartu stále hledá nesprávné UUID kryptodisku a a ani nepomohlo update-grub:
    sudo mount --bind /dev /mnt/dev;sudo mount --bind /sys /mnt/sys;sudo mount --bind /proc /mnt/proc;
    sudo chroot /mnt;sudo update-grub

Takže pořád nechápu odkud to bere to UUID, které v grub nevidím. Jestli vás napadají další příkazy co zkusit?, mě tedy napadá

A) znovu potupně reinstalovat systém, nabootovat (snad by měl fungovat) a pak sudo mount --bind / /mnt a zo samé na starém PC a rsyncnout ze starého na nový (rsync -qaHAXS --delete) s tím že z rsyncu vypustím ty adresáře jako je /boot/, ale tady zase nevím které mám dát do exclude. A nebo jestli by stačio rsync pouze neexistující soubory /.
B) Druhá varianta je skutečně čistá instalace a znovu nainstalovat apliakce:
STARY: pacman -Qqen > pkglist.txt;pacman -Qqem > pkglist_aur.txt
NOVY: pacman -S --needed - < pkglist.txt; for p in $(cat pkglist_aur.txt);do pamac build $p --no-confirm;done
a obnovit /home

jak to vidíte? děkuji

11
novy disk si tedy rozdelil jak?
- rozlozeni GPT
- 1 oddil EFI (a pridan v gparted priznak Boot a ESP)
- 2 oddil pro LUKS, ten si odemknul, zformatoval a rsyncem prehodil vse z odemknuteho puvodniho disku?
Děkuju  :D , ano, GPT a EFI s boot a esp flag. LUKS byl vytvořený grafickým instalátorem systému Manjaro, protože jsem to nechtěl komplikovat manuálním vytvářením (nikdy jsem to nedělal). Na disk byl tedy nainstalován výchozí Linux systém s EFI, LUKS a obsah dešifrovaného LUKS oddílu jsem pod live USB systémem přepsal tím rsyncem ze starého disku (rsync -qaHAXS /staryroot /novyroot/).
Ano, nový disk teď zkouším bootovat v UEFI počítači.

nesprávné UUID cryptodisku (začínající písmenem b) hledá zavaděč při bootování.. jediné co se zobrazí je:


i přes to, že jsem v chroot na tom disku nastavil UUIDs která jsou v grub souborech uvedených níže
sudo cryptsetup luksUUID /dev/XY --uuid id1
sudo tune2fs -U id2 /dev/mapper/luks-XY
(zde obrázek kde cryptsetup a gparted dokládá změnu)

a grub soubory mají ID, které zobrazuje gparted/cryptsetup:

etc/default/grub:
https://bin.disroot.org/?36a335aed5f4dc28#F9ZECTmruWeFACbL6HuxMz14W7Rcs5kePgQBAjRVwrYR

boot/grub/grub.cfg boot menu linky obsahující UUID (kryptodisku a nebo v něm obsaženého ext4 oddílu):
https://bin.disroot.org/?4045942c6085ad1f#385HRHYLQdYMwjMr8ryoYLnn7R674X9RG3SP1nHHekBo

boot/grub/grub.cfg kompletní:
https://bin.disroot.org/?aebb087e1f20da57#63nGcegJKyk5wJ5Lo3PYwf2hyfmRCV5iXcGcQj5H5WhD

"sudo cryptsetup luksUUID /dev/sda1" ti zobrazi UUID to ktere si menil? to co to hleda?
ukazuje to, ktere jsem měnil (9...) ne to které je vidět při bootu

update-grub pokus, obrázek

v pripade ze si regeneroval initramdisk, mel si v tu chvili luks kontejner odemcenej pod STEJNYM nazvem jako mas uvedene v /etc/crypttab? (prvni sloupec) a mel si tam spravne UUID=... ? (druhej sloupec)
Tohle nevím, nevěděl jsem že jde odemknout pod jiným názvem a tím narušit update-grub apod., je to ale pravděpodobné, že jsem dal název např. abc (cryptsetup luksOpen dev abc), ale v /etc/crypttab je název luks-uuid ...

=> přijde mi že v  chroot jsem správně změnil ID na ta, která jsou v uvedených grub souborech, ale nevím proč tedy zavaděč hledá jiné luks ID... možná by pomohlo dočasně v GRUB cmd spustit pod novým ID a po startu OS aktualizovat grub.

@k3dAR doufám že můj popis nebyl moc zmatečný, děkuji moc za případné rady

12
Četl jsem nějaké návody k té změně velikosti:
https://unix.stackexchange.com/a/41093
https://wiki.archlinux.org/index.php/Resizing_LVM-on-LUKS#Resize_LUKS_volume

až jsem se po zmenšení ext4 v LUKS a zmenšení LUKS dostal na zmenšení samotného oddílu, ale nepokračuju dál, protože se mi to nechce zničit zadáním špatných čísel:
Citace
$ sudo parted /dev/sda
GNU Parted 3.3
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) unit                                                             
Unit?  [compact]? s                                                       
(parted) p                                                               
Error: Can't have a partition outside the disk!
Ignore/Cancel? i                                                         
Error: Can't have a partition outside the disk!
Ignore/Cancel? i                                                         
Error: Can't have the end before the start! (start sector=3054462464 length=-2098627181)
Model: ATA Samsung SSD 850 (scsi)                                         
Disk /dev/sda: 234441648s
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:
(parted) q

takže jsem zkusil připojit oba disky,
sudo cryptsetup luksOpen /dev/sdc1 abc
druhý už byl připojen podle $lsblk
Zkoušel jsem ten mount s přepínačem --bind, ale byla tam chyba:
sudo mount --bind /dev/mapper/abc /mnt
mount: /mnt: mount(2) system call failed: Not a directory.
bez --bind ale fungovalo:
sudo mount /dev/mapper/abc /mnt
sudo mkdir /mnt2;sudo mount jmeno-desifrovaneho-oddilu-Noveho-Disku-podleLSBLK /mnt2

a pak tedy překopírování dat ze starého disku /mnt na /mnt2:
sudo rsync -qaHAXS /mnt/ /mnt2/

po vložení nového disku  do nového PC to nenachází cryptodisk, protože ten rsync asi přepsal grub apod. Já jsem tedy změnil UUID aby souhlasily s tím co je v boot/grub/grub.cfg:
sudo cryptsetup luksUUID /dev/sda1 --uuid newuuidHERE (a skutečně to změnilo UUID kryptodisku)
sudo tune2fs -U 6a62939e-9d02-4cd1-ad50-297d166daf23 /dev/mapper/luks-0bbfe23e-921f-46df-89a0-e299032688ef
(podle https://scriptthe.net/2016/08/24/changing-uuids-on-luks-encrypted-partitions/ )
bylo potřeba udělat kontrolu fsck přes gparted.

Problém je, že boot z disku nejde, pořád to hledá kryptodisk který není nalezen, asi ten starý. fstab UUID neobsahuje. Končí to v grub příkazové řádce.

13
1) odemknout LUKS kontejner (uvnitř partition /dev/sda1) a zmenšit oddíl/filesystém uvnitř LUKS kontejneru tak, aby bylo následně možné zmenšit LUKS kontejner (nenapsal jste, jak to přesně máte rozložené, takže tady nelze poradit líp)
2) zmenšit LUKS kontejner
3) zmenšit LUKS partition (/dev/sda1)
...
V gparted je právě ta chyba oddíl mimo disk a nemožnost cokoliv dešifrovat, přidat nebo resize. Viz obrázek pod odkazem níže.
Nástroj "Disks" někeré funkce umí, ale neumožňuje resize (volba je neaktivní) nebo přidání oddílu. Ani ten nedokáže dešifrovat LUKS, viz. chyba na obrázku, odkaz níže.

Zkusil jsem dešifrovat manuálně:
$ cryptsetup luksOpen /dev/sda1 abc
Disks ukázal ext4 ale stále nemůžu resize a když jsem zkoušel manuální příkaz resize2fs -p /dev/sda1 tak si to stěžovalo že je využíván a nemůže nic udělat. Možná jsem jen zadal špatnou cestu.
Jelikož jsem lama, tak bych tuhle úlohu nejraději udělal v gparted, ale nemůžu, obrázky:

https://postimg.cc/gallery/mRTVTTG

Pokud vás NEnapadne jak to resize a novou partition vytvořit, tak se budu asi klonit k instalaci od nuly a možná pak zkusit to, co tu psal @k3dAR (skopírování dat ze starého disku na nový):
Citace
sudo mount --bind / /mnt
sudo rsync -av --progress --sparse --links --hard-links /mnt/ sshuser@sshserver:/adresar/kam
Možná, že nový počítač by musel být v režimu live-usb a root filesystem mountnutý, kvůli tomu aby nebyl při nahrazování používán.
Jinak druhá varianta je jen obnovit /home/user a nainstalovat aplikace
STARY: pacman -Qqen > pkglist.txt;pacman -Qqem > pkglist_aur.txt
NOVY: pacman -S --needed - < pkglist.txt; for p in $(cat pkglist_aur.txt);do pamac build $p --no-confirm;done

14
Děkuji. Nemám žádné velké novinky zatím, ale přesto:
@k3dAR

Kód: [Vybrat]
$ lsblk /dev/sda
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                             8:0    0 111,8G  0 disk 
└─sda1                                          8:1    0 111,8G  0 part 
  └─luks-... 254:0    0 111,8G  0 crypt /

Na disku není LVM, vše kromě asi zavaděče by mělo být šifrované LUKS, žádný jiný oddíl (ani swap) by tam neměl být.

Překlep, ne FileZilla ale CloneZilla zahlásila oddíl mimo disk, to samé gparted. RedoBackup (stará verze) to zdá se zazálohovala, i když trochu podezřele.

> sudo mount --bind / /mnt
tomuhle moc nerozumím (včetně toho bind), v chroot bych asi nepoužil / ale /dev/sdX a při bootování z toho disku, který chci zálohovat nevím jaký by byl efekt to mountnout 2x (zapoměl jsem podotknout že nejsem pokročilý uživatel Linux).

15
Ahoj, byl bych moc vděčný za radu. Nový počítač podporuje podle všeho jen UEFI, ne BIOS MBR/legacy.
A já mám ve starém PC šifrovaný LUKS disk s MBR. Takže když změním UEFI boot tak POST hlásí 3F0 chybu a s diskem se nebaví.

Zjistil jsem, že je asi potřeba vytvořit EFI oddíl, jenže problém je jak. Když v gparted dešifruju ten LUKS disk, tak není vidět boot oddíl , jen ext4 a gparted říká: Cant have a partition outside the disk! (díky tomu nelze disk zálohovat pomocí FIleZilla, RedoBackup fungoval)

$ sudo fdisk -l /dev/sda* ukazuje jen 1 oddíl:

Citace
    Disklabel type: dos
    Disk identifier: 0xc75ac368

    Device Boot Start End Sectors Size Id Type
    /dev/sda1 * 2048 234436544 234434497 111,8G 83 Linux

$ sudo gdisk -l /dev/sda ukazuje:

Citace
    GPT fdisk (gdisk) version 1.0.6

    Warning: Partition table header claims that the size of partition table
    entries is 1153912944 bytes, but this program supports only 128-byte entries.
    Adjusting accordingly, but partition table may be garbage.
    Warning: Partition table header claims that the size of partition table
    entries is 0 bytes, but this program supports only 128-byte entries.
    Adjusting accordingly, but partition table may be garbage.
    Partition table scan:
    MBR: MBR only
    BSD: not present
    APM: not present
    GPT: not present
    …
    Partition table holds up to 128 entries
    Main partition table begins at sector 2 and ends at sector 33
    First usable sector is 34, last usable sector is 234441614
    Partitions will be aligned on 2048-sector boundaries
    Total free space is 7084 sectors (3.5 MiB)

    Number Start (sector) End (sector) Size Code Name
    1 2048 234436544 111.8 GiB 8300 Linux filesystem

Jak byste tedy postupovali ohledně umožnění UEFI bootování z toho disku? Pod odkazem v prvním odstavci jsou popsané postupy jak pracovat s grub ohledně EFI, nevím ale jestli to stačí, protože podle manuálu pro můj systém se uvádí že potřebuju asi 300MB EFI oddíl FAT32, asi s boot a esp flag.

děkuji

Stran: [1] 2 3