Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #266471 > unrolled thread

OT: Is there any size limit for ISO's?

Back to article view | Back to linux.debian.user

Contents

  OT: Is there any size limit for ISO's? Hans <hans.ullrich@loop.de> - 2024-01-22 21:10 +0100
    Re: OT: Is there any size limit for ISO's? Marco Moock <mm@dorfdsl.de> - 2024-01-22 21:30 +0100
    Re: OT: Is there any size limit for ISO's? "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-22 22:00 +0100
      Re: OT: Is there any size limit for ISO's? Hans <hans.ullrich@loop.de> - 2024-01-22 22:40 +0100
        Re: OT: Is there any size limit for ISO's? Stefan Monnier <monnier@iro.umontreal.ca> - 2024-01-22 23:40 +0100
          Re: OT: Is there any size limit for ISO's? Hans <hans.ullrich@loop.de> - 2024-01-23 11:30 +0100
            Re: OT: Is there any size limit for ISO's? Hans <hans.ullrich@loop.de> - 2024-01-24 13:30 +0100
        Re: OT: Is there any size limit for ISO's? gene heskett <gheskett@shentel.net> - 2024-01-23 03:30 +0100
    Encrypted partiotions - which files related? Hans <hans.ullrich@loop.de> - 2024-01-29 11:40 +0100
      Re: Encrypted partiotions - which files related? Arno Lehmann <al@its-lehmann.de> - 2024-01-29 12:20 +0100
        Re: Encrypted partiotions - which files related? Hans <hans.ullrich@loop.de> - 2024-01-29 12:40 +0100
          Re: Encrypted partiotions - which files related? Arno Lehmann <al@its-lehmann.de> - 2024-01-29 13:20 +0100
            Re: Encrypted partiotions - which files related? Hans <hans.ullrich@loop.de> - 2024-01-29 16:20 +0100
              Re: Encrypted partiotions - which files related? David Wright <deblis@lionunicorn.co.uk> - 2024-01-29 21:00 +0100

#266471 — OT: Is there any size limit for ISO's?

Hi folks, 

does anyone know, if there is a limit of the size an iso may have?

Background: I have a selfmade lifefile iso image, which was created by 
bootcdwrite. The size of the imagefile is about 32GB.

I copied the file using dd to an usb stick, but it does crash at boot.

When the stick is booting, first appear the usual text messages, but then the 
screen goes blank and the further boot hangs.

However, when I am booting this file (this iso-image) with Virtualbox, 
everything is working well.

As it is a livefile and goes blank, I can not see, why it hangs.

Note: In earlier times I had a smaller image (about 8 GB), which booted 
perfectly. 

So I believe, the size of the image is, what matters. But maybe I am wrong.

Be happy for all hints.

Best regards

Hans

[toc] | [next] | [standalone]

#266473

Am 22.01.2024 um 21:07:55 Uhr schrieb Hans:

> I copied the file using dd to an usb stick, but it does crash at boot.

Is the USB stick equal or bigger than the ISO?
If not, the writing process will just stop at the end of the device and
the stick data will be corrupted because they are incomplete.

[toc] | [prev] | [next] | [standalone]

#266474

Hi,

Hans wrote:
> does anyone know, if there is a limit of the size an iso may have?

With xorriso: 4 TiB = 4096 GiB.

An ISO 9660 filesystem may have 2 exp 32 data blocks. The usual block
size is 2 exp 11 = 2048 bytes. That would be 2 exp 43 = 8 TiB in total.
But xorriso uses libburn for writing and a poor design decision of
about 20 years ago lets it use signed int for block addresses.
So only 2 exp 31 blocks = 4 TiB are possible with libburn and xorriso.


> Background: I have a selfmade lifefile iso image, which was created by
> bootcdwrite. The size of the imagefile is about 32GB.

Looks like bootcd uses genisoimage for producing the ISO,
(https://tracker.debian.org/media/packages/b/bootcd/control-6.7)

Anyways, 32 GB of size should not be a problem.


> When the stick is booting, first appear the usual text messages,

Can you determine the origin of the last visible messages ?
BIOS/EFI ?
Boot loader (GRUB or ISOLINUX/SYSLINUX) ?
Linux ?
Debian installation software ?


> but then the screen goes blank and the further boot hangs.
> However, when I am booting this file (this iso-image) with Virtualbox,
> everything is working well.

Is Virtualbox using the same BIOS type as the real machine ?
I mean EFI versus Legacy BIOS aka CSM mode.


> Note: In earlier times I had a smaller image (about 8 GB), which booted
> perfectly.

Is the USB stick large enough for the image ?

Can dd read the whole image back from the USB stick ?

  # Set variable blocks to image file size divided by 2048
  blocks=...
  # Set variable stick to device file address of the USB stick
  stick=...

  dd if="$stick" bs=2048 count="$blocks" | md5sum

If no i/o error is reported by dd, compute the MD5 sum of the image file
and compare both.


> So I believe, the size of the image is, what matters. But maybe I am wrong.

It's not impossible. Especially if the stick hardware has problems.
But depending on the origin of the last visible message there is also
a chance that boot loader or Linux derail because of buggy file content
in the elsewise healthy ISO.


Have a nice day :)

Thomas

[toc] | [prev] | [next] | [standalone]

#266476

Hi Thomas,

> Anyways, 32 GB of size should not be a problem.

Ok. size does not matter
> 
> > When the stick is booting, first appear the usual text messages,
> 

The first message is the boot prompt. Then the usual messages· PCI found and so 
on.

Last message is, that a new USB device is found, then the screen goes blank. I 
can make some snapshots of a video, by interest.

> Can you determine the origin of the last visible messages ?

Yes, see above.
> BIOS/EFI ?

The BIOS is without EFI.

> Boot loader (GRUB or ISOLINUX/SYSLINUX) ?

Bootloader is grub, the image is an image from kali linux. The big size comes 
from a virtualbox image inside for windows 10. (the vmdk is smaller than 4GB, 
so bootcdwrite got not into problems).

> Linux ?

Yes, KALI Linux, which is Debian based.
> Debian installation software ?

vers close to.
> 
> Is Virtualbox using the same BIOS type as the real machine ?
> I mean EFI versus Legacy BIOS aka CSM mode.
> 
Yes, it uses legacy bios. 

> 
> Is the USB stick large enough for the image ?

Yes, it is. The image is about 32 GB big, the USB-stick is 64GB. Should fit 
very well. The last ISO working was baout 12GB and fit on a 32GB stick.
> 
> Can dd read the whole image back from the USB stick ?
> 

Yes, it can. I tried also dd with option bs=1, so to install bitwise, just to 
make clear everything is copied.

>   # Set variable blocks to image file size divided by 2048
>   blocks=...
>   # Set variable stick to device file address of the USB stick
>   stick=...
> 
>   dd if="$stick" bs=2048 count="$blocks" | md5sum

I already tried thzis, too. 1024, 2048 and 4096, and of course 1.
> 
> If no i/o error is reported by dd, compute the MD5 sum of the image file
> and compare both.
> 

Already did, comarision was ok.

> It's not impossible. Especially if the stick hardware has problems.
> But depending on the origin of the last visible message there is also
> a chance that boot loader or Linux derail because of buggy file content
> in the elsewise healthy ISO.
> 

This stick is new. However, the stck I used before, was another distributor. I 
changed the stick, because the former stick I used before, died after about 
10th or 12th installing of the iso. 
> 
> Have a nice day :)
> 
Same to you!

Best 

Hans

> Thomas

[toc] | [prev] | [next] | [standalone]

#266481

> Last message is, that a new USB device is found, then the screen goes
> blank.  I can make some snapshots of a video, by interest.

My crystal ball blames the video driver (presuming that the DRM module
for your video card is loaded around the same time as that USB device is
found).


        Stefan

[toc] | [prev] | [next] | [standalone]

#266509

Am Montag, 22. Januar 2024, 23:35:23 CET schrieb Stefan Monnier:
Hi Stefan,

I think your crystal ball is clever. The same idea came in my mind, and I 
believe, the screen goes blank, when the graphics card wants to switch into 
vesa mode. 

Please note, that I start the livefile on the sam computer, where I have built 
it from. So of course, all graphic drivers are existent. 

The next days I will try some kernel settings, as far as I rembeer, I can 
force some vga modes at boot (something I used in the old times like "vga=691 
or so, can't exactly remember).

I will inform you!

Best 


Hans
 

> > Last message is, that a new USB device is found, then the screen goes
> > blank.  I can make some snapshots of a video, by interest.
> 
> My crystal ball blames the video driver (presuming that the DRM module
> for your video card is loaded around the same time as that USB device is
> found).
> 
> 
>         Stefan

[toc] | [prev] | [next] | [standalone]

#266555

Hi all,

so, the problem is 90 percent solved. It was indeed the problem with the 
graphic mode, just as Stefan's crytal ball told. Orinially the kernel driver 
should automatically detect, which mode is possible and then switch to it. But 
it doesn't. So the screen went blank. 

The fix was easy: I added the parm "vga=791" to the kernel and the screen went 
to the required solution.

Everything is working now, when I boot the stick on another computer.

Thus I can say: generally it is working!
 
However: When I boot this stick on the same computer, where I built the iso, 
it hangs at boot. I suppose, this is related to, that I am using encrypted 
filesystems on the harddrive. It appears (although the ISO is working 
completely in RAM), it wants the encryption password.

This is strange. In the past I gor a solution for it: Before building and 
creating the ISO, I moved /etc/crypttab away and then created the ISO. This 
was working well in the past. 

You should know, that I have written a little script, which prepares the 
system (by deleting history and other unnecessary things or moving some things 
away), then build and at last move everything back. 

This is working like a charm.

Oh, and maybe the issues I described might appear with a newer kernel, because 
KALI linux was running 6.1 but now it is running 6.5. However, this might not 
matter, just want to mention it, if someone else is interested and fell into 
the same issue as me.

As I said: the problem is 90 percent solved, now I am just try to solve the 
(very!) little thing with the password issue.

Stay tuned, I'll be back.

Best 

Hans  

[toc] | [prev] | [next] | [standalone]

#266483

On 1/22/24 16:30, Hans wrote:
> Hi Thomas,
> 
>> Anyways, 32 GB of size should not be a problem.
> 
> Ok. size does not matter
>>
>>> When the stick is booting, first appear the usual text messages,
>>
> 
> The first message is the boot prompt. Then the usual messages· PCI found and so
> on.
> 
> Last message is, that a new USB device is found, then the screen goes blank. I
> can make some snapshots of a video, by interest.

 From a C.E.T., probably not needed. If the found usb hub has something 
plugged in, the port power will be enabled in order to investigate what 
it might be, and if its usb bus powered, might draw too much, triggering 
an under voltage protective shutdown, test by externally powering 
whatever is plugged in, or unplugging it to remove that load.  If 
nothing is/was plugged in, its likely something else unrelated.

>> Can you determine the origin of the last visible messages ?
> 
> Yes, see above.
>> BIOS/EFI ?
> 
> The BIOS is without EFI.
> 
>> Boot loader (GRUB or ISOLINUX/SYSLINUX) ?
> 
> Bootloader is grub, the image is an image from kali linux. The big size comes
> from a virtualbox image inside for windows 10. (the vmdk is smaller than 4GB,
> so bootcdwrite got not into problems).
> 
>> Linux ?
> 
> Yes, KALI Linux, which is Debian based.
>> Debian installation software ?
> 
> vers close to.
>>
>> Is Virtualbox using the same BIOS type as the real machine ?
>> I mean EFI versus Legacy BIOS aka CSM mode.
>>
> Yes, it uses legacy bios.
> 
>>
>> Is the USB stick large enough for the image ?
> 
> Yes, it is. The image is about 32 GB big, the USB-stick is 64GB. Should fit
> very well. The last ISO working was baout 12GB and fit on a 32GB stick.
>>
>> Can dd read the whole image back from the USB stick ?
>>
> 
> Yes, it can. I tried also dd with option bs=1, so to install bitwise, just to
> make clear everything is copied.
> 
>>    # Set variable blocks to image file size divided by 2048
>>    blocks=...
>>    # Set variable stick to device file address of the USB stick
>>    stick=...
>>
>>    dd if="$stick" bs=2048 count="$blocks" | md5sum
> 
> I already tried thzis, too. 1024, 2048 and 4096, and of course 1.
>>
>> If no i/o error is reported by dd, compute the MD5 sum of the image file
>> and compare both.
>>
> 
> Already did, comarision was ok.
> 
>> It's not impossible. Especially if the stick hardware has problems.
>> But depending on the origin of the last visible message there is also
>> a chance that boot loader or Linux derail because of buggy file content
>> in the elsewise healthy ISO.
>>
> 
> This stick is new. However, the stck I used before, was another distributor. I
> changed the stick, because the former stick I used before, died after about
> 10th or 12th installing of the iso.
>>
>> Have a nice day :)
>>
> Same to you!
> 
> Best
> 
> Hans
> 
>> Thomas
> 
> 
> 
> 
> .

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
  soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
  - Louis D. Brandeis

[toc] | [prev] | [next] | [standalone]

#266708 — 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
 

[toc] | [prev] | [next] | [standalone]

#266709 — 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

[toc] | [prev] | [next] | [standalone]

#266710 — 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

[toc] | [prev] | [next] | [standalone]

#266711 — 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

[toc] | [prev] | [next] | [standalone]

#266718 — 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  
 

[toc] | [prev] | [next] | [standalone]

#266741 — 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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web