lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 11 Apr 2019 11:57:54 +0200
From:   Andrea Lo Pumo <>
To:     unlisted-recipients:; (no To-header on input)
Subject: Re: Run mkfs.ext4 on an already existing ext4 filesystem. Seeking
 professional help or programming hints for the recovery.

To clarify, the commands run on the machine were:

   cryptsetup luksOpen /dev/sda1 secure_storage
   mkfs.ext4 /dev/mapper/secure_storage  <--- this messed everything

Through the emails I used "/dev/sda1" to make the story simpler, as I
believe that /dev/mapper/secure_storage is the same as a normal

Thank you again.

Il giorno gio 11 apr 2019 alle ore 11:45 Andrea Lo Pumo
<> ha scritto:
> Il giorno gio 11 apr 2019 alle ore 11:42 Reindl Harald
> <> ha scritto:
> >
> > Am 11.04.19 um 11:37 schrieb Andrea Lo Pumo:
> > > On /dev/sda1(*) there was an ext4 file system with a lot of large
> > > files. Now, by mistake, mkfs.ext4 has been run on /dev/sda1. The
> > > result is that now /dev/sda1 is "empty": mounting it shows no files.
> > >
> > > Note *: actually, it is /dev/mapper/secure_storage, an encrypted
> > > volume opened with LUKS: cryptsetup luksOpen /dev/sda1 secure_storage
> >
> > no
> >
> > you said you had a LUKS volume on /dev/sda1 which means by directly
> > create a fs on /dev/sda1 you have overwritten parts of the encryption
> > layer *and* at the same time the filesystem *on top* of it
> Sorry, I explained it badly. The commands were:
>   cryptsetup luksOpen /dev/sda1 secure_storage
>   mkfs.ext4 /dev/mapper/secure_storage

Powered by blists - more mailing lists