Bug#872867: related bug

[Daniel Pocock]

Some interesting comments in here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900849

Bug#877200: help users identify unknown keyboard layouts

[Daniel Pocock]

Package: debian-installer
Severity: wishlist

The installer currently asks the user to select their keyboard layout
from a list.

Sometimes the user or person doing the installation doesn't know the
name/country for their keyboard layout.

It would be useful to offer some type of keyboard identification wizard
that takes them through a series of questions to identify their keyboard
and then asks them to press some keys (like "z" and "/") to see if they
are correctly recognized.

Bug#245465: related bugs / discussions

[Daniel Pocock]

https://lists.debian.org/debian-devel/2012/05/msg01092.html
https://lists.debian.org/debian-devel/2012/06/msg00311.html (summary of
the above)

https://wiki.debian.org/SSDOptimization#Reduction_of_SSD_write_frequency_via_RAMDISK

and various bugs about systemd doing tmp on tmpfs by default:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718906
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807769

and systemd ignoring RAMTMP:
https://github.com/debian-pi/raspbian-ua-netinst/issues/210

Bug#875393: partman-auto: allow user to easily edit mount points and sizes

[Daniel Pocock]

Package: partman-auto
Severity: wishlist

When people select the guided partitioning, the list of possible
partitions is very restricted (all in one, root+home or root+home+var+tmp)

It would be useful to have an extra option, "custom", where the user can
see a list:

/ (root)   100%
/home  0%
/var   0%
/tmp   0%

and edit the percentages or replace them with sizes in GB

If they put 0% or 0, that partition/LV would not be created.

For tmp, it would also be useful to have some way to indicate that tmpfs
/ ramdisk should be used (see also bug #245465)

This screen would also show the amount of space free if they don't use
it all.

This would aim to help people with a single disk (or single RAID volume)
and wouldn't need to try and cover use cases where they want to assign
different mounts to different physical volumes or choose individual
filesystem types.

Bug#872867: is ISO-3166 really the optimal list for our users?

[Daniel Pocock]

On 24/08/17 18:02, Wouter Verhelst wrote:

> Case in point: why would Kosovo *need* to be on the d-i list of
> countries? Is there a difference between Kosovo and Serbia[1] or other
> countries in the former Yugoslavia that d-i would need to be aware of
> (such as locale settings, keyboard layout, time zone, or preferred
> mirror), or is this bug in fact just the result of people with a
> background of Kosovan nationalist ideology complaining about it to
> you[2]? So far I've only seen you argue that "Kosovo needs to be on the


Another consideration is the uncertainty:  for many ordinary users (not
necessarily people with strong political opinions) it is simply not
clear what the technical consequences will be if they select RS or AL
from the list.  Simply abolishing the list and asking people to manually
select a timezone may be one way to eliminate this uncertainty.

About 50% of the population is under 30[1] - many of them presumably
have no memory of being a Serbian or Yugoslavian, they have simply been
brought up as Kosovans.  This is also the age group where people are
likely to try free software.  I haven't observed any Kosovan taking up
arms when they see the country list, rather, it is more sadness,
disappointment and frustration.

Regards,

Daniel


1. http://www.indexmundi.com/kosovo/age_structure.html

Bug#872867: is ISO-3166 really the optimal list for our users?

[Daniel Pocock]

On 24/08/17 18:02, Wouter Verhelst wrote:

> Case in point: why would Kosovo *need* to be on the d-i list of
> countries? Is there a difference between Kosovo and Serbia[1] or other
> countries in the former Yugoslavia that d-i would need to be aware of
> (such as locale settings, keyboard layout, time zone, or preferred
> mirror), or is this bug in fact just the result of people with a

90% of citizens in Kosovo are ethnic Albanian[1] and would probably
prefer the installer to help them select the Albanian language (coming
soon thanks to a translation sprint at FOSSCamp.cc) and mirrors in
Kosovo.  These are probably the two main differences from RS.  Kosovo
has EUR as currency, RS does not.

The locale chooser and the country list for mirrors could potentially
work in different ways too, e.g. maybe subdivisions could be introduced
for the mirror list.

It doesn't impact time zone

I don't have hard data about the keyboard layouts users prefer in the
region, but I've seen US style keyboards there.

Regards,

Daniel



1. https://en.wikipedia.org/wiki/Kosovo_Albanians

Bug#872867: is ISO-3166 really the optimal list for our users?

[Daniel Pocock]

On 24/08/17 08:51, Wouter Verhelst wrote:

> In the case of XYZ, "use a different distribution" isn't going to
> silence such people. Instead, they'll just yell harder. "Debian's making
> a political statement about XYZ, and it's wrong, and I told them that
> it's wrong, and they're ignoring me!"
>

Including and excluding are different things

Including extra "countries" may cause offense to people with certain
political sensitivities, but doesn't cause any technical problem for
people in other countries.

So if Debian has a policy that we favour inclusion over exclusion and
that any country can be listed if at least one DD visits there and
confirms it exists, is that political or would that be a policy that can
be defended?

I wonder how long it would be before somebody proposed California or
Scotland?  If they entered the list at the same time as Kosovo (and Hutt
River) then it becomes a lot less political and the focus is not on a
single region.

> Whatever solution you[1] come up with should avoid that.
> 
> [1] I'm assuming you're planning on submitting a patch, since you
> suggested this change in the first place...
> 

I would not want to waste time coding something before we have some
consensus about what the community is comfortable with.

Bug#872867: is ISO-3166 really the optimal list for our users?

[Daniel Pocock]

On 23/08/17 19:22, Wouter Verhelst wrote:
> On Tue, Aug 22, 2017 at 11:02:27AM +0200, Daniel Pocock wrote:
>> While it is good that we use material from official sources, Debian is
>> independent of any state and may not need to feel constrained by such lists/
>> standards in the same way that a commercial software vendor might be.
> 
> On the other hand, the advantage of having an official standard to point
> to is that we can deflect complaints when they appear.
> 
> There are many areas in dispute in this world, and in some cases
> deciding whether a particular area is or is not a country will result in
> offending one or the other party. When Debian accidentally and

We should be respectful of all users, but I don't think fear of causing
offence should be the primary concern.  Otherwise we never would have
moved to systemd.

I feel the concern should be providing a technically valid installation
process for as many users as possible.


> temporarily updated the representation of the countries in the installer
> so that they would refer to the area sometimes referred to as the
> "Republic of China", otherwise known as "Taiwan", in a particular way,
> this offended one of our developers enough that he decided to leave the
> project.
> 

If a developer puts his political opinions against the needs of users in
 a particular region, then is it possible that developer is failing to
respect the Debian Social Contract and may not be eligible to be a
developer?

In such cases, it is sometimes possible to identify other developers or
users who adopted a project because they favour the decision too.

> While it may be true that the list of countries in ISO-3166 is decided
> upon by a small number of people, presumably these people are aware of
> all the peculiarities and policital sensitivies in deciding what is or
> isn't a country, and what should or should not be allowed in a list of
> countries. As such, deciding to use ISO-3166 as our base to decide on
> which countries to list keeps Debian politically neutral in an area for
> which we really have no expertise and in which we really should not get
> ourselves involved one way or the other.
> 

I agree Debian should not get into the political side of this debate.
This bug is only for the technical side...

> It may make sense to change the list of places so that it also includes
> subdivisions, provided we do so in either a way which makes the
> distinction between "country" and "subdivision" clear, or a way which
> puts both in a singular list but which makes it clear that the list does
> not refer to countries in any form or sort. Both solutions would allow
> areas such as Kosovo to appear on the list of places, without offending
> people who believe Kosovo should not be considered an independent nation
> (yes, there are such people).
> 

If that means a user in Kosovo is more likely to configure their system
correctly, then it is a good technical solution, similar to what I
described (leaving out the country codes for such regions and helping
them choose alternatives).

We could also have a disclaimer, "Not all entries in this list are
officially recognized as countries, some are disputed territories that
have been included for the purpose of helping users in those regions get
the optimal configuration."

More concise: "Select the entry from this list of regions and countries
that most closely matches your geographic location"


> We should not, however, move away from ISO-3166 as our basis for
> deciding what is or isn't a country, unless you can point to another
> list which has the same level of international recognition as ISO-3166.
> I don't think such a list exists, however.
> 
> If we continue to use the ISO-3611 list, then if any error in the list
> of countries in our installer exists it will either be a bug in the
> installer code (which we could obviously fix and apologise for,
> hopefully without offending anyone), or a matter of "the list is
> outdated" (which we would usually fix by rebuilding the installer,
> hopefully also without offending anyone), or an error in the ISO-3611
> list (in which case people might be offended, but the offending elements
> would not be ours and we can tell them to get ISO to update the list
> rather than to complain to us).
> 
> Debian is about Free Software; it is not about International Politics.
> Let's keep it that way.

I agree - but producing Free Software means we should feel free to
innovate in this area as long as we are open and honest with our users
about what we are doing and why.

As systemd demonstrated, Debian can't please everybody all the time.

Regards,

Daniel

Bug#872867: another option: GENC

[Daniel Pocock]

Mozilla decided[1] to use GENC[2], a list produced by the US Government
and including additional countries that are not correctly covered by
ISO3166.

The US Govertment's approach (making their own list based on ISO3166) is
similar in some ways to the approach I have suggested for Debian.


1. https://bugzilla.mozilla.org/show_bug.cgi?id=733417#c20
2. https://nsgreg.nga.mil/doc/view?i=2500

Bug#872867: is ISO-3166 really the optimal list for our users?

[Daniel Pocock]

On 22/08/17 10:52, Bastian Blank wrote:
> On Tue, Aug 22, 2017 at 12:28:18AM +0200, Daniel Pocock wrote:
>> According to this section in the Debian Installer i18n guide[1], the
>> list of countries is based on ISO3166.
> Kosovo is listed in ISO3166 as RS-KM, see
> https://www.iso.org/obp/ui/#iso:code:3166:RS 
>
> However we don't list subdivisions.

I'm not sure adding support for subdivisions would satisfy Debian users
in some of these situations but it could be one part of the solution.

>> According to wikipedia, ISO3166 comes from a group of 10
>> representatives[2] from mostly rich countries.
> Most of them from countries actually reognizing Kosovo as independent,
> so what?

While it is good that we use material from official sources, Debian is
independent of any state and may not need to feel constrained by such
lists/standards in the same way that a commercial software vendor might be.


>> It may be interesting to support micronations like the Principality of
>> Hutt River[5] too.
> This one is not recognized by anyone.
>
> Please let the peolpe of Kosovo speak for themselves.

Well, when somebody in Kosovo set up a new mirror, they listed[1] it
under AL (Albania) rather than RS (Serbia).

Regards,

Daniel

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867255

Bug#872867: is ISO-3166 really the optimal list for our users?

[Daniel Pocock]

Package: localechooser
Version: 2.69
Severity: wishlist

While visiting Kosovo, I have met several people interested in becoming
Debian users.

The first time I helped one of them run the Debian installation, I was
baffled to find that their country was not in the list offered by the
installer.

It is potentially not a good situation for a developer to be in a
country, surround by 1.8 million people who consider themselves to be
citizens of a country that our installer doesn't know about. 
Fortunately Kosovans are really nice people and weren't upset about this
but I can image they must feel quite sad each time something like this
happens.

According to this section in the Debian Installer i18n guide[1], the
list of countries is based on ISO3166.

According to wikipedia, ISO3166 comes from a group of 10
representatives[2] from mostly rich countries.

The Debian Social Contract[3], point 4, requires us to put our users
first.  Can Debian do more to listen to the 1.8 million potential users
in Kosovo and other countries like it?  Are we actually obliged to
respect how our users see themselves over and above the way some
bureaucrats in Geneva see them?

I would propose that we regard ISO3166 as a subset of the list of
countries perceived by our users and that for the next installer
release, the locale chooser offers a list of countries with a disclaimer
that some of them are not in ISO3166 but they are included at the
request of our users.

Maybe the list can show two columns, country and country code.  For
countries where ISO3166 is not competent, the country code column could
be blank.

Implementing this might be tricky but not impossible.  For example, a
crude implementation may simply display the extra countries in the main
list, but if somebody selects one of them, the installer shows a message
apologizing for the fact they are not fully supported and offering to
help them choose from a subset of related country codes.  Maybe their
preferred choice (verbose country name) could be saved somewhere for
later use when their country is fully supported and a future version of
localechooser will help them adapt to their eventual country code during
a future dist-upgrade.

For Kosovo in particular, Wikipedia notes[4] that "The code XK is being
used by the European Commission
,^[21]
 the IMF
, and SWIFT
,^[22]
 CLDR and
other organizations as a temporary country code for Kosovo
.".  Other 2-letter codes are
mentioned elsewhere so the ideal solution may avoid using a 2 letter
code for such countries or maybe it can borrow one of the codes used by
other international organizations who didn't wait for ISO3166.

It may be interesting to support micronations like the Principality of
Hutt River[5] too.

Regards,

Daniel


1. https://d-i.alioth.debian.org/doc/i18n/ch01s05.html#idm45330184240096
2. https://en.wikipedia.org/wiki/ISO_3166#Members
3. https://www.debian.org/social_contract
4. https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
5. https://en.wikipedia.org/wiki/Principality_of_Hutt_River

Bug#860368: installer: create network bridges by default?

[Daniel Pocock]

On 15/04/17 13:27, Wouter Verhelst wrote:
> On Sat, Apr 15, 2017 at 01:18:52PM +0200, Daniel Pocock wrote:
>> As you describe, the default network is an extra layer of NAT.  It
>> works, but not everybody wants that.
> 
> So those who don't want it can fix their bloody configuration.
> 
> Are you honestly suggesting that we should create unnecessary fluff for
> all our users just because NAT doesn't work for a small minority of our
> users?
> 

There are separate questions about
  (a) whether it can be an option (not default), or
  (b) whether it would be a useful default


> It's always possible to create a bridge manually, there's no need to do
> that from the installer; and NAT works out of the box (virt-manager will
> even suggest you enable the default network if you try to use it and it
> hasn't been enabled yet).
> 


It isn't so hard to do manually, but every person who wants this needs
to go and find out the necessary changes and edit /etc/network/interfaces

There is also the inconvenience factor: people have to bounce their
interface or reboot when making a change like that.  If the bridge is
already there we save them that inconvenience too.

Regards,

Daniel

Bug#860368: installer: create network bridges by default?

[Daniel Pocock]

On 15/04/17 13:05, Wouter Verhelst wrote:
> On Sat, Apr 15, 2017 at 10:50:30AM +0200, Daniel Pocock wrote:
>> With libvirt, that is possible using macvtap but it is unreliable and
>> doesn't allow[3] communication between the guest and the host, only
>> between the guest and other hosts on the subnet.
>>
>> The solution is for people to configure a bridge or Open vSwitch (OVS)
>> in /etc/network/interfaces.
> 
> Actually, you can just tell virt-manager to use the "default" network,
> which is configured correctly. However, it does not come enabled out of
> the box; to fix, you can do one of two things; either run "virsh
> net-autostart default; virsh net-start default", or use the virt-manager
> UI to do the same (under Edit->Connection details->Virtual networks)
> 
> This uses NAT, and creates a virtual NIC, which therefore requires root
> access; but it works nicely IME.
> 

As you describe, the default network is an extra layer of NAT.  It
works, but not everybody wants that.

For example, when your guest is behind NAT, you can't easily connect to
it from other hosts on the network.

Bug#860368: installer: create network bridges by default?

[Daniel Pocock]

Package: debian-installer
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org


With VirtualBox dropping out of testing[1], more people will be using
KVM and libvirt/virt-manager[2] for desktop virtualization.

With VirtualBox, it was possible for people to bridge their physical
network interfaces with their VM guest systems using the GUI / setup wizard.

With libvirt, that is possible using macvtap but it is unreliable and
doesn't allow[3] communication between the guest and the host, only
between the guest and other hosts on the subnet.

The solution is for people to configure a bridge or Open vSwitch (OVS)
in /etc/network/interfaces.  (Notice OVS can be configured[4] in the
interfaces file).  Maybe it would be useful to offer one or both of
these options at install time, or even configure a standard (non-OVS)
bridge by default in case the user decides to try KVM in future?

Are there other use cases apart from KVM that would benefit from this?

Are there things that would break badly if Debian offered this in future?

It is probably too late in the stretch release cycle for a change like this.

Regards,

Daniel



1. https://packages.qa.debian.org/v/virtualbox.html
2. https://packages.qa.debian.org/v/virt-manager.html
3. https://libvirt.org/formatnetwork.html#examplesDirect
4.
https://sources.debian.net/src/openvswitch/2.6.2~pre%2Bgit20161223-3/debian/openvswitch-switch.README.Debian/

Bug#717107: limited TZ choices

[Daniel Pocock]

On 16/07/13 23:56, Cyril Brulebois wrote:
 Daniel Pocock (2013-07-16):
 Actually, it's a little confusing - I just went back in the installer
 and yes, I can choose that permutation and then I'm told There is no
 locale defined for the country of language and country and then I can
 manually get en_GB.  So I can achieve the correct configuration.

 However, some users may simply choose GB as their country (I'm an
 Australian but I choose GB because Australians use British English and I
 personally spent a lot of time living there) - so while I don't see this
 as a severe issue, I think it would be helpful to let the user choose a
 country that they associate with rather than their exact location at the
 moment of installation.  Then the TZ question should let them deviate
 further from the options for their country.
 No, no, no. You really really should *read* instead of *assuming* random
 things.

 Quoting the “Select your location” screen, first two sentences are:
 | The selected location will be used to set your time zone and also for
 | example to help select the system locale. Normally this should be the
 | country where you live.

I agree it is not fundamentally broken and for people who know
Debian/Linux it is not hard to change later, but I still feel it is
rigid and it would not be hard to let people alter the timezone after
choosing a country

To give another example, consider a British person setting up a PC in
their holiday home in France: country where you live does not help
them make the system work the way they want.

Another option may be changing the text: Normally this should be the
country where the computer is physically located or physically
accessed.  This will not limit you to using the language or locale of
the country you choose and the installer will proceed in the current
language.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e65402.9080...@pocock.com.au

Bug#717107: limited TZ choices

[Daniel Pocock]

On 17/07/13 11:21, Cyril Brulebois wrote:

 Another option may be changing the text: Normally this should be the
 country where the computer is physically located or physically
 accessed.  This will not limit you to using the language or locale of
 the country you choose and the installer will proceed in the current
 language.
 I'm not sure that's an improvement.
physically located or more specific than where somebody lives

I also included physically accessed given the fact people are
installing so many VMs these days - the VM may be physically running in
the US but accessed almost exclusively from Europe, for example.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e66541.6010...@pocock.com.au

Bug#717107: limited TZ choices

[Daniel Pocock]

Package: tzsetup
Version: 7.1.0 installer



I am doing a text mode expert install

I chose UK locale and US keyboard.

However, I am in .ch

The timezone menu only offers me British summer time and UTC

1 in 4 people here in .ch are foreign - most of us do not use a Swiss
locale or German keyboard though.  Debian should probably be more
flexible about these hybrid locale/keyboard/timezone combinations.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51e5b49c.4030...@pocock.com.au

Bug#684128: SI units (was Re: failure to communicate)

[Daniel Pocock]

On 05/04/13 14:06, Ian Jackson wrote:
 Daniel Pocock writes (SI units (was Re: failure to communicate)):
 It may actually be useful for the technical committee to review what is
 on the wiki and make some general statement about Debian's position (if
 they haven't done so in the past), and that can guide the way similar
 bugs are classified for jessie and beyond.

 1. http://lists.debian.org/debian-devel/2007/06/thrd2.html#00700

 2. http://wiki.debian.org/ConsistentUnitPrefixes
 
 You should try to address this through the policy process.  If and
 when we have competing policy proposals the TC might want to
 arbitrate.


Hi Ian (and thanks Ian),

Your issue is now on the radar and this is a clear way forward - even if
it has been missed for wheezy, I too would like to see this progress in
Debian, not just for the installer

Here is the link to the policy team:
   http://wiki.debian.org/Teams/Policy

and this is the existing wiki on units, which doesn't appear to be
formal policy just yet:
   http://wiki.debian.org/ConsistentUnitPrefixes

In the short term, the installer team really appear to have a lot of
competing demands, there are a range of bugs listed for D-I related
packages.  In the long term, to keep Debian at the forefront, things
like installing onto bootable btrfs RAID1 works fine[1] but needs
changes to the installer to make it easy, and that appears to require
strategic changes to the installer architecture[2].  There is a clear
opportunity here for more people to be involved in the installer project
(both collaborating on the more urgent bugs and doing strategic work),
and approaching these issues as a whole would certainly give you a
chance of influencing its future direction.

Regards,

Daniel



1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686130

2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686097


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/516174b5.1040...@pocock.com.au

Bug#684128: SI units (was Re: failure to communicate)

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/04/13 22:43, Christian PERRIER wrote:
 Quoting ian_br...@fastmail.net (ian_br...@fastmail.net):

 If Debian bug report #684128 proves anything, it is that you will never
 convince anyone with technical argument, facts advanced in support of


 I perfectly understand you can be frustrated but, honestly, as of now,
 we're focused on the wheezy release, again. Fixing debootstrap has
 much more importance than Giga/Gibibytes. Once wheezy is released, I
 see no reason for your proposed patch to be rejected.

Sadly, it appears that failure to communicate was from both sides

Ian was told several times that changes may not be accepted for wheezy

However, that communication was overshadowed by several comments
suggesting nobody cares about the issue at all, rather than comments
like that above explaining the relative importance of fixing other issues.

This issue of units comes up again and again, there is a huge thread on
debian-devel in 2007[1] - that hardly seems like something that nobody
cares about.

So while it may not make it into wheezy (I won't give my own opinion on
this one, it is for the release team to decide), I don't think the
reporter of this bug should be deterred by comments about it being a
trivial wishlist or nonsense item.

It may actually be useful for the technical committee to review what is
on the wiki and make some general statement about Debian's position (if
they haven't done so in the past), and that can guide the way similar
bugs are classified for jessie and beyond.

1. http://lists.debian.org/debian-devel/2007/06/thrd2.html#00700

2. http://wiki.debian.org/ConsistentUnitPrefixes


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJRXpjBAAoJEOm1uwJp1aqDmTsQAL7tmMmZqoZevDa4ZhfuxGrh
R8340K+Fn0aZsYI66bxDHg/HDCJtCGfUpfTOYDnYfsSq+D+4X4ZFTJq6ezKvmbrO
mBDCILtq0km753MyfYgnq37/sCbbTrZ/dLKtSWLNioAcqfnqItSC3PqLUYH2l4Tn
MeXNCzMHKiG2J3hvWLM3knc3UMq/QGE2DUHzD32mk8zTCU4lAYOEsJOh8CQFKVri
oYfGnFlC0Yy6+xf/E1An9Gx80qfRf07vW1odtEIMFmtrotocsj+z3xW1Q8LgwvTA
EQ+yXHK7XWSFaruKSbkLyaM826syiRrDBzzTWN9Fi3gptYgJgEY0yGEQViQ6r5SL
eosQlxALWLCCG9HOzXLf0HXlKDg4keRI+Ay1BJJkcNurcvF4v70ee4YxmlmD6lXK
2LiK/wb+FBjId0vpDP/kLRjhljt+kdNXe/4hqbc2d3aIY7Gnqjgz1o/I+x6+atrm
YIKJM6pGTYrFL2vfsIn1mlrbXnqJEyyD04v7U2afb3n1Dxn9zh/6j7L2R0tv5eLl
dCrnBkXjdLMyMaawyzb/uQyP2FvoFjk92XsehKDATLobQBnZvJ7B2ON6qtLWbn1Q
jG5BvdMH++jU7m+yDlctcVo0dakgAd8UnQFvckjH1JhPwRIsmBYUbJu0Y8fqY2Gz
mbpjVc641/AjIS4ytp10
=L0ZB
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/515e98c5.6010...@pocock.com.au

Bug#696206: radeon brokenness observed with Toshiba/Radeon video

[Daniel Pocock]

On 20/12/12 05:03, Cyril Brulebois wrote:
 Control: severity -1 normal
 Control: tag -1 pending

 Hi Daniel,

 Daniel Pocock dan...@pocock.com.au (18/12/2012):
   
 Package: installation-reports
 Severity: serious
 
   
 During Debian's first and subsequent boot, the console becomes corrupted

 The X display is just blank too

 Access to the box is possible using ssh

 Adding

radeon.modeset=0

 to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub

 makes the system work normally.
 
 that shouldn't happen anymore in the next release, thanks to the
 following linux kernel uploads: linux (3.2.35-1)

   * radeon: Disable KMS earlier if firmware is not installed (Closes: #607194)

 Mraw,
 KiBi.
   
Later on, I added firmware-linux-all (to get the wifi firmware) and on
the next boot, X was failing again, this time it was a blank screen and
this was in the log:

drm  wait for fifo failed status : 0xE57004E0 0x00110103

I was still able to access the box remotely using ssh

I removed all the firmware packages except the Intel wifi firmware, and
subsequently I could boot successfully


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50d30e17.7000...@pocock.com.au

Bug#696206: radeon brokenness observed with Toshiba/Radeon video

[Daniel Pocock]

Package: installation-reports
Severity: serious

Image version: beta4 netinst CD amd64

System type: Toshiba Satellite P305-S8825

Installer is fine

During Debian's first and subsequent boot, the console becomes corrupted

The X display is just blank too

Access to the box is possible using ssh

Adding 

   radeon.modeset=0

to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub

makes the system work normally.

squeeze Live DVD worked fine on the same system.  wheezy is installed to hard 
disk


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50cfeaaa.30...@pocock.com.au

Bug#686096: unreproducable

[Daniel Pocock]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 02/11/12 11:13, Cyril Brulebois wrote:
 Hi Daniel,
 
 I guess you didn't see this as you weren't cc'd:
 
 willem kuyn willemk...@gmail.com (14/10/2012):
 I tried to reproduce the bug with 
 debian-wheezy-DI-b2-amd64-netinst.iso in a virtual machine.
 
 Both cases were not reproducable. In the actions there is a 
 switching between shell and installer menu and maybe the
 installer is not aware of the changes made in the shell but i
 cannot reproduce the error.
 
 I think the bug can be closed.
 
 What do you think?
 

I definitely saw this bug on two different machines

Also, I only went into the shell _after_ I saw the bug.  I did not use
the shell to change things before observing the bug.

In both cases, there were existing partitions on the disks, I don't
know if this could be a factor

I agree the use case of two PVs on a single HDD is not so common, but
the bug could actually be revealing some deeper flaw in the partman
logic that may also manifest itself in other ways.  Therefore, I'm not
sure it is a good idea to downgrade the bug without someone familiar
with the partman code having a look `under the hood'

Some suggestions for going forward:

a) could more logging code be added to partman to help understand the
problem next time somebody sees it?

b) can anyone comment on which part of the partman source code needs
to be reviewed (and which VCS it is in)?


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJQlX1GAAoJEOm1uwJp1aqD/DUQAJRKdTFuvkPs+QwXuSfxrHbf
ftxW47ovUBsrpa6UUz65uheTmZrgGKKBAakyerfw9V0AqClXKcFb7y+ZdpmC4wVA
RPw2hCxXPMDY4Tk5nKKB2zKw3k7qbxTXrPmq/I3uHVYcMgseZtHxzwD8zBFwzvrF
P3rsJ9ooPdyjt22DF+r0FcXstIw95XWoeiuOZ+XTL4Ur8AwDlAmRePUFw4Am0nSV
5bXBN7rslLZMG+QdOBU7gNTo2t0i9RzK7Nm75apRu9r5pom47YrQ6iu8XhsDFkD1
bxbMj7hLQnJpRYNaTfcxkSL2oGGQRnopLennwMY+Cd8YF/eEC1+7eNhCRK4cUOCH
JKxXWSrEdoFmieVzxK66bmoIIVhv8E4cs5EGTgxJp4MIfkLZSLMBOYNHcGk0bzni
PXsUbJj6i+IZ+fjfvlaj9/BZO/TbxxjHLe797D9pPgqYCwZOOnVL6kvoqvrBhacv
wAaLru3dQrwczXQeO8ug3d7Murs50HTU5a0Ye7jFaWdoPkZol41+c3MP4A6bGgFB
vie32q5eg7BiDvvoYltfzyta5tvdC8snV6SLfj3SZrZQefCOkT3mn/ukK2tRVbND
2edDxKdgscuMecmafQQ+JKLR+qFU3uXYpe//PwbqSLkM72ugK1gB3RuMf9+JtJCf
oFgrWW65R3VjnxKSUOyZ
=M29n
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50957d47.7040...@pocock.com.au

Bug#686096: again on another machine

[Daniel Pocock]

I've finally observed something like this again, may or may not be related

On this second machine, there was an existing VG and existing NTFS
partitions (Windows and Lenovo recovery data) and an existing /boot
partition from a previous install

In partman, I did the following:

a) highlighted the /dev/sda3 (was /boot), partman tells me it is not
using the partition, I changed it to be /boot and ext2

b) I ran the partman LVM menu and deleted the existing two LVs and then
I deleted the VG

c) I returned to the main partman menu and deleted the two partitions
that were used by LVM:

sda5  (40GB)
sda6  (250GB)

d) I then created a new partition:

sda5  (400GB)  type 8e

e) then I ran the partman LVM menu again.  On entering the menu, it
reports that sda5 = 40GB  (the old size).  No mention of sda6

f) then I go to a shell and run fdisk /dev/sda
It shows me the correct partition sizes for sda4 (extended) and sda5
(type 8e for LVM)

g) if I back out of the LVM config menu and go back in again, same problem

h) I accept the dodgy values and let it create the volume group.  Then I
run pvscan.  It shows me /dev/sda5 = 37.25 GB (the wrong value)

i) if I manually create the VG, it is fine:

pvcreate -ff /dev/sda5
vgcreate vg00 /dev/sda5
pvscan  (now shows correct output)

Therefore, I believe the wrong value was cached somewhere within partman


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5050c780.3030...@pocock.com.au

Bug#686097: possible solution

[Daniel Pocock]

Suggested that any enhancement to support this for wheezy must be
non-disruptive and must not require changes to any strings that would
need to be translated.

The only way I see of supporting that for wheezy is described below:



Concept:

  * user can specify two partitions with the same mount point,
provided they are both btrfs
  * partman-btrfs will recognise this special case and assume
that RAID1 is desired
  * due to the requirement to avoid changing any text strings,
this will happen silently and the user will not be
prompted to choose RAID level or other possible choices
  * if filesystems are not btrfs, the normal error will appear


package partman-target
--

  check.d/
proper_mountpoints
duplicate_labels
same_mountpoint and same_label errors must be suppressed when
this special case is detected

package partman-btrfs
-

  commit.d/
format_btrfs
* must do a pre-screening of all filesystem specs
  and identify those that need RAID
* format the normal filesystems first, and the RAID ones in a
  second pass

  fstab.d/
btrfs
* must do a pre-screening of all filesystem specs
  and identify those that need RAID
* output the normal filesystems first
* for the RAID filesystems, must mount by UUID= syntax
  (due to bug #612402)
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612402
* one possible technique is to just check UUID of each
  filesystem, and parse the resulting fstab output via uniq


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/503f95e2.50...@pocock.com.au

Bug#686097: understanding/contributing to partman-btrfs

[Daniel Pocock]

On 30/08/12 22:07, Joey Hess wrote:
 Daniel Pocock wrote:
 I've described such a solution in the bug report:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686097

 If you think it is sensible (or if something looks obviously silly),
 could you comment on it?  I will hopefully have more time next week to
 play with it, but I'll let it sit there for a few days to see if
 anyone has comments about it.
 
 I don't know if that's worth it, it'll be a feature that entirely lacks
 discoverability for users.
 

Maybe not such a bad thing: the btrfs crew still insist it is experimental.

Just the other day I saw something about btrfs crashing the kernel when
all RAID elements are not present


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/503fcec6.90...@pocock.com.au

Bug#686130: related issue in lvm2/initramfs, patch submitted

[Daniel Pocock]

The patches submitted here:

   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612402#66

fix the initramfs issue and allow Debian Wheezy to boot from the btrfs RAID1

For this to work, the filesystem must be specified by UUID on the kernel
command line from grub, e.g.


   root=UUID=57f36137-36ec-4f6c-a76e-c72c86330cc2

and should also be specified by UUID in /etc/fstab, e.g.


# cat /etc/fstab
UUID=57f36137-36ec-4f6c-a76e-c72c86330cc2   /   btrfs  defaults 0 1
/dev/sda1 /boot  ext4  defaults 0 2
/dev/sda2  none swap sw 0 0


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/503e14d9.9060...@pocock.com.au

Bug#686095: partman/LVM: can't map LV to specified PV

[Daniel Pocock]

Package: installation-reports

Image version: beta1 DVD amd64
http://cdimage.debian.org/cdimage/wheezy_di_beta1/amd64/iso-dvd/debian-wheezy-DI-b1-amd64-DVD-1.iso
Date: 28 August 2012



I successfully proceed through all steps up to partitioning / partman

I have a single disk of 500GB

I create the following:

sda1 256MB
sda2 250GB
sda3 250GB


Then I create a VG, called vg00, with two PVs, sda2 and sda3

Finally, I create an LV, called /dev/vg00/lv0, size = 250GB

pvdisplay shows me that everything was lumped onto /dev/sda2 and nothing
is on /dev/sda3

For modern use cases, such as btrfs RAID1, it is very useful to manually
assign each LV to a PV, e.g.

  lvcreate -n lv0 -L 250GB vg00 /dev/sda2
  lvcreate -n lv1 -L 250GB vg00 /dev/sda3

  mkfs.btrfs -d raid1 -m raid1 /dev/vg00/lv0 /dev/vg00/lv1

However, partman does not allow the final option to be added to the
lvcreate command line.

Workaround: user can run lvcreate from the shell to get exactly what
they want.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/503cccd7.5010...@pocock.com.au

Bug#686096: LVM partman corruption of logical partitions on same extended partition

[Daniel Pocock]

Package: installation-reports
Severity: critical

Image version: beta1 DVD amd64
http://cdimage.debian.org/cdimage/wheezy_di_beta1/amd64/iso-dvd/debian-wheezy-DI-b1-amd64-DVD-1.iso
Date: 28 August 2012


I successfully proceed through all steps up to partitioning / partman

I have a single disk of 500GB

I create the following:

sda1 256MB
sda5 250GB
sda6 250GB

In the main partman partitioning screen, it now shows me

#1 primary 254.8 MB ext4 /boot
#5 logical 250.0 GB lvm
#6 logical 249.8 GB lvm

Then I choose the menu option to set up LVM and create a volume group

It asks me Please select the devices for the new volume group and it
shows the following with checkboxes:

sda1 256MB
sda5 499GB   *** this is wrong
sda6 250GB

Notice that for sda5, it reports the size of the extended partition
rather than the logical partition?

fdisk /dev/sda shows correct values:

sda1 256MB
sda2 499GB  (type 5, Extended)
sda5 250GB  (type 8e)
sda6 250GB  (type 8e)

I go ahead and tick both of sda5 and sda6

partman is now at the menu where I can create an LV, etc

I go to a shell and run

pvscan

and I see the following:

PV /dev/sda5  VG vg00 lvm2 [465.52 GiB / 465
PV /dev/sda6232.69 GiB
Total: 2 [698.21 GiB]

Notice it is not just displaying the wrong values: it actually thinks I
have 750GB of space when I only have 500GB

I don't want to guess what happens if it writes to the latter half of
/dev/sda5 and I don't have time to try it, but I can't imagine any
positive outcome

If I delete the volume group and then create it again, the second time
around, it behaves correctly.

Looking at Alt-F4 log output, I notice

kernel: pvcreate: sending ioctl 1261 to a partition!

appears twice around the time that the bad VG was created.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/503cd0b5.9020...@pocock.com.au

Bug#686097: Can't make btrfs raid1 from installer

[Daniel Pocock]

Package: installation-reports

Image version: beta1 DVD amd64
http://cdimage.debian.org/cdimage/wheezy_di_beta1/amd64/iso-dvd/debian-wheezy-DI-b1-amd64-DVD-1.iso
Date: 28 August 2012



I successfully proceed through all steps up to partitioning

In the partitioning system, I create two logical volumes:

/dev/vg00/lv0
/dev/vg00/lv1

I then exit the LVM tool and in the main partitioning tool, I highlight
each of them, and designate both of them as btrfs and mount pount = /

I was expecting to create a RAID1, e.g. for the installer to run the
following command:

mkfs.btrfs \
-m raid1 \
-d raid1 \
  /dev/vg00/lv0 /dev/vg00/lv1

When I select `Finish...write to disk' I see the error Identical mount
points for two file systems

If I try to use the menu option Configure software RAID, it only
offers the `md' RAID1 and not btrfs RAID1

There are probably several valid ways to handle this:

a) if user selects Configure software RAID, they could be offered an
option to choose either md or btrfs style RAID

b) if user tries to assign several devices to the same mount point,
maybe they should see a prompt asking them if they want RAID1, RAID0,
etc (or if they just made a mistake and want to go back)

c) hack: maybe just ask the user if they want to drop into a shell and
create the filesystem using their own mkfs command?

This is likely to be a pain because the user can't easily RAID their
btrfs filesystem after it has been created (needs a 3.3 or later kernel
and new tools).  Therefore, it must be done from the installer, or from
a command line during the install phase.
https://btrfs.wiki.kernel.org/index.php/Balance_Filters


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/503cd0fa.6000...@pocock.com.au

Bug#686117: partman fails to recognise existing btrfs data

[Daniel Pocock]

Package: installation-reports
Severity: important

Image version: beta1 DVD amd64
http://cdimage.debian.org/cdimage/wheezy_di_beta1/amd64/iso-dvd/debian-wheezy-DI-b1-amd64-DVD-1.iso
Date: 28 August 2012



I successfully proceed through all steps up to partitioning

In the partitioning system, I create two logical volumes:

  /dev/vg00/lv0
  /dev/vg00/lv1

I then go to a shell and format them as btrfs RAID1:

  mkfs.btrfs -d raid1 -m raid1 /dev/vg00/lv0 /dev/vg00/lv1

Then I go back to partman.  I use `Go Back' to return to the main
installer menu and run `Detect Disks'.  Then I go in to partman again


It shows the LVs are empty

If I highlight one of them and press enter, it says:

You are editing partition #1 of LVM VG vg00, LV lv0.  No existing file
system was detected in this partition.

I then went back to the shell and ran

  btrfs dev scan

and then returned to D-I, `Detect Disks' again, and return to partman.
Still the same problem.

Even if btrfs RAID is not supported at all in wheezy, I think it is a
serious bug for the installer to suggest the LV or partition is not
formatted when btrfs is a supported FS for Debian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/503d18be.10...@pocock.com.au

Bug#686130: hack for installing with btrfs raid1

[Daniel Pocock]

Package: installation-reports

Image version: beta1 DVD amd64
http://cdimage.debian.org/cdimage/wheezy_di_beta1/amd64/iso-dvd/debian-wheezy-DI-b1-amd64-DVD-1.iso
Date: 28 August 2012


Although D-I doesn't have menu-based support for btrfs RAID, I was keen
to find out if there were any other traps later on in the process.

Therefore, I describe the hack I've used to run D-I and install onto
btrfs RAID1

The install is done in expert mode, text interface, using VirtualBox
with two virtual SATA disks of 10GB each.

I successfully proceed through all steps up to partitioning

In the partitioning system, I create raw partitions for LVM on each of
my two disks

sda:
  /dev/sda1  type 83   (ext4 for /boot)
  /dev/sda2   swap
  /dev/sda3  type 8e
sdb:
  /dev/sdb3  type 83

I then do the LVM setup, creating a VG called vg00 with both disks

Next, I leave partman running and press Alt-F2 for a shell

In the shell, I manually create two LVs:

  lvcreate -n lv0 -L 10GB vg00 /dev/sda3
  lvcreate -n lv1 -L 10GB vg00 /dev/sdb3

and I join them into a btrfs RAID1:

  mkfs.btrfs -d raid1 -m raid1 /dev/vg00/lv0 /dev/vg00/lv1

Going back to the D-I menu, I try to `Detect Disks' and back into
partman, it just doesn't recognise the RAID1,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686117
   so a further workaround is needed:

I simply ask partman to format /dev/vg00/lv0 alone as btrfs (no RAID)
for mount = / (root filesystem)

Then I am back in the main menu.  Before running the step Install the
base system, I go back to the shell, (alt-f2)

  umount /target/boot
  umount /target
  mkfs.btrfs -d raid1 -m raid1 /dev/vg00/lv0 /dev/vg00/lv1
  mount /dev/vg00/lv0 /target
  mkdir /target/boot
  mount /dev/sda1 /target/boot

Now I go back to the D-I menu and proceed normally from `Install the
base system'

Note that /etc/fstab is not created correctly.  It is necessary to
manually edit /target/etc/fstab

When it reboots into grub, there is trouble (this may require a fix in
update-initramfs tool or in the initramfs scripts provided by btrfs-tools)

Loading, please wait...
Scanning for Btrfs filesystems
mount: mounting /dev/mapper/vg00-lv0 on /root failed: Invalid argument

and we are dumped in the BusyBox shell.  The first discovery is that
/dev/vg00/lv1 is not active:

(initramfs) lvm
lvm lvscan
  ACTIVE   /dev/vg00/lv0
  inactive /dev/vg00/lv1
lvm lvchange -ay vg00
  ACTIVE   /dev/vg00/lv0
  ACTIVE   /dev/vg00/lv1
lvm exit
(initramfs) btrfs dev scan
Scanning for btrfs filesystems
(initramfs) mount -o ro /dev/vg00/lv0 /root
(initramfs) ls /root

At this point, /root looks normal

However, trying to continue the init (e.g. typing `exit' or trying to
invoke switch_root /root /sbin/init) fails, e.g.


Usage: switch_root [-c /dev/console] NEW_ROOT NEW_INIT [ARGS]


Only the help text appears, no details about why switch_root is unhappy


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/503d3acf.90...@pocock.com.au

Bug#686130: finishing the hack

[Daniel Pocock]

Some further comments - it finally does boot


Following on from the original install report (stuck in initramfs), I then

a) boot into rescue mode with the Debian beta1 DVD

b) ask the rescue system to mount /dev/vg00/lv0

c) select the option to launch a shell in the root FS

d) hack /usr/share/initramfs-tools/scripts/local-premount/btrfs to make
sure all LVs are active before the btrfs dev scan command (notice I
added the lvchange command below into the existing script):

if [ -x /sbin/btrfs ]
then
modprobe btrfs
/sbin/lvm lvchange -ay vg00
/sbin/btrfs device scan 2 /dev/null
fi


e) regenerate the initramfs

  mount /boot  update-initramfs -k all -u

f) exit the shell and reboot from the rescue mode menu


Now my system boots into a fresh install of wheezy on btrfs RAID1


Action items for full btrfs RAID1 in Debian:

- partman needs to be able to call
mkfs.btrfs -t raid1 -m raid1
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686097

- tweak the initramfs support in btrfs-tools (or maybe it is actually an
lvm2 issue?)





root@wheezy3:~# btrfs fil df /
Data, RAID1: total=5.00GB, used=3.18GB
Data: total=8.00MB, used=0.00
System, RAID1: total=8.00MB, used=4.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=1.00GB, used=242.18MB
Metadata: total=8.00MB, used=0.00

root@wheezy3:~# df -lh
FilesystemSize  Used Avail Use% Mounted on
rootfs 18G  6.9G  9.5G  42% /
udev   10M 0   10M   0% /dev
tmpfs 202M  584K  201M   1% /run
/dev/mapper/vg00-lv0   18G  6.9G  9.5G  42% /
tmpfs 5.0M 0  5.0M   0% /run/lock
tmpfs 403M  8.0K  403M   1% /tmp
tmpfs 403M   72K  403M   1% /run/shm
/dev/sda1 120M   26M   89M  23% /boot


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/503d4096.2000...@pocock.com.au

Bug#646998: nfs client missing, no client for accessing a server FS from installer/rescue shells

[Daniel Pocock]

Package: debian-installer


I seem to remember older versions of D-I had the NFS client
modules/utilities present

They appear to have disappeared

Now, when in a shell started from the installer or the rescue mode,
there is no apparent way to interact with a server filesystem

It would be ideal to have NFS, NBD, iSCSI or some other means of copying
files to/from servers - but none of them are present, and just copying
the binaries and modules from a full Debian system doesn't seem to be
enough to get any of them working in the installer or rescue shell







-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eaba333.5070...@pocock.com.au

Bug#646998: nfs client missing, no client for accessing a server FS from installer/rescue shells

[Daniel Pocock]

On 29/10/11 16:12, Miguel Figueiredo wrote:
 A Sábado, 29 de Outubro de 2011 07:54:43 Daniel Pocock você escreveu:
   
 Package: debian-installer


 I seem to remember older versions of D-I had the NFS client
 modules/utilities present

 They appear to have disappeared

 Now, when in a shell started from the installer or the rescue mode,
 there is no apparent way to interact with a server filesystem

 It would be ideal to have NFS, NBD, iSCSI or some other means of copying
 files to/from servers - but none of them are present, and just copying
 the binaries and modules from a full Debian system doesn't seem to be
 enough to get any of them working in the installer or rescue shell
 
 It is present a openssh-client which allows you to copy files via ssh.
 You just have to install the client udeb:

 $ anna-install openssh-client-udeb

 and 'voila', you're good to go with scp.
   

Thanks, I wasn't aware that scp was included, did earlier releases have
the ssh binary only?

 For NFS and iSCSI here are already wishlist bugs asking for it (see bugs 
 #237121 and #441291 - btw existing debian installer bugs can be found on [1]) 
 but still lacks who to develop such packages.
 For nbd d-i already has NBD support with the package partman-nbd [2].
   
I could only see partman-reiserfs in the menu as I'm using the stable
build D-I, it's good to see nbd is coming in the next release as that is
probably a lot easier than NFS for many simple applications where
someone wants to move around data from block devices




--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eabc722.8010...@pocock.com.au

Bug#604155: Windows 7 not in grub menu

[Daniel Pocock]

Subsequent to my last email, I think that the root filesystem was not 
mounted properly due to an unrelated issue, rebooting fixed it, this is 
the output from 30_os-prober:


# /etc/grub.d/30_os-prober
Found Windows 7 (loader) on /dev/sda1
menuentry Windows 7 (loader) (on /dev/sda1) {
   insmod part_msdos
   insmod ntfs
   set root='(hd0,msdos1)'
   search --no-floppy --fs-uuid --set a23821f33821c6df
   chainloader +1
}

and this is update-grub:

# update-grub
Generating grub.cfg ...
Found background image: moreblue-orbit-grub.png
Found linux image: /boot/vmlinuz-2.6.32-5-xen-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-xen-amd64
Found linux image: /boot/vmlinuz-2.6.32-5-xen-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-xen-amd64
Found linux image: /boot/vmlinuz-2.6.32-5-amd64
Found initrd image: /boot/initrd.img-2.6.32-5-amd64
done

So os_prober can find Windows, but it isn't in the menu

This is what I see in /boot/grub/grub.cfg after update-grub:

### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###





--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cf25da0.8070...@pocock.com.au

Bug#604155: Windows 7 not in grub menu

[Daniel Pocock]

On Mon, 22 Nov 2010 21:21:03 +0100, Daniel Pocock wrote:
  

I had already run update-grub, but that hasn't made any difference



update-grub should call the script '/etc/grub.d/30_os-prober'. What if
you call it directly? Does it return any error? You may also call
os-prober directly.
  

r...@debian6:/etc# /etc/grub.d/30_os-prober
/usr/bin/os-prober: 99: cannot create /tmp/os-prober.tMerGF/mounted-map: 
Invalid argument
/usr/bin/os-prober: 100: cannot create /tmp/os-prober.tMerGF/raided-map: 
Invalid argument

r...@debian6:/etc# mount | grep tmp
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
r...@debian6:/etc# ls -ld /tmp
drwxrwxrwt 10 root root 4096 Nov 27 12:09 /tmp

I checked disk space - it is not an issue



r...@debian6:/etc# mkdir /tmp/os-prober.tMerGF/
r...@debian6:/etc# touch /tmp/os-prober.tMerGF/mounted-map
touch: setting times of `/tmp/os-prober.tMerGF/mounted-map': No such 
file or directory



r...@debian6:/etc# touch /test1
r...@debian6:/etc# touch /tmp/test2
touch: setting times of `/tmp/test2': No such file or directory

Something funny going on in /tmp - not exactly sure what - would you 
recognise this problem, or should I look more closely?






--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cf0e82e.9040...@pocock.com.au

Bug#604155: Windows 7 not in grub menu

[Daniel Pocock]

Lennart Sorensen wrote:

On Sat, Nov 20, 2010 at 07:07:31PM +0100, Daniel Pocock wrote:
  

Package: installation-reports

squeeze / amd64 fresh install on a Thinkpad X61s

Windows 7 is already on the machine

The installer told me it found Vista and asked if I want to install grub  
to the MBR.  I agreed to install MBR.


On rebooting, the grub menu appears and Debian is the only option.

Checking the partition table with fdisk, I can see that Win 7 is still  
there.



Try running 'update-grub'.

I have seen a number of cases where on install it doesn't detect windows,
but running update-grub works and detects windows.

It seems that during install it has a bug in some cases.

  


I had already run update-grub, but that hasn't made any difference

I can boot Windows by pressing `c' in the grub menu, and using the commands

root (hd0,1)
chainloader +1
boot

The machine is a fresh install:

- Windows 7 (64 bit) fresh install onto blank disk
- Debian (amd64) installed from squeeze beta1 DVD

Is there anything else I can check to find the root cause of the 
problem?  I don't mind doing more test installs on this machine, it is 
dedicated for that purpose.








--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4cead0af.1030...@pocock.com.au

Bug#604080: Xen domU fails to boot after install

[Daniel Pocock]

Ian Campbell wrote:

On Sat, 2010-11-20 at 18:48 +0100, Daniel Pocock wrote:

  

Ultimately, I believe Debian 5 (lenny) is still a supported option for
people after the release of squeeze and up to the release date of
Debian 7.



oldstable is generally supported for a little while after a new stable
release but it is a very much more frozen/conservative style support
even than stable, which is in itself quite conservative in what it takes
in updates. The bar for taking fixes into oldstable is high and is
focused on security fixes and super-critical issues etc.

  
I agree with this policy - and I think that any solution should respect 
that, while simultaneously aiming to make life easier for people mixing 
lenny and squeeze.  For many people, virtualization is quite normal 
nowadays, and installing into a domU will be their first experience of 
squeeze (like for me).


A solution that respects that would simply display some more definite 
error messages, maybe directing people to get an additional support 
package or obtain a fresher pygrub from backports, maybe with the full 
pathname of some README file that gives step by step instructions.


  
Is it feasible to include some kind of grub1-emulator package in 
squeeze, something that lets the squeeze system use grub2, but creating 
a valid menu.lst file for pygrub to find?  I think this would provide 
the smoothest experience for the users who just want the lenny/squeeze 
dom0/domU thing to work.



I'm sure it would be technically possible but I'm not sure if the grub2
package maintainers would go for it, it would be a largish maintenance
burden for them which is needed only to support Xen.
  

I agree it is not the prettiest solution

If you can make the preseeding on the installer command line thing work
I would certainly be open to taking a patch to the Squeeze xm-debian.cfg
example file to detect a Lenny dom0 somehow and automatically append the
necessary runes.

  
I'm going to do another test run shortly and I'll try that approach and 
share the results.



Root causes:
- Squeeze installs grub 2, which doesn't have any /boot/grub/menu.lst
- pygrub can't seem to identify the boot partition in the MBR created by 
the installer



pygrub doesn't care about the contents of the MBR as such, it just
parses the partition table and AFAIK pygrub does know how to find the
bootable partition. There should be nothing Squeeze or grub[12] specific
about this aspect of things,
  
  
I tried invoking the pygrub script directly against the LV and the 
partition within the LV:


/usr/lib/xen-3.2-1/bin/pygrub -i /dev/mapper/vg00-squeeze1_disk0
gives an error

 kpartx -a /dev/mapper/vg00-squeeze1_disk0 
/usr/lib/xen-3.2-1/bin/pygrub -i /dev/mapper/vg00-squeeze1_disk0p1
finds the menu.lst I created manually, and displays the menu



This manually created menu.lst was present in the pygrub example just
above too?

  
In both attempts, it is the same raw disk - I have tried those commands 
several times


kpartx seems quite content with the partition table, it successfully 
creates the p1 device node from it.  pygrub, on the other hand, can't 
find the partition by itself when given the whole disk.



If it is not an MBR issue on squeeze1_disk0, why doesn't pygrub find the 
boot partition and menu.lst?



A bug in pygrub rather than anything to do with the content of the
MBR/partition-table. I think we can trust that the Squeeze installer is
creating a partition table which a physical system would be happy to
boot correctly (otherwise there would be a lot of noise being made!) and
pygrub should/must not need anything more special.

  

I agree - as I said, kpartx didn't complain about the table


I'm pretty certain this works in more recent pygrubs although I don't
see an obvious smoking gun in the diff between the two. It might be
interesting to instrument up the various probing functions of pygrub and
see why it is rejecting the bootable partition.

I don't have any Lenny domain 0 systems handy but I'm going to install a
Squeeze VM on the system I do have and try running the Lenny pygrub on
it to see if I can reproduce the issue. Your Squeeze VM is a pretty
straight forward mostly pressed enter installation, right?

  
Yes - it was my first install of squeeze, so I just decided to do the 
easy install (not the custom install) and take defaults for whatever I could



Does grub2 do anything else to the partition table?



I don't know, but partitioning is more a function of the installer (or
the advanced user if they go manual) than grub so I'd expect not.

  

/boot partition is a real partition

The rest of the disk is LVM, with separate volumes for /, usr, var, 
swap, tmp, home all created by the installer








--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ceadcbd.2060...@pocock.com.au

Bug#604080: Xen domU fails to boot after install

[Daniel Pocock]

Hi Ian, thanks for the prompt feedback

I've provided more details about some of those points below

Ultimately, I believe Debian 5 (lenny) is still a supported option for 
people after the release of squeeze and up to the release date of Debian 7.


For me, this was the only bad experience I had during the install.  It 
would seem like a great shame not to provide a convenient way for people 
to get lenny and squeeze on the same system.


I might be willing to have a deeper look at the problem and see if I can 
improve the error messages, etc.  However, if such a patch was produced, 
would it be adopted in lenny so that users who keep their systems up to 
date will be able to run this without effort?


Is it feasible to include some kind of grub1-emulator package in 
squeeze, something that lets the squeeze system use grub2, but creating 
a valid menu.lst file for pygrub to find?  I think this would provide 
the smoothest experience for the users who just want the lenny/squeeze 
dom0/domU thing to work.


I then tried to do the first boot:

xm create -c xm-squeeze1.cfg


I get this error:

Error: Boot loader didn't return any data!



Unfortunately the version of pygrub in Lenny does not understand grub2
configuration files. You are quite correct that the error message is
rubbish. FWIW it's likely that /var/log/xen/xend.log contains more
information from pygrub, although those messages are also not always
terribly helpful either...

  
xend.log only told me the pygrub command line, but not the root cause of 
the problem


I had to figure it out with Google and guesswork


You should be able to cause Squeeze to install grub1 (aka grub-legacy),
although it may be an expert mode installation option only which is less
convenient.
  
I can chroot the domU and get grub-legacy, but I'm hesitant to run any 
grub commands within the chroot out of concern that it will impact the 
dom0's MBR

http://d-i.alioth.debian.org/manual/en.i386/apbs04.html describes how
you can pressed the installation to install grub-legacy instead of grub2
and I think anything you can do in a preseed file you can also add to
the kernel command line when running the installer, so that might be
worth a go. 

  

Ok, thanks for that suggestion - I will try that too method too

Root causes:
- Squeeze installs grub 2, which doesn't have any /boot/grub/menu.lst
- pygrub can't seem to identify the boot partition in the MBR created by 
the installer



pygrub doesn't care about the contents of the MBR as such, it just
parses the partition table and AFAIK pygrub does know how to find the
bootable partition. There should be nothing Squeeze or grub[12] specific
about this aspect of things,
  
I tried invoking the pygrub script directly against the LV and the 
partition within the LV:


/usr/lib/xen-3.2-1/bin/pygrub -i /dev/mapper/vg00-squeeze1_disk0
gives an error

kpartx -a /dev/mapper/vg00-squeeze1_disk0 
/usr/lib/xen-3.2-1/bin/pygrub -i /dev/mapper/vg00-squeeze1_disk0p1
finds the menu.lst I created manually, and displays the menu

If it is not an MBR issue on squeeze1_disk0, why doesn't pygrub find the 
boot partition and menu.lst?  Does grub2 do anything else to the 
partition table?  If I run fdisk on that partition table, it complains 
about cylinder boundaries:


fdisk /dev/mapper/vg00-squeeze1_disk0

Command (m for help): p

Disk /dev/mapper/vg00-squeeze1_disk0: 6979 MB, 6979321856 bytes
255 heads, 63 sectors/track, 848 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x373f

Device Boot  Start End  
Blocks   Id  System
/dev/mapper/vg00-squeeze1_disk0p1   *   1  32  
248832   83  Linux

Partition 1 does not end on cylinder boundary.
/dev/mapper/vg00-squeeze1_disk0p2  32 849 
65638415  Extended

Partition 2 does not end on cylinder boundary.
/dev/mapper/vg00-squeeze1_disk0p5  32 849 
6563840   8e  Linux LVM







--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ce809f2.60...@pocock.com.au

Bug#604154: Thinkpad packages not automatically installed

[Daniel Pocock]

Package: installation-reports


squeeze / amd64 fresh install on a Thinkpad X61s

When the installer asks me about the set of packages to install, Laptop 
was automatically selected, I agreed to this


I notice that the battery monitor is working, etc

However, the tp-smapi package is not automatically installed.  It would 
be highly desirable to install useful packages like this for specific 
platforms.






--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ce80e5e.8000...@pocock.com.au

Bug#604155: Windows 7 not in grub menu

[Daniel Pocock]

Package: installation-reports

squeeze / amd64 fresh install on a Thinkpad X61s

Windows 7 is already on the machine

The installer told me it found Vista and asked if I want to install grub 
to the MBR.  I agreed to install MBR.


On rebooting, the grub menu appears and Debian is the only option.

Checking the partition table with fdisk, I can see that Win 7 is still 
there.






--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ce80e63.2090...@pocock.com.au

Bug#604080: Xen domU fails to boot after install

[Daniel Pocock]

Package: installation-reports

I have an amd64 dom0 with lenny

I successfully run the Debian Installer in a fresh domU

xm create -c xm-squeeze1.cfg install=true 
install-mirror=http://mirror.positive-internet.com/debian 
install-installer=http://ftp.nl.debian.org/debian/dists/testing/main/installer-amd64/current/images/




I then tried to do the first boot:

xm create -c xm-squeeze1.cfg


I get this error:

Error: Boot loader didn't return any data!

Root causes:
- Squeeze installs grub 2, which doesn't have any /boot/grub/menu.lst
- pygrub can't seem to identify the boot partition in the MBR created by 
the installer
- pygrub on lenny is looking for /boot/grub/menu.lst (actually, 
/grub/menu.lst on the bootable partition)


Workaround 1:
- mount the filesystem, possibly using kpartx, manually create 
/boot/grub/menu.lst
- tweak the cfg file to tell pygrub to look in the /boot partition 
(because it doesn't recognise the grub2 MBR)


bootargs = '/dev/mapper/vg00-squeeze1_disk0p1'

Workaround 2:
- mount the filesystem, possibly using kpartx
- copy the kernel and initrd to the dom0
- modify the cfg file, tell it to use the kernel and initrd from the 
dom0 and not use pygrub as bootloader


Suggestions:
- the MBR should be recognisable by the lenny version of pygrub
- better error needed from pygrub when it doesn't find menu.lst
- maybe grub2 should create menu.lst for backwards compatibility?  or 
maybe some optional tool in the domU can create it?
- maybe a support package is needed for lenny dom0 users? and a helpful 
message to let them know it exists?








--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ce7138a.2070...@pocock.com.au

Bug#604081: root password mismatch

[Daniel Pocock]

Package: installation-reports

Installing amd64 as a domU in xen

At the first prompt for root password, just hit enter

At the second prompt, type a password

No password-mismatch error is displayed, installer proceeds to setting 
up a user account


Once rebooted, root login impossible using blank password or the 
`repeat' password


Mount the root fs (e.g. from dom0 or another OS), inspect /etc/shadow:

root:!:14932:0:9:7:::


/etc/shadow can be fixed by copying an entry from a working /etc/shadow file





--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4ce7153f.6050...@pocock.com.au

Bug#596791: guide doesn't discuss dynamic disks or Windows LDM

[Daniel Pocock]

Package: installation-guide

Windows LDM (Logical Disk Manager) and `dynamic disks' are a reality for
anyone installing a dual boot machine, especially if Windows Vista or
Windows 7 is already on the machine.

The guide may need to be updated to touch on various issues:

- choice of boot loader (grub doesn't support LDM yet)

- GPT disk labels created by some Windows installs

- Should LDM dynamic disks be used as physical volumes (PV) for LVM2?

- Can the LDM part of the disk be safely shrunk to create space for a
real partition for Linux or LVM2?

It would be good to discuss both practical constraints and installation
strategies, and provide a working example for the typical scenario of a
machine with an existing all-of-disk LDM Windows 7 install.

This issue is related:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569133



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c8f2284.2050...@pocock.com.au

Bug#509875: extended partition is too small when creating logical partition at end of volume

[Daniel Pocock]

Package: partman-base

This issue was encountered using a lenny i386 CD, the CD was 
downloaded/burnt around 2008-09-05


Consider the following volume:

total capacity: 80GB
Primary partitions: 128MB (/boot), 10GB (FAT32), 10GB (NTFS)

The user now chooses to create another 10GB partition, and when 
prompted, chooses:

- type: logical (not primary)
- location: end (not beginning)

The partitioner creates a 10GB extended partition at the end of the 
disk, and a 10GB logical partition within this space.


The other 50GB, between the end of the third primary partition (NTFS) 
and the beginning of the logical partition is unusable.


I believe the correct behaviour would be something like this:

- warn the user in any situation where unusuable gaps will exist after 
partition

and/or
- ask the size and location questions twice: once for the extended 
partition, and again for the logical partition within the extended partition

and/or
- force the user to do things like this with cfdisk (bug 274290)
and/or
- automatically create an extended partition that uses all available 
space (although this is assuming that the user won't replace or resize 
the NTFS partition later)


Workaround:
- use gparted to resize the extended partition after installation of 
Debian, leaving the logical partition in the same place


Related:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274290
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333086
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386574










--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509662: graphical splash screen not iLO compatible

[Daniel Pocock]

When the Debian installer is booted (either from CD or netboot), it
displays a graphical splash screen (splash.rle)



Hmm. Are you only talking about the splash screen (Etch installer) or 
(also) about the graphical boot menu used introduced in the Lenny 
installer?


  
In this case, lenny - please excuse me for not understanding the details 
of this implementation



When someone is accessing a server remotely using a HP iLO, they may
not have the iLO licensed for graphical modes (extra license fees have
to be paid to HP)

Alternatively, someone may be using a serial port for remote access
(e.g. through a Cisco 2511 with multiple async ports)



For both Etch and Lenny this issue is covered in the Installation Guide. 
See the notes in the following pages:

- http://www.debian.org/releases/etch/i386/ch05s01.html.en#boot-screen
- http://www.debian.org/releases/lenny/i386/ch05s01.html.en#boot-screen

  

Thanks for pointing that out - the page correctly describes the issues.

However, the instructions given there don't work for an iLO - blindly 
pressing keystrokes doesn't seem to work.


I had already discovered the fb=false parameter, and by setting the 
syslinux args default=expert, timeout=3 and setting the kernel arg 
fb=false, I'm able to PXE boot into the installer.



Therefore, it would be desirable to have one of these options:
- a non-graphical variation of the install CD



We already have a huge number of installation media and variants...

  

- a pause before entering graphical mode, with the user having the
chance to press a key choosing non-graphical install
- no use of graphics until the user has explicitly agreed



AFAIK syslinux/isolinux does not offer those options.

I'm tagging this report wontfix as I don't really see any realistic way to 
do anything about it.
  

Couldn't it be recorded as a syslinux feature request?

Maybe the default configuration files could include commented out 
variations of the workaround I've used myself, or even go as far as 
distributing a netboot-nonfb.tar.gz on the mirrors?






--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509662: graphical splash screen not iLO compatible

[Daniel Pocock]

Package: debian-installer

When the Debian installer is booted (either from CD or netboot), it 
displays a graphical splash screen (splash.rle)


When someone is accessing a server remotely using a HP iLO, they may not 
have the iLO licensed for graphical modes (extra license fees have to be 
paid to HP)


Alternatively, someone may be using a serial port for remote access 
(e.g. through a Cisco 2511 with multiple async ports)


Therefore, it would be desirable to have one of these options:
- a non-graphical variation of the install CD
- a pause before entering graphical mode, with the user having the 
chance to press a key choosing non-graphical install

- no use of graphics until the user has explicitly agreed





--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509379: firmware not found on virtual floppy or virtual CDROM

[Daniel Pocock]

Christian Perrier wrote:

reassign 509379 hw-detect
thanks

Quoting Daniel Pocock (dan...@pocock.com.au):
  

Package: debian-installer

Installing lenny amd64 on a Dell M600 blade server using PXE/netboot method.

bnx2 firmware required for network access.

Installer prompts for a floppy or USB device.

I attempted to mount an ext3 formatted floppy image, and an ISO CDROM  



You attempted to *mount*?

What exactly did you try to do apart from putting the firmware file (or
deb package for the record) on a removable medium and hit Enter when
prompted for firmware?
  

My explanation wasn't thorough enough:

- I saw the prompt to insert the floppy or USB disk

- I used the iDRAC (Dell's iLO solution) to enable the virtual floppy

- I pressed the OK button in d-i, telling it to search for the removable 
media


- d-i told me no removable media found (I can't remember the exact 
message I saw)


- I then opened a shell (Alt-F2) and tried to manually locate the firmware

If you tried some manual actions in a shell in VT2, that might be the
cause of the problem.

  
I only did that after getting errors from d-i.  I wanted to know if the 
removable media was recognised by the installer's kernel.  In this case, 
it was recognised by the kernel as a SCSI device.

If you just did what's instructed (put the files on a floppy, USB
stick or CD, then hit Enter), then something went wrong, really..:-)

In such case, after seeing the error message that the media can't be
located, could you switch to VT2 (Alt+F2), then check if something is
mounted on /media...
  
I will test this on a similar box, as this one has already gone live.  
It may not happen until January now.  Thanks for taking the time to look 
into this issue, I hope the detail I'm providing is useful.


Regards,

Daniel




--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509378: should use labels for all partitions in fstab

[Daniel Pocock]

Colin Watson wrote:

On Sun, Dec 21, 2008 at 08:15:55PM +, Daniel Pocock wrote:
  
I believe it would be much safer to use labels for partitions rather 
than using the device nodes.



Automatically assigning labels is a really, really bad idea. Red Hat
tried this and the result was that if you did two Red Hat installations
on the same machine then they would get terribly confused on boot as
there would be two filesystems with LABEL=root. I spoke to the Anaconda
  
That is why my earlier email proposed that we check for duplicates 
before creating fstab - however, I'm not saying it's a perfect solution.




Of course you could try to generate universally unique labels, but this
is a bit silly when we already have UUIDs. Labels should be reserved for
assignment by the system administrator.
  
That is a reasonable argument - in this case, d-i may need to force the 
user to specify (or agree to) a set of labels.



I absolutely think that we should be using UUIDs by default for devices
where there isn't some other stable naming, as Ubuntu does.
  

I think this is reasonable too, as long as we deal with the fstab issues.

Note that pretty much every naming system has its downsides:

  * Traditional device names

Fail when devices are enumerated in a different order at boot, or
when the kernel changes device naming (e.g. IDE - libata).

  
With removable disks becoming more common, this is going to become more 
of an issue.

  * Labels

Good when assigned manually by the system administrator, but
assigning automatically is fraught with problems. Bit-for-bit
filesystem copies will preserve the label, which is fine for backup
and restore but can have surprising results. If you have to
reconstruct a filesystem during disaster recovery you need to
remember to reset the label too (or adjust /etc/fstab).

  
Maybe we can create a hidden file in each filesystem to provide a clue 
about where it was mounted?


IMO the best answer is to use UUIDs by default, but use labels if they
are manually set during installation. This way people who don't care can
have it just work, and people who care can set labels. In Ubuntu we put
a comment above the UUID in /etc/fstab with the original traditional
device name for the device in question, which is often a useful
aide-memoire.

  
The only solution I can see is for d-i to enforce the use of labels for 
/boot and other non-LVM filesystems.  Using the labels with LVM 
filesystems would be nice but not essential.



I think it's best to use the LVM names for LVM filesystems, since they
already form a stable naming scheme.

  
This is all fine for me, with the additional possibility that we create 
a hidden file (maybe .debian-mount or something) to provide a clue about 
where to mount when re-constructing fstab.  It would be nice if such 
information could be kept in filesystem metadata, but the label field is 
only quite small.







--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509378: should use labels for all partitions in fstab

[Daniel Pocock]

Christian Perrier wrote:

Quoting Daniel Pocock (dan...@pocock.com.au):
  

Package: debian-installer


I believe it would be much safer to use labels for partitions rather  
than using the device nodes.



Reassigning to the correct package. We might even have an already
existing bug report about this but I can't check right now.

As most wishlist features, this is of course something we can do in
the queeze release cycleand, as always, it will not happen by
magic: it needs someone to do it, and given the current state of the
d-i resourcesdon't expect too muchunless you're ready to do
the work..:-)

  
This one could be quite disruptive for some users installing for the 
first time, so hopefully it will be given consideration.


Here are some more specific ideas for implementation, if an approach is 
agreed on, I might code something:


- it needs to be automatic - therefore, the filesystems need to be named 
automatically, perhaps use the convention HOSTNAME_PATH for top level 
filesystems, and HOSTNAME_001/002, etc for filesystems with deeper mount 
points.  E.g. if hostname=host1, / would be host1_root, /usr would be 
host1_usr


- if using labels, the filesystem definition window should not allow the 
user to proceed if the label is missing


- as an alternative to the above, use the UUID instead - this is always 
present, and it doesn't have the length issues


- maybe put a comment in /etc/fstab to show where the filesystem was 
found (device node) during install, particularly important for UUID, e.g.:


# /boot was on /dev/sdb1 during install
LABEL=myhost_boot /boot ext3 defaults 0 0

or


# /boot was on /dev/sdb1 during install
UUID=558e4695-e2c8-4e79-93cb-8b89313dce6a /boot ext3 defaults 0 0

- if using pre-formatted filesystems, must check that the label and/or 
UUID is present before writing fstab, and either instruct the user to 
label their filesystems manually, or even better, prompt them to enter 
labels and do it for them


- in the case of existing filesystems, an automatic approach should be 
able to use either UUID or label, if one and not the other is present


- must also check that each label and UUID is unique within the host, 
display an error and refuse to create fstab if not the case







--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509378: should use labels for all partitions in fstab

[Daniel Pocock]

Package: debian-installer


I believe it would be much safer to use labels for partitions rather 
than using the device nodes.


This is not such a big issue for LVM filesystems, as they can always be 
found using the same name.


However, for SCSI devices, the failure to use labels is causing more and 
more problems.  Consider these examples:


- A recent install I did on an M600 blade server with Dell's 
remote/virtual floppy

- The virtual floppy was visible as /dev/sda during the install session,
- /boot filesystem was created on /dev/sdb1 by the installer.
- debian-installer put /dev/sdb1 in /etc/fstab
- I detached the virtual floppy and rebooted
- On the subsequent boot, the /boot fs is /dev/sda1, and fstab has to be 
modified - boot fails


I can also see similar situations arising when people attach a USB 
device (/dev/sda) to load firmware before the main disk is found.  The 
main disk, if SCSI, will be /dev/sdb during the install session.


The only solution I can see is for d-i to enforce the use of labels for 
/boot and other non-LVM filesystems.  Using the labels with LVM 
filesystems would be nice but not essential.



Note: the install I refer to above was done using d-i netboot, 
downloaded on 20/12/2008, for amd64






--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#509379: firmware not found on virtual floppy or virtual CDROM

[Daniel Pocock]

Package: debian-installer

Installing lenny amd64 on a Dell M600 blade server using PXE/netboot method.

bnx2 firmware required for network access.

Installer prompts for a floppy or USB device.

I attempted to mount an ext3 formatted floppy image, and an ISO CDROM 
image, using the virtual device mechanisms of Dell's iDRAC remote 
access/lights out solution.  Both images contained the bnx2 firmware 
file in the root directory.  d-i wasn't able to recognise either.


Kernel messages revealed that the virtual floppy appeared to be 
/dev/sda, but there was no partition table.  Floppies don't normally 
have partition tables, but I tried created a floppy image with a 
partition table, and the kernel still complained.


Finally, I gave up on the virtual disks and just re-built initrd.gz with 
the firmware file placed under /lib/firmware:


gunzip  initrd.gz
mkdir tmpdir
cd tmpdir
cpio -i  ../initrd
mkdir lib/firmware
cp /tmp/bnx2-06-4.0.5.fw lib/firmware/
find . | cpio -o -H newc  ../initrd
cd ..
gzip initrd


bnx2-06-4.0.5.fw had been found in the relevant package on another 
Debian box.


Another solution to this problem might be creating a non-free version of 
initrd.gz for distribution, e.g. initrd-nonfree.gz.  Users could then 
choose it on the boot menu.







--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Xen with Debian installer

[Daniel Pocock]

Goswin von Brederlow wrote:

Hi,

do you need to use the Debian-Installer?

I always use xen-create-image from xen-tools which creates a fully
functional domU for you with one simple command.

MfG
Goswin

  


A couple of reasons:

a) This web site says it should work:
http://wiki.debian.org/DebianInstaller/Xen

b) The domU systems should be indistinguishable from normal systems - 
using D-I is one way to ensure this.  It seems reasonable to expect that 
any changes to the install process will happen in D-I before being 
implemented elsewhere (e.g. is it possible that xen-create-image may lag 
behind D-I on some things?)





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Xen with Debian installer

[Daniel Pocock]

Goswin von Brederlow wrote:

Daniel Pocock [EMAIL PROTECTED] writes:

  

Goswin von Brederlow wrote:


Hi,

do you need to use the Debian-Installer?

I always use xen-create-image from xen-tools which creates a fully
functional domU for you with one simple command.

MfG
Goswin


  

A couple of reasons:

a) This web site says it should work:
http://wiki.debian.org/DebianInstaller/Xen



Sure, should. If only for easier testing of D-I.
  


It is also a more familiar method for people familiar with D-I and not 
familiar with Xen and the tools.


Testing D-I doesn't just apply to developers either: it is equally 
useful for people learning about Debian, wanting to play with the 
installer and not having a real machine to do it on.


  

b) The domU systems should be indistinguishable from normal systems -
using D-I is one way to ensure this.  It seems reasonable to expect
that any changes to the install process will happen in D-I before
being implemented elsewhere (e.g. is it possible that xen-create-image
may lag behind D-I on some things?)



Both D-I and xen-create-image call debootstrap. There should be little
difference. Most of the install process is implemented in the actual
debs and those will be the same all the time.

  
Yes, I agree that the individual package scripts are the same.  However, 
comments on the various wikis, such as the one linked to above, suggest 
the debootstrap method leaves some stuff for manual attention.  For 
someone who is not doing such installations regularly, it is probably 
more convenient to use D-I than remembering what needs to be done (if 
anything) after running debootstrap.


Regards,

Daniel


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Xen with Debian installer

[Daniel Pocock]

Ian Campbell wrote:

On Sun, 2008-05-18 at 09:39 +0100, Daniel Pocock wrote:

  
b) The domU systems should be indistinguishable from normal systems - 
using D-I is one way to ensure this.



I'm afraid I don't have any helpful suggestions about your current
issues. However I am working on ensuring that Lenny D-I works out of the
box on Xen so things should get better with time.

  


Are there any recently compiled versions of D-I that are likely to 
work?  I found various links to alpha versions of D-I.  If there is a 
suitable image people can use, a link could go in the wiki.


I've updated the wiki to show the steps I used in detail and the current 
status, it is all at the bottom of the page.


Regards,

Daniel


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Xen with Debian installer

[Daniel Pocock]

I posted this on the Xen list but got no response, maybe someone here can make 
some suggestions?


I've downloaded this version of the Debian installer:

http://ftp.nl.debian.org/debian/dists/etch/main/installer-i386/current/images/netboot/netboot.tar.gz

In my domU, the installer reports that no disks are found.

If I run a shell from the installer menu, I can successfully partition the
disk /dev/sda from the command line, using fdisk

I suspect that the Debian installer wants to access the disk using a devfs
name.  How do I either
a) get the installer to use /dev/sda or
b) force my Xen kernel to create the devfs device nodes?

The dom0 system is lenny, Xen 3.2, current versions of the packages, it
was only installed yesterday.  Nothing has been compiled in-house.  The
initrd has had the modules added to match the Xen kernel, otherwise it's
content is identical to the netboot initrd.


kernel = /boot/vmlinuz-2.6.18-6-xen-686
ramdisk = /boot/initrd-xen-debian-installer.gz
memory = 512
name = test1
vif = [ 'bridge=eth0' ]
disk = [ 'phy:/dev/mapper/daniel_vg-dom1_root,sda,w' ]
root = /dev/sda1 ro vga=normal console=tty0 devfs=mount,dall




--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Xen with Debian installer

[Daniel Pocock]

I posted this on the Xen list but got no response, maybe someone here can make 
some suggestions?


I've downloaded this version of the Debian installer:

http://ftp.nl.debian.org/debian/dists/etch/main/installer-i386/current/images/netboot/netboot.tar.gz

In my domU, the installer reports that no disks are found.

If I run a shell from the installer menu, I can successfully partition the
disk /dev/sda from the command line, using fdisk

I suspect that the Debian installer wants to access the disk using a devfs
name.  How do I either
a) get the installer to use /dev/sda or
b) force my Xen kernel to create the devfs device nodes?

The dom0 system is lenny, Xen 3.2, current versions of the packages, it
was only installed yesterday.  Nothing has been compiled in-house.  The
initrd has had the modules added to match the Xen kernel, otherwise it's
content is identical to the netboot initrd.


kernel = /boot/vmlinuz-2.6.18-6-xen-686
ramdisk = /boot/initrd-xen-debian-installer.gz
memory = 512
name = test1
vif = [ 'bridge=eth0' ]
disk = [ 'phy:/dev/mapper/daniel_vg-dom1_root,sda,w' ]
root = /dev/sda1 ro vga=normal console=tty0 devfs=mount,dall


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]