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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
