id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
212	Duplicated volumes under Live-USB	frisco	lars	"This bug report applies to r1126 of the deb-live build, based on cryptobox-server 3.4.5.

Some disks are listed twice in the ""Disks"" web page view. In the attached screen shot, there is one plaintext and one LUKS volume listed even though only one 37 GB disk actually exists. The ""Disks"" comes directly from reread_container_list().

From `trunk/src/cryptobox/core/main.py`:
{{{
148 	    def reread_container_list(self):
149 	        """"""Reinitialize the list of available containers.
150 	
151 	        This should be called whenever the available containers may have changed.
152 	        E.g.: after partitioning and after device addition/removal
153 	        """"""
154 	        self.log.debug(""rereading container list"")
155 	        self.__containers = []
156 	        blockdevice.CACHE.reset()
157 	        for device in blockdevice.Blockdevices().get_storage_devices():
158 	            if self.is_device_allowed(device) and not self.is_config_partition(device):
159 	                self.__containers.append(cbxContainer.CryptoBoxContainer(device, self))
160 	        ## sort by container name
161 	        self.__containers.sort(cmp = lambda x, y: x.get_name() < y.get_name() and -1 or 1)
}}}
This is where most of the ""special-case"" filtering takes place. Checking whether a partition is part of the live-media could be added here.


From `trunk/src/cryptobox/core/main.py`:
{{{
239 	    def get_container_list(self, filter_type=None, filter_name=None):
240 	        ""retrieve the list of all containers of this cryptobox""
241 	        try:
242 	            result = self.__containers[:]
243 	            if filter_type != None:
244 	                if filter_type in range(len(cbxContainer.CONTAINERTYPES)):
245 	                    return [e for e in self.__containers if e.get_type() == filter_type]
246 	                else:
247 	                    self.log.info(""invalid filter_type (%d)"" % filter_type)
248 	                    result.clear()
249 	            if filter_name != None:
250 	                result = [e for e in self.__containers if e.get_name() == filter_name]
251 	            return result
252 	        except AttributeError:
253 	            return []
}}}
Note that the only filtering that takes place at this point is by name and filesystem type.


From `trunk/src/cryptobox/core/container.py`:
{{{
34 	CONTAINERTYPES = {
35 	    ""unused"":0,
36 	    ""plain"":1,
37 	    ""luks"":2,
38 	    ""swap"":3,
39 	    }
40 	
41 	FSTYPES = {
42 	    ""plain"":[""ext3"", ""ext2"", ""vfat"", ""reiserfs"", ""xfs"", ""hfs"", ""jfs"", ""minix"", ""ntfs""],
43 	    ""swap"":[""swap""]}
}}}

From this list it's easy to see that the live-cd would not have been in the list of containers because ""iso9660"" isn't in the ""plain"" list, but that live-USB media would show up because it's formatted as ""vfat"". This has in fact happened, though not shown in the attachment ""Bogus disks.png""

I don't totally understand why mounted LUKS volume appear twice, given that `/dev/mapper` devices shouldn't be listed in the ""Disks"" list and don't appear to be covered by the ""allowed devices"" mechanism.[[BR]]

I noticed that the two duplicate disks in my example have different names.[[BR]]

Below this point is rambling speculation; don't give it too much attention: [[BR]]
One factor may be that the disk-naming mechanism, which uses UUIDs, may assume the presence of a persistent configuration partition, which was not present in most of my tests. The Debian Live situation may be a bit different from dfsbuild regarding what happens with no configuration partition. Users '''are''' allowed to run the CryptoNAS without a configuration partition, so making the /var/cache/cryptobox-server/config (?) directory read-only isn't a good option."	defect	closed	normal	cryptonas-live-cd 0.4.0	live-cd	cryptobox-server 0.3.4	normal	worksforme	duplicated volumes disks