On Tue, 2014-01-28 at 16:28 -0500, Phillip Susi wrote: > On 01/28/2014 04:09 PM, Christoph Anton Mitterer wrote: > > - for plain dm-crypt it's a "good" way to make it recognisable > Or use LUKS instead. Well some people don't want to do so... whether that makes sense or not.. is probably up to them :) > The problem with hints is that they often tend to be wrong, which is > why Linux ignores them and goes straight to looking at what is in the > partition. Sure and that's likely the best approach,... but there is not only Linux ;-) > If it isn't used then why have it? All it does is add confusion. Again... other systems may use it... there is the ID for the ESP, which is definitely used... and you never know which other system (other OS, bootloader) comes a long and tries to do something based on it. Anyway.. as I said... no one is forced to use it at all... it just sounds better to have something defined that to leave that open and have people choose anything... And this mail was merely to inform fdisk upstream that these values were now "chosen". > >> Linux doesn't use partition IDs. > > Phew... that's not fully true... not even for the kernel which I > > think still contains the code to do MD auto assembly with 0.9 > > superblocks when some MBR partition type is set... > That's the exception and is depreciated/legacy behavior from the days > before initrd/initramfs. Well but that exception just proves my point.. that feature was deprecated for good reason as it caused many issues... and you cannot guarantee that no one else (e.g. outside the FLOSS world) comes along and adds some other seemingly smart functionality... and at least one could hope that such someone wouldn't touch any IDs which clearly don't "belong" to him. > >> Also isn't plain dm-crypt depreciated? > > Why should it be? > For all of the reasons that LUKS was created. In particular, the lack > of the ability to identify the thing. Well I guess the main reason was rather to have the functionality with key slots, and have the cipher/hash/mode/etc. stored. Aprart from that one would usually rather try not to run around shouting that one has an encrypted container... Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
