Re: Encrypted partiotions - which files related?
On Mon 29 Jan 2024 at 16:12:30 (+0100), Hans wrote: > > That appears to be too much overhead to me... virtual machines (for > > server as full OS) seem much more appropriate to me, in particular as > > differences between in-VM and physical devices are pretty much (not > > completely, though!) abstracted away these days. > > non no, that is exactly, what I was not wanted. My goal was to have my > environment completely and easily portable. Without the need of having > virtualkbox or anything else: just plugin the usb-stick in ANY computer I > want, and I have everything available. Instead of this, I could carry my > notebook with me, but that is not what I want. Be prepared, also in any > situations. And a usb-stick you can always carry with you. That was the idea. > > And except this little annoying question at boot - which is only annoying and > does no harm - everyt6hing is running perfectly to my needs. > > Oh, and I believe, you are right, the cuase of this issue might really be the > initrd (which maye can be configured somehow) and then chosen as the initrd, > which is copied to the livesystem. Maybe I will take a look at this. > > However, it looks like no one else had other ideas, which are the files > responsible, that the boot process is discovering the harddrive and wants to > decrypt it. Well you haven't exactly given a lot of information to go on. For example, before you hijacked your own thread (OT: Is there any size limit for ISO's?), you said that you only got the prompts when the stick booted in the "home" PC, not "foreign" ones. That didn't make it into this thread, but one about ISOs, which I had already deleted days earlier but happened to have skimmed. https://lists.debian.org/debian-user/2024/01/msg01218.html Not a lot here about which filesystems are encrypted, what's in crypttab, fstab, the initrd, etc. and so on, but just some narrative. > If no one else has any ideas in the future, I think, we should declare this > issue as closed. > > I got a workaround, this is well enough for me. > > Thank you and all others for your help! Cheers, David.
Re: Encrypted partiotions - which files related?
Hi Arno, > > That appears to be too much overhead to me... virtual machines (for > server as full OS) seem much more appropriate to me, in particular as > differences between in-VM and physical devices are pretty much (not > completely, though!) abstracted away these days. > non no, that is exactly, what I was not wanted. My goal was to have my environment completely and easily portable. Without the need of having virtualkbox or anything else: just plugin the usb-stick in ANY computer I want, and I have everything available. Instead of this, I could carry my notebook with me, but that is not what I want. Be prepared, also in any situations. And a usb-stick you can always carry with you. That was the idea. And except this little annoying question at boot - which is only annoying and does no harm - everyt6hing is running perfectly to my needs. Oh, and I believe, you are right, the cuase of this issue might really be the initrd (which maye can be configured somehow) and then chosen as the initrd, which is copied to the livesystem. Maybe I will take a look at this. However, it looks like no one else had other ideas, which are the files responsible, that the boot process is discovering the harddrive and wants to decrypt it. If no one else has any ideas in the future, I think, we should declare this issue as closed. I got a workaround, this is well enough for me. Thank you and all others for your help! Best regards Hans
Re: Encrypted partiotions - which files related?
Hello Hans, Am 29.01.2024 um 12:34 schrieb Hans: Am Montag, 29. Januar 2024, 12:16:14 CET schrieb Arno Lehmann: Hi Arno, yes, I saw the option SRCDISK. For my understanding it is used, when you want to mount a an alien system i.e. via network and make a livefile from this. But even I will do so, still all files will be copied to the livefilesystem, this makes no change. Well, I think this is what you can expect when using a tool to essentially copy your running Linux to a DVD image. You asked me, what I want. Simple: I am running KALI-Linux on one of my notebooks· with encrypted partitions. As my KALI got some tools, which need lots of plugins, has added some software NOT in the KALI-repo and got several personal settings, I could not build a livefile system of KALI by using live-build. I'll try to not digress into why you would want to use a heavily modified Kali in the first place, and then copy it to a different media, which probably results in something quite unmaintainable ;-) ... Everything is working perfectly, except this little annoying at boot. So I understand you want the exact same system as you run it on the host, *but* without the file systems mounted. Here we reach the point where I must admit I do not know how bootcdwrite works :-) However, from its documentation, I conclude it essentially puts all system configuration into its target directory tree, but it will have to modify some of it -- for example, if / is mounted from the live file system, a mount point in /etc/fstab for / would be counterproductive. The tool, accordingly, has to modify all the fstab entries for the file systems it copies. That seems to work, as you state above. Also apparently, the underlying block storage setup *is* copied. Your goal seems clear, you do not want that block storage to be accessed, so you'd have tomake sure the necessary setup is *not* copied. Depending on the stack you use, that could be md, lvm, luks, and possible more stuff. Now, where do you draw the line? I, for example, would prefer to have md automatically trying to assemble any RAID it may find, and LVM to kick in, too. Matters of taste put aside -- I think you can use the extra_changes() function in the configuration to mangle the respective configurations according to your needs. Removing entries from fstab and crypttab would possibly be sufficient, but if the created image makes use of your existing initrd, you might have to modify that as well. In that latter case, I would probably decide that the modifications are so invasive, that the idea to call this a "copy" of the origin system is no longer true, and just using a generic live / rescue system may be easier. Besides: Doing so, is a great advantage, as you might agree: I can make a livesystem from a server, then boot it and now can dangerousless test different configurations, can install packages, can test special settings and so on. Just without to harm any productive system. That appears to be too much overhead to me... virtual machines (for server as full OS) seem much more appropriate to me, in particular as differences between in-VM and physical devices are pretty much (not completely, though!) abstracted away these days. If a real, identical piece of hardware is needed for such projects, I would rather invest money than time and still carry the risk to accidentally destroy a production system, which also would, by necessity, be down for whenever I experiment. Which would at least make comparisons of behaviour much more difficult. And after testing, I can easily change the well tested configurations to the productive server! Two advantages, as you see. My views are quite different, but that may be because I'm working too much in environments where lab - staging - production systems are prescribed anyway, and configuration is engineered in labs and eventually deployed through automated systems. Does this make things a little bit clearer? Definitely clearer, but I suspect you'll eventually have to put a lot of your own effort into your final solution, as the general idea is rather specific. Cheers, Arno -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück
Re: Encrypted partiotions - which files related?
Am Montag, 29. Januar 2024, 12:16:14 CET schrieb Arno Lehmann: Hi Arno, yes, I saw the option SRCDISK. For my understanding it is used, when you want to mount a an alien system i.e. via network and make a livefile from this. But even I will do so, still all files will be copied to the livefilesystem, this makes no change. You asked me, what I want. Simple: I am running KALI-Linux on one of my notebooks· with encrypted partitions. As my KALI got some tools, which need lots of plugins, has added some software NOT in the KALI-repo and got several personal settings, I could not build a livefile system of KALI by using live-build. Thus my idea, creating a livefile from the running KALI (which I did already successfull with a debian system on another computer) and copy it to a usb- stick by using the dd command. So I created an ISO with about 32GB size, than copied it to a 64GB usb-stick and Voila, I got my own KALI running from usb-stick. Everything is working perfectly, except this little annoying at boot. Besides: Doing so, is a great advantage, as you might agree: I can make a livesystem from a server, then boot it and now can dangerousless test different configurations, can install packages, can test special settings and so on. Just without to harm any productive system. And after testing, I can easily change the well tested configurations to the productive server! Two advantages, as you see. Does this make things a little bit clearer? Best Hans > Hi Hans, > > Am 29.01.2024 um 11:30 schrieb Hans: > > Hi folks, > > > > I created a livefile system with bootcdwrite from a system with encrypted > > partitions. > > > > Everything is working fine, but ... > > Checking the manual for bootcdwrite.conf, I find > > OPTIONS > > SRCDISK > The Variables SRCDISK defines the root of the files that will be copied. > > For example, to build an image from a remote system, export > root-directory with nfs, mount it locally to /mnt/remote and add: > > SRCDISK=/mnt/remote > > > > It is added as prefix to KERNEL, INITRD, DISABLE_CRON and NOT_TO_CD, if > this are relativ paths (without starting "/") > > Default: > > SRCDISK=/ > > > which I understand implies that, by default, bootcdwrite more or less > copying the system you run it on. Thus, the expectation that it should > keep off of your lawn, erm, partitions seems unrealistic. > > On the other hand, you can create a configuration that uses a different > source system, or modifies it. In your case, it appears that you want > some modifications. > > My understanding, however, is that you want modifications going so deep, > that it may be more reasonable to *not* start with your regular system. > Before we try to identify what you'd have to exclude, can you give us an > idea of what your actual goal ist? > > Cheers, > > Arno
Re: Encrypted partiotions - which files related?
Hi Hans, Am 29.01.2024 um 11:30 schrieb Hans: Hi folks, I created a livefile system with bootcdwrite from a system with encrypted partitions. Everything is working fine, but ... Checking the manual for bootcdwrite.conf, I find OPTIONS SRCDISK The Variables SRCDISK defines the root of the files that will be copied. For example, to build an image from a remote system, export root-directory with nfs, mount it locally to /mnt/remote and add: SRCDISK=/mnt/remote It is added as prefix to KERNEL, INITRD, DISABLE_CRON and NOT_TO_CD, if this are relativ paths (without starting "/") Default: SRCDISK=/ which I understand implies that, by default, bootcdwrite more or less copying the system you run it on. Thus, the expectation that it should keep off of your lawn, erm, partitions seems unrealistic. On the other hand, you can create a configuration that uses a different source system, or modifies it. In your case, it appears that you want some modifications. My understanding, however, is that you want modifications going so deep, that it may be more reasonable to *not* start with your regular system. Before we try to identify what you'd have to exclude, can you give us an idea of what your actual goal ist? Cheers, Arno -- Arno Lehmann IT-Service Lehmann Sandstr. 6, 49080 Osnabrück
Encrypted partiotions - which files related?
Hi folks, I created a livefile system with bootcdwrite from a system with encrypted partitions. Everything is working fine, but strangely the livefile discovers the encrypted partitions and wants the decryption keys. This is wondering me, because the livefile is running in RAM and should not access the harddrive, encrypted or not. The workaround is, before creating the livefilesystem, I moved /etc/crypttab out of the way. Thus, it already wants to decrypt, but pressing enter for three times (pass an ampty password) let the boot go on. So I searched, which files are related to encrypted partitions, too, to get them also out of the way, but I found none. What did I miss? Any idea or solution, why thje livefile still finds and want to decrypt those partitions? Besides: If I let /etc/crypttab stay, then I must enter the correct password of the partitions during boot in the livefile (which IMO is normal). Thanks for any feedback. Best regards Hans
