[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: LVM and RAID



On Thu, 29 Aug 2013 19:20:03 -0300
Ben Armstrong <synrg@sanctuary.nslug.ns.ca> wrote:

> All I was trying to convey is many live users have their own use cases
> and each one might think their own use case should be covered in the
> default images. But we do have a flexible set of tools that can be
> used to address everyone's own use cases without changing the prebuilt
> ones.

Of course, for many of those use cases, access to existing filesystems
would be an absolute prerequisite. It might not even be possible to get
a network connection without it.

quoting my previous messages:

>> if you can construct any argument as to why running a print server is
>> a more basic function for a live ISO than mounting existing
>> filesystems, I'd be curious to hear it.

>> http://live.debian.net/gitweb/?p=live-images.git;a=blob;f=images/xfce-desktop/config/package-lists/desktop.list.chroot;hb=HEAD

>> I'd like to hear an answer to that last question. Explain to me why
>> it's so important that a live ISO can function as a print server that
>> this must be explicitly specified, whereas doing the same to allow
>> access to standard filesystems would be inappropriate and
>> unacceptable.

> Yes, there is a precedent for inclusion of extra materials. You'll
> note that the bulk of these are covered in various task-* packages, as
> I said.

>> No doubt for very good and valid technical reasons. As there would be
>> for lvm2 and mdadm.
> 
> I don't know the history of all of those, but I would suppose so.

I await an explanation of why print serving is in, but standard mass
storage systems are out.

> Since you raised the objection that you didn't like to use the rescue
> image because it was command-line only, was it jumping to conclusions
> for me to think you wanted the prebuilt desktop images to serve as a
> rescue system on occasion? Today *you* only want just a couple of
> rescue tools. Tomorrow another user will want more, etc. That's how we
> ended up with the lengthy rescue list we have today.

>> Deciding that the ability to mount existing filesystems is important
>> certainly comes under the heading of "focusing on the live part of
>> the problem", which is all that I'm suggesting.
> 
> Fair enough.

> I was just following where "let's expand the purpose of our desktop
> images to handle the 'rescue' use case" leads if you apply the same
> logic to accepting these two to the next two, and the next four, and
> so on ...

quoting from my first post:

>> Wanting to mount existing filesystems is not specifically a "rescue"
>> operation.

> I just don't know who decides which of the many possible packages from
> the rescue category are "worth including" and on what criteria.

I understand your desire to have some objective criteria to decide what
gets in and what doesn't, to avoid kitchen-sink-syndrome. So let me
propose one: the live CDs should have the same level of filesystem
support as the normal installation CDs. That would be e2fsprogs (already
present), lvm2, mdadm, parted, and grub2.

I concede that those last two arguably fall into the category of
"rescue" utilities. But they are on the installation CDs; why should
they be treated as a special case by excluding them from the live CDs?

If it were decided to include these five packages according to this
criterion, perhaps the way to do it would be to create another package
list called "filesystems.list.chroot" (what is the significance of the
"chroot"?), and add this to all the ISO build lists.


-- Ian Bruce


Reply to: