Beiträge von reddy

  • Encrypted Kralizec installation - no cryptsetup after reboot?

    Hello,


    I'm trying to install a fully encrypted system (except /boot) with Kralizec ISO similarly as I did with old 0.3.x (http://wiki.openmediavault.org…2C_feedback.2C_discussion).
    All I changed in the ISO is once again just commenting out all lines in "### Partitioning" section to get full access to the partitioning options. I didn't have to load any additional modules during the installation as the current installer already has xts.ko and gf128mul.ko included. There's no need to re-create the encrypted partition as the installer by default uses aes-xts-plain64 now. So, it'd seem that it should be nice and easy thing, everything could be set up through the installer, but...
    Everything installs properly but after the reboot system doesn't ask for encryption password to the partition. It fails on searching for LVM volumes, which is obvious if the encryption partition isn't open. I even tried the simplest option with encryption from the installer - Guided partitioning with everything on one encrypted partition - still the same problem after first reboot.


    So I tried the same with clean Debian minimal network ISO and it nicely asks for the password after the reboot... So it looks like Kralizec image is somehow faulty - like cryptsetup startup scripts are missing after the restart. Any idea how to fix it or how to update the Kralizec ISO to work the same way as the original Debian one?
    I know I can simply install Debian and put Kralizec on top but I'd prefer to go with the image you created as I believe you've tweaked everything in the best possible way :)


    Thanks in advance for any help. I spend full two days and countless reinstallations in VBox to make it working, with no luck so far :(


    Update: I tried to install also to chroot into installed system before the reboot (similarly as described in my initial guide linked above) and install cryptsetup manually there (and run "update-initramfs –u" after that) - no change, still doesn't boot. What might be stripped from Kralizec image that it allows the installer to create all necessary partitions but it won't boot with encryption?

  • Single raid1 split into two degraded ones

    Just FYI - since I switched to ext4 (more than 6 months now) my mirror is stable with no surprises like this split. I hope it will stay like that :) I have no idea if and how the file system can affect mdadm, so I don't know how to help anybody or even myself if that happens again...

  • Upgrade kernel to the most recent one

    Hi,


    I'm affected by the problems with Intel wlan cards (yes, I know I should connect NAS to the ethernet cable but need to use my NAS over wlan :) ) - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/944271 - which exists even in the 3.2 kernel available in backports for Squeeze. How to upgrade to the most recent kernel (like 3.9.x or 3.10.x)? Is e.g. this guide safe:
    http://linuxg.net/how-to-insta…tu-linux-mint-and-debian/
    ?


    BTW, any estimation when we may expect OMV release based on wheeze? Newer kernels are available in wheeze backports.


    Cheers,
    Reddy

  • Encrypted OMV installation with aes-xts-plain64 cipher

    Hello,


    I've just posted on wiki the very first draft of manual describing how to set up an encrypted OMV installation with aes-xts-plain64 cipher, random key for swap and exposing the rest of boot disk to store data.
    http://wiki.openmediavault.org…f_boot_disk_to_store_data


    I'll update it with screenshots soon. I hope you'll find it useful and maybe help to improve it.


    This thread is meant for feedback, discussion and ideas related to that manual.

  • Encryption with OMV?

    Zitat von "fetto"

    This could probably be setup with dmcrypt quite easily, or even be integrated with a plugin or built into the control panel as default. Someone has to do it though :)


    Such a plugin would be great. I see from http://bugtracker.openmediavault.org/view.php?id=7 that support for encryption is planned, but with no work on the subject as of now.


    Zitat von "ptruman"

    Do a custom install and/or select LVM with encryption. You'll have to enter the decrypt key on every boot however (meaning you'll need to be present or have an IP KVM).....


    I don't mind to enter the key manually on every boot.
    What are the pros and cons of each method (dm-crypt vs LVM)? Maybe other methods are worth considering (e.g. TrueCrypt)?
    I'm sorry for lame questions, but I'm new to encryption under Linux. Maybe somebody can write some tutorial or point to a good one?

  • Single raid1 split into two degraded ones

    Thanks for the hint on the filesystem, I can still switch as I don't have a lot of data there yet. I built the NAS for reliability only, speed is not an issue (it works on USB drives anyway) so if there's something scary about XFS I'd prefer to switch to good old ext4.
    Nevertheless, I'd like to know why those mount points change...

  • Single raid1 split into two degraded ones

    When rebuild finished everything seemed to be ok, mirror was mounted as originally defined to /dev/md0. However, after reboot the mirror is still clean but again changed mount point to /dev/md127 this time:




    This instability scares me a bit... Why it behaves in such a strange manner?


    For reference, current /proc/mdstat


    Code
    root@nas:/home/reddy#  cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md127 : active raid1 sdb[0] sdc[2]
      1953513424 blocks super 1.2 [2/2] [UU]


unused devices: <none>


    and /etc/mdadm/mdadm.conf


  • Single raid1 split into two degraded ones

    I tried to fix the array in following way:


    Code
    umount /dev/md126
umount /dev/md127
mdadm –stop /dev/md126
mdadm –stop /dev/md127
mdadm -A /dev/md0 -f –update=summaries /dev/sdb /dev/sdc
mdadm /dev/md0 -a /dev/sdc


    And it started re-building the array:


    Code
    reddy@nas:~$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdc[2] sdb[0]
      1953513424 blocks super 1.2 [2/1] [U_]
      [===>.................]  recovery = 17.6% (345273472/1953513424) finish=1285.7min speed=20846K/sec


unused devices: <none>


    It will take quite a while. Is there any other way avoiding recovery? Both disks should already contain perfectly synchronized data in this case...