On Mon, Dec 05, 2011 at 07:02:20PM +0100, Jacek Konieczny wrote:
> On Sun, Dec 04, 2011 at 11:44:05PM +0100, Artur Frysiak wrote:
> > Ewentualnie:
> > dmsetup deps lolek_crypt
>
> Już trochę lepiej:
>
> [root@lolek /boot]# dmsetup deps lolek_crypt
> 1 dependencies : (8, 3)
>
> To, wraz z /proc/
On Sun, Dec 04, 2011 at 11:44:05PM +0100, Artur Frysiak wrote:
> Ewentualnie:
> dmsetup deps lolek_crypt
Już trochę lepiej:
[root@lolek /boot]# dmsetup deps lolek_crypt
1 dependencies : (8, 3)
To, wraz z /proc/partition już daje co trzeba.
--
Pozdrowienia,
Jacek
__
On Sun, Dec 04, 2011 at 10:58:42PM +0100, Arkadiusz Miśkiewicz wrote:
> dmsetup status --target crypt lolek_crypt
> dmsetup status lolek_crypt
>
> co wypluwają?
Nic ciekawego:
[root@lolek /boot]# dmsetup status --target crypt lolek_crypt
0 964043553 crypt
[root@lolek /boot]# dmsetup status lolek_
2011/12/4 Arkadiusz Miśkiewicz :
> On Sunday 04 of December 2011, Jacek Konieczny wrote:
>
>> > Fajnie jednak jakbyś znalazł jak na tym starym cryptsetupie na podstawie
>> > /dev/mapper/lolek_crypt dojść do /dev/urządzenie_pod_spodem.
>>
>> Przez chwilę szukałem, ale nic takiego nie znalazłem. No c
On Sunday 04 of December 2011, Jacek Konieczny wrote:
> > Fajnie jednak jakbyś znalazł jak na tym starym cryptsetupie na podstawie
> > /dev/mapper/lolek_crypt dojść do /dev/urządzenie_pod_spodem.
>
> Przez chwilę szukałem, ale nic takiego nie znalazłem. No chyba, ze z
> /etc/crypttab odczytać (u
On Sun, Dec 04, 2011 at 10:04:59PM +0100, Arkadiusz Miśkiewicz wrote:
> Ten problem pojawia się wtedy gdy system masz odpalony z użyciem starego
> cryptsetup (0.x czy 1.0) w initrd.
Ok, rozumiem.
> Po odpaleniu przez nowszy cryptsetup dostaje się potem więcej info:
>
> [arekm@t400 ~]$ sudo cryp
On Sunday 04 of December 2011, Jacek Konieczny wrote:
> Po upgrade system mi nie wstał, okazało się, że źle się wygenerował
> initrd:
>
> geninitrd: LVM PV for lolek_vg: /dev/mapper/lolek_crypt
> geninitrd: is_luks: /dev/mapper/lolek_crypt is not cryptsetup luks
>
> To ni
Po upgrade system mi nie wstał, okazało się, że źle się wygenerował
initrd:
geninitrd: LVM PV for lolek_vg: /dev/mapper/lolek_crypt
geninitrd: is_luks: /dev/mapper/lolek_crypt is not cryptsetup luks
To nieprawda:
# /sbin/cryptsetup status lolek_crypt
/dev/mapper/lolek_crypt is active and is in
Dnia sobota 22 września 2007 21:51, Szymon Siwek napisał:
> On Sat, Sep 22, 2007 at 05:24:53PM +0200, Tomasz Grobelny wrote:
> > Jak wygląda zależność pomiędzy cryptsetup a cryptsetup-luks?
>
> Wedle mojej wiedzy wygląda to mniej więcej tak:
> (...)
Dzięki za wyjaśnienie.
>
On Sat, Sep 22, 2007 at 05:24:53PM +0200, Tomasz Grobelny wrote:
> Jak wygląda zależność pomiędzy cryptsetup a cryptsetup-luks?
Wedle mojej wiedzy wygląda to mniej więcej tak:
> Swego czasu
> cryptsetup-luks dostarczał cryptsetup,
Ale w pewnym momencie oba projekty się rozjechały i
Jak wygląda zależność pomiędzy cryptsetup a cryptsetup-luks? Swego czasu
cryptsetup-luks dostarczał cryptsetup, jednak ta zmiana została wycofana,
mimo takiego wpisu na stronie cryptsetup-luks:
"From this release onwards, cryptsetup-luks becomes cryptsetup. Hence, we are
replacing the ori
The Source, Luke.
> http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/34
>
> Moze proste dostosowanie pacza do wersji 2.13 nie wystarczylo...
>
> Janek
Okazało się, że problem wynikał z powiększających się różnic między
cryptsetup a cryptsetup-luks, które jakoby (wed
12 matches
Mail list logo
