Re: LVM and RAID
On Wed, 28 Aug 2013 19:58:00 -0300
Ben Armstrong <synrg@sanctuary.nslug.ns.ca> wrote:
>> one of the things that people very commonly want to do with a live
>> ISO is access their existing filesystems, when they can't boot off
>> them for some reason. LVM and RAID are not rare or unusual; they are
>> standard for any serious installation.
>
> If they are "standard for any serious installation", why aren't they
> present if I do an install, accepting all default answers?
I can't answer that question; if it were up to me, they would be.
Perhaps a default installation is not considered to be serious?
I can't imagine why anybody who uses a computer for serious work would
be willing to risk losing their filesystems to a single hard disk
failure.
Or would forego, in advance, the possibility of enlarging their
filesystems without taking them offline, if that ever turned out to be
necessary.
But perhaps that's because my definition of "serious work" means that
it's sufficiently important to be worth paying an extra $70 for a second
hard disk, in order to make these things possible.
Others may differ on this point.
>> If this usage is not contemplated, then why include the ext{2,3,4}
>> utilities on the desktop ISOs?
>
> You mean e2fsprogs which is "Essential: yes"? Please try a plain
> debootstrap and see what happens. This was just a consequence of what
> is installed in Debian by default.
Do you wish to argue that if this package was not automatically included
on the live ISO images, it would be wrong to explicitly specify it?
>> You'll say "that's what the rescue ISO is for."
>
> Exactly.
>
>> But then you have to use a text-mode console, which is really
>> inconvenient if you need to look at a lot of things simultaneously,
>> or refer to PDF or HTML (or online) documentation. It would be much
>> better if basic mass-storage functionality was included in the
>> desktop ISOs, as it very easily could be.
>
> Aha. And now for the first time you state your real requirements.
No, I was pretty clear in my first message:
>> I am aware that there is a non-graphical "rescue" image which
>> includes these packages, but there is no reason why you should have
>> to sacrifice the window manager in order to have them. Wanting to
>> mount existing filesystems is not specifically a "rescue" operation.
>> Presumably the graphical images include the ext{2,3,4} filesystems;
>> why should LVM and RAID, which are standard for any serious
>> installation, be in a different category?
It surely doesn't take any great leap of the imagination to see why a
window manager is preferable to a text-mode console.
> I'll recap and, I hope, sum up with a clarification of my point, as
> you seem to have not gotten it:
No, I get it. I answer every point you raise, so you keep on making up
new and increasingly irrelevant objections.
> The guiding principle for making each of the prebuilt desktop images
> is that they should reflect what you would get by default performing a
> Debian install and selecting each of those desktops.
If that's the guiding principle, it's clearly a flexible one, because
all of the desktop ISO images --
http://live.debian.net/gitweb/?p=live-images.git;a=tree;f=images/gnome-desktop/config/package-lists;hb=HEAD
http://live.debian.net/gitweb/?p=live-images.git;a=tree;f=images/kde-desktop/config/package-lists;hb=HEAD
http://live.debian.net/gitweb/?p=live-images.git;a=tree;f=images/lxde-desktop/config/package-lists;hb=HEAD
http://live.debian.net/gitweb/?p=live-images.git;a=tree;f=images/xfce-desktop/config/package-lists;hb=HEAD
-- already explicitly include packages task-print-server, task-english,
task-laptop, task-ssh-server, console-tools, memtest86+, and rsync, all
with priority "optional" or "extra".
No doubt for very good and valid technical reasons. As there would be
for lvm2 and mdadm.
Although 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.
> We prefer to delegate the responsibility for package selection to each
> of the teams who make it their specialty to say "this is what a
> default Debian install for this desktop should look like". To that
> end, we make use of task-* packages maintained by teams other than
> Debian Live to decide what goes into those images. This frees us from
> the burden of maintaining our own, possibly divergent lists of
> packages, preferring to lean on the expertise of each group
> responsible for each task-* package to make these decisions for us.
And nowhere did I suggest altering, or maintaining divergent versions
of, the task-gnome-desktop, task-kde-desktop, task-lxde-desktop, and
task-xfce-desktop packages.
> It also gives users the freedom to use those same package selections
> in other contexts that may not be live systems, or may not be built
> using our own tools. It is simply a way of saying "we focus on the
> live part of the problem, and the rest of Debian takes care of the
> rest."
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.
> I acknowledge this does not cover all possible use cases, and your
> very specific use case of "I want a desktop system that is also a
> rescue system" is not addressed.
I didn't say that, you did. I said I wanted a system with a window
manager that could access preexisting mass storage filesystems. This is
nowhere near as bizarre as you make it out to be; there are whole
distributions that serve this purpose:
http://www.sysresccd.org/
In answer to your inevitable question of "why not use that, then?" --
normally you could, but there are situations in which you might need
Debian-specific tools, and therefore actually need to be running Debian.
> To address it properly, we would need to make each of the four
> desktop-flavoured variants of a rescue system, as surely everyone
> desiring a desktop-based rescue image would want to have it in their
> own favourite flavour.
Nowhere did I propose creating "variants". This is a strawman argument
of your own invention. I said that RAID and LVM filesystems could be
accommodated at the cost of increasing the size of the existing images
by about 0.25%, which you just acknowledged is "not too big" and "easy
to include".
> Logically, as well, we would need to compound the historical mistake
> of maintaining our own package lists within our rescue image
> configuration by extending it to cover "what are the proper graphical
> rescue tools to include on each flavour of desktop", as surely GNOME
> users will want GNOMEish rescue tools, KDE users will want KDEish
> rescue tools, etc.
If this seems logical to you, that's your business. I never said or
implied any such thing.
Nowhere did I request "graphical rescue tools". I suggested lvm2, mdadm,
and possibly parted, which, if you're not already aware, are all console
utilities.
> I'm personally not interested in such work ...
Neither am I, which is why I didn't suggest it. I'm not sure why you
would bother to write such a lengthy argument against something that
nobody is asking for.
-- Ian Bruce
Reply to: