Re: Bug#998408: "good password" advice in installer is still bad two years after this was reported

[Brian Potkin]

On Thu 07 Sep 2023 at 01:27:23 +0200, Philip Hands wrote:

> Jonathan Kamens  writes:
> 
> > Oh, I see now that the fact that the installer shouldn't recommend 
> > changing one's password regularly was also reported previously, in bug 
> > #868869.
> 
> Also, in #656509 (in which Cyril states that the effort of translating a
> new message outweighs the importance of the change).
> 
> I've no idea if that justification for inaction still stands, but I
> thought this would make a nice little example for the use of the
> salsa-CI pipeline (and my branch2repo variant of that), so here's an MR:
> 
>   https://salsa.debian.org/installer-team/user-setup/-/merge_requests/7
> 
> and here's a screenshot of what the change looks like:
> 
>   https://openqa.debian.net/tests/185853#step/passwords/1
> 
> I'm not 100% happy with the wording (and the underlines around 'should'
> need to go) so I'm very likely to tweak it tomorrow.
> 
> Suggestions for improvement welcome, although be aware that given the
> resistance to fixing this in the past, it's always possible such a
> change will also be deemed unjustified now.
> 
> I think it's probably about time we fixed it, since even the civil
> servants in the UK have stopped recommending password changes by now,
> and they tend to make such changes at least a decade late. ;-)

The password strength advice in d-i has been there from the year dot.
Irrespective of what GCHQ and others say now, it was a load of nonsense
then and remains so.

The vast majority of users ignore it; some might schedule a password
change at the same time they change the locks on all outside doors of
their residence or on their cars.

Debian has no need to offer password advice (as opposed to roo vs sudo).
So leave it there as a historical oddity or delete the d-i advice. The
latter route does not involve anyone in any great effort to maintain
the staus quo.

-- 
Brian.

Hi

[Brian Reynolds]

Lci 

Sent from my iPhone

Re: Unable to set root password with clear text using preseed/early_command

[Brian Potkin]

On Wed 16 Feb 2022 at 10:32:25 +0100, More Thanks wrote:

> On Wed, Feb 16, 2022 at 04:52:48PM +0800, Glen Huang wrote:
> > On Feb 16, 2022, at 4:38 PM, Philip Hands  wrote:
> > > Glen Huang  writes:
> > > > Thanks to Cyril Brulebois’s tip that I could use DEBCONF_DEBUG
> > > > to debug debconf, I found out the seen flag should be set in order
> > > > for db_input to pick up the value.
> > > > 
> > > > Case solved, thanks to everyone helped!
> > > 
> > > I was wondering about that, but didn't see my code setting lots of seen
> > > flags, so wasn't sure.
> > > 
> > > I now realise that the reason for that is that I generally preseed the
> > > things I don't want to be asked, even if I'm going to set them via
> > > script, and the act of preseeding them to a place-holder value also sets
> > > the seen flag.  Then you get to override that in a script without
> > > worrying about also setting the seen flag at that point.
> > > 
> > 
> > Setting a placeholder value is a great idea, it simplifies the
> > early_command since the seen flag no longer needs to be set.
> > 
> > Thanks for the tip Philip.
>  
> Thank your future self by sharing your solution with the mailinglist.

Geert Stappers is not the only one who would like to know your solution.
Detail appreciated.

-- 
Brian.

Re: Problem preseeding wifi password

[Brian Potkin]

On Thu 11 Nov 2021 at 06:05:49 -0800, VDRU VDRU wrote:

> > It is assumed something like 'cp  /dev/sdX' has been used to write
> > to the USB stick.
> 
> I always use Rufus on a Windows desktop to write iso's to bootable usb
> sticks. I know a lot of others do as well, maybe the assumption it's
> done from a Linux command line is a bad assumption to make?
> 
> > I successfully preseed with
> >
> >  d-i netcfg/wireless_show_essids select manual
> >  d-i netcfg/wireless_essid string Horizon
> >  d-i netcfg/wireless_security_type select wpa
> >  d-i netcfg/wireless_wpa string 
> > JYWw2Dx0gy56TJmiP0r8JlHvhs4gm0Q8LgoHuaCGOhOrZAPFLLMBidUFaq7B9Z7
> 
> Does it still work if you only preseed netcfg/wireless_wpa,  or
> wireless_security_type and wireless_wpa?

Exchange of keys and association with the access point succeeded
only in the first case.

-- 
Brian.

Re: Problem preseeding wifi password

[Brian Potkin]

On Thu 11 Nov 2021 at 06:41:04 +0100, Geert Stappers wrote:

> On Wed, Nov 10, 2021 at 06:08:22PM -0800, VDRU VDRU wrote:

[...]

> > And, preseeding just a wpa password fails in all cases.
> 
> That is unexpected.
> 
> Disclosure:
> I myself never did preseed WIFI password.
> (and didn't noticed previous reports about it not working)
> 
> I hope that this messages triggers  "works for me" notifications.

It is assumed something like 'cp  /dev/sdX' has been used to write
to the USB stick.

I successfully preseed with

 d-i netcfg/wireless_show_essids select manual
 d-i netcfg/wireless_essid string Horizon
 d-i netcfg/wireless_security_type select wpa
 d-i netcfg/wireless_wpa string 
JYWw2Dx0gy56TJmiP0r8JlHvhs4gm0Q8LgoHuaCGOhOrZAPFLLMBidUFaq7B9Z7

The WAP uses TKIP.
  
> > Another discovery I made is that the wifi device wants nonfree
> > firmware "rtlwifi/rtl8192cufw.bin". If I copy
> > "rtlwifi/rtl8192cufw.bin" to the root dir of the usb stick, the
> > installer fails to find it when I select yes. If I unplug the usb
> > stick and connect it in a different usb port and select yes again, the
> > installer finds it but sometimes takes a few tries. Maybe it's a good
> > idea to have the installer automatically check the root dir of the usb
> > it booted from for any missing firmware before asking the user for it?
> 
> I can't tell if effects the problem from the subject line.

Neither can I, but it's a possibility, I suppose. My preseed.cfg has

 # Provide non-free firmware files directly to the installer. It now
 # does not need to search for them in other packages.
 d-i preseed/early_command string\
 cp -a /hd-media/files/firmware /lib

Not much use to VDRU VDRU as it stands (I use hd-media for installing),
but copying can be done from a labelled partition on a USB stick.

-- 
Brian.

Bug#996955: task-desktop silently pulls in task-desktop-gnome via Recommends

[Brian Potkin]

On Thu 21 Oct 2021 at 20:39:01 +0200, Fabian Greffrath wrote:

> Am Donnerstag, dem 21.10.2021 um 18:33 +0100 schrieb Brian Potkin:
> > I think this is exactly the way it was designed. Whether the design
> > is the best is what has been brought up in this report.
> 
> The results are pretty surprising and unpredictable, though.

Indeed. Many users, myself included, have stared at the choices and
wondered what the first choice implies. "Default - Gnome" next to it
might have helped.

Fortunately, not selecting it isn't of any consequence. A user gets
what else is chosen.
 
> > There is the concept of "default desktop". At the present time it is
> > Gnome. The first selection is for the default. The description for
> > task-desktop says:
> 
> You don't have a chance to read the description of the task-desktop
> package during d-i. As Holger already stated, it must be made clear
> that merely selecting "Desktop Environment" will have the same effect
> as selecting the first one in the list, even if this has been
> explicitly unselected.

No, that is not the case. Selecting "Desktop Environment" only will
have the effect of selecting the default desktop. This could be Xfce,
which is not the first one in the list.

Cheers,

Brian.

Bug#996955: task-desktop silently pulls in task-desktop-gnome via Recommends

[Brian Potkin]

On Thu 21 Oct 2021 at 17:27:22 +0200, Fabian Greffrath wrote:

> Hi Holger,
> 
> thanks for your reply!
> 
> Am 21.10.2021 16:31, schrieb Holger Wansing:
> > Selecting "Desktop Environment", but not choose one of the displayed
> > possiblities (like "GNOME", "KDE" and so on) is not the way, how this
> > dialog was designed, I guess.
> 
> Yes, apparently. :/

I think this is exactly the way it was designed. Whether the design
is the best is what has been brought up in this report.

There is the concept of "default desktop". At the present time it is
Gnome. The first selection is for the default. The description for
task-desktop says:

  This task package is used to install the Debian desktop.

Regards,

Brian.

Bug#604839: Bug#988472: Bug#604839: [installation-guide] Planned overhaul of chapter 4.3 "Preparing Files for USB Memory Stick Booting"

[Brian Potkin]

On Sat 09 Oct 2021 at 11:21:54 +0200, Holger Wansing wrote:

> Hi,

Hello Holger,

Thank you for your consideration

> Brian Potkin  wrote (Sun, 3 Oct 2021 14:45:29 +0100):
> >  > You should be able to see to which device the USB stick was mapped
> >  > by running the command dmesg after inserting it.
> > 
> > I would add lsblk, with a link to its manual page.
> > 
> >  You should be able to see to which device the USB stick was mapped
> >  by running the command lsblk before and after inserting it. The
> >  output of dmesg (as root) is another discovery method.
> 
> Ok, applied (similar).

Looks good.
 
> > --
> > 
> >  > If you use the wrong device the result could be that all information
> >  > on for example a hard disk could be lost.
> > 
> > Surely it would be quite surprising if all information was not lost?
> > Why not continue the dire warning, particularly as the process is done
> > as root? "would" instead of "could"?
> 
> I would simplify that to 
> "If you use the wrong device the result could be that all
> information on for example a hard disk is lost."

Sorry, it appears I wasn't very clear. What I wrote was not intended as
replacemet text but a short commentary on whether there is a possibility
or a certainty of data being lost. Changing one word in your text and
putting in a couple of commas:

  "If you use the wrong device the result will be that all
   information on, for example, a hard disk is lost."

> > -
> > 
> >  > Debian installation images for this architecture are created using
> >  > the “isohybrid”...
> > 
> > I do not understand why "isohybrid" needs to be enclosed in double
> > quotes. Two links:
> 
> Ok, I replaced the quotes by a bold font.

Better.
 
> >   https://joeyh.name/blog/entry/Debian_USB_install_from_hybrid_iso/
> >   https://blog.einval.com/2011/01/07
> > 
> > I have forgotten whether the Guide policy allows referencing pages
> > outside the Debian infrastructure.
> > 
> > ---
> > 
> >  > If you have chosen the mini.iso to be written the USB stick, the
> >  > second partition doesn't have to be created, as - very nice - ...
> > 
> > The original ("very nicely") is OK and better English (IMO).
> 
> Ok, applied.

Thanks.


> Brian Potkin  wrote (Sun, 3 Oct 2021 15:51:28 +0100):
> > On Sat 02 Oct 2021 at 19:48:41 +0200, Holger Wansing wrote:
> > 
> > [...]
> > 
> > > I had some understanding issues, mostly in chapter
> > > "Manually copying files to the USB stick — the flexible way"
> > 
> > I have never really understood what is so special about syslinux and
> > mbr.bin in the context of using hd-media. GRUB should always be at
> > hand on a Linux machine. This is my flexible way:
> > 
> > 1. dd if=/dev/zero of=/dev/sdb count=100
> >(Could be omitted).
> > 
> > 2. cfdisk /dev/sdb (FAT).
> > 
> > 3. mkfs.vfat /dev/sdb1
> >dosfslabel /dev/sdb1 LABEL.
> >(Download dosfstools).
> > 
> > 4. mount /dev/sdb1 /mnt
> >grub-install --boot-directory=/mnt/boot /dev/sdb
> > 
> > 5. cp vmlinuz /mnt/boot
> >cp initrd.gz /mnt/boot
> > 
> > 6. cp  /mnt
> > 
> > 7. # An example grub.cfg.
> >menuentry 'Debian 11.0.0' {
> >linux /boot/vmlinuz shared/ask_device=manual \
> >shared/enter_device=/dev/disk/by-label/LABEL
> >initrd /boot/initrd.gz
> >}
> > 
> > 8. cp grub.cfg /mnt/boot/grub
> > 
> > 9. Boot.
> > 
> > More detail at https://wiki.debian.org/Installation+Archive+USBStick.
> > To declare an interest - I wrote that page.
> 
> I personally have no strict preference on syslinux.
> However, the proposed alternative does not look much easier to me ...
> (leaving only the pro, that syslinux does not need to be installed)
> 
> 
> Other opinions?
> 
> 
> 
> 
> Brian Potkin  wrote (Sun, 3 Oct 2021 19:40:00 +0100):
> > On Sat 02 Oct 2021 at 19:48:41 +0200, Holger Wansing wrote:
> > 
> > [...]
> > 
> > > - Because a long time has passed by since the last overhaul of this 
> > > chapter,
> > >   maybe there is some more, that could be changed, for example because of
> > >   changed/new technology or experience?
> > 
> > Regardin

Bug#604839: [installation-guide] Planned overhaul of chapter 4.3 "Preparing Files for USB Memory Stick Booting"

[Brian Potkin]

On Sat 02 Oct 2021 at 19:48:41 +0200, Holger Wansing wrote:

[...]

> - Because a long time has passed by since the last overhaul of this chapter,
>   maybe there is some more, that could be changed, for example because of
>   changed/new technology or experience?

Regarding 4.3.2. at

  
https://people.debian.org/~holgerw/installation-guide_2021-10-02/amd64/ch04s03.html


 > An alternative way to set up your USB stick is to manually copy
 > the installer files,...

This section has been about since the dawn of time :). It predates the
advent of isohybrid technology and could be said to have served its
purpose and be retired. An alternative would be to leave it there and
introduce it as follows:

 Prior to isohybrid technology being used for all Debian ISOs, this way
 was the method used to boot from a USB device. It has been superseded
 by the technique in Section 4.3.1 [LINK] but has been left here for
 educational and  historical purposes and in case it proves of use to a
 user.



 > ...(smaller setups are possible if you follow Section 4.3.3,...

I wonder about this. The Debian 11 netinst ISO is 480M. GRUB plus the
boot files are 33M. Would they fit on a 512M USB stick (which is not
really 512M)? Partially tested to say "no". My rule of thumb is 1G.



The link beginning

  http://http.us.debian.org/

should be

  http://deb.debian.org/

or

  https://deb.debian.org/



The Note exercised my mind. It has nothing to do with the being able to
use this method but refers to an after effect. "major disadvantage"
refers to this after effect. An alarming term.

 > Note that, although convenient and successful, this method does have a
 > drawback affecting how the size of the USB device is seen because it
 > sets its logical size to 1 GB, even if the capacity of the USB stick is
 > larger. You will need to repartition the USB stick and create new file
 > systems to get its full capacity back if you ever want to use it for
 > some different purpose.

----

Regards,

Brian.
 

Bug#988472: Bug#604839: [installation-guide] Planned overhaul of chapter 4.3 "Preparing Files for USB Memory Stick Booting"

[Brian Potkin]

On Sat 02 Oct 2021 at 19:48:41 +0200, Holger Wansing wrote:

[...]

> I had some understanding issues, mostly in chapter
> "Manually copying files to the USB stick — the flexible way"

I have never really understood what is so special about syslinux and
mbr.bin in the context of using hd-media. GRUB should always be at
hand on a Linux machine. This is my flexible way:

1. dd if=/dev/zero of=/dev/sdb count=100
   (Could be omitted).

2. cfdisk /dev/sdb (FAT).

3. mkfs.vfat /dev/sdb1
   dosfslabel /dev/sdb1 LABEL.
   (Download dosfstools).

4. mount /dev/sdb1 /mnt
   grub-install --boot-directory=/mnt/boot /dev/sdb

5. cp vmlinuz /mnt/boot
   cp initrd.gz /mnt/boot

6. cp  /mnt

7. # An example grub.cfg.
   menuentry 'Debian 11.0.0' {
   linux /boot/vmlinuz shared/ask_device=manual \
   shared/enter_device=/dev/disk/by-label/LABEL
   initrd /boot/initrd.gz
   }

8. cp grub.cfg /mnt/boot/grub

9. Boot.

More detail at https://wiki.debian.org/Installation+Archive+USBStick.
To declare an interest - I wrote that page.

Regards,

Brian.

Bug#988472: Bug#604839: [installation-guide] Planned overhaul of chapter 4.3 "Preparing Files for USB Memory Stick Booting"

[Brian Potkin]

On Sat 02 Oct 2021 at 19:48:41 +0200, Holger Wansing wrote:

> Hi,

Hello Holger,
 
> I'm thinking about (long overdue) updating chapter 
> https://d-i.debian.org/doc/installation-guide/en.amd64/ch04s03.html
> "Preparing Files for USB Memory Stick Booting".

I am working from

  https://people.debian.org/~holgerw/

and will devote this mail to comments on the introductory section and
section 4.3.1.


 > You should be able to see to which device the USB stick was mapped
 > by running the command dmesg after inserting it.

I would add lsblk, with a link to its manual page.

 You should be able to see to which device the USB stick was mapped
 by running the command lsblk before and after inserting it. The
 output of dmesg (as root) is another discovery method.

--

 > If you use the wrong device the result could be that all information
 > on for example a hard disk could be lost.

Surely it would be quite surprising if all information was not lost?
Why not continue the dire warning, particularly as the process is done
as root? "would" instead of "could"?

-

 > Debian installation images for this architecture are created using
 > the “isohybrid”...

I do not understand why "isohybrid" needs to be enclosed in double
quotes. Two links:

  https://joeyh.name/blog/entry/Debian_USB_install_from_hybrid_iso/
  https://blog.einval.com/2011/01/07

I have forgotten whether the Guide policy allows referencing pages
outside the Debian infrastructure.

---

 > If you have chosen the mini.iso to be written the USB stick, the
 > second partition doesn't have to be created, as - very nice - ...

The original ("very nicely") is OK and better English (IMO).

---

Regards,

Brian.

Bug#993668: CUPS is missing after a default GNOME Desktop Install

[Brian Potkin]

On Sat 04 Sep 2021 at 16:16:50 +0200, Nader Nooryani wrote:

> Package: task-gnome-desktop
> Version: 3.68
> 
> As of Debian 11, Print Server is no longer included as an option in the
> Debian installer if you use the defaults: Debian desktop environment, GNOME
> and standard system utilities.  Ref:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950553
> 
> This leaves the user without CUPS after a default install.  This should
> perhaps be included in task-gnome-desktop
> 
> Suggestion: It may be wise to include CUPS in task-gnome-desktop or
> somewhere else, since there are no instructions informing the user how they
> can enable support for printing.
> 
> I am using Linux debian 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03)
> x86_64 GNU/Linux

>From a previous mail to -boot:

 > I have written a bit more about this on Reddit as well.
 > https://www.reddit.com/r/debian/comments/pgl6c9/debian_11_and_printing/

It would be nice if the reddit thread could be updated to record the
responsive and timely intervention from the d-i maintainers.

Regards,

Brian.

Bug#993668: CUPS is missing after a default GNOME Desktop Install

[Brian Potkin]

On Sat 04 Sep 2021 at 21:09:56 +0200, Holger Wansing wrote:

> Hi,
> 
> Nader Nooryani  wrote (Sat, 4 Sep 2021 16:16:50 
> +0200):
> > As of Debian 11, Print Server is no longer included as an option in the
> > Debian installer if you use the defaults: Debian desktop environment, GNOME
> > and standard system utilities.  Ref:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950553
> > 
> > This leaves the user without CUPS after a default install.  This should
> > perhaps be included in task-gnome-desktop
> 
> I have tested this, and CUPS got installed here with GNOME desktop (default 
> install).
> 
> The dependency chain turns out to be:
> task-gnome-desktop -> gnome-core -> system-config-printer-common -> 
> cups-pk-helper -> libcups2
> 
> (BTW: CUPS also gets installed with the other desktops via
> gnome-core -> system-config-printer-common -> cups-pk-helper -> libcups2)
> 
> So, I cannot reproduce this.
> 
> 
> Do you have the installation logs available?

I have a recent bullseye installation that has only the base system.
Therefore, I can be confident that 'apt install task-x-desktop
will show all the packages to be installed. Only kde and cinnamon
install the cups package.

libcups2 has shared libraries. For a working printing system it is
essential to have the scheduler, cupsd, available, This is in the
cups-daemon package and would be installed when cups is pulled in.

Regards,

Brian.

Bug#993668: CUPS is missing after a default GNOME Desktop Install

[Brian Potkin]

On Sun 05 Sep 2021 at 01:48:06 +0200, Nader Nooryani wrote:

> Sorry, I should have mentioned that I have the packages you mention as well
> as ipp-usb.
> Will Debian detect and add both driverless-enabled printers and ones that
> require drivers?

Yes - if the scheduler is present. Printing, whether driverless or not,
requires cupsd.

> When I check Settings -> Printers in GNOME I am presented with this "Sorry!
> The system printing service doesn't seem to be available."

The scheduler is not present. 'apt install cups'.

Regards,

Brian.

Gecos... gecos? Because because!!!!

[Brian Jonnes]

Dear Debi-dev(s).
I find myself reaching for a beer when I get hot under the collar about
silliness which exists in abundance and want to point a stick at a mirror
and tell people one by one to go to Hell. I can't be saying I won't
continue to do that in the privacy of my own home, but I most certainly
find reaching for a stout beer, even if it is half way through the morning,
a much more productive use of my time.
But even here I figure your advice would come in handy.

With the help of my advisors, I will have to cut back to one stout beer a
day (Castle Milk Stout, btw). This stuff is about as addictive as
shit-posting. People who think they're addicted to shit posting have
probably not tried sticking it somewhere they can go back to and revise
when they find themselves thinking, "maybe I shouldn't have told that
person to go to hell, or tell the entire American population to drown
themselves".

Which is where we found ourselves, when we were trying to come to terms
with what we see going on, with the insight of a man and an overgrown boy
who have spent no less than thirty-five years, together watching with
interest (and horror) the industry of all industries.

Which is to say, the Microcomputer Industry.

But now I've resorted to the first person plural... a habit I am trying to
kick, unless by way of instruction. I don't hold out much hope. I do hope
this stout holds out to the end of this email. Getting myself a cup of
coffee, therefore, and a piece of ham and a piece of cheese so as not to
forget what this world is about, I humbly apologize to the good hearted
Americans, who I know exist in abundance, if they saw a person who goes by
the twitter handle of imperialsixfour saying hateful, spiteful, and, to be
quite honest, impatient nonsense.

Impatient, because we (I give up) have had to work for about a month on
getting ourselves to the point where we can make contact with the people we
know exist.

Please read the following webdocs of mine, to the first of which this email
is attached.

• Gecos because .. because <https://killtheworld.co.za/gecos>!
• Sentimental dross floss < <https://killtheworld.co.za/sentimental>
<https://killtheworld.co.za/sentimental>
https://killtheworld.co.za/sentimental
<https://killtheworld.co.za/sentimental>>!
• Gnu-Brian gets on his feet after an (expert) sex change <
https://killtheworld.co.za/gnu-brian>(?).

We have made a tune which we would like to dedicate to Ian Murdoch, but
which obviously we can't do without having the GNU-Team-of-teams (in our
opinion) talking to us. And we're struggling to find the right MIDI editor
which will allow us to include a dedication (hence our reference to the PMS
package).

What do you say?

ROTFLMAO (Read over this fairly lengthy message about our) gnu love.

Re: Merge request created [Re: Use isenkram to get around the firmware problem?]

[Brian Potkin]

On Mon 08 Mar 2021 at 22:41:53 +0100, Holger Wansing wrote:

> Hi,
> 
> Holger Wansing  wrote (Sun, 7 Mar 2021 17:02:06 +0100):
> > And for the (graphics) firmware problem, isenkram is of no help as it 
> > seems, 
> > at least for Bullseye.
> 
> I have reached the end of my path on this issue.
> 
> isenkram is apparently no solution for Bullseye.
> 
> At the bare minimum, I have created a merge request for my "introduce a dialog
> to enter packages for firmware installation" approach, so it is at least 
> officially documented somewhere...

It has been said before that installing packages with late_command is
a trivial matter. So why an additional dialog to add to the installtion
process?

https://lists.debian.org/debian-boot/2014/10/msg00320.html

-- 
Brian.

Re: Use isenkram to get around the firmware problem?

[Brian Potkin]

On Sun 07 Mar 2021 at 17:12:33 +0100, John Paul Adrian Glaubitz wrote:

> On 3/7/21 5:02 PM, Holger Wansing wrote:
> > I fear, all the above is out of my skills.
> > 
> > And for the (graphics) firmware problem, isenkram is of no help as it 
> > seems, 
> > at least for Bullseye.

[...]

> As a compromise, I think it would already be a step forward if the non-free 
> images
> were more visible on the Debian homepage so that users don't have to search 
> for them
> on the interwebs.

At least half a dozen pages were altered to include pointers to the
non-free images. The one page that was not altered was the one that
many people want to be changed was the home page. Interesting.

-- 
Brian.

Re: Manually add firmware (or other) packages for installation?

[Brian Potkin]

On Sat 27 Feb 2021 at 11:16:13 +0100, Holger Wansing wrote:

[...]

> + If you know your hardware requires this, and you have enabled "non-free"
> + package sources, you can list firmware packages here to have them installed.
> + For AMD/ATI graphics cards you might want to install 
> "firmware-amd-graphics";
> + for Intel or Nvidia, "firmware-misc-nonfree".

Maybe the user doesn't want or need these packages or doesn't have a
clue what to do at this prompt. Why not link to firmware.zip at

   
https://cdimage.debian.org/cdimage/unofficial/non-free/firmware/bullseye/20210222/

and give instructions.

> + Please note, that you can also use this dialog for installation of any other
> + additional packages you want to have installed, not just firmware. Package
> + names need to be space-separated.

Is that an improvement on what the installer already provides?

-- 
Brian.

Re: Manually add firmware (or other) packages for installation?

[Brian Potkin]

On Sat 27 Feb 2021 at 17:32:34 +, Justin B Rye wrote:

> John Paul Adrian Glaubitz wrote:
> > On 2/27/21 11:46 AM, Holger Wansing wrote:
> >> John Paul Adrian Glaubitz  wrote (Sat, 27 
> >> Feb 2021 11:21:58 +0100):
> >>> The point is: We separate free and non-free images for a very reason and 
> >>> if
> >>> you add a mechanism that just silently enables non-free on a system that
> >>> was installed with the free installer, you are defeating this separation.
> >> 
> >> 1. *I* do not do or change anything here. It's the case like this for ages!
> > 
> > Of course, you are. You are sending in a patch.
> 
> But is that patch one that "silently enables non-free" and "taints"
> the official installer?  All I see it doing is giving expert users
> more convenient access to the mechanism they can already use on the
> console to get their hardware working properly.

I wouldn't use the term "silently enables non-free" myself. However,
the patch blatently pushes users towards using non-free. Considering
that one of the targets of the patch is "newbie users", expert mode
leaves them in the cold, as many of them use Install.
  
> If only we knew of a plausible use case for a kind of "additional
> package" that someone might install this way *other* than firmware, I
> suspect that would make this more palatable.  The nearest I can think
> of is that I hear tales of people setting up a local repo with a
> "LAN-standard package-set" metapackage.  Any takers?
> 
> >> 2. non-free does *NOT* be *silently* activated! The user is prompted for 
> >> this,
> >>and he needs to explicitly say YES to this option! 
> >>And this question is only be asked in expert installation mode.
> > 
> > You are contradicting yourself. Earlier in the discussion you claim that the
> > user just enters the name of the firmware packages and the installer does
> > the rest of the work.
> 
> *If* the user has configured apt appropriately, it's already possible
> to do this via a console.  Holger's idea is that if people often need
> to do that, the installer could just offer a dialog.

Why use a console when early_command, late_command and pkgsel are
at hand?

BTW. What is this "official installer"? Is the same as "the installer"?

-- 
Brian.

Re: Manually add firmware (or other) packages for installation?

[Brian Potkin]

On Sat 27 Feb 2021 at 19:22:24 +0100, Holger Wansing wrote:

> Hi,
> 
> Brian Potkin  wrote (Sat, 27 Feb 2021 16:54:01 +):
> > > +Template: hw-detect/firmware_packages_to_install
> > > +Type: string
> > > +# :sl2:
> > > +Description: Additional/firmware packages to be installed:
> > > + Modern devices (like graphics cards or network devices) tend to need 
> > > firmware
> > > + blobs to be loaded onto the device, to be (fully) functional. This may 
> > > already
> > > + have been dealt with,
> > 
> > Surely not "may" but "will".
> 
> Sorry, I don't get your point here.
> Do you think, that the installer will surely do the needed things regarding 
> firmware
> installation automatically?

As far as the firmware it knows about, yes. If it doesn't it is a
bug. That is why the sentence should read

  This will already have been dealt with,

Whether it has been dealt with to your satisfaction is a different
matter.

> This is true for many hardware, but not true for graphics cards!
> Which is the reason for this patch.

I think I understand your concerns.

[...]

> > A duplication of what the installer already provides.

I'd have liked that addressed.
 
> > > + .
> > > + If you don't know what to enter, just leave it blank to not install any
> > > + additional packages.
> > 
> > Have you thought of using tasksel to provide the installation of
> > non-free packages?
> 
> Using tasksel for this would just allow to display one simple line for
> this topic ("Install firmware packages" or similar) and no possibility to

"Install non-free firmware packages" would be the option. Why should
it need more detail? The other entries aren't exactly locquacious.

> give more detailed description, what this is or why this is needed (and
> mention that this may need non-free).
> This all is what the patch does.
> And how to use tasksel: do you want to add a single task for every firmware 
> package? How many entries for such tasks would that be?

A metapackage? 

> Or do you want to add just one task, and install all firmware packages we have
> in Debian at once, no matter which hardware is in the PC?

Installing all firmware packages isn't unreasonable, surely? After
all, xorg installs all video drivers. Nobody has complained yet.
> 
> No, I think using tasksel for this is not suitable.

How about early_command, late_command and pkgsel? These facilities
are already provided by the installer. Why are they not suitable?

-- 
Brian.

Re: Manually add firmware (or other) packages for installation?

[Brian Potkin]

On Sat 27 Feb 2021 at 19:28:49 +0100, Holger Wansing wrote:

> Hi,
> 
> Brian Potkin  wrote (Sat, 27 Feb 2021 16:54:01 +):
> > > but if the installer does not include non-free 
> > > firmware
> > > + packages,
> > 
> > "if"? There is only *one* installer. It does not include non-free
> > firmware packages. Did you have some other non-Debian variant in
> > mind to promote in the installer?
> 
> Sorry, I overlooked this part:

No problem, Holger.
 
> You are wrong here, we have indeed more than one installer!!!
> Looking at 
> https://www.debian.org/devel/debian-installer/
> for example, there you will find (at the bottom, below the daily snapshots)
> links to unofficial installer images, which have firmware packages included.

The word "unofficial" gives it away. I suppose there could be as many
unofficial images as there developers who commit their efforts to
https://cdimage.debian.org/cdimage/unofficial/. None of them would be
the one, true and free installer. None of them deserves to be called
"the installer". The sentence I referred to should read

   but the installer does not include non-free firmware packages,

This is not a matter of Englis usage but of reality.

-- 
Brian.

Re: Manually add firmware (or other) packages for installation?

[Brian Potkin]

On Sat 27 Feb 2021 at 11:16:13 +0100, Holger Wansing wrote:

[...]

> In summary, I have thrown this all together to the attached patch.
> 
> Holger
> 
> 
> 
> -- 
> Holger Wansing 
> PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

> diff --git a/debian/hw-detect.templates b/debian/hw-detect.templates
> index c413e88e..3a1e4641 100644
> --- a/debian/hw-detect.templates
> +++ b/debian/hw-detect.templates
> @@ -96,6 +96,29 @@ Type: text
>  # :sl1:
>  _Description: Checking for firmware...
>  
> +Template: hw-detect/firmware_packages_to_install
> +Type: string
> +# :sl2:
> +Description: Additional/firmware packages to be installed:
> + Modern devices (like graphics cards or network devices) tend to need 
> firmware
> + blobs to be loaded onto the device, to be (fully) functional. This may 
> already
> + have been dealt with,

Surely not "may" but "will".

> but if the installer does not include non-free 
> firmware
> + packages,

"if"? There is only *one* installer. It does not include non-free
firmware packages. Did you have some other non-Debian variant in
mind to promote in the installer?

> or could not detect the need for them (this may be the case
> + especially for graphics cards), it may be necessary to fetch them manually 
> at
> + this stage.

What militates against using the existing infrastructure? pkgsel,
early_command and late_command?

> + .
> + If you know your hardware requires this, and you have enabled "non-free"
> + package sources, you can list firmware packages here to have them installed.
> + For AMD/ATI graphics cards you might want to install 
> "firmware-amd-graphics";
> + for Intel or Nvidia, "firmware-misc-nonfree".
> + .
> + Please note, that you can also use this dialog for installation of any other
> + additional packages you want to have installed, not just firmware. Package
> + names need to be space-separated.

A duplication of what the installer already provides.

> + .
> + If you don't know what to enter, just leave it blank to not install any
> + additional packages.

Have you thought of using tasksel to provide the installation of
non-free packages?

-- 
Brian.

Re: Manually add firmware (or other) packages for installation?

[Brian Potkin]

On Sat 27 Feb 2021 at 11:21:58 +0100, John Paul Adrian Glaubitz wrote:

> On 2/27/21 12:12 AM, Holger Wansing wrote:

[...]

> > And there was a huge discussion on debian-devel in January regarding 
> > firmware/nonfree etc., starting here:
> > https://lists.debian.org/debian-devel/2021/01/msg00151.html
> 
> I'm not going to read through that huge thread now.

When you do get the opportunity, I suggest you read the first post
very carefully.

  > The current policy of hiding other versions of Debian is
  > limiting the adoption of your OS by people like me who are
  > interested in moving from Windows 10.

Do we hide any version of Debian? I don't see any evidence for that.
Also, it does not appear directly related to the patch being discussed
in this thread.

-- 
Brian.

Bug#982640: [d-i] finish-install: improve understandability of reboot screen

[Brian Potkin]

On Fri 12 Feb 2021 at 21:26:50 +0100, Holger Wansing wrote:

> John Paul Adrian Glaubitz  wrote (Fri, 12 Feb 
> 2021 21:08:14 +0100):
> > On 2/12/21 9:00 PM, Holger Wansing wrote:
> > > I have prepared a small patch, to improve the understandability of the 
> > > screen.
> > 
> > "+ Then, choose  to reboot.".
> >
> > I think that sentence sounds a bit weird.

The comma isn't needed

> > It's probably better to write just "Please choose  to reboot."

Yes, but why change anything?   
  

  
  ...Installation is complete, so it is time to boot into your  
  
  new system.   
  

  
Isn't that clear enough? The only other choice is .

> Yes, maybe.

The link the OP quoted also has 
  

  
  Switch to another console...  
  
    
  
I find that very clear too.

-- 
Brian.

Bug#666530: cups fails to configure under cdebconf

[Brian Potkin]

A nine year old bug with no response. I am closing it. If it has

relevance to today's printing system, someone will reopen it.

-- 
Brian.

Re: Change templates: CD -> installation medium

[Brian Potkin]

On Sun 25 Aug 2019 at 22:18:34 +0200, Samuel Thibault wrote:

> Hello,
> 
> Holger Wansing, le dim. 25 août 2019 22:12:57 +0200, a ecrit:
> > Change "CD" into "installation medium" 
> 
> More generally, our usage of "CD" confuses people, and people tend to
> think that our ISO images don't work on USB sticks, so I'm all for
> getting rid of "CD" naming in general :)

About time. Perhaps whoever has responsibilty for the FAQ about Debian
CDs/DVDs

https://www.debian.org/CD/faq/

could take note of this sensible change.

Having submitted unaccepted patches for this page in the past, I will
not hold my breath.

-- 
Brian.

Re: Bug#931911: user-setup: Fails to present no-root-password_first-user-sudoer option as a reasonable choice

[Brian Potkin]

On Fri 12 Jul 2019 at 10:22:59 +0200, Philip Hands wrote:

> Package: user-setup
> Severity: normal
> 
> Prompted by this LWN comment relating to installing buster:
> 
>   https://lwn.net/Articles/792960/
> 
>   "The installer text specifically said that not setting a root password
>was a Very Bad Idea"
> 
> looking at the text in question, I was surprised at how negative it is
> about the completely reasonable choice of selecting no root password in
> order to provoke the first-user-is-sudoer setup.
> 
>   
> https://salsa.debian.org/installer-team/user-setup/blob/master/debian/user-setup-udeb.templates#L37
> 
> I presume that this text is as it is because there is a previously
> defined question about whether one wants a root login enabled, that
> explains the way things will work with sudo if one chooses 'no':
> 
>   
> https://salsa.debian.org/installer-team/user-setup/blob/master/debian/user-setup-udeb.templates#L25
> 
> however, that question is no longer presented to users by default, so
> they get dropped into the rather scary sounding text about why one needs
> to set a root password.
> 
> It seems to me that we need to reword this completely, so that choosing
> to leave the password blank is described as a reasonable thing to do,
> which will result in a perfectly decent, and often desired, sudo setup.

Although I do not see the text as "scary", it might be better to present
the two options on equal standing. OTOH, the question seems to me simply
to say that a user can choose to login as root or with sudo.

It is noted that you leave the advice that the password "...should be
changed at regular intervals" untouched. There is a short discussion in
#868869 about this issue:

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

#656509 received short shrift.

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

Not in your proposal - but how about killing two birds with one stone?

-- 
Brian.

Bug#925105: closed by Steve McIntyre (Re: Bug#925105: CD-ROM is default repository, not mirror)

[Brian Wengel]

I would say It all depends if you select a mirror in the installation
process.
If you DO, I would claim must will prefer and expect it to be used as that
repository..
For those who don't select a mirror,of course the repository should be the
CD-ROM.
By the wayI believe the waste majority use ISO files -> USB flash, not
CD-ROM/DVD.
All in all, the current setup is for the few in favor of the majority, and
that's a wrong priority in my view (I don't have any facts and statistics
to back up my assertions, so I might be wrong).

I had the same battle with the OPNsense community about the old mindset of
CD/DVD (even floppy images).very very few use CD/DVD today, today you
use USB-Flash and net installs.
*I'm not saying CD/DVD shouldn't  be supported*, just don't have a mindset
about this is what most people use. It's not.
This goes for the website, dokumentation and how solutions are designed.
Having CD-ROM as the main repository is a good example.

Best regards
Brian W, Denmark





On Wed, Mar 20, 2019 at 5:42 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> This is an automatic notification regarding your Bug report
> which was filed against the debian-installer package:
>
> #925105: CD-ROM is default repository, not mirror
>
> It has been closed by Steve McIntyre .
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Steve McIntyre <
> st...@einval.com> by
> replying to this email.
>
>
> --
> 925105: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925105
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: Steve McIntyre 
> To: Brian Wengel , 925105-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Wed, 20 Mar 2019 16:38:52 +
> Subject: Re: Bug#925105: CD-ROM is default repository, not mirror
> Hi Brian,
>
> Thanks for your comments!
>
> On Tue, Mar 19, 2019 at 09:35:28PM +0100, Brian Wengel wrote:
> >Package: debian-installer
> >
> >Version: debian-testing-amd64-DVD-1.iso, from 2019-03-16
> >
> >
> >After a clean installation this in the content of the sources.list:
> >
> ># deb cdrom:[Debian GNU/Linux testing _Buster_ - Official Snapshot amd64
> DVD
> >Binary-1 20190311-05:00]/ buster contrib main
> >
> >deb cdrom:[Debian GNU/Linux testing _Buster_ - Official Snapshot amd64 DVD
> >Binary-1 20190311-05:00]/ buster contrib main
> >
> >deb http://deb.debian.org/debian/ buster main
> >
> >deb-src http://deb.debian.org/debian/ buster main
> >
> >deb http://security.debian.org/debian-security buster/updates main
> contrib
> >
> >deb-src http://security.debian.org/debian-security buster/updates main
> contrib
> >
> >
> >I guess you can always argue if this is a bug.
> >But I will claim that by far the waste majority of Debian users want to
> have
> >the selected mirror in the installation to be the primary repository, not
> the,
> >in many ways, useless CD-ROM.
> >Wouldn't it be more fair that the very few that actually want the CD-ROM
> to be
> >the primary repositor, are the one who has to modify the sources.list?
> And not
> >the waste majority of the users.
> >And if they don't, they can just skip selecting a mirror in the
> installation,
> >and then the CD-ROM should be the repository.
>
> We already have logic in the installer in this area. If the user is
> using a netinst image or a live image, then we will *not* keep that
> image as a primary source once the installation is finished. But for
> larger images (DVD, BD) we keep it in the sources.list. It's a
> difficult choice to make reliably for everybody here...
>
> --
> Steve McIntyre, Cambridge, UK.
> st...@einval.com
>   Mature Sporty Personal
>   More Innovation More Adult
>   A Man in Dandism
>   Powered Midship Specialty
>
>
> -- Forwarded message --
> From: Brian Wengel 
> To: sub...@bugs.debian.org
> Cc:
> Bcc:
> Date: Tue, 19 Mar 2019 21:35:28 +0100
> Subject: CD-ROM is default repository, not mirror
>
> Package: debian-installer
>
> Version: debian-testing-amd64-DVD-1.iso, from 2019-03-16
>
>
> After a clean installation this in the content of the sources.list:
>
> # deb cdrom:[Debian GNU/Linux testing _Buster_ - Official Snapshot amd64
> DVD Binary-1 20190311-05:00]/ buster contrib main
>
> deb cdrom:[Debian GNU/Linux testing _Buster_ - Official Snapshot amd64 DVD
> Binary-1 20190311-05:00]/ buster contrib main
>
> deb http://deb.debian.org/

Feature request: Support for QEMU Virtio driver for CD-ROM

[Brian Wengel]

Package: debian-installer

Version: debian-testing-amd64-DVD-1.iso, from 2019-03-16


When installing Debian as a guest in KVM/QEMU assigning the ISO to a CD-ROM
using Virtio or Virtio-SCSI as the bus type the debian-installer cannot see
the CD-ROM drive and ask for drivers.
I assume the Virtio drivers are not bundled/loaded in the installer. It
would be nice if it was :-)

In my benchmark of different bus types for CD-RO I got this read numbers:
-ata/ide: 541MB/s

-sata:  1,2GBs

-Virtio-SCSI:   3,6GB


Unfortunately I didn't test Virtio, but it should be at least just as fast
as the Virtio-SCSI
I've read from RHEL that Virtio is a little faster (at least for HDDs).

Bug#925105: CD-ROM is default repository, not mirror

[Brian Wengel]

Package: debian-installer

Version: debian-testing-amd64-DVD-1.iso, from 2019-03-16


After a clean installation this in the content of the sources.list:

# deb cdrom:[Debian GNU/Linux testing _Buster_ - Official Snapshot amd64
DVD Binary-1 20190311-05:00]/ buster contrib main

deb cdrom:[Debian GNU/Linux testing _Buster_ - Official Snapshot amd64 DVD
Binary-1 20190311-05:00]/ buster contrib main

deb http://deb.debian.org/debian/ buster main

deb-src http://deb.debian.org/debian/ buster main

deb http://security.debian.org/debian-security buster/updates main contrib

deb-src http://security.debian.org/debian-security buster/updates main
contrib

I guess you can always argue if this is a bug.
But I will claim that by far the waste majority of Debian users want to
have the selected mirror in the installation to be the primary repository,
not the, in many ways, useless CD-ROM.
Wouldn't it be more fair that the very few that actually want the CD-ROM to
be the primary repositor, are the one who has to modify the sources.list?
And not the waste majority of the users.
And if they don't, they can just skip selecting a mirror in the
installation, and then the CD-ROM should be the repository.

install log attached.


Debian_install_logs.7z
Description: Binary data

Bug#924760: logfiles...

[Brian Wengel]

Here it is...sorry

(one of many symptoms of this last century bug system...I have to use an
obscure webmail because the bug system doesn't follow good practice of NOT
showing email addresses to the public. Of all people, the Debian techies
should know that)

On Sun, Mar 17, 2019 at 10:37 PM Samuel Thibault 
wrote:

> Brian Wengel, le dim. 17 mars 2019 22:19:57 +0100, a ecrit:
> > The problem seem to be related to XFS filesystem (of the root partition).
> > I hereby attach syslog and partman from the installation.
>
> Mmm, nothing was attached?
>
> Samuel
>


logfiles.7z
Description: application/7z

Bug#924760: logfiles...

[Brian Wengel]

The problem seem to be related to XFS filesystem (of the root partition).
I hereby attach syslog and partman from the installation.

Bug#924760: Grub is extremely picky in regards to partition

[Brian Wengel]

it seems the issue is the XFS root partition. Thought XFS was support by
both Debian and GRUB2?


KVM guest, qcow2 file, 50GB

EFI partiton(1) 300MB

ROOT: 53,4GB, ext4
OK!

EFI partiton(1) 37MB

ROOT: 53,5GB, ext4
OK

EFI partiton(1) 37MB

ROOT: 10GB
ok

EFI: 37MB

ROOT: 10GB, XFS
fail


On Sun, Mar 17, 2019 at 11:50 AM Samuel Thibault 
wrote:

> Control: tags -1 + moreinfo
>
> Hello,
>
> It is hard to understand what issue exactly you had, so we can only try
> to guess...
>
> Brian Wengel, le dim. 17 mars 2019 01:52:17 +0100, a ecrit:
> > I hope the installer could be a little more flexible in regards to  EFI
> > partition,
> [...]
> > Why put a size limit which is way larger than the technical limit?
>
> Which size limit are you talking about?  Which error message do you
> get exactly, at which point of the installation? Please never assume
> anything is obvious in a bug report.
>
> The one I can find in partman-efi, the source code about EFI partitions, is
>
> “
> "EFI System Partitions on this architecture cannot be created with a size "
> "less than 35 MB. Please make the EFI System Partition larger."
> ”
>
> which corresponds to
>
> # Experimentally-verified minimum size for a FAT32 filesystem created using
> # libparted.
>
> i.e. a technical limitation.
>
> I can not find anything in grub-installer. Perhaps the error message you
> are mentioning actually comes from grub, but without knowing the exact
> error message you got, it's very hard to tell.
>
> > But the installer absolutely want a very big partition.
>
> How big did you see it require?
>
> > There might be a technical reason, but I assume is just a matter of
> opinion,
> > right?
>
> By default, assume technical reason, not opinion. Perhaps it's just a
> bug in computing sizes. But without more information of the case you
> encountered, it's hard to determine what went wrong, so we need more
> information.
>
> Samuel
>

Bug#924760: Grub is extremely picky in regards to partition

[Brian Wengel]

Package: debian-installer
Version: Buster, debian-testing-amd64-DVD-1.iso, downloaded 2019-03-16

I hope the installer could be a little more flexible in regards to  EFI
partition, or is it because it require a SWAP partition, haven't been able
to point down the problem. Can only make a successful installation using
automatic.

Why put a size limit which is way larger than the technical limit?
This is Linux, not Apple or Windows!

I believe you can install grub2 on a 5MB FAT16 partition if you prefer.
But the installer absolutely want a very big partition.
There might be a technical reason, but I assume is just a matter of
opinion, right?
It fine it give a warning, but please let the user decide what to do. He
know what is best for him, not you. It is a very paternalistic attitude and
very far from the Linux spirit.

Bug#924730: "No kernel modules were found" using the direct online installer (virsh)

[Brian Wengel]

Package: debian-installer
Version: From testing,
http://httpredir.debian.org/debian/dists/buster/main/installer-amd64/

Installing Debian 10 as KVM/QEMU guest, host Debian 9.

Virsh-install command:
SCIO virt-install \
--virt-type kvm \
--name "Debian10" \
--vcpus 2 \
--memory 2048 \
--boot uefi \
--cpu host \
--os-variant debiantesting \
--features acpi=on \
--location
http://httpredir.debian.org/debian/dists/buster/main/installer-amd64/ \
--disk device=cdrom,bus=scsi \--disk device=disk,path="
/vm/Debian10/disk1.qcow2",format=qcow2,cache=unsafe,discard=unmap,bus=scsi \
--controller type=virtio-serial \
--controller type=scsi,model=virtio-scsi \
--network bridge=brLAN,model=virtio, \
--graphics vnc,port=5904,keymap=local,listen=0.0.0.0 \
--noautoconsole


Error, see attached screen-dump.
The installation went better using the DVD iso file.

Bug#913389: installation-guide: Updating advice for choosing a network mirror (Section 6.3.5.1.3)

[Brian Potkin]

Package: installation-guide
Severity: normal
Tags: d-i patch



The present "6.3.5.1.3. Choosing a network mirror" at

https://www.debian.org/releases/testing/i386/install.txt.en

has four paragraphs. Each paragraph is treated separately in what
follows and the proposals are based on #797340, #907704 and the daily
i386 testing netinst for 2018-11-09.

Paragraph 1
---
Split into two for readability. There should probably be a link to
deb.debian.org.

=== Patch begins ===

If you have selected to use a network mirror during the installation (optional
for CD/DVD/USB installs, required for netboot images), you will be presented 
with a
list of geographically nearby (and therefore hopefully fast) network mirrors
based upon your country selection earlier in the installation process. Choosing
the offered default is usually fine.

The offered default is deb.debian.org, which does not have packages itself, but
the name has SRV records in the DNS that lets apt find places that do, and then 
apt
is redirected to an up-to-date and (hopefully) fast host. Note that this mirror 
also
supports TLS and is under the umbrella of the Debian System Administration 
(DSA) team.

=== Patch ends =


Paragraph 2
---
There isn't any facility to specify a mirror by hand. This paragraph is
redundant if this is intentional.


Paragraph 3
---
I don't know anything about IPv6. If deb.debian.org is IPv6-capable it
could be mentioned in the second half of the first paragraph.

=== Patch begins ===
   

The offered default is deb.debian.org, which does not have packages itself, but
the name has SRV records in the DNS that lets apt find places that do, and then 
apt
is redirected to an up-to-date and (hopefully) fast host. Note that this mirror 
also
supports TLS and takes into account the protocol you connect to it with (if you 
use
IPv6, it will refer you to an IPv6-capable mirror). deb.debian.org is under the
umbrella of the Debian System Administration (DSA) team.

=== Patch ends   ===


Paragraph 4
---
Appears to be redundant.

Regards,

Brian.

Bug#911020: installation-guide: Comments on section D.3

[Brian Potkin]

On Tue 16 Oct 2018 at 23:00:17 +0200, Holger Wansing wrote:

> Hi,
> 
> Brian Potkin  wrote:
> > Please have a look at
> > 
> >   https://lists.debian.org/debian-user/2018/10/msg00438.html
> > 
> > and its followup
> > 
> >   https://lists.debian.org/debian-user/2018/10/msg00448.html
> > 
> > Could changes to advice for /e/n/i and /etc/hosts be considered?
> 
> Getting some sort of a patch for this would speed up the process ...

This is for D.3.4.4. Configure Networking.

8<==8<===

###
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
# See the interfaces(5) manpage for information on what options are
# available and look at the files in /usr/share/doc/ifupdown/examples/.
###

# The loopback interface isn't really required any longer,
# but can be used if needed.
#
# auto lo
# iface lo inet loopback

# To use dhcp:
#
# auto eth0
# iface eth0 inet dhcp

# An example static IP setup: (network, broadcast and gateway are optional)
#
# auto eth0
# iface eth0 inet static
# address 192.168.0.42
# netmask 255.255.255.0
# gateway 192.168.0.1

Enter your nameserver(s) and search directives in /etc/resolv.conf:

# editor /etc/resolv.conf

A simple example /etc/resolv.conf:

search example.com
nameserver 10.1.1.36
nameserver 192.168.9.100

==8<==8<

I hope this is reasonably helpful and sufficient for you to make a
decision.

Regards,

Brian.

Bug#911020: installation-guide: Comments on section D.3

[Brian Potkin]

Package: installation-guide
Severity: normal
Tags: d-i



Please have a look at

  https://lists.debian.org/debian-user/2018/10/msg00438.html

and its followup

  https://lists.debian.org/debian-user/2018/10/msg00448.html

Could changes to advice for /e/n/i and /etc/hosts be considered?

Regards,

Brian.

Bug#861454: console-setup: Have to use setupcon at every boot

[Brian Potkin]

notfound 861454 1.186
thanks



On Sat 29 Apr 2017 at 11:32:13 +0100, Brian Potkin wrote:

> Package: console-setup
> Version: 1.160
> Severity: normal
> Tags: d-i
> 
> 
> Debian (i386) was installed without tasksel's  extra software using the
> RC3 Stretch installer. 'dpkg-reconfigure console-setup' was run after
> the first boot to give
> 
> # CONFIGURATION FILE FOR SETUPCON
> 
> # Consult the console-setup(5) manual page.
> 
> ACTIVE_CONSOLES="/dev/tty[1-6]"
> 
> CHARMAP="UTF-8"
> 
> CODESET="Lat15"
> FONTFACE="TerminusBold"
> FONTSIZE="11x22"
> 
> VIDEOMODE=
> 
> # The following is an example how to use a braille font
> # FONT='lat9w-08.psf.gz brl-8x8.psf'
> 
> in /etc/default/console-setup.
> 
> At every subsequent boot the usual tiny console font is used and setupcon
> has to be used to obtain TerminusBold 11x22.

I brought one of my unstable installations up-to-date today. After a
reboot I noticed that the font was 11x22. That is, I did not have to
run setupcon manually.

I updated another unstable installation but this time upgraded only
systemd-sysv, libpam-systemd and console-setup. After a reboot I got
the usual tiny console font. Completing the upgrade and rebooting
gets me a 11x22 font.

I have no idea what has caused the change in behaviour but this bug
appears to have been fixed in some way.

Regards,

Brian.

Bug#606287: d-i manual: should add a "what is the Debian Installer" section

[Brian Potkin]

On Sun 30 Sep 2018 at 23:28:25 +0200, Holger Wansing wrote:

> Hi,
> 
> Brian Potkin  wrote:
> > On Sun 30 Sep 2018 at 20:18:32 +0200, Holger Wansing wrote:
> > 
> > > 
> > > Miguel Figueiredo  wrote:
> > > > on 1.x add What is the Debian Installer (purpose and scope of the
> > > > installer)
> > > 
> > > I would like to apply the below patch from Miguel, if noone objects:
> > > 
> > > 
> > > 
> > > What is the Debian Installer?
> > > 
> > > 
> > > 
> > > Debian Installer, also known as "d-i", is the software system to install 
> > > a basic working Debian system. A wide range of hardware such as
> > > embedded devices, laptops, desktops and server machines is supported and a
> > > large set of free software for many purposes is offered.
> > > 
> > > 
> > 
> > Looks ok.
> >  
> > > The installation is conducted by answering a basic set of questions.
> > > Also available are an expert mode that allows to control every aspect of 
> > > the installation and an advanced feature to perform automated 
> > > installations.
> > > The installed system can be used as is or further customized.
> > > The installation can be performed from a multitude of sources: USB,
> >   ^
> >number (multitude is a bit more 
> > than 4)   
> > > CD/DVD/Blue Ray or the network.
> > > 
> > > 
> > > 
> > > The installer goes back to the boot-floppies project, and it was
> > 
> >  ^
> >"has its origin in" is an alternative. Nit picking
> 
> Unsure, which one is better...

So am I. "goes back to" implies that the start of d-i was about the
same time when the boot-floppies project existed. "has its origin in"
makes a more causal link in that it says that d-i was developed from
the boot-floppies project.

> > >  > > url="http://lists.debian.org/debian-boot/2000/06/msg00279.html;>first 
> > > mentioned by Joey Hess in 2000 [1]. Since then the installation 
> > > system 
> > > has been continuously developed by volunteers improving and adding more 
> > ^
> >continually (time, not space. I am in a minority.)
> 
> Sorry, I don't understand what is meant with "I am in a minority" ... ?
> Does it mean "Changing 'continuously' into 'continually' is a point to
> discuss about", or is it a sentence which describes why 'continuously' should 
> be
> changed into 'continually'.
> 
> Sorry, language barrier :-)

No, it was entirely my fault; I was too brief in what I said. Forget
I ever said it, please. "continuously" is fine.

-- 
Brian.

Bug#606287: d-i manual: should add a "what is the Debian Installer" section

[Brian Potkin]

On Sun 30 Sep 2018 at 20:18:32 +0200, Holger Wansing wrote:

> 
> Miguel Figueiredo  wrote:
> > on 1.x add What is the Debian Installer (purpose and scope of the
> > installer)
> 
> I would like to apply the below patch from Miguel, if noone objects:
> 
> 
> 
> What is the Debian Installer?
> 
> 
> 
> Debian Installer, also known as "d-i", is the software system to install 
> a basic working Debian system. A wide range of hardware such as
> embedded devices, laptops, desktops and server machines is supported and a
> large set of free software for many purposes is offered.
> 
> 

Looks ok.
 
> The installation is conducted by answering a basic set of questions.
> Also available are an expert mode that allows to control every aspect of 
> the installation and an advanced feature to perform automated installations.
> The installed system can be used as is or further customized.
> The installation can be performed from a multitude of sources: USB,
  ^
   number (multitude is a bit more than 
4)   
> CD/DVD/Blue Ray or the network.
> 
> 
> 
> The installer goes back to the boot-floppies project, and it was

 ^
   "has its origin in" is an alternative. Nit picking

> http://lists.debian.org/debian-boot/2000/06/msg00279.html;>first 
> mentioned by Joey Hess in 2000 [1]. Since then the installation 
> system 
> has been continuously developed by volunteers improving and adding more 
^
   continually (time, not space. I am in a minority.)

> features.
> 
> 
> 
> More information can be found on the  url="http://www.debian.org/devel/debian-installer/;>Debian Installer page
> , on the http://wiki.debian.org/DebianInstalle;>Wiki
>  and on the http://lists.debian.org/debian-boot/;>
> debian-boot mailing list.
> 
> 
> 
>  

-- 
Brian.

Bug#759428: [installation-guide] non-US is no longer existing, so there is also no "export-restricted" software

[Brian Potkin]

On Thu 02 Aug 2018 at 08:34:04 +0200, Holger Wansing wrote:

> Control: tags -1 + pending
> 
> 
> Ben Hutchings  wrote:
> > On Tue, 2018-07-31 at 11:00 +0200, Holger Wansing wrote:
> > > 
> > > diff --git a/en/post-install/orientation.xml 
> > > b/en/post-install/orientation.xml
> > > index 0ec05037f..f3eb00bee 100644
> > > --- a/en/post-install/orientation.xml
> > > +++ b/en/post-install/orientation.xml
> > > @@ -59,10 +59,13 @@ around this by putting packages on 
> > > hold in
> > >  
> > >  
> > >  One of the best installation methods is apt. You can use the command
> > > -line version of apt or full-screen text version
> > > -aptitude.  Note apt will also let you merge
> > > -main, contrib, and non-free so you can have export-restricted packages
> > > -as well as standard versions.
> > > +line version of apt as well as tools like
> > > +aptitude or 
> > > synaptic
> > > +(which are just graphical frontends for apt).
> > > +Note that apt will also let you merge
> > > +main, contrib, and non-free so you can have restricted packages
> > > +(strictly spoken not belonging to ) as well as packages from
> > > + at the same time.
> > >  
> > >  
> > >
> > 
> > Looks good to me.
> 
> Just committed. Tagging this bug as pending

 +Note that apt will also let you merge 
 
 +main, contrib, and non-free so you can have restricted packages   
     
 +(strictly spoken not belonging to ) as well as packages from  
 
 + at the same time.

I would have "strictly speaking not belonging to...". I cannot recollect
seeing "spoken" used in this context.

-- 
Brian.

Bug#615646: [installation-guide] How do I know which CD has the package I need?

[Brian Potkin]

On Sun 29 Jul 2018 at 10:05:51 +, Holger Wansing wrote:

> Hi,
> 
> Am Sonntag, 29. Juli 2018 schrieb Wouter Verhelst:
> > On Sun, Jul 29, 2018 at 07:50:18AM +0200, Holger Wansing wrote:
> > > +Also, keep in mind: if the CDs/DVDs you are using don't contain some 
> > > packages
> > > +you need, you can always install that packages afterwards from your 
> > > running
> > > +new Debian system (after the installation has finished). If you need to 
> > > know,
> > 
> > Drop the comma (you do need it in German, but English doesn't need it)
> 
> Ok. Thanks

For "packages" (plural): that packages ---> those packages.

-- 
Brian.

Bug#615646: [installation-guide] How do I know which CD has the package I need?

[Brian Potkin]

On Sat 28 Jul 2018 at 19:44:26 +0200, Holger Wansing wrote:

> 
> Robert Cymbala  wrote:
> > QUESTION:  
> >I burned the first fifteen (15) CD's and GNU/Emacs, which I want to 
> > install, 
> >is not on them.  How do I find out which CDs I need to burn? (There are 
> > 37 
> >more in cdimage.debian.org/debian-cd/6.0.0/i386/iso-cd/ and I used to 
> > burn 
> >all the CDs for a release but am too lazy to burn all 52 discs this 
> > time, 
> >I only burnt the first 15.)
> 
> Time has changed, we don't provide that big sets of CD images anymore. 
> So the above question is no longer that important.
> 
> However, I would like to add something like the following to chapter 4.1
> (https://d-i.debian.org/manual/en.amd64/ch04s01.html):
> 
> diff --git a/en/install-methods/official-cdrom.xml 
> b/en/install-methods/official-cdrom.xml
> index 512011690..f1f12554d 100644
> --- a/en/install-methods/official-cdrom.xml
> +++ b/en/install-methods/official-cdrom.xml
> @@ -30,6 +30,12 @@ the installation to download the remaining files or 
> additional CDs.
>  
>  
>  
> +Also, keep in mind: if the CD(s) you are using doesn't contain some packages
> +you need, you can always install that packages afterwards from your running
> +new Debian system (after the installation has finished).
> +
> +
> +
>  If your machine doesn't support CD booting (only relevant
>  on very old PC systems), but you do have a CD set,
>  you can use an alternative strategy such as

English (partly), I'm afraid:

CD(s) ---> DVD/CDs (brackets not needed)

doesn't ---> don't

that packages ---> a package

(after the installation has finished) is probably superfluous.

Keep up the good work.

Brian.

Bug#863868: [installation-guide] Re: USB Memory Stick: Issues with win32diskimager

[Brian Potkin]

On Fri 27 Jul 2018 at 19:07:37 +0200, Holger Wansing wrote:

> Hi,

Hi Holger,

[Snip]
 
> So I changed my patch into the following; committing shortly, if noone 
> objects:

No objections from me. Thank you for listening and engaging.

[Snip]

Regards,

Brian.

Bug#863868: [installation-guide] Re: USB Memory Stick: Issues with win32diskimager

[Brian Potkin]

I read the mail in -boot and responded to the list and not to the bug.
Rectifying. Apologies.



On Wed 25 Jul 2018 at 22:55:04 +, Holger Wansing wrote:

> Hi,
> 
> Am Mittwoch, 25. Juli 2018 schrieb Brian Potkin:
> > On Wed 25 Jul 2018 at 21:06:23 +0200, Holger Wansing wrote:
> > 
> > > Hi,
> > > 
> > > Varanka Risto  wrote:
> > > > Package: installation-guide
> > > > Severity: important
> > > > Tags: security
> > > > 
> > > > The online installation guide for Debian Stable at 
> > > > https://www.debian.org/releases/stable/i386/ch04s03.html.en recommends 
> > > > the use 
> > > > of the win32diskimager utility for writing images to USB in section 
> > > > "4.3.1. Preparing a USB stick using a hybrid CD or DVD image". This 
> > > > software 
> > > > currently has issues, might compromise the security of Debian users and 
> > > > probably 
> > > > should not be recommended by Debian:
> > > > 
> > > > 1) User comments on the main page 
> > > > https://sourceforge.net/projects/win32diskimager/ report that the 
> > > > current 
> > > > version 1.0.0 contains malware, or tries to install crapware as part of 
> > > > the 
> > > > installation process. (If possible this should be investigated and if 
> > > > indeed 
> > > > the project is compromised, Debian users should be notified.)
> > > > 
> > > > 2) Some user comments also state the tool does not work on Windows 10 
> > > > while 
> > > > others claim it does. I installed this on a Windows 10 system and the 
> > > > software 
> > > > turned out not to function properly, indicating that 1) might also be 
> > > > the case, 
> > > > and of course majorly impacting Debian installation experience. Details 
> > > > below.
> > > > 
> > > > Navigate to Files->Archive and click on 
> > > > win32diskimager-1.0.0-install.exe. 
> > > > On the following page download starts automatically. Install the tool, 
> > > > run it 
> > > > and provide administrator credentials. Try to select the file to write: 
> > > > the 
> > > > opened file browser does not display almost any directories, and when 
> > > > an .img 
> > > > file is copied to the directories available, it does not show up in the 
> > > > file 
> > > > browser.
> > > > 
> > > > I suggest to replace the recommended tool for the time being and to 
> > > > investigate the trustworthiness of the utility.
> > > 
> > > 
> > > I would like to change it this way, if noone objects:
> > > 
> > > 
> > > diff --git a/en/install-methods/boot-usb-files.xml 
> > > b/en/install-methods/boot-usb-files.xml
> > > index 7f59939d9..13b6e175a 100644
> > > --- a/en/install-methods/boot-usb-files.xml
> > > +++ b/en/install-methods/boot-usb-files.xml
> > > @@ -55,10 +55,9 @@ as follows, after having made sure that the stick is 
> > > unmounted:
> > >  # sync
> > >  
> > >  
> > > -The
> > > -http://sf.net/projects/win32diskimager/;>
> > > -win32diskimager
> > > -utility can be used under other operating systems to copy the image.
> > > +There are also utilities for other operating systems to copy the image, 
> > > like
> > > +https://rufus.akeo.ie/;>Rufus or
> > > + > > url="http://sf.net/projects/win32diskimager/;>win32diskimager.
> > >  
> > >  
> > 
> > So, now we recommend two tools Debian does not control in the
> > Installation Guide. When another post like Varanka Risto's
> > (quoted above) comes along, do we look for a third one? Then a
> > fourth?
> > 
> > Mentioning such software in a core document implies we support
> > it. (Your response is actually a gesture of support for a non-
> > working Debian recommendation).
> > 
> > > +There are also utilities for other operating systems to copy the image.
> > 
> > is factual and covers the situation. Why not go with that? It
> > is neutral and does not commit us to anything, unlike adding
> > a second suggestion.
> > 
> > Specifics can be dealt with at https://www.debian.org/CD/faq/
> > or in the wiki. The Installation Guide is not the place for
> > promoting non-Debian utilities.
> 
> Sorry, I don't get your poin

Re: Bug#863868: [installation-guide] Re: USB Memory Stick: Issues with win32diskimager

[Brian Potkin]

On Wed 25 Jul 2018 at 21:06:23 +0200, Holger Wansing wrote:

> Hi,
> 
> Varanka Risto  wrote:
> > Package: installation-guide
> > Severity: important
> > Tags: security
> > 
> > The online installation guide for Debian Stable at 
> > https://www.debian.org/releases/stable/i386/ch04s03.html.en recommends the 
> > use 
> > of the win32diskimager utility for writing images to USB in section 
> > "4.3.1. Preparing a USB stick using a hybrid CD or DVD image". This 
> > software 
> > currently has issues, might compromise the security of Debian users and 
> > probably 
> > should not be recommended by Debian:
> > 
> > 1) User comments on the main page 
> > https://sourceforge.net/projects/win32diskimager/ report that the current 
> > version 1.0.0 contains malware, or tries to install crapware as part of the 
> > installation process. (If possible this should be investigated and if 
> > indeed 
> > the project is compromised, Debian users should be notified.)
> > 
> > 2) Some user comments also state the tool does not work on Windows 10 while 
> > others claim it does. I installed this on a Windows 10 system and the 
> > software 
> > turned out not to function properly, indicating that 1) might also be the 
> > case, 
> > and of course majorly impacting Debian installation experience. Details 
> > below.
> > 
> > Navigate to Files->Archive and click on win32diskimager-1.0.0-install.exe. 
> > On the following page download starts automatically. Install the tool, run 
> > it 
> > and provide administrator credentials. Try to select the file to write: the 
> > opened file browser does not display almost any directories, and when an 
> > .img 
> > file is copied to the directories available, it does not show up in the 
> > file 
> > browser.
> > 
> > I suggest to replace the recommended tool for the time being and to 
> > investigate the trustworthiness of the utility.
> 
> 
> I would like to change it this way, if noone objects:
> 
> 
> diff --git a/en/install-methods/boot-usb-files.xml 
> b/en/install-methods/boot-usb-files.xml
> index 7f59939d9..13b6e175a 100644
> --- a/en/install-methods/boot-usb-files.xml
> +++ b/en/install-methods/boot-usb-files.xml
> @@ -55,10 +55,9 @@ as follows, after having made sure that the stick is 
> unmounted:
>  # sync
>  
>  
> -The
> -http://sf.net/projects/win32diskimager/;>
> -win32diskimager
> -utility can be used under other operating systems to copy the image.
> +There are also utilities for other operating systems to copy the image, like
> +https://rufus.akeo.ie/;>Rufus or
> +http://sf.net/projects/win32diskimager/;>win32diskimager.
>  
>  

So, now we recommend two tools Debian does not control in the
Installation Guide. When another post like Varanka Risto's
(quoted above) comes along, do we look for a third one? Then a
fourth?

Mentioning such software in a core document implies we support
it. (Your response is actually a gesture of support for a non-
working Debian recommendation).

> +There are also utilities for other operating systems to copy the image.

is factual and covers the situation. Why not go with that? It
is neutral and does not commit us to anything, unlike adding
a second suggestion.

Specifics can be dealt with at https://www.debian.org/CD/faq/
or in the wiki. The Installation Guide is not the place for
promoting non-Debian utilities.

-- 
Brian.

Bug#900058: console-setup: Not keeping font over a reboot

[Brian Potkin]

On Fri 25 May 2018 at 23:37:49 +1200, Chris Bannister wrote:

>* What led up to the situation?
> I rebooted the computer.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> Not sure what is meant by this question, but if I set the font
> via dpkg-reconfigure console-setup then reboot the computer the
> font settings are not kept and I have to do another dpkg-reconfigure
> to get it back.
> 
> Please note that before filing this report I had already done a 
> dpkg-reconfigure console-setup.

See #857132 and its merged bugs.

Regards,

Brian.

Bug#694068: netcfg: Wireless connectivity present during an install but absent afterwards

[Brian Potkin]

On Tue 06 Mar 2018 at 11:07:59 +1100, Trent W. Buck wrote:

> Brian Potkin wrote:
> > The number of users affected by this issue over the years is not
> > insignificant. Not a single one has written in support of the
> > situation.
> 
> This issue has bitten me at least twice so far.
> 
> This issue's history seems to be bogged down on whether interfaces(5)
> can be mode 0600 (to hide the cleartext passphrase).
> This is not necessary; the passphrase can go in a separate file.

Mode 0600 wasn't intially given as a reason:

https://lists.debian.org/debian-boot/2012/09/msg00282.html

 > I realise a default is only a default and the selection can be changed,
 > but I'm puzzled by the third option. Why treat a wireless install
 > differently from a wired install? It would expected that a user who has
 > chosen not to use a wired connection would still want connectivity after
 > booting into into the new system,

   The main reason for this is that as far as I know writing configs
   related to a wireless network to /e/n/i enforce using only that
   particular network later (of course if you don't modify the file) and
   also that the interface is unmanageable for other tools. The idea was
   to leave the network unconfigured, so that it can be managed later
   (perhaps via something else than NM).

Later in the thread:

https://lists.debian.org/debian-boot/2012/09/msg00313.html

 > On the other hand, we have users who chose not to install a desktop
 > environment but want their machine to migrate between networks when it's
 > moved. These users are going to need to do some form of sysadmin work
 > post-install, whether it's installing a desktop environment and wicd, or
 > editing /etc/network/interfaces on each fresh network, or bringing up
 > wifi connections by hand. So I can't see locking a default into
 > /etc/network/interfaces causing them much bother.

   IIRC we decided on this default before we added the code to change the
   access mode of /e/n/i if it contains a password. The main reason for
   defaulting to no configuration in this case was to avoid having
   passwords in there. If people think it should default to ifupdown in
   this case this can be changed.

The default (loopback only for wireless) was added without considering
mode 0600. At this stage in the history there appears to be a willingness
to use ifupdown and not loopback.

> Here is a minimal config, assuming WPA2 PSK (not Enterprise) and DHCP (not 
> static) for all SSIDs:
> 
> cat >/etc/network/interfaces < allow-auto lo $iface
> iface lo inet loopback
> iface default inet dhcp
> iface $iface inet manual
>   wpa-roam /etc/wpa_supplicant/wpa_supplicant-$iface.conf
> EOF
> 
> wpa_passphrase "$ssid" "$passphrase" 
> >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf"
> chmod 0600 "/etc/wpa_supplicant/wpa_supplicant-$iface.conf"
> 
> If you don't want to udebify wpa_passphrase, you can do it by hand:
> 
> cat >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf" < network={
>   ssid="$ssid"
>   psk="$passphrase"
> }
> EOF
> 
> If you really hate ifupdown, you can use systemd instead (not fully tested):
> 
> cat >/etc/systemd/network/$iface.network < [Match]
> iface=$iface
> [Network]
> DHCP=yes
> EOF
> 
> systemctl enable wpa_supplicant@$iface.service
> 
> wpa_passphrase "$ssid" "$passphrase" 
> >"/etc/wpa_supplicant/wpa_supplicant-$iface.conf"
> chmod 0600 "/etc/wpa_supplicant/wpa_supplicant-$iface.conf"
> 
> If even these things are too much, can you AT LEAST install
> wpasupplicant?  Writing config files is much easier than ferrying
> .debs between computers by USB key.
> 
> If this bug is going to be kept ANOTHER Debian release, can you at
> least warn people about it in the buster Installation Guide?

Or dispense with loopback for an installation over wireless (an easy
enough change) and warn about 0600 in the Release Notes.

-- 
Brian.

Bug#694068: (solved) Re: wireless fail after stretch installation

[Brian]

On Tue 06 Mar 2018 at 18:34:27 +, Ian Jackson wrote:

> bw writes ("Re: (solved) Re: wireless fail after stretch installation"):
> > I think the idea needs to be talked over a little better, because using 
> > e/n/i for wireless by default after first boot has implications if the 
> > user (who is clueless) later installs a desktop environment.
> 
> If installing a desktop environment, after putting the wireless in
> /e/n/i, does not work, then that is a bug in the desktop environment,
> surely ?

Most probably. But desktop environments were not the subject of this
thread. (Sorry for trying to keep on-topic).

> In practice I would expect the config in /e/n/i to keep working
> because nowadays network-manager will ignore things in /e/n/i.  The
> difficulty would only come if you
>   - used the installer to install a bare system over wifi

That difficulty is  exactly the subject of this thread. The rest of this
post is snipped because it side-steps addressing the issue. What is put
in /e/n/i ceases to work because it is obliterated by the installer for
reasons unknown.

One user calls it a "sick joke". After five years and with no attempt
to rectify the situation, I'm beginning to have sympathy with that view.

(Yes, I know we are all volunteers).

-- 
Brian.




>   - later install network-manager or wicd
>   - then expect the system to give you a gui prompt for new wifi
> networks, rather than expect to have to edit /e/n/i
> 
> It would be possible for the n-m and wicd packages to spot when this
> is happening and offer to take over the interface.  And I do think
> that in the absence of code to do that, it would be more important to
> make the barebones system work in the first place, than to improve the
> behaviour you later install n-m.
> 
> (I'm not sure if what I say about wicd is right.  I use n-m on
> machines I have where the user needs to switch between various network
> connections, wifi networks, etc.)
> 
> > I'd hate to see the bug tracker turned into a discussion forum though.  
> 
> The bug tyracker is precisely the right place to discuss how to solve
> a particular bug.  So I have CC'd it.
> 
> Ian.
> 
> -- 
> Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.
> 
> If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
> a private address which bypasses my fierce spamfilter.
> 

Bug#694068: netcfg: Wireless connectivity present during an install but absent afterwards

[Brian Potkin]

On Fri 23 Nov 2012 at 14:31:20 +, Brian Potkin wrote:

> I installed in expert mode over a wireless link from
> 
> Debian GNU/Linux testing "Wheezy" - Official Snapshot i386 NETINST Binary-1 
> 20121122-21:21
> 
> This ISO has netcfg_1.102. Only "Standard system utilities" was selected
> as a task. Re-booted as instructed. No network! Checked the contents of
> /etc/network/interfaces. The only interface available is lo. I'm still
> in a state of shock. :)

[...]

The number of users affected by this issue over the years is not
insignificant. Not a single one has written in support of the
situation.

https://lists.debian.org/debian-user/2018/03/msg00066.html

has the latest experiences of three users.

Regards,

Brian.

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Brian Potkin]

On Mon 11 Dec 2017 at 17:46:44 +, Steve McIntyre wrote:

> On Mon, Dec 11, 2017 at 06:20:55PM +0100, Christian PERRIER wrote:
> >Quoting Raymond Burkholder (r...@oneunified.net):
> >> > > So, as an accommodation,  a flag in the preseed mechanism to
> >> > enable/disable would be helpful.  
> >> > 
> >> > You mean something like:
> >> > 
> >> > Template: pkgsel/update-policy
> >> > Type: select
> >> > Default: unattended-upgrades
> >> > 
> >> > pkgsel/update-policy=none thus seem the perfect preseed choice for your
> >> > use case.
> >> > 
> >> 
> >> Yes, thank you, that works for me.
> >> 
> >> Is there a dictionary somewhere where I can look these things up?  From
> >> where did you get your Template extract?
> >
> >No, there is no such dictionary. Sadly, documenting all possible
> >presseding options really lacks a dedicated effort. There was one, in
> >the past, when the D-I team was much bigger, and, still the
> >Installation Guiide does document the most important options, but
> >those that have been "recently" added ("recentlly" means "last years")
> >shoudl be added there.
> >
> >I got the template extractfrom the package source itself (pkgsel
> >package, here).
> 
> As a trivial lookup, sources.debian.net will show all the template
> files in Debian:
> 
>   
> https://codesearch.debian.net/search?q=Template%3A+path%3Adebian%2F.*.template
> 
> but it's a large set in just sid: ("761 files grepped (4453 results)")...

apt-extracttemplates is a useful utility in apt-utils. For a set of
udebs

  apt-extracttemplates -t $PWD *.udeb

will extract any templates files in the udebs.

  rm *.config.*

deletes unneeded files.

All that is needed for a "dictionary" is to tidy up the templates files.
Perhaps

  
https://wiki.debian.org/DebianInstaller/Preseed#Preseeding_and_the_installer.27s_debconf_templates

helps?

-- 
Brian.

Re: Run debootstrap twice

[Brian Potkin]

On Wed 16 Aug 2017 at 20:29:17 +0200, Philipp Kern wrote:

> On 16.08.2017 17:38, Sven Schiffner wrote:
> > I don't know if it's a bug or a feature but I'm not able to run debootstrap
> > twice in the same directory. I mean run debootstrap after a successfull run
> > of debootstrap. So is this possible or not?
> 
> Nope. And unfortunately you also don't seem to state why this should
> work in the first place.

And, also unfortunately, you don't say why it is not possible. Talk
about information underload!

-- 
Brian.

Bug#868869: debian-installer should not recommend to change password periodically (and more)

[Brian Potkin]

On Wed 26 Jul 2017 at 17:00:12 +0100, Miguel Figueiredo wrote:

> On 24-07-2017 11:38, Hideki Yamane wrote:
> >Hi,
> >
> >On Sun, 23 Jul 2017 10:49:53 +0200
> >Philipp Kern <pk...@debian.org> wrote:
> >>It seems to me that today at least the guidance of mixed
> >>character classes still makes some sense as a default, to avoid the most
> >>obvious blunder of just using a simple dictionary word and be
> >>compromised over SSH because password authentication is turned on.
> >
> >  Okay, I agree with it.
> >
> >>And change it to make brute force attacks harder.
> >
> >  But it also makes administrator to remember it harder as its trade-off...
> >  (and they maybe choose easy password as a result). It's a not good idea
> >  to suggests to change root password periodically, IMO. It's not a best
> >  practice.
> >
> >  1) Add password check feature whether password has an enough strength
> > like RHEL's anaconda or SUSE's installer.
> >  2) Drop suggestion root password change periodically from message.
> >
> >  is better.
> 
> We have libpam-passwqc on the archive, which it's a "Password
> quality-control PAM module".
> I think it addresses the point of checking the password strength.

It possibly does, but isn't it more suitable as a solution to
#854653 or #364526 rather than this bug (changing a password at
periodic intervals, no matter how strong it is)?

-- 
Brian.

Bug#868869: debian-installer should not recommend to change password periodically (and more)

[Brian Potkin]

On Tue 25 Jul 2017 at 23:22:19 +0200, Philipp Kern wrote:

> On 07/24/2017 12:38 PM, Hideki Yamane wrote:
> >  But it also makes administrator to remember it harder as its trade-off...
> >  (and they maybe choose easy password as a result). It's a not good idea
> >  to suggests to change root password periodically, IMO. It's not a best
> >  practice.
> 
> I'd say it's one of two things: If it's easy, make sure to change it
> periodically. If it's hard enough to withstand brute-force, you don't
> need to.
> 
> As I said: I'm totally with you that in a standard setup it'd great for
> that not to be necessary. Unfortunately the standard setup does not ship
> with the mitigating controls.

Do you (or anyone else) change the locks on your car or front door
at regular intervals? This is really the gist of the OP's report.
Poor passwords stay poor. Good passwords do not deteriorate over
time, so why change them? (Periodically changing one poor password
for another poor password is an interesting idea).

The question has been asked before; #656509.

  Christian PERRIER says:

Are you ready to handle the round of updates for over
sixty languages, for a very debatable and cosmetic change?

I am not, sorry.

  Cyril Brulebois says:

Neither am I, so I'll just close this bug report for now.

It is a nice debating point but I am inclined to go along with this
assessment when it comes to the installer. Nobody takes any notice
of the advice anyway and there are far more important things to
attend to. Let this report suffer the same fate as the previous one,

-- 
Brian.

Bug#866629: debian-installer: Installer showes Debootstrap Error debian stretch live installation

[Brian Potkin]

On Thu 06 Jul 2017 at 02:13:57 +0530, Prahlad Yeri wrote:

> On Wed, 5 Jul 2017 20:24:20 +0100
> Brian Potkin <claremont...@gmail.com> wrote:
> 
> > On Thu 06 Jul 2017 at 00:35:21 +0530, Prahlad Yeri wrote:
> > 
> > > Can confirm this bug on the live installer - tried both XFCE and
> > > LXDE versions.
> > > 
> > > Never expected such goof up on a debian stable version!
> > > Granted that its just released, but we do go through ages of testing
> > > before reaching stable, don't we? The reason a user comes to debian
> > > in the first place is stability. If you don't even get that, then
> > > what is the rationale for using debian stable against something
> > > like Ubuntu LTS where you get both stability and newer packages?  
> > 
> > Your question (after the rhetorical first one) is probing. Debian has
> > never had bugs before. We do not know how this managed to creep in. We
> > will try better.
> 
> Sorry, didn't intend to hurt your feelings, just trying to raise my
> concerns as a user and trying to understand the process. I don't know
> how the testing process works at debian, but If I were making the point
> release of a distro, one of the basic things I'd check is whether the
> ISO installs work on an actual physical machine (not in a VM) - and
> doing so would have helped catch this bug as there are usually no
> network resources (like wifi, etc.) configured at boot time that could
> have provided internet connectivity (in which case, it used to work and
> the bug wasn't apparent).

I subscribe to and read -user, where quite a large number of posts have
recently discussed the state of installing from a live image. I have
also seen reports of the efforts being made to mitigate the situation,
particularly by Steve McIntyre. So I became a bit grumpy, a mood which
is not good when contributing to a bug report. Apologies if I gave the
impression user contributions are unwelcome.

Perhaps

  https://lists.debian.org/debian-devel/2017/06/msg00335.html

brings some perspective to the matter. The more users who use live
images and report bugs in the pre-release phase, the better the image
quality will become.

-- 
Brian.




> 
> I understand that bugs are a part of the linux distro life cycle, but
> I did not expect something as basic as an install process to falter.
> But again, maybe I'm wrong about the bug being so apparent, and its
> just easy to say this in hindsight.
> 
> No offence meant, have a nice day!
> 
> -- 
> Regards,
> Prahlad

Bug#866629: debian-installer: Installer showes Debootstrap Error debian stretch live installation

[Brian Potkin]

On Thu 06 Jul 2017 at 00:35:21 +0530, Prahlad Yeri wrote:

> Can confirm this bug on the live installer - tried both XFCE and LXDE
> versions.
> 
> Never expected such goof up on a debian stable version!
> Granted that its just released, but we do go through ages of testing
> before reaching stable, don't we? The reason a user comes to debian in
> the first place is stability. If you don't even get that, then what is
> the rationale for using debian stable against something like Ubuntu LTS
> where you get both stability and newer packages?

Your question (after the rhetorical first one) is probing. Debian has
never had bugs before. We do not know how this managed to creep in. We
will try better.

Bug#863868: USB Memory Stick: Issues with win32diskimager

[Brian Potkin]

On Fri 02 Jun 2017 at 17:08:37 +0100, Steve McIntyre wrote:

> On Fri, Jun 02, 2017 at 06:45:33AM +0200, Cyril Brulebois wrote:
> >Hi,
> >
> >and thanks for your report.
> >
> >Varanka Risto  (2017-06-01):
> >> Package: installation-guide
> >> Severity: important
> >> Tags: security
> >> 
> >> The online installation guide for Debian Stable at
> >> https://www.debian.org/releases/stable/i386/ch04s03.html.en recommends
> >> the use of the win32diskimager utility for writing images to USB in
> >> section "4.3.1. Preparing a USB stick using a hybrid CD or DVD image".
> >> This software currently has issues, might compromise the security of
> >> Debian users and probably should not be recommended by Debian:
> >> 
> >> 1) User comments on the main page
> >> https://sourceforge.net/projects/win32diskimager/ report that the
> >> current version 1.0.0 contains malware, or tries to install crapware
> >> as part of the installation process. (If possible this should be
> >> investigated and if indeed the project is compromised, Debian users
> >> should be notified.)
> >
> >ISTR sf.net tends to do that for Windows binaries, and this might not be
> >specific to win32diskimager.
> >
> >> 2) Some user comments also state the tool does not work on Windows 10
> >> while others claim it does. I installed this on a Windows 10 system
> >> and the software turned out not to function properly, indicating that
> >> 1) might also be the case, and of course majorly impacting Debian
> >> installation experience. Details below.
> >> 
> >> Navigate to Files->Archive and click on
> >> win32diskimager-1.0.0-install.exe. On the following page download
> >> starts automatically. Install the tool, run it and provide
> >> administrator credentials. Try to select the file to write: the opened
> >> file browser does not display almost any directories, and when an .img
> >> file is copied to the directories available, it does not show up in
> >> the file browser.
> >> 
> >> I suggest to replace the recommended tool for the time being and to
> >> investigate the trustworthiness of the utility.
> >
> >Any recommendations for alternative software?
> 
> My own recommendation now would be Rufus, in dd mode.

My recommendation would be for nothing to be recommended. Changing it on

a year by year is hardly inspiring. Debian should not be *recommending* 

software it has no control over; especially in the Manual. The CD FAQ   

seems geared up for promoting guidance for other OSs.  Why not use that?



(Some of the issues raised in the OP are probably a load of nonsense so,

on the basis the devil you know is better than the one you don't, stick 

with win32diskmanager if it highly desirable to promote utilities of

this nature within official documentation).

Re: Bug#863868: USB Memory Stick: Issues with win32diskimager

[Brian Potkin]

On Fri 02 Jun 2017 at 17:08:37 +0100, Steve McIntyre wrote:

> On Fri, Jun 02, 2017 at 06:45:33AM +0200, Cyril Brulebois wrote:
> >Hi,
> >
> >and thanks for your report.
> >
> >Varanka Risto  (2017-06-01):
> >> Package: installation-guide
> >> Severity: important
> >> Tags: security
> >> 
> >> The online installation guide for Debian Stable at
> >> https://www.debian.org/releases/stable/i386/ch04s03.html.en recommends
> >> the use of the win32diskimager utility for writing images to USB in
> >> section "4.3.1. Preparing a USB stick using a hybrid CD or DVD image".
> >> This software currently has issues, might compromise the security of
> >> Debian users and probably should not be recommended by Debian:
> >> 
> >> 1) User comments on the main page
> >> https://sourceforge.net/projects/win32diskimager/ report that the
> >> current version 1.0.0 contains malware, or tries to install crapware
> >> as part of the installation process. (If possible this should be
> >> investigated and if indeed the project is compromised, Debian users
> >> should be notified.)
> >
> >ISTR sf.net tends to do that for Windows binaries, and this might not be
> >specific to win32diskimager.
> >
> >> 2) Some user comments also state the tool does not work on Windows 10
> >> while others claim it does. I installed this on a Windows 10 system
> >> and the software turned out not to function properly, indicating that
> >> 1) might also be the case, and of course majorly impacting Debian
> >> installation experience. Details below.
> >> 
> >> Navigate to Files->Archive and click on
> >> win32diskimager-1.0.0-install.exe. On the following page download
> >> starts automatically. Install the tool, run it and provide
> >> administrator credentials. Try to select the file to write: the opened
> >> file browser does not display almost any directories, and when an .img
> >> file is copied to the directories available, it does not show up in
> >> the file browser.
> >> 
> >> I suggest to replace the recommended tool for the time being and to
> >> investigate the trustworthiness of the utility.
> >
> >Any recommendations for alternative software?
> 
> My own recommendation now would be Rufus, in dd mode.

My recommendation would be for nothing to be recommended. Changing it on
a year by year is hardly inspiring. Debian should not be *recommending*
software it has no control over; especially in the Manual. The CD FAQ
seems geared up for promoting guidance for other OSs.  Why not use that?

(Some of the issues raised in the OP are probably a load of nonsense so,
on the basis the devil you know is better than the one you don't, stick
with win32diskmanager if it highly desirable to promote utilities of
this nature within official documentation).

Bug#861454: console-setup: Have to use setupcon at every booty

[Brian Potkin]

On Sat 29 Apr 2017 at 17:40:46 +0300, Anton Zinoviev wrote:

> On Sat, Apr 29, 2017 at 03:35:08PM +0100, Brian Potkin wrote:
> 
> Then it seems this is a duplicate of the misterious bug #857132.

I did look at #857132 and thought it to be a little different from
what I wanted to report. A misjudgement on my part, leading to extra
work for you. Thank you for your timely response. I'll probably end
up putting 'setupcon' in ~/.bashrc.

-- 
Brian.

Bug#861454: console-setup: Have to use setupcon at every boot

[Brian Potkin]

On Sat 29 Apr 2017 at 17:02:21 +0300, Anton Zinoviev wrote:

> On Sat, Apr 29, 2017 at 11:32:13AM +0100, Brian Potkin wrote:
> > 
> > Debian (i386) was installed without tasksel's  extra software using the
> > RC3 Stretch installer. 'dpkg-reconfigure console-setup' was run after
> > the first boot to give
> > 
> > CODESET="Lat15"
> > FONTFACE="TerminusBold"
> > FONTSIZE="11x22"
> > 
> > in /etc/default/console-setup.
> 
> What about /etc/console-setup/cached_setup_font.sh?

root@cupsexp:~# cat /etc/console-setup/cached_setup_font.sh

#!/bin/sh

setfont '/etc/console-setup/cached_Lat15-TerminusBold22x11.psf.gz'

if ls /dev/fb* >/dev/null 2>/dev/null; then
for i in /dev/vcs[0-9]*; do
{ :
setfont '/etc/console-setup/cached_Lat15-TerminusBold22x11.psf.gz'
} < /dev/tty${i#/dev/vcs} > /dev/tty${i#/dev/vcs}
done
fi

mkdir -p /run/console-setup
> /run/console-setup/font-loaded
for i in /dev/vcs[0-9]*; do
{ :
printf '\033%%G'
} < /dev/tty${i#/dev/vcs} > /dev/tty${i#/dev/vcs}
done

> Something unusual about the kernel?  Read-only file systems?  With or 
> without systemd?

Apart from configuring the console font (and installing gpm and less)
the system is as described earlier - a minimal installation without
the standard utilities or a DE.

Yes, it has systemd. However, I note that the one unstable machine I
have with sysvinit does not exhibit this issue.

-- 
Brian.

Bug#861454: console-setup: Have to use setupcon at every boot

[Brian Potkin]

Package: console-setup
Version: 1.160
Severity: normal
Tags: d-i


Debian (i386) was installed without tasksel's  extra software using the
RC3 Stretch installer. 'dpkg-reconfigure console-setup' was run after
the first boot to give

# CONFIGURATION FILE FOR SETUPCON

# Consult the console-setup(5) manual page.

ACTIVE_CONSOLES="/dev/tty[1-6]"

CHARMAP="UTF-8"

CODESET="Lat15"
FONTFACE="TerminusBold"
FONTSIZE="11x22"

VIDEOMODE=

# The following is an example how to use a braille font
# FONT='lat9w-08.psf.gz brl-8x8.psf'

in /etc/default/console-setup.

At every subsequent boot the usual tiny console font is used and setupcon
has to be used to obtain TerminusBold 11x22.

Regards,

Brian.

Re: Bug#854801: Bug#740998: Bug#854801: No network after netinst Stretch RC2

[Brian Potkin]

On Thu 16 Feb 2017 at 14:10:08 +0100, Bernhard Schmidt wrote:

> On 14.02.2017 00:43, Pierre Ynard wrote:
> 
> Hi,
> 
> >> in finish-install /e/n/i will never be properly populated for a wireless
> >> installation without network-manager, although I think ifupdown would be
> >> capable to do this (not tested, but have a look at
> >> https://anonscm.debian.org/cgit/d-i/netcfg.git/tree/write_interface.c).
> >> I guess the justification is that people using wireless usually would
> >> want a GUI to roam between networks, and a interface stanza would
> >> prevent even a (later installed) network-manager from touching the
> >> interface.
> > 
> > That makes sense. Maybe it could still output commented-out
> > configuration into /e/n/i, to make it easier in case people do end up
> > editing the file to set up their network, for whatever reason.
> 
> We already have several bugs for this behaviour:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=694068
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727740
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777439
> 
> and likely more.
> 
> Users installing with a wireless connection do not have network after
> first boot, unless a -desktop task pulls in network-manager _and_
> network-manager is not blocked by rdnssd.
> 
> I can fix the latter by removing the conflicts and changing the hook
> again to be a no-op if network-manager is installed. But I think a
> proper solution would be to warn the user at the end of the installation
> that he will not have network access after boot and offer to write a
> complete /e/n/i or forcibly install network-manager .

My suggestion for a warning at the end of the installation (if it ever
came about) would be:

  You have chosen to install a bare minimum of Debian over WiFi and
  think the network configuration will be carried over to the installed
  system. We think you are kidding and really want to start again from
  scratch. So that's what you are getting - no connectivity at first
  boot. Good luck. [No, we will not explain the rationale underpinning
  this decision].

I've given up on this and simply preseed to get what I want. 

Forcibly installing network-manager? Why not just give the user what he
wants - a working network?

-- 
Brian.

Re: All D-I's debconf templates in a single HTML page.

[Brian Potkin]

On Thu 08 Sep 2016 at 00:37:15 +0200, Cyril Brulebois wrote:

> Hi Charles,
> 
> Charles Plessy <ple...@debian.org> (2016-09-06):
> > while working on preseeding D-I to make Cloud images, I found it a bit
> > difficult to figure out the details of this and that debconf template that 
> > is
> > listed in the preseed.txt example of the installation guide.  Therefore, I
> > collated them in a single HTML page.
> > 
> > https://people.debian.org/~plessy/DebianInstallerDebconfTemplates.html
> > 
> > I would be very intereted to have some feedback on how useful this is, and 
> > if
> > there would be a more relevant place or format to hold this information.
> 
> As others have already said: looks like very useful. Not sure where to
> make it available at the moment though (in the middle of a very busy
> couple of months, and preparing for the next point release).

I have put links to Charles' script and its output on

  https://wiki.debian.org/DebianInstaller/Preseed

and also added three new sections based on a smartened-up version of my
own work. The focus is on all installer debconf templates in one text
file.

-- 
Brian.

Re: All D-I's debconf templates in a single HTML page.

[Brian Potkin]

On Wed 07 Sep 2016 at 16:42:32 +0100, Ian Campbell wrote:

> On Tue, 2016-09-06 at 21:18 +0900, Charles Plessy wrote:
> > 
> > I would be very intereted to have some feedback on how useful this is, and 
> > if
> > > there would be a more relevant place or format to hold this information.
> 
> Seems like it could be very useful, thanks!
> 
> Might be worth filtering out the non-question stuff, i.e. "text" and
> "error" types which AFAIK are the contents of various dialog boxes and
> not questions. Not sure if there are others in the same category (I
> didn't see any).

Your suggested filtering is not unreasonable but there could be some
benefit in leaving them there (with a note that they obviously cannot be
preseeded) because one then has a complete list of template options on
which to make decisions.

I'd be more concerned about

  netcfg/target_network_config (select)
  for internal use; can be preseeded Specifies what kind of network
  connection management tool should be configured post-installation if
  multiple are available. Automatic selection is used in this order when
  not specified: network-manager if available (on Linux only), ethernet
  configuration through ifupdown on wired installation and loopback
  configuration through ifupdown on wireless installations.
  Choices:
  Default: 

The netcfg templates file has Choices-C and and its omission reduces the
usefulness of this section. There cannot be a default (and one isn't
mentioned) because what is done depends on what is installed and how it
is done.

Again:

  netcfg/link_wait_timeout (string)
  Waiting time (in seconds) for link detection: Please enter the maximum
  time you would like to wait for network link detection.

This has a (missing) "Default: 3".

Everything in one place is certainly useful but, as a simple user, I
have to wonder about the simplicity of reproducing it confidently with
ease.

-- 
Brian.

Re: All D-I's debconf templates in a single HTML page.

[Brian Potkin]

On Tue 06 Sep 2016 at 21:18:58 +0900, Charles Plessy wrote:

> Hello everybody,

Hello Charles,

> while working on preseeding D-I to make Cloud images, I found it a bit
> difficult to figure out the details of this and that debconf template that is
> listed in the preseed.txt example of the installation guide.  Therefore, I
> collated them in a single HTML page.
> 
> https://people.debian.org/~plessy/DebianInstallerDebconfTemplates.html
> 
> I would be very intereted to have some feedback on how useful this is, and if
> there would be a more relevant place or format to hold this information.

>From the perspective of a user I find this very useful. Usually I look
at the templates file in a udeb and try to figure it out from there.
This puts puts almost everything on one page. I say almost everything
because Choices, Choices-C and Default isn't always filled in.

I'd say a wiki page would be a suitable place for your work. Something
which would try to remove the obfuscation in the official documentation
and make debconf and preseeding accessible to interested users.

-- 
Brian

Bug#833525: debootstrap: Deleted my entire /home partition using "mostly harmless" debootstrap --print-debs option

[Brian Drummond]

On Fri, 2016-08-05 at 17:15 +0200, Johannes Schauer wrote:
> Control: tag -1 + patch
> 
> On Fri, 05 Aug 2016 13:55:14 +0100 Brian Drummond <bri...@shapes.demo
> n.co.uk> wrote:
> > 
> > *** Reporter, please consider answering these questions, where
> > appropriate ***
> > 
> > 8) I said this was embarassing...
> > 
> >    * What exactly did you do (or not do) that was effective (or
> >  ineffective)?
> > debootstrap --print-debs /chroot/i386
> > 
> if I understand correctly, the problem is two-fold:
> 
>  - debootstrap removes everything in a directory even if there was
> stuff in it
>    beforehand (this should not happen)
> 
>  - debootstrap removes recursively across filesystem boundaries (how
> was this
>    not noticed earlier?)
> 
> The following patch should fix this:

Thank you! 

If I understand the patch, it should have the desired effect.

I find myself strangely reluctant to test it ... may I
be forgiven?

(I know ... why don't I just chroot into a safe place and test it
there? :-)

Hopefully it will be accepted into Debian and stop somebody else making
such a fool of themselves...

Thanks again!

-- Brian

Bug#833525: debootstrap: Deleted my entire /home partition using "mostly harmless" debootstrap --print-debs option

[Brian Drummond]

Package: debootstrap
Version: 1.0.81
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
0) Okay, this will be embarrassing...
1) Occasional need to work on i386 software on an x86-64 machine.
2) Previous experiment led to a marginally usable "minimal"  /chroot/i386 
partition (without internet connection)
3) Desire to add internet connection to same, start by listing packages which 
would be installed by "debootstrap --print-debs"
4) Failure to understand that "debootstrap --print-debs" operated by performing 
the entire debootstrap operation, 
listing packages, then deleting the created directory, despite a note in the 
manfile to that effect.
5) Further failure to note that such deletion would apply recursively to any 
automounted partitions in said created directory. 
6) Previous experiment involved automounting /proc, /sys, /var/tp, and /home 
into said /chroot/i386 partition.
7) Re-using the /chroot/i386 directory name in the "debootstrap --print-files" 
command. Without the --keep-bootstrop-dir option, since I was about to replace 
it.
8) I said this was embarassing...

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Sadly, I no longer have my exact notes, as will become clear. But 
approximately, the command was (possibly with sudo, or after su):
debootstrap --print-debs /chroot/i386

   * What was the outcome of this action?
Well I briefly saw the list of packages flash past, before debootstrap got to 
the "The TARGET directory will be deleted" part.
At which point various strange things started happening, until it gradually 
dawned on me that /home and /var/tmp were slowly disappearing before my eyes...

   * What outcome did you expect instead?

Somehow I expected to be left with a list of .deb packages and a functioning 
computer. I now understand my expectations were unrealistic.

Perhaps I have been punished enough ... and perhaps it would be a good idea to 
modify the bit of debootstrap that implements 
"The TARGET directory will be deleted" and convince it to stop at 
automounted partitions in /etc/fstab (and/or mtab)?

It is too late for me, but it might be very pleasing to some future unwary 
operators to be left with their /home partition intact... 

(NB the packages/versions listed below apply to a reinstall, not the exact 
formerly-running system, for reasons that are hopefully clear)

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages debootstrap depends on:
ii  wget  1.18-1

Versions of packages debootstrap recommends:
ii  debian-archive-keyring  2014.3
ii  gnupg   1.4.20-6

debootstrap suggests no packages.

-- no debconf information

Re: debian-installer issues with no wireless network connection after a text based Jessie installation

[Brian Potkin]

On Fri 20 May 2016 at 01:54:02 -0500, Nick Gawronski wrote:

> prompts but then once the Debian system rebooted no internet settings were
> on the system in the /etc/network/interfaces or any other wifi packages that
> were installed such as wpa_supplicant.  My question is why does the

Are you certain wpa_supplicant was not on the system? If the machine has
no ethernet connection you now have problems.

> installer not copy over the wireless networking settings from the installer
> to the target system when doing a text only install with speech?  Nick
> Gawronski

It happens with any install. The thinking appears to be:

You used a wired install without selecting a desktop task. That means
you wanted a wired connection after the install.

You used a wired or wireless connection and selected a desktop task.
That means you wanted to use networkmanager.

That's ok up to there. There is some practical sense in it. You will
have connectivity after the first boot and can change what you want.

If you used a wireless onnection and did not select a desktop task
that means you want to select and set up your connectivity software
after first boot. Basically - you were just kidding when you used
wireless to install Debian; you didn't want immediate connectivity
afterwards.

Setting up wireless all over again is good fun when your passphrase
has 63 characters. Copy and paste? You could download gpm but

That is one of the reasons I preseed.

Regards.

Brian.

Re: debian-installer issues with no wireless network connection after a text based Jessie installation

[Brian Potkin]

On Thu 19 May 2016 at 23:52:57 -0500, Nick Gawronski wrote:

> Hi, I am using the net installer of Jessie version 8.0.0 that includes the
> firmware as I am totally blind and found that the latest installer once it
> was installed I had no software speech after installing the system.  I was
> installing Debian Jessie on my laptop with just a text based system mainly
> for a rescue system for when X windows is down and for times when I don't
> wish to use X windows.  I found that during the installation I was able to
> connect to the internet and successfully install the system but once the
> system was rebooted I had no internet access over any network method.  What
> would it take for the debian installation to copy the network settings from
> the installer to the target system as it makes no sence why networking would
> be setup and working during a text based installation but not in the target
> system?  What file should I edit to add my wireless network as well as my
> wired network using DHCP so they both will work when my text based system
> boots?  Nick Gawronski

I preseed this in a file with

  d-i netcfg/target_network_config select ifupdown

The same outcome should be possible with an installer boot parameter:

  netcfg/target_network_config=ifupdown

should do it (I think).

The wired network could be added after booting into the new system;
unless you want to do it by preseeding a late_command.

Regards,

Brian.

Bug#824645: task-print-server: Please reconsider the dependencies of this package

[Brian Potkin]

Package: task-print-server
Version: 3.34
Severity: wishlist
Tags: d-i



cups and cups-client are Depends:. However, cups depends on cups-client
and has done so since version 1.3.10-3. From the changelog:

 [ Till Kamppeter ]

 [...snip...]

  * debian/control: Moved dependency on cups-client to Depends:, as 
   
cups-client is needed by the post-install script for the update of the  
   
PPDs of existing print queues.

I would also query cups-bsd as a Depends: (or even as a Recommends:).
cups itself has it as a Suggests: and command line printing is well
covered by the System V utilities in cups-client.

Regards,

Brian.

Re: Should apt-transport-https be Priority: Important ? (Re: own cloud task in tasksel?)

[Brian Gupta]

On Mon, Mar 14, 2016 at 9:26 PM, Charles Plessy <ple...@debian.org> wrote:
> Le Mon, Mar 14, 2016 at 10:34:14PM +0800, James Bromberger a écrit :
>>
>> No, not using any cml line params. My manifets has:
>>   install:
>>   - awscli
>>   - python-boto
>>   - python3-boto
>>   - apt-transport-https
> [...]
>
> Hi again James and everybody,
>
> With the worldwide effort of using HTTPS everywhere, I wonder if
> apt-transport-https shouldn't be installed by default anyway on systems with
> network connectivity, that is, its priority should be Important.  What do
> people think about this ?  Would it make sense to raise the question on
> debian-devel ?
>
> Cheers,
>
> --
> Charles

Charles,

If you think this makes sense, I'd raise it on debian-devel, and move
the debate there.

Going to all https is a worthy goal, especially now that Let's
Encrypt has been launched.

-Brian

P.S. - I am in favor of your proposal.

Bug#814553: Not possible to use arch armhf with debboostrap > 1.0.76

[Brian Murray]

Package: debootstrap
Version: 1.0.78
Severity: normal #http://www.debian.org/Bugs/Developer#severities
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial

I discovered that I was no longer able to use mk-sbuild to create armhf
chroots with deboostrap version 1.0.78. The process ends with the
following:

I: Extracting zlib1g...
I: Running command: chroot /tmp/schroot-XJCj5b /debootstrap/debootstrap
--second-stage
I: Keyring file not available at
/usr/share/keyrings/ubuntu-archive-keyring.gpg; switching to https
mirror https://mirrors.kernel.org/debian

Manually running the chroot and debootstrap command listed above ends
with the same error even when using the --verbose switch.  Downgrading
debootstrap to version 1.0.75 fixes the issue and using 1.0.76 recreates
it. So it seems to be an issue caused by the changes between 1.0.75 and
1.0.76. Here is the full mk-sbuild command I'm using.

DEBOOTSTRAP_MIRROR=http://ports.ubuntu.com mk-sbuild --vg=virtual-vg
--arch armhf --name snapper vivid

--
Brian Murray @ubuntu.com


signature.asc
Description: Digital signature

Re: Cloud images with backports APT-enabled.

[Brian Gupta]

On Mon, Dec 28, 2015 at 9:19 AM, Charles Plessy <ple...@debian.org> wrote:
> Le Mon, Nov 30, 2015 at 10:31:14PM +0900, Charles Plessy a écrit :
>>
>> I started a discussion on the debian-backports mailing list.  Let's see how 
>> it
>> goes.
>>
>> <https://lists.debian.org/debian-backports/2015/11/msg00067.html>
>
> Hello everybody,
>
> To summarise the original question:
>
> some Debian Stable images prepared by us for some "cloud" systems contain a 
> few
> hand-picked packages from stable-backports (or from testing or unstable, in
> which case the creation of a stable backport could be considered).  To provide
> a path for security and bug upgrades, the most straightforward way is to add
> the stable-backports suite to APT's source list.  This means that some users
> may install backported packages without realising it.  The Debian Backports
> package states "Backports cannot be tested as extensively as Debian stable, 
> and
> backports are provided on an as-is basis, with risk of incompatibilities with
> other components in Debian stable. Use with care!".  Therefore, it is
> controversial whether using and enabling Backports is appropriate for an image
> that we call "Stable", and we wondered if something could be changed on APT's
> side to prevent unintentional installation of backports.
>
> First, let's recapitulate how APT installs backports.
>
> The current behaviour of APT with the Backports suites is a logical 
> consequence
> of its design, and is actually not specific to backports.  For instance,
> similar phenomena can be observed with the "experimental" suite.
>
> When the "install" command is called for a package, APT will consider the
> versions available from the suites listed as APT data sources, plus the 
> locally
> installed package if any.  Following some rules explained in the
> apt_preferences manpage, each version receives a priority ("pin values"), and
> APT will either install one of the highest-priority versions or do nothing.
> Installing and upgrading a package are done with the same command ("install"),
> following the same set of rules: from APT's point of view, there is no
> conceptual difference.  Likewise, there is nothing special about installing a
> package from the backports suite without having selected it explicitely.
>
> Thus, if a package in stable-backports has the highest priority, it will be
> installed.  The default priorities in backports suites are set to be lower 
> than
> the default priorities in stable suites, but if there is no package available
> locally or from a stable suite, the backports can be the best valid candidate,
> and therefore be installed.
>
> About the user interface.
>
> It is assumed that if the user typed "apt install foo", the user will be
> satisfied with the installation of "foo".  I think that this is a core point 
> of
> disagreement in the discussion on whether backports can be enabled by default
> or not.
>
> There is interest in the APT team to "make it (more) easy to rate a solution 
> by
> displaying more information".  Depending on the user impact (including the 
> fact
> that they also use aptitude and other front-ends), this may open the way to
> enable backports by default on stable systems.  There is no timeline, but
> obviously, contributions to APT development are most welcome.
>
> In conclusion:
>
> We are not going to enable backports by default in the short term, but I hope
> that some readers, like me, strenghtened their understanding on how APT works.
>
> Thanks everybody for following so far, and have a happy new year !
>
> --
> Charles
>

Charles, great summary! I'm now wondering if cloud-init might be a candidate
for "stable-updates"?

The criteria  [1] are:
- The update is urgent and not of a security nature. Security updates
will continue to be pushed through the security archive. Examples
include packages broken by the flow of time (c.f. spamassassin and the
year 2010 problem) and fixes for bugs introduced by point releases.
- The package in question is a data package and the data must be
updated in a timely manner (e.g. tzdata).
- Fixes to leaf packages that were broken by external changes (e.g.
video downloading tools and tor).
- Packages that need to be current to be useful (e.g. clamav).

It seems to me that at least a couple of these criteria fit for cloud-init.

Thoughts?

-Brian

[1] - https://www.debian.org/News/2011/20110215

Bug#759657: console-setup w/ systemd forgets font setting

[Brian Potkin]

On Thu 10 Dec 2015 at 03:47:24 +0100, Michael Biebl wrote:

> Am 10.12.2015 um 00:55 schrieb Samuel Thibault:
> > Eric Cooper, on Thu 19 Nov 2015 13:31:57 -0500, wrote:
> >> While booting, it looks like the font switches from VGA to Terminus
> >> during the boot messages.  But then the screen is cleared and the
> >> getty login prompts are back in VGA.  If I run "setupcon" manually, it
> >> changes to Terminus.
> > 
> > So it seems like something is resetting the font back to VGA (and it's
> > not console-setup, which loads Terminus).
> > 
> > systemd people, do you have any idea?  This has started happening with
> > the switch to systemd.
> 
> From a cursory look, it doesn't seem to be caused by systemd itself but
> it's a race condition and the way console-setup works. And the timing
> under systemd might simply the different then under sysvinit (it's
> usually faster).
> 
> When Karsten added the dependency on udev settle, it probably just
> changed the timing (by delaying it a little) so made it less likely to
> happen.
> 
> It might be, that loading the KMS module resets the font.
> So maybe console-setup should run when hardware shows up.
> This is a shot in the dark, but can you try and create the following
> udev rules file:
> 
> $ cat /etc/udev/rules.d/90-setupcon.rules
> ACTION=="add", SUBSYSTEM=="vtconsole", KERNEL=="vtcon*",
> RUN+="/bin/setupcon"

This file does it for me up to now. After about 10 reboots the font is
not being reset back to VGA.

Regards,

Brian.

Re: WiFi During Install

[Brian Potkin]

On Mon 14 Sep 2015 at 17:06:30 +0200, Cyril Brulebois wrote:

> Jamie Nunnery <m...@jamienunnery.com> (2015-09-14):
> > Over the weekend I installed Jessie on a netbook.  All checkboxes were
> > unchecked except for at the bottom for Standard Linux Tools (so no GUI).
> > During setup, I was able to connect to Wifi, but after installation, Debian
> > forgot all the settings, and I had to reconfigure WiFi.  I wish that Debian
> > remembered those WiFi settings from the initial installation, so that we
> > don't have to configure WiFi twice because the first thing I want to do
> > after install is use apt as quickly as possible.  Thank you for taking the
> > time to read my message and thank you for all the time you invest in Debian.
> 
> Settings ought to be propagated to the installed system; since that
> doesn't seem to have worked in your case, please file an installation
> report so that someone can try and investigate. Instructions are at:
>   https://www.debian.org/releases/stable/amd64/ch05s04.html#problem-report

I think the behaviour described by Jamie is intended. Please see #694068.

Regards,

Brian.

Bug#796474: busybox: mishandles non-hash lines in sha512sum and friends

[brian m. carlson]

Package: busybox-static
Version: 1:1.22.0-15
Severity: normal

I have an OpenPGP-signed file that contains lines produced by
sha512sum[0].  Running sha512sum -c on it exits 0, noting the
improperly-formatted lines:

  vauxhall ok % LC_ALL=C sha512sum -c SHA512SUMS; echo $?
  0223b187.asc: OK
  README.adoc: OK
  README.xhtml: OK
  otr.adoc: OK
  otr.xhtml: OK
  ssh-keys.txt: OK
  sha512sum: WARNING: 20 lines are improperly formatted
  0

However, busybox's sha512sum exits 1:

  vauxhall no % LC_ALL=C busybox sha512sum -c SHA512SUMS; echo $?
  0223b187.asc: OK
  README.adoc: OK
  README.xhtml: OK
  otr.adoc: OK
  otr.xhtml: OK
  ssh-keys.txt: OK
  sha512sum: WARNING: 20 of 26 computed checksums did NOT match
  1

Furthermore, it claims that there were 20 computed checksums that did
not match, which is untrue and misleading.  As there were no
corresponding files, it did not compute any checksums for those lines,
and all the checksums it did compute did, in fact, match.

OpenPGP clearsigning hash files is not uncommon; for example, kernel.org
does it[1].  busybox's sha512sum (and sha256sum, etc.) should exit 0 on
success even in the face of ill-formed lines, and it should accurately
reflect that those lines were ill-formed and not lead the user to
believe that there was a mismatch when there was not.

[0] Available at https://www.crustytoothpaste.net/~bmc/keys/
[1] https://www.kernel.org/pub/software/scm/git/sha256sums.asc

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=es_US.UTF-8, LC_CTYPE=es_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Bug#785512: regression: cannot find iso image on usb stick any more

[Brian Potkin]

On Mon 01 Jun 2015 at 00:51:58 +0900, Norbert Preining wrote:

 Hi Brian,

Hello Norbert,

 On Sat, 30 May 2015, Brian Potkin wrote:
  On the other hand, #785512 is reporting a regression between the
  Jessie installer and some random, unknown, testing version for which
  documentation of any intentional change is lacking. Note that it is not
 
 Well, it is not *completely* unknown, it was this file:
 http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/daily-builds/sid_d-i/current/amd64/iso-cd/firmware-testing-amd64-netinst.iso
 on/around 2014-05.
 
 So I wouldn't say this is random, unknown etc ...
 
  a regression compared with the Wheezy installer, which is also unable
  to take advantage of GRUB's loopback facility.
 
 It is not about GRUB's loopback facility, but the missing
   iso-scan
 package in current installers. It don't know whether this packages
 was loaded in wheezy or not, but it was loaded in the above one.

I do not know why a testing image should behave differently from the
realeased Wheezy and Jessie images. I have a recollection I experienced
something similar with a Wheezy testing image but put it down to things
coming and going during the testing period.

  There are at least three ways to boot a netinst ISO from a USB stick. An
 
 Hmm, I didn't find *one* that leaves the sstick useable for other things,
 and allows to boot into a variety of other rescue iso images etc
 at the same time. Please let me know which one?

Surely the method you describe on your blog and the use of the hd-media
method allows this? Another method is to partition the stick. The grub
directory and the ISO images to use with loopback can be on the larger
partition. Then dd the firmware ISO to the second partition and boot it
with a stanza like

  menuentry Debian 8.0.0 i386 netinst with firmware {
  search --label --set=root Debian 8.0.0 i386 1
  linux /install.386/vmlinuz
  initrd /install.386/initrd.gz
  }
 
 (Fat16 - was that a joke on the current jessie installer images about
 needing fat16 on the usb stick? The options explained on
 https://www.debian.org/releases/stable/i386/ch04s03.html.en
 are all either destructive of previous data, or don't play well as
 carry on sticks for the emergency case, nor nor nor. )

Unlike ext* modules the fat and vfat modules are available from the very
start of the install.

  additional one based on GRUB's loopback would be nice. All have their
  advantages and disadvantages but installing Debian successfully without
  the tedium and in a controlled manner is still possible without it.
 
 Is there a reason why iso-scan is *not* loaded?

The author of iso-scan has this to say:

  iso-scan is part of the Debian installer[1].
 
  However, it is only included in the hd-media initrd. There is no reason
  to include it on the regular CD initrd, because isohybrid allows
  mounting the USB stick directly. (Not a loop-mount of an iso file
  included in some disk, which the hd-media initrd handles.)

   https://lists.debian.org/debian-boot/2013/09/msg00097.html

Regards,

Brian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150601125209.ga6...@copernicus.demon.co.uk

Bug#785512: regression: cannot find iso image on usb stick any more

[Brian Potkin]

On Sat 30 May 2015 at 11:19:17 +0200, Christian Kastner wrote:

 On Fri, 29 May 2015 12:32:13 +0900 Norbert Preining prein...@logic.at
 wrote:
   It looks to me as though we're missing iso-scan and load-iso from the
   cdrom target, and that as a result we neither include the loop module,
   nor do we attempt to mount the usb stick, nor look for the ISO therein.
  
  Indeed, checking the initrd you mentioned I see the iso-scan and load-iso
  packages available, while in the initrd from current image
  it is not.
 
 I believe this issue (or a variant of it) was already reported as #618000.

#618000 and this bug are related (both involve the kernel module loop.ko
being in the initrd) but they are not the same issue. #618000 is an
enhancement request for D-I. #724931 could be viewed as an attempt to
move the issue to a conclusion.

On the other hand, #785512 is reporting a regression between the
Jessie installer and some random, unknown, testing version for which
documentation of any intentional change is lacking. Note that it is not
a regression compared with the Wheezy installer, which is also unable
to take advantage of GRUB's loopback facility.

 A fix in the ISO would be great. I used as similar workaround as the one
 you mentioned in your blog post, but that quickly became tedious
 (assuming one updates the stick at every point release, too).

There are at least three ways to boot a netinst ISO from a USB stick. An
additional one based on GRUB's loopback would be nice. All have their
advantages and disadvantages but installing Debian successfully without
the tedium and in a controlled manner is still possible without it.

Regards,

Brian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/30052015191143.c5939e408...@desktop.copernicus.demon.co.uk

Bug#775814: installation-guide: Advise users against using unetbootin

[Brian Potkin]

On Tue 20 Jan 2015 at 23:25:14 +1100, Stuart Prescott wrote:

 Elsewhere (#775689), there has been a discussion of some of the problems
 that unetbootin can pose when used with Debian install media. It would be
 great to better document these problems and warn users against copying
 images to USB sticks with unetbootin rather than having these problems exist
 only in folklore.

Any reason why the CD FAQ would not be the right and proper place for
this documentation? After all, it already contains advice for users of
other OSs on how to burn an image to a CD.

 The attached patches takes a stab at doing this as well as being a little
 more explicit about which images the user can use on the USB stick (since
 that is also a FAQ in #debian).

[Snip]

 * Advise users not to use unetbootin

The Guide is for describing *how* to install Debian, not for how not to
install it. The CD FAQ would appear to be ideal for such advice.

 * Suggest win32diskimager as an alternativee to unetbootin

A similar suggestion to recommend software in the Guide over which
Debian has no control met with a distinct lack of enthusiasm. Please see
#692309.

Regards,

Brian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/22012015145502.75977aeee...@desktop.copernicus.demon.co.uk

Bug#705971: debian-installer hangs when tty console in use (console-setup)

[Brian Minton]

Package: console-setup
Version: 1.116
Followup-For: Bug #705971

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

I'm still seeing this issue.  Here's some of the output of ps auxfw,

root 28645  0.0  0.0  72564  3416 pts/15   S08:50   0:00  \_ su -
root 28654  0.0  0.1  20564 10656 pts/15   S08:50   0:00  \_ -su
root 29271  2.8  3.4 276576 262800 pts/15  S+   08:58   0:01  
\_ dpkg -i console-setup_1.116_all.deb
root 29272  0.0  0.0  13184  2828 pts/15   S+   08:58   0:00
  \_ /bin/bash -c (test -x /usr/lib/needrestart/dpkg-status  
/usr/lib/needrestart/dpkg-status || cat  /
dev/null)
root 29273  0.0  0.0  13188  2328 pts/15   S+   08:58   0:00
  |   \_ /bin/bash -c (test -x /usr/lib/needrestart/dpkg-status  
/usr/lib/needrestart/dpkg-status || cat
  /dev/null)
root 29274  0.0  0.0   4328   760 pts/15   S+   08:58   0:00
  |   \_ /bin/sh /usr/lib/needrestart/dpkg-status
root 29292  1.1  0.4  86200 34028 pts/15   S+   08:59   0:00
  \_ /usr/bin/perl -w /usr/share/debconf/frontend 
/var/lib/dpkg/info/console-setup.postinst configure
root 29357  0.0  0.0  0 0 pts/15   Z+   08:59   0:00
  \_ [console-setup.p] defunct

- -- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages console-setup depends on:
ii  console-setup-linux 1.116
ii  debconf 1.5.55
ii  keyboard-configuration  1.116
ii  xkb-data2.12-1

console-setup recommends no packages.

Versions of packages console-setup suggests:
ii  locales2.19-13
ii  locales-all [locales]  2.19-13
ii  lsb-base   4.1+Debian13+nmu1

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.55
ii  initscripts 2.88dsf-58
ii  liblocale-gettext-perl  1.05-8+b1

Versions of packages console-setup-linux depends on:
ii  kbd 1.15.5-2
ii  keyboard-configuration  1.116

console-setup-linux suggests no packages.

Versions of packages console-setup is related to:
ii  console-common  0.7.88
ii  console-data2:1.12-5
pn  console-tools   none
ii  kbd 1.15.5-2

- -- debconf information:
* keyboard-configuration/variant: English (US)
  debian-installer/console-setup-udeb/title:
  keyboard-configuration/store_defaults_in_debconf_db: true
  keyboard-configuration/unsupported_config_layout: true
  keyboard-configuration/optionscode: compose:ralt,terminate:ctrl_alt_bksp
* keyboard-configuration/altgr: The default for the keyboard layout
  keyboard-configuration/unsupported_layout: true
  keyboard-configuration/xkb-keymap: us
  keyboard-configuration/switch: No temporary switch
* keyboard-configuration/ctrl_alt_bksp: true
  keyboard-configuration/layoutcode: us
  keyboard-configuration/unsupported_options: true
  keyboard-configuration/layout:
  keyboard-configuration/modelcode: pc104
* keyboard-configuration/compose: Right Alt (AltGr)
* keyboard-configuration/model: Generic 104-key PC
  keyboard-configuration/variantcode:
  keyboard-configuration/unsupported_config_options: true
  keyboard-configuration/toggle: No toggling
  keyboard-configuration/other:

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iF4EAREIAAYFAlSRkNQACgkQa46zoGXPuql3ugD/Tw8UbET/2uox/hytiC2EBlEV
EaJrDtrTXjA4KTPplEcA/iDOOgLXd7gQngP6JrgMwr98dGhkdJP3AoYKixGdMIBq
=QgNW
-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: 
https://lists.debian.org/20141217141915.29831.54790.report...@bminton.is-a-geek.net

Bug#764587: installation-reports: After successful installation from usb stick the stick is not recognised on reboot.

[Brian Potkin]

Hello Philip,

I'm assuming that since you did not CC the bug that this is intended to
be a private mail.


On Wed 26 Nov 2014 at 18:22:52 +1300, Philip Charles wrote:

 
  I have a USB stick that is used for installing Wheezy and which is
  recognised on reboot. Instead of writing DVD1 to the stick I do the
  following:
  
  1. Have a FAT16 partition spanning the whole stick. Format as vfat.
  
  2. Install GRUB in the MBR and copy the hd-media vmlinuz and initrd.gz
 to /boot and write a grub.cfg to boot from them. Copy DVD1 to /.
  
  3. Copy the files in /pool on DVD1 to /debian on the stick. Create a
 packages file in /debian. We now have a mirror which can be used
 during and after the install.
  
  4. Install, preseeding with a late_command for tasks. A few lines of
 mine in that command are
  
   mkdir /target/media/usbmount; \
   mount --bind /hd-media /target/media/usbmount; \
   sed -i 's/^/#/' /target/etc/apt/sources.list; \
   echo deb [ trusted=yes ] file:/media/usbmount/debian wheezy main  
  /target/etc/apt/sources.list
  
  5. Install additional software after the install by mounting the mirror
 on /media/usbmount.
 
 What I do is to hack /etc/apt/apt.conf.d/00CDMountPoint
 to read,
 Acquire::cdrom {
 mount /media/usb;
 }
 Dir::Media::MountPath /media/usb;
 
 where usb was cdrom.  Then the the system looks for the installation
 media at the usb port.

I originally did something like this with the first eight CD images and
used apt-cdrom. The user user experience with having to mount and
unmount different images wasn't (IMO) the best, so I re-thought the
issue.

I have a script, apt-usb. A user types 'apt-usb cups' and is prompted to
insert the stick. Re-issuing the command mounts the stick, installs the
packages and unmounts the stick. apt-usb is copied to /target during the
initial install.

Regards,

Brian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/26112014104930.7571abec1...@desktop.copernicus.demon.co.uk

Bug#764587: installation-reports: After successful installation from usb stick the stick is not recognised on reboot.

[Brian Potkin]

On Tue 25 Nov 2014 at 22:11:48 +1300, Philip Charles wrote:

 On Thu, 2014-10-09 at 23:32 +1300, Philip Charles wrote:
  Package: installation-reports
  Severity: normal
   After successful installation from usb stick the stick is not
  recognised on reboot.
  
  Boot method: usb stick
  Image version: beta 2 installer amd64 DVD1 (copied to usb stick)
  Date: Oct 2014
 
 From a email sent to me,
 One of my friends works for an NGO and is based in rural parts of Asia
 and Latin America for about 10 months of the year. He told me that most
 of the machines were second-hand and had faulty DVD drives. Moreover DVD
 discs are prone to scratches and wear-and-tear. On the other hand USB
 flash drives are ubiquitous and relatively inexpensive. Even used
 machines have at least a USB port.
 
 I have produced complete 32  64 bit installation sticks for wheezy
 (~43GB) and Jessie (~55GB) which fit nicely on a 64GB stick.  However,
 the stick is of limited use because the stick cannot be accessed after
 the initial installation which means that additional software cannot be
 installed.

I have a USB stick that is used for installing Wheezy and which is
recognised on reboot. Instead of writing DVD1 to the stick I do the
following:

1. Have a FAT16 partition spanning the whole stick. Format as vfat.

2. Install GRUB in the MBR and copy the hd-media vmlinuz and initrd.gz
   to /boot and write a grub.cfg to boot from them. Copy DVD1 to /.

3. Copy the files in /pool on DVD1 to /debian on the stick. Create a
   packages file in /debian. We now have a mirror which can be used
   during and after the install.

4. Install, preseeding with a late_command for tasks. A few lines of
   mine in that command are

 mkdir /target/media/usbmount; \
 mount --bind /hd-media /target/media/usbmount; \
 sed -i 's/^/#/' /target/etc/apt/sources.list; \
 echo deb [ trusted=yes ] file:/media/usbmount/debian wheezy main  
/target/etc/apt/sources.list

5. Install additional software after the install by mounting the mirror
   on /media/usbmount.

Regards,

Brian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141126011939.ga6...@copernicus.demon.co.uk

Re: Old-timer installer, task-sysvinit?

[Brian Potkin]

On Sun 23 Nov 2014 at 20:36:42 +, Philip Hands wrote:

 If you want a way to do a non-shell based preseed, you _may_ be able to
 get away with some combination of these:
 
 =-=-=-=-
 Template: base-installer/includes
 Type: string
 Description: for internal use; can be preseeded
  Packages to be included in base installation

I've used this and it works. There do not appear to be any drawbacks and
it seems a good method.
 
 Template: base-installer/excludes
 Type: string
 Description: for internal use; can be preseeded
  Packages to be excluded in base installation

I think needs fixing for this to work.
 
 Template: pkgsel/include
 Type: string
 Description: for internal use; can be preseeded
  Comma/space-separated list of extra packages to install
 =-=-=-=-

Tried it once and it worked. I prefer base-installer/includes or a
late_command.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/23112014223722.e2b5977f7...@desktop.copernicus.demon.co.uk

Re: Old-timer installer, task-sysvinit?

[Brian Potkin]

On Sun 23 Nov 2014 at 22:43:53 +, Brian Potkin wrote:

 I think needs fixing for this to work.
 ^
   #668001   


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/23112014224510.026b22256...@desktop.copernicus.demon.co.uk

Re: UltraHD installation: partitioning step shows installation media too

[Brian Potkin]

On Fri 21 Nov 2014 at 16:07:52 +0100, Eugen Dedu wrote:

 I am installing debian amd64 on a Lenovo Y50 with UltraHD 3840x2160
 resolution.  I use today's debian-testing...iso from 
 http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd.
 
 I chose for partitioning: guided – use entire disk.  It shows there
 choices: the disc, and the two partitions/discs of the USB stick.
 As I am installing debian from the USB stick itself, I think it
 should not show the USB stick as disc to install linux on (or at
 least show them in grey).

Not showing the USB stick when using mini.iso would be a disadvantage
if it was the only medium available to install to. Greying it out
seems to present no advantage.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/21112014221526.a78e27a5d...@desktop.copernicus.demon.co.uk

LVM installer: select percentage of VG to use

[Brian Candler]

In the current Debian installer[1], if you select Guided Partitioning 
with LVM, the entire volume group is allocated for filesystems and swap.


This means you lose much of the flexibility of LVM (e.g. being able to 
choose which filesystems to extend later, or being able to create new 
logical volumes).  You could reclaim space later by shrinking one of the 
filesystems/LVs, but this is relatively painful as it must be done off-line.


This pretty much forces you to do a long-winded manual install if you 
want to leave space in your volume group, e.g. see[2]

https://nsrc.org/workshops/2014/wacren-virtualization/raw-attachment/wiki/Agenda/ex-debian-kvm-libvirt.htm#partitioning

The Ubuntu installer fixed this by asking the user what percentage of 
the volume group to use. This simple feature is a huge improvement.


Is there any chance this feature could be ported into Debian? Has this 
been discussed before?


Thanks,

Brian Candler.

[1] I've just re-tested this with Jessie Beta 1, and the behaviour is 
unchanged


[2] This is from a virtualization workshop using Debian as the base 
platform. We need to leave space in the volume group for creating 
logical volumes for virtual machines, with Ganeti. Today we have to make 
students do the whole long-winded process of creating logical volumes 
for root, swap and /var by hand.



--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/542fb007.50...@pobox.com

Bug#763072: How/Where to file a feature request

[Brian]

On Mon 29 Sep 2014 at 12:48:58 -0400, Philippe Clérié wrote:

 On 09/27/2014 01:27 PM, Lisi Reisz wrote:
 
 I have looked at the bug report, and I would suggest that it may be
 misphrased.  Keyboard selection is already in the installer.  I always choose
 a standard UK keyboard and would struggle to install without it.  What is
 missing apparently is the actual one you want.  Keyboard selection comes
 after language selection.  Presumably (and I am guessing here) you choose US
 English and are just given a US keyboard but the wrong one, rather than the
 list of keyboards to select from that we British English choosers get.
 
 Lisi
 
 
 
 You know, you have forced me to re-evaluate what I thought I knew.
 
 It appears that the Debian installer _does not_ have a Keymap
 variant selection dialog, even in expert mode. Even dpkg-reconfigure
 keyboard-configuration does not seem to do anything, while in Ubuntu
 you get to do some more customization of the keyboard.

You may want to evaluate keeping your report open in the light of reading
#698322:

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


With 'dpkg-reconfigure keyboard-configuration' I see two international
keyboard layouts. Both are under Englis (US).


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/29092014191428.8d2b952b0...@desktop.copernicus.demon.co.uk

Bug#751704: bug#18289: libparted ped_disk_clobber() overwrites firmware on some arm systems

[Brian C. Lane]

On Thu, Aug 28, 2014 at 12:06:21AM +0200, Karsten Merker wrote:
 On Mon, Aug 18, 2014 at 10:07:59PM +0200, Karsten Merker wrote:
 
  You are fully right that normally a bootloader should be
  installed after partitioning.  This works well for the case of a
  bootloader that uses universally available BIOS functions and is
  not hardware-specific, such as is the case on PCs.  In the case
  of u-boot on the other hand, in PC-lingo we would have to provide
  the installer with the ability to flash the BIOS for every PC
  model on the market as part of the operating system installation,
  which is not feasible.  We might be able to do that for a small
  selection of devices, but not for all of them -- we need to keep
  the u-boot image that is on the device even when creating a new
  disklabel, but we are unsure what is the best way to handle this.
  
  The approach in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704#60
  (setting PedDisk.needs_clobber to 0 before calling ped_disk_commit
  for specific devices) works in practice, but the question was
  whether it is ok for the calling application to fiddle around with
  the needs_clobber flag, or whether we should take some other
  approach.
 
 Hello Brian,
 
 may I ping you again regarding the last paragraph? The question
 whether this approach is ok from a libparted point of view is
 still open and I would very much apprechiate your feedback on it.

Oops, sorry about that. I think that's probably ok. I'm not sure what
other option you have.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140827221646.gd2...@lister.brianlane.com

Bug#673715: [d-i manual] doc about creating a bootable Debian usb stick

[Brian Potkin]

On Sat 23 Aug 2014 at 18:54:14 +0200, Holger Wansing wrote:

 Bug report boot.img now creates a 1 GB filesystem, no longer 256 MB
 
 The mentioned changings are already fixed in the manual.
 
 
 But the increase of the boot.img leads to another change in the d-i manual.
 
 4.3.3. Manually copying files to the USB stick — the flexible way says:
   One advantage of using this method is that — if the capacity of your 
   USB stick is large enough — you have the option of copying a full 
   CD ISO image to it. 
 
 This is no longer true, since also the 'easy way' method documented in
 4.3.2. Manually copying files to the USB stick now allows to copy
 full CD images, because of the 1G filesystem.

I'd see the contrast as between an inflexible 1GB filesystem and one
which can be any chosen size

Perhaps

  ...you have the option of copying a full CD or DVD ISO image to it.

or

  ...you have the option of copying an ISO image of any size to it.

would suit?


Regards,

Brian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/24082014094241.ebc5f5d1a...@desktop.copernicus.demon.co.uk

Bug#673715: [d-i manual] doc about creating a bootable Debian usb stick

[Brian Potkin]

On Sun 24 Aug 2014 at 19:24:48 +0200, Holger Wansing wrote:

 +USB stick is large enough mdash; you have the option of copying any
 +ISO image, even a DVD image to it.

Could you tolerate an extra comma?

   +USB stick is large enough mdash; you have the option of copying any
   +ISO image, even a DVD image, to it.

Sorry to nitpick.

Regards,

Brian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/24082014223634.08db4c74d...@desktop.copernicus.demon.co.uk

Bug#485586: debian-installer: Default to graphical install

[Brian Potkin]

On Mon 18 Aug 2014 at 23:07:11 +0200, Holger Wansing wrote:

 I have prepared a patch for this (attached) and I would like to receive some 
 thoughts on it. 
 I have added Samuel Thibault in CC, since he has also some knowledge and
 interest on the d-i manual.
 
 Basically I moved the chapter Appendix D.6. The Graphical Installer to
 5.1.8 (at the end of Booting the installer on 32-bit PC), leaving the
 content unchanged.

Defaulting to a graphical (gtk) frontend on i386 and amd64 would mean
that it becomes the regular frontend, unless it is desired to credit the
newt frontend with some special status.

In the context of Section 5.3.2. there is a difference between the
text and newt frontends. But for many users the distinction is lost
and the present regular frontend as presented in the user interface is
a text one.

 And I moved chapter Appendix D.6.1. Using the graphical installer to
 6.1.1 (at the end of How the Installer Works), leaving the content
 mostly unchanged (only the first line differs).

Section 6.1 uses character-based instead of text. It would be nice
to have some consistency in referring to the alternative to the default
graphical installation.

  For a normal installation, select either the quoteInstall/quote or
  the quoteGraphical install/quote entry  mdash; using either the
  arrow keys on your keyboard or by typing the first (highlighted) letter, the
 -quoteInstall/quote entry is already selected by default mdash; and press
 +quoteGraphical install/quote entry is already selected by default 
 mdash; and press
  enterkey; to boot the installer.

I'd restructure that to draw attention to the default highlighting and
to have it read better.

  For a normal installation, select either the “Install” or the “Graphical 
install”
  entry — using either the arrow keys on your keyboard or by typing the first
  (highlighted) letter — and press Enter to boot the installer. The entry 
Graphical
  install is already selected by default.
  
 +The graphical version of the installer is only available for a limited
 +number of architectures, including arch-title;. The functionality of
 +the graphical installer is essentially the same as that of the regular
 +installer as it basically uses the same programs, but with a different
 +frontend.

Replace regular with text?

 +Although the functionality is identical, the graphical installer still has
 +a few significant advantages. The main advantage is that it supports more
 +languages, namely those that use a character set that cannot be displayed
 +with the regular quotenewt/quote frontend. It also has a few usability
 +advantages such as the option to use a mouse, and in some cases several
 +questions can be displayed on a single screen.

Replace regular newt frontend with text installer?

 +Just as with the regular installer it is possible to add boot parameters
 +when starting the graphical installer.

Replace regular with text?

 +If the amount of memory in your system is below minimum-memory;,
 +the graphical installer may fail to boot at all while booting the
 +regular installer would still work. Using the regular installer is
 +recommended for systems with little available memory.

Replace both regulars with texts?

 +The graphical installer basically works the same as
 +the regular installer and thus the rest of this manual can be used to guide
 +you through the installation process.

Replace regular with text?

 +To switch to another console, you will also need to use the
 +keycapCtrl/keycap key, just as with the X Window System. For example,
 +to switch to VT2 (the first debug shell) you would use: keycombo
 +keycapCtrl/keycap keycapLeft Alt/keycap keycapF2/keycap
 +/keycombo. The graphical installer itself runs on VT5, so you can use
 +keycombo keycapLeft Alt/keycap keycapF5/keycap /keycombo
 +to switch back.

I'm unsure whether a reference to the X Window System is useful, even
for those who know what it is.

In Section 6,1 the paragraph beginning For this architecture the 
would need the default user interface and the link altering. There are
also a few other links in the manual to Sections D.6. and D.6.1..

In Section 5.3.2. should the default frontend reference become gtk?

Regards,

Brian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140819130344.ga7...@copernicus.demon.co.uk

Bug#485586: debian-installer: Default to graphical install

[Brian Potkin]

On Tue 19 Aug 2014 at 17:39:18 +0200, Holger Wansing wrote:

 Brian Potkin claremont...@gmail.com wrote:
  Defaulting to a graphical (gtk) frontend on i386 and amd64 would mean
  that it becomes the regular frontend, unless it is desired to credit the
  newt frontend with some special status.

 From a global point of view, the graphical frontend is still something
 special, an exceptional case, since it's only available on 2 archs out
 of 8 in Jessie. So I would leave the text installer on 'regular' status IMO.

That thought went through my mind too but I discounted it because it
seemed we were looking at i386 and amd64 documentation. If -user had a
question about the regular/normal/usual/default user interface for
Jessie I would say it is definitely the graphical one.

However, since you are doing the work it is your call. :)

(I wonder whether using Debian makes either of us regular guys?).

  I'm unsure whether a reference to the X Window System is useful, even
  for those who know what it is.

 For users who have worked with Debian in the past already, it would not
 hurt to leave that hint in place. And novice users don't get
 irritated too much by this IMO.

It was an aside. I'm sure you are correct.

Thank you for considering.

Regards,

Brian


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/19082014201811.def77e25f...@desktop.copernicus.demon.co.uk

Bug#751704: bug#18289: libparted ped_disk_clobber() overwrites firmware on some arm systems

[Brian C. Lane]

On Mon, Aug 18, 2014 at 08:19:17AM +0200, Karsten Merker wrote:
 Hello,
 
 the following is a discussion from the Debian bugtracking system regarding
 Debian Bug#751704 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751704).
 It needs involvement from parted upstream, therefore I am forwarding it to 
 bug-par...@gnu.org.

Thanks for forwarding this. parted should only be clobbering these extra
sectors when a new disklabel is applied (eg. mklabel in the ui) which, I
think, is the appropriate thing to do.

If you are operating on an existing disklabel and want to preserver a
boot loader in the space before the 1st partition you shouldn't be
calling ped_disk_new_fresh(). If you are creating a new disklabel then
any boot loader code should be installed after partitioning.

I don't think parted needs any changes.

-- 
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140818165949.gx27...@lister.brianlane.com

Bug#758307: installation-reports: First user not added to the lpadmin group

[Brian Potkin]

On Sun 17 Aug 2014 at 08:29:57 +0200, Christian PERRIER wrote:

 Still:
 
 # Allow preseeding the groups to which the first created user is added
 Template: passwd/user-default-groups
 Type: string
 Default: audio cdrom dip floppy video plugdev netdev powerdev scanner 
 bluetooth debian-tor lpadmin
 Description: for internal use only
 
 The code that uses this:
 
 if [ -n $USER ]; then
 db_get passwd/user-default-groups
 for group in $RET; do
 $log $chroot $ROOT adduser $USER $group /dev/null 
 21 || true
 done
 fi
 
 
 After more thinking, my (wild) guess is that, at the time this is
 done, these groups...do not exist on the system. And adduser user
 group then fails when group doesn't exist.
 
 If I'm right, there are probably traces of this is the installer log, I'd 
 guess.

Not such a wild guess.

  Aug 16 16:06:42 user-setup: Adding user `brian' to group `netdev' ...
  Aug 16 16:06:42 user-setup: Adding user brian to group netdev
  Aug 16 17:06:42 gpasswd[5287]: user brian added by root to group netdev
  Aug 16 16:06:42 user-setup: Done.
  Aug 16 16:06:42 user-setup: adduser: The group `powerdev' does not exist.
  Aug 16 16:06:42 user-setup: adduser: The group `scanner' does not exist.
  Aug 16 16:06:42 user-setup: adduser: The group `bluetooth' does not exist.
  Aug 16 16:06:42 user-setup: adduser: The group `debian-tor' does not exist.
  Aug 16 16:06:42 user-setup: adduser: The group `lpadmin' does not exist.
  Aug 16 16:06:42 finish-install: info: Running 
/usr/lib/finish-install.d/07brltty
  Aug 16 16:06:42 finish-install: info: Running 
/usr/lib/finish-install.d/07preseed
  Aug 16 16:06:42 finish-install: info: Running 
/usr/lib/finish-install.d/07speakup
  Aug 16 16:06:42 finish-install: info: Running 
/usr/lib/finish-install.d/10apt-cdrom-setup
  Aug 16 16:06:42 finish-install: Disabling netinst CD in sources.list

Regards,

Brian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/17082014080851.7644c3c9d...@desktop.copernicus.demon.co.uk

Bug#758307: installation-reports: First user not added to the lpadmin group

[Brian Potkin]

On Sun 17 Aug 2014 at 16:03:13 +0200, Christian PERRIER wrote:

 Quoting Brian Potkin (claremont...@gmail.com):
 
   After more thinking, my (wild) guess is that, at the time this is
   done, these groups...do not exist on the system. And adduser user
   group then fails when group doesn't exist.
   
   If I'm right, there are probably traces of this is the installer log, I'd 
   guess.
  
  Not such a wild guess.
 
 .../...
 
 Right. 
 
 The package changelog indeed does give the key:
 
 user-setup (1.3) unstable; urgency=low
 
   * Add first user to two additional groups: netdev and powerdev
 Note that this assumes that something creates these groups during
 the task installation, as hal does with powerdev. The first user is added
 to the groups in finish-install so the groups need not be static.
 Closes: #352713
 
 .../...
 
  -- Joey Hess jo...@debian.org  Mon, 10 Jul 2006 18:23:44 -0400
 
 In short, if packages that need some groups are installed *during
 installation*, then the first created user will be added to these
 groups.

I'm beginning to see the light. base-passwd copies group.master to
/etc/group. Other installed programs create groups as needed. For
example, ifupdown creates netdev and systemd adds systemd-journal.

Here was me thinking d-i itself created groups.

If I go for the Printer server task I'd now expect it to create
lpadmin. And so it does. And the first user is a member of that group.

 Which brings the question: what package is in charge of creating lpadmin?

The postinst of cups-daemon.

May I leave it to you deal with this non-bug? Close it or mark it
wontfix and leave it open as a sign of user naïvety. :)

Regards,

Brian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/17082014180110.9e057a705...@desktop.copernicus.demon.co.uk

Bug#758307: installation-reports: First user not added to the lpadmin group

[Brian Potkin]

Package: user-setup-udeb
Severity: normal
Tags: d-i



#697331 was closed with the following comment:

  * Add first created user to lpadmin group so that it can use local
printers when installed.

After an install using debian-jessie-DI-b1-i386-netinst.iso 'groups'
gives

brian cdrom floppy audio dip video plugdev netdev

(A CC to debian-print...@lists.debian.org because there will likely be
an interest in this there).


Regards,

Brian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/16082014170918.7a58f0696...@desktop.copernicus.demon.co.uk

Bug#758111: installation-reports: Please consider dbus for the core files

[Brian Potkin]

Package: installation-reports
Severity: wishlist
Tags: d-i


The install using debian-jessie-DI-b1-i386-netinst.iso was uneventful;
manual partitioning with one single partition and grub put in the MBR.
No tasks were selected.

The booted system has tty1 available but ttys 2-6 cannot be activated
without installing dbus. The base system is installed without
Recommends: of course. journalctl showed that there was a failure to
start the Login Service. It would be nice if the system behaved in a
similar way to previous ones and it was not necessary to surmount a
little hurdle on first boot.

Pkg-utopia-maintainers CCed.

Regards,

Brian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/14082014105000.07163c43e...@desktop.copernicus.demon.co.uk

Bug#758145: installation-reports: Missing dbus; logind service fails

[Brian Potkin]

merge 758111
thanks



On Thu 14 Aug 2014 at 15:05:30 -0400, Mel Davis wrote:

 What led to situation...
 Fresh install of OS on new SD card. Basic default installation. No custom 
 drivers. No errors or problems reported during the install. 
 
 Booting into OS reported the following error: 
 Failed to start Login Service.
 
 What I did that was effective...
 Running systemctl status systemd-login.service -l indicated that it 
 failed to find the dbus.socket.
 
 Installed dbus via apt-get.   
 Rebooted. Problem solved.

Doesn't seem much different from #758111, so merging.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/14082014224836.77d3d44f4...@desktop.copernicus.demon.co.uk

Bug#756893: ram requirements for d-i: stats in d-i manual

[Brian Potkin]

On Mon 04 Aug 2014 at 11:39:29 +0200, Samuel Thibault wrote:

 Holger Wansing, le Mon 04 Aug 2014 11:22:06 +0200, a écrit :
  So what needs to be changed?
  In
  https://lists.debian.org/debian-boot/2013/05/msg00662.html
  I have already proposed the following:
  
  
Table 3.2. Recommended Minimum System Requirements
Install Type  RAM (minimal)   RAM (recommended)   Hard Drive
  - No desktop64 megabytes256 megabytes   1 gigabyte
  - With Desktop  128 megabytes   512 megabytes   5 gigabytes
  + No desktop128 megabytes   512 megabytes   1 gigabyte
  + With Desktop  256 megabytes   1 gigabyte  5 gigabytes
  
  OK to commit this?
 
 That sounds reasonable to me, although we may want to double the hard
 drive part too (these are recommended values, not minimum values; I
 wouldn't recommend just 1GiB and 5GiB).

I'm presently working with Jessie (an upgraded Wheezy with no tasks
installed), little additional software (vim, gpm. systemd, less, mc) and
the cache cleared out. df -h shows 730M used. I'd not feel comfortable
with a 1GiB partition.

apt-get install task-gnome-desktop wants to get 780 MB of archives,
which will use 2,552 MB of disk space. I could live with a 5 GiB
partition there.

BTW, it should be minimum - not minimal

Regards,

Brian.


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/04082014130724.ce789f9f4...@desktop.copernicus.demon.co.uk