Bug#377504: installation-report: problem pick'n'mix, mostly RAID-related
Hi, thanks for the quick and detailed answer.
Installation and installed system are basically two different things.
If you want a different priority from the default, just run
'dpkg-reconfigure debconf'.
With all due respect, I don't really agree - the installed system is
the result of the installation and as much configuration as possible
should "survive". If what I set in the "Change debconf priority" step
isn't saved then by the same logic the installer could omit to save
language, keyboard layout and time zone.
If you really think this is as it should be please change the name of
the step to "Change debconf priority (for installation only)"
2) Where has the 'state of the install' detection between steps gone?
Not exactly sure what you mean here. The installer does indeed keep track
of which steps have been completed and which not. If a step fails, most
of the time it can be resumed. If you decide to go back, you currently do have to
manually keep track of which steps you need to execute again.
Sorry, I'll try to explain what I meant:
Let's take partitioning as an example:
The old installer would allow me run any menu item that depended on
partitioning, provided
something remotely sensible was mounted on /target. That way one could
partition the disk via command line or even prior to the install.
d-i will instead check if its partitioning module was executed
successfully -- if the partman module chokes on a particular config
there's no obvious way to circumvent it.
In short the old installer would constantly check the actual state of
an install (is stuff already mounted? is that file already there? ...
) while d-i just checks for completion of one of its steps, which may
or may not have anything to do with being able to proceed.
Consequently d-i does not anymore support resuming an install after a
reboot in the middle.
However, you are not really meant to skip around unless you
really know what you're doing anyway.
People do make mistakes, select the wrong item, hit enter once too
often ... especially if they do not know what they are doing.
The installer has gotten a lot more complex which means that skipping
steps and doing things manually is probably no longer supported in the
way it was, although intervention still is possible in a lot of places.
Am I the only one wo consinders this a pretty serious bug? From the
FAQ: "Also installs for experienced users with higher control using
the same installer are a must."
To be honest, expert mode doesn't give higher control, just a few more
items to peck enter on.
> Most notably the item 'Install the base system' gives a choice of
> kernels at the end. Once I selected the wrong one, [...]
I don't understand this. AFAIK kernel selection is the last dialog in that
step, so if you already selected one there is no going back within that
step anyway.
No, there's a dialog which asks for the initrd creator to use, and
that had a back button. Even if there weren't, selecting the wrong
item in a list should not force you to repeat a very time-consuming
and unrelated (from an user's point of view) step.
Why would you want to select a different timezone from the country you are
in?
Good question, it just seemed odd to have a step with no user input.
Maybe a company in a multi-TZ country would like their servers all to
show the same local time?
The dialog was only added because else the step would have no visible output at all at
medium or low priority.
Fair enough.
> Also, the 'clock in UTC' question should have an 'is this correct'
> dialog which shows the output of date or similar.
We have discussed that at length. Showing the time only makes sense if you
can offer the option to change it. Currently we cannot.
I'd find it reassuring to check the shown local time against a wall
clock at this point, is all. An "It is now:" + output of 'date' would
do fine.
Your [partitionable md] naming scheme seems extremely non-standard to me.
As indicated before, please provide some references to convince us that it should be
supported.
From the mdadm man page, DEVICE NAMES section: "The standard names for
partitionable arrays (as available from 2.6 onwards) is one of
/dev/md/dNN or /dev/md_dNN. Partition numbers should be indicated by
added "pMM" to these [...]"
As for supported, why shouldn't they be? It's a regular partitionable
block device, just like /dev/sda or /dev/hda. If partman needs a major
update just to support block devices with new names the design is
rather questionable IMHO.
If partman is only intended for the most common cases that's fine, but
then the (expert) user needs another way to partition that is
recognized as such by the installer.
> having two ways to setup RAID, with the obvious one not working for root-on-RAID
> is confusing.
Which means you probably did not read the installation guide on the
subject?
What has the installation guide got to do with this? I stand by my
original point, which is that having access to mdcfg from partman and
from the main menu, with different dependencies is confusing.
Logically the md management belongs to partitioning -- why not remove
the main menu entry?
> 3) mdcfg should support bitmaps
You'll
have to be more specific though as to what exactly is wanted and for
which RAID levels. Most of us are not RAID experts.
Insert a checkbox somewhere "[x] create with internal bitmap (can
speed up rebuilds)" and if checked add the option "--bitmap internal"
to the mdadm command line when creating the array. Works for 1 and 5
at least, probably for all redundant levels.
The way I understand it it's a RAID-level journal -- the bitmap is
used to mark out-of-sync parts of an array so only those need to be
resynced in case of a power failiure, etc.
> How about grouping eligible partitions with approximately the same size
> together on one line, to make it easier to select the correct disks?
Nice suggestion. We could at least list the size in the dialog.
Yes, that's probably easier to do. Nice to finally agree on something :)
> 5) mdcfg creates arrays out-of-order
Could it be that the naming was influenced by the presence of old
superblocks?
Possibly. If I can reproduce it with clean disks I'll get back to you.
You can go back to the menu [from partman] whenever you like.
No, I couldn't. The partman module multiple times refused to let me
leave without writing something to the disks. Particularly funny once
I actually had a partitionable array running and partman decided it
wanted to re-write the partition table _on_the_component_disks_
However, you cannot expect the installer to accept a broken disk setup
and continue the installation as if nothing is wrong.
Nothing broken about it, just no root fs defined. Subsequent steps are
free to complain.
The automatic formatting of the swap space is a minor annoyance for me
too, but was probably a conscious choice.
- likely breaks any software-suspended OSs on other disks
- ruins RAID consistency since partman again formatted partitions on
the component devices.
In closing, my main complaint is that d-i lacks a lot of flexibility
and thus tolerance for non-standard scenarios compared to the previous
generation. I hope this will get better with time. Those cases that
were planned for (i. e. standard desktop installs) work superbly.
Thanks,
C.
Reply to: