Bug#1056697: 12.2 Installation Report, Complete Failure of Network

[Lennart Sorensen]

On Fri, Nov 24, 2023 at 12:34:50PM -0600, David Hillman wrote:
> 
> Package: installation-reports
> 
> Boot method: USB stick
> Image version: 
> https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/debian-12.2.0-amd64-netinst.iso
> Date: 2023-November-23 11PM GMT
> 
> Machine: Dell R720
> Processor: 2 x Xeon E5-2650
> Memory: 192GB
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O ]
> Detect network card:    [E ]
> Configure network:  [E ]
> Detect media:   [ ]
> Load installer modules: [ ]
> Detect hard drives: [O ]
> Partition hard drives:  [O ]
> Install base system:    [ ]
> Clock/timezone setup:   [ ]
> User/password setup:    [O ]
> Install tasks:  [ ]
> Install boot loader:    [ ]
> Overall install:    [E ]
> 
> Comments/Problems:
> 
> 
> Installer completely failed to identify the presence of all four integrated
> Broadcom BCM5720 ethernet ports, and even after manually adding and
> configuring the four interfaces, no network connectivity is to be had. 
> Interfaces are allegedly "UP", but cannot ping anything nor respond to any
> communication.  IDRAC card interface works fine -- on the same subnet.  A
> half-dozen other multi-interface machines on the same subnet are working
> fine, as well.
> 
> Ubuntu 20 and 22 installers work just fine on the same hardware, so this is
> a Debian-specific issue.  All four interfaces work just fine under both
> Ubuntu 20 and 22, but are totally dysfunctional with Debian 12.
> 
> Journal entries for NetworkManager and avahi-daemon appear to show the
> correct IP addresses being registered for all four interfaces, and "ip"
> agress, all to no avail.  No related error messages exist in the journal.

I suspect you are missing the firmware file for the network port.  I think this 
one:

firmware-misc-nonfree: /lib/firmware/tigon/tg3.bin

The installer probably does not include that.

-- 
Len Sorensen

Re: Add Feature Prevent Installing non-free-firmware in Noraml Mode (Like expert mode)

[Lennart Sorensen]

On Wed, Nov 01, 2023 at 09:27:16AM +, Modaresi Soft Hard wrote:
> Hello. From Debian 12 onwards, proprietary drivers will be automatically 
> installed in normal mode.
> 
> Can you make the installer ask questions in normal mode for installing 
> proprietary drivers?
> (Like a check box with No and Yes)
> 
> What does firmware=never do? # 
> https://wiki.debian.org/Firmware#How_to_disable_detection_and_use_of_non-free_firmware
> 
> Does firmware=never affect the installation and detection of free firmwares?
> 
> I use an interpreter. forgive me

firmware and proprietary drivers are two very different things.

Firmware files are loaded into memory on the hardware to make it operate.
The drivers are often still open source.  Proprietary drivers (like nvidia
and amd) on the other hand execute on your CPU, usually in kernel space
(at least partially) and is a very different story.  People tend to
have a much bigger issue with proprietary drivers than they do with
firmware files.

The firmware file simply does what in the past would have been done with
a rom or flash chip on the card but is now done with ram to save some
money on the design.

-- 
Len Sorensen

Re: Bug#1040901: Upcoming changes to Debian Linux kernel packages

[Lennart Sorensen]

On Mon, Sep 25, 2023 at 02:03:35AM +0200, Bastian Blank wrote:
> The current way does not work.  See all the bug reports about
> uninstallable packages and what not with dkms.
> 
> To build modules against version x, you'll need to install version x of
> the headers, not x-1 or x+1.  This currently works most of the time, but
> is by far stable.  And if you already have to search for the specific
> version, it does not matter if you might have the ability to install
> multiple at the same time, the archive will in any case only contain one
> version at a time.

So you want to change something from where dkms works 99.99% of the time
to 0% of the time?  Having multiple kernel versions and being able
to build for them is a very normal thing to do that almost always works.
Why break that?

Sure there are some bugs for when dkms has issues, but you don't get
bug reports for all the cases where it is working.

I am having trouble understanding what the problem was that you are
attempting to fix, but so far the cure sounds far worse than the disease.

-- 
Len Sorensen

Re: installation-guide: MS-DOS and Windows

[Lennart Sorensen]

On Sun, Aug 06, 2023 at 12:15:35PM +0200, John Paul Adrian Glaubitz wrote:
> OK, that's better. Btw, while it's okay to remove references to MS-DOS, 
> please make sure that the
> semantics of a sentence is not altered. For example, it's still valid to call 
> DOS partition labels
> by their original name as by contrast newer hardware uses GPT partition 
> labels, for example. Calling
> the old DOS partioning scheme "Windows partitioning" would not be correct.

Don't most partition tools call it MBR vs GPT partition tables?  I suppose
some of them still call it DOS parttions.

-- 
Len Sorensen

Bug#1042563: installation-reports: installation OK, screen remains blank during boot and GDM Greeter

[Lennart Sorensen]

On Sun, Jul 30, 2023 at 01:08:13PM +0100, Steve McIntyre wrote:
> Hi Axel!
> 
> I'm a little confused here...
> 
> You say the machine is a Thinkpad X230, but the attached cpuinfo says
> you have an Atom CPU and the DMI data says it's an ASUSTeK Eee
> PC. What hardware are we actually looking at here please?

It also says 4.15 kernel which is clearly not bookworm.  I think the
installation log was accidentally from a much earlier install on a
different machine.

-- 
Len Sorensen

Re: Strange MBR CHS partition values created by debian-installer

[Lennart Sorensen]

On Sun, Jul 09, 2023 at 12:15:35AM +0300, ValdikSS wrote:
> On 09.07.2023 00:02, Steve McIntyre wrote:
> > Nothing should be caring about C/H/S at all in the 21st century. Using
> > C/H/S only allows you to access 515MB of disk [1]. *Everything* these
> > days uses LBA instead.
> > 
> > What makes you think that the BIOS on this old machine cares about
> > C/H/S?
> 
> My machine is old, it's a 32-bit CPU from 2006 in a machine from 2008.

That's sad.  My 486 from 1993 uses LBA correctly and doesn't care about
CHS at all.  How could a machine from 15 years later when disks much
much bigger than CHS supported possibly care at all?

-- 
Len Sorensen

Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

[Lennart Sorensen]

On Tue, May 09, 2023 at 12:22:02AM +0100, Pete Batard wrote:
> Interesting; TIL.
> 
> I guess I'm probably not the only person who thought DT was something that
> was only cooked recently by Linux kernel maintainers, since that's when it
> became mainstream for the majority of the x86/PC based end-user crowd.

You are definitely not the only one.  The ability to attach an fdt
devicetree file to the kernel on systems that didn't have openfirmware
to provide the data was a more recent addition, but it was simply taking
advantage of a system that was already present for years.

> Well, the thing is overall units tends to correlate pretty closely to
> overall end-users. And, while one may try to plan for what one expects/hopes
> the end-user landscape to shift towards, one must still strive to create
> software that makes life easier for the current one. In terms of units, ACPI
> has certainly been more widespread, even if it's mostly due to the
> homogeneity of the dominant arch and platform (x86 based PC).

Certainly it is hard to fight against anything Microsoft and Intel have
decided they are going to use.  Neither one seems to care much what
anyone else is doing already.

> > Apple is almost certainly back to devicetree on their arm devices since
> > they used it on their powerpc based systems already in the past.
> 
> If that's the case, then (I'm going to assume that) it's shame Apple didn't
> use their position to join the discussion and provide some opposition to
> Microsoft, when it came to going with ACPI-only for SBBR...

Apple doesn't seem interested in their OS being able to run on anyone
else's hardware or anyone else's OS running on their hardware.  So not
complyoing with standards probably suits them just fine.

> I'd venture to say that there's been a bit of a chicken and egg problem
> there, which SBBR is in part trying to solve, by attempting to remove one of
> the hurdle people face when getting an ARM64 server, i.e. how the heck am I
> going to install my OS/distro of choice on this machine, instead of being
> constrained by whatever custom version of some other OS/distro the
> manufacturer of the platform decided to go with.

Being able to install an OS certainly is handy, although being able to
even buy the hardware is probably the first step.

> I do agree that we're still early in the game here, if game there eventually
> is, which is the *precise* reason why a group of us worked together to
> provide an SBBR implementation on the commonplace and relatively limited Pi
> platforms, i.e. something that is everything but an ARM server, to both
> provide an easy to access working implementation as well as demonstrate to
> ARM64 system manufacturers that, if this can be accomplished for the Pi with
> limited effort, this should certainly be achievable for their platform.

Certainly useful to have a small cheap platform to be able to work on it.
Unfortunate that even a Pi is a bit hard to get a hold of these days.

> Again, I'd prefer to go with number end-users as a better measure, since
> we're not developing for the greater variety but for is likely to benefit
> the greater masses. Of course, if ARM64 system manufacturers collectively
> decide they want to ignore Windows and SBBR, and go with openfirmware, I'll
> be more than happy to let Microsoft add openfirmware compatibility to
> Windows on ARM, as long as the end-users stop having to jump through
> system-specific hoops to install the OS they want.

Well certainly devicetree makes the kernel and driver handling much
simpler and more consistent, but the boot loader on all the different
arm systems isn't standardized.  Using UEFI on SBBR means a standard
grub2 uefi boot loader should work on any system, so that does seem
like a benefit.  Of course that really just means UEFI might be a big
improvement, not that ACPI vs devicetree is.  No idea if UEFI can work
with devicetree or not.  Being an intel thing I would not be surprised
if ACPI is rather tied into it, since that would make sense.  A quick
look at wikipedia says UEFI actually provides devicetree services on
RISC processor systems.  I guess that makes sense since pretty much all
RISC systems seem to have used openfirmware or something similar so
their OS would expect that.  Little endian only though of course.

> I'm going to go further than that and say that not even Microsoft
> appears/appeared to care that much about running Windows on ARM systems, as
> we pretty much offered them a golden opportunity to chase a goal they should
> be exceedingly familiar with, and, what's more, one that Apple will never
> challenge them on, namely running their OS on *cheap* commonplace hardware.
> But they pretty much ignored the crowd that was interested in running
> Windows on the Pi, even as Windows 11 21H2 does run very decently on an 8 GB
> Pi 4 and, current hardware price hike notwithstanding, could have gained
> significant traction with the low income masses. This, in turn, could 

Re: Bug#1029843: live-boot: Devices Requiring Firmware: multiple requested files in single line overlapping / special characters

[Lennart Sorensen]

On Mon, May 08, 2023 at 06:16:52PM +0100, Pete Batard wrote:
> Plus, UEFI has an official standard, and standards are (for the most part) a
> good thing.

IEEE-1275 is a standard too.

> However, with what I have mentioned initially and the weight that Microsoft
> has, the only way you're going to have vendors moving away from ACPI is if
> Microsoft decides to add support for DT in Windows (or something else that
> they see better than ACPI)... which I don't really see happening in the near
> to medium term, since, much to their benefit, Microsoft did manage to get
> the ARM SBBR specs to go with ACPI and thus continue business as usual as
> far as Windows is concerned.
> 
> Again, I am hoping that there was some consideration given by Microsoft and
> other members of the SBBR committee as to whether it made sense to go with
> Device Tree. One of the problems I would see however is that, I doubt the
> Linux folks consulted with Microsoft when they introduced Device Tree (then
> again why and how would they) to see if Microsoft had some interest for
> using it in the long run, and if so, what they could do to make it more
> palatable for Windows usage.

Well devicetree is part of open firmware aka IEEE-1275, from 1994.
ACPI is from 1996.  And of course since I don't think Sun cared at
all what Microsoft thought when they designed the firmware interface,
I don't think that matters.  Since open firmware or at least devicetree
has then ended up used on SPARC, PowerPC, ARM, MIPS, and who knows what
else, while ACPI is x86 and now some ARM but nothing else as far as I
can tell, other than in terms of overall units using it, ACPI certainly
has a lot less interest.

> And that's the old problem of ecosystems being split on OS lines, when it
> would be nice if we could look a bit further than that, with Linuxfolks most
> likely not that eager to ask Microsoft if they have some input on the
> direction they wanted to take when they introduced DT, and, likewise,
> Microsoft unlikely to want to use some "Not Invented Here" technologies like
> DT, even more so when you have the other elephant in the room for the "Not
> Invented Here", i.e. Apple, which seems so adverse to compromising with
> anybody that it provides the worst example to follow such as, using their
> own version of EFI on x86 based hardware rather than UEFI, and then dropping
> that altogether on their ARM based silicon, to now use their own completely
> custom pre OS execution environment. At this stage, I should probably add
> that it's going to be fat chance to ever see Apple use SBBR on their
> hardware even, if on paper, it should have been a perfect target for it and
> sure would have make booting and installing Debian on Apple Silicon
> easier... even if one were to be constrained to use ACPI over DT.

Apple is almost certainly back to devicetree on their arm devices since
they used it on their powerpc based systems already in the past.

> To me, it looks like mostly a question of reducing development cost as well
> as what one can get away with by not going out of their way to try to talk
> and seek compromise with other parties. And, as usual, it's the end-users
> that pay the price by having hardware and OSes that restrict what they
> should be able to do with it, starting with their ability to install the OS
> they prefer on modern ARM64 hardware.
> 
> And that's actually the reason why I think efforts like SBBR should be
> supported, because they are trying to break the status quo, even if it
> appears that Microsoft might have gotten what they wanted at the detriment
> of Linux, and even if Apple are unlikely to ever want to touch SBBR with a
> ten foot pole...

Well unfortunately for years it seems the status quo has also been 64
bit arm servers being annonced, but not able to be purchased anywhere
unless you were google or amazon or some other large cloud provider.
Apparently they didn't actually want to sell their systems.  Then they
complained that there was no market for arm servers.  Maybe it has gotten
better in the last few years, but in my current job having arm servers
is no longer relevant unfortunately.  I sure wanted some 8 or 10 years
ago when they were announcing them but not actually selling them.

> Well supported across architectures: yes.
> Well supported across OSes: Unfortunately no, when you do consider Windows.

Any OS that ever ran on an openfirmware system, which is a lot of them.

> And that is the main issue here. SBBR is not just for Linux, or for Windows.
> So, yes, someone, on the OS side, is likely to have to do extra work, whose
> only purpose will be to allow people to install a completely different OS.
> And yes, that sucks. But if it benefits end-users, it's the price one has to
> pay.

It seems that it benefits only one OS, the one it seems just about no
one cares to run on arm systems.

Doesn't mean that long term ACPI and UEFI might not be better for SBBR.
I highly doubt the decision was made without 

Re: Bug#1033546: Debian installer / Network configuration

[Lennart Sorensen]

On Mon, Mar 27, 2023 at 08:45:35PM +0200, Geert Stappers wrote:
> On Mon, Mar 27, 2023 at 08:35:22AM +,  Christophe wrote:
> > Configure network:      [E]
> > 
> > Comments/Problems:
> > 
> > This bug is present since many years.
> 
>   :-)
> 
> 
> > Currently, tt's not possible to declare a network like this :
> > 
> > | IPv4:54.37.96.xxx/32
> > | Gateway: 54.38.179.254
> > 
> > The installer tell "Unreachable gateway" but it's not true. If the
> > network if configured with these values, everything is fine.
> > 
> > If i put this in /etc/network/interfaces, it works :
> > 
> > | auto eth0
> > | iface eth0 inet static
> > |     address 54.37.96.xxx/32
> > |     gateway 54.38.179.254
> 
> 
> Which feels wrong.
> 
> It is the  /32   that makes it odd.

Yeah that's for sure.  The gateway IP is not within the subnet (given
only one IP is) so it is definitely unreachable by normal IPv4 routing
rules.

If it was a PtP link, then perhaps it would be a different story, but
it probably isn't.

Certainly for any normal functional network, those settings would not
work.  If they do work, the network is doing things outside normal IPv4
routing rules.

-- 
Len Sorensen

Re: Firmware GR result - what happens next?

[Lennart Sorensen]

On Mon, Oct 03, 2022 at 02:47:33PM +0200, Pascal Hambourg wrote:
> Not even replace "stable/updates" with "stable-security" during the upgrade
> from buster to bullseye ?

Hmm I don't recall but I suppose it just wasn't very memorable to do it.
At least it would have given an error fetching the list if you didn't
do it.  Not adding a new entry on the other hand will not.

-- 
Len Sorensen

Re: Firmware GR result - what happens next?

[Lennart Sorensen]

On Sun, Oct 02, 2022 at 08:21:31PM +0100, Steve McIntyre wrote:
> Two things:
> 
>  1. I'm worried what bugs we might expose by having packages be in two
> components at once.
>  2. I really don't like the idea of leaving two different
> configurations in the wild; it'll confuse people and is more
> likely to cause issues in the future IMHO.
> 
> Plus, as Shengjing Zhu points out: we already expect people to manage
> the sources.list anyway on upgrades.

People that just have 'stable' in their sources.list haven't had to
do anything.  I can't think of ever having had to add anything, only
change the release name.

This will get missed and it will get missed a lot.

-- 
Len Sorensen

Bug#1013678: installation-reports: honeycomb lx2: partial success, network and issues with raid/lvm/grub

[Lennart Sorensen]

On Fri, Jun 24, 2022 at 02:10:44PM -0700, Vagrant Cascadian wrote:
> Package: installation-reports
> Severity: normal
> X-Debbugs-Cc: vagr...@debian.org
> 
> Boot method: network
> Image version: 
> https://d-i.debian.org/daily-images/arm64/20220624-02:19/netboot/netboot.tar.gz
> Date: 2022-06-24 after breakfast but before lunch
> 
> Machine: Solidrun Honeycomb LX2
> Partitions:
> udev   devtmpfs  32513604   0  32513604   0% /dev
> tmpfs  tmpfs  6514616 744   6513872   1% /run
> /dev/sda3  ext4   9510080 1530260   7475144  17% /
> tmpfs  tmpfs 32573080   0  32573080   0% /dev/shm
> tmpfs  tmpfs 5120   0  5120   0% /run/lock
> /dev/sda1  vfat3899043536386368   1% /boot/efi
> tmpfs  tmpfs  6514616   0   6514616   0% /run/user/1000
> 
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[E]
> Configure network:  [O]
> Detect media:   [O]
> Load installer modules: [O]
> Clock/timezone setup:   [O]
> User/password setup:[O]
> Detect hard drives: [O]
> Partition hard drives:  [O]
> Install base system:[O]
> Install tasks:  [O]
> Install boot loader:[E]
> Overall install:[E]
> 
> Comments/Problems:
> 
> On-board ethernet is not detected in debian-installer or even once the
> system is installed. Worked around with a USB-ethernet adapter.
> 
> Boot loader would install successfully, but grub would not boot when I
> had a system with rootfs on lvm on raid1 (with degraded 1-disk
> array). I think this sort of configuration used to work, but it has
> been ages since I've tested. Will check another install if it works
> better with a not degraded array (e.g. raid1, two disks). Workaround
> was to use a plain partition with ext4 for rootfs.
> 
> FWIW, Same issues with bullseye's installer too, so at least it's
> not...  a regression? :)
> 
> 
> live well,
>   vagrant
> 
> -- Package-specific info:
> 
> ==
> Installer lsb-release:
> ==
> DISTRIB_ID=Debian
> DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
> DISTRIB_RELEASE="12 (bookworm) - installer build 20220624-02:01:58"
> X_INSTALLATION_MEDIUM=netboot
> 
> ==
> Installer hardware-summary:
> ==
> uname -a: Linux hclx2 5.18.0-2-arm64 #1 SMP Debian 5.18.5-1 (2022-06-16) 
> aarch64 GNU/Linux
> lsmod: Module  Size  Used by
> lsmod: fuse  131072  0
> lsmod: nls_ascii  16384  1
> lsmod: nls_cp437  20480  1
> lsmod: efivarfs   20480  1
> lsmod: dm_mod143360  6
> lsmod: dax36864  1 dm_mod
> lsmod: raid1  57344  1
> lsmod: md_mod167936  4 raid1
> lsmod: xfs  1376256  0
> lsmod: jfs   196608  0
> lsmod: btrfs1466368  0
> lsmod: xor20480  1 btrfs
> lsmod: xor_neon   20480  1 xor
> lsmod: raid6_pq  106496  1 btrfs
> lsmod: zstd_compress 253952  1 btrfs
> lsmod: libcrc32c  16384  2 btrfs,xfs
> lsmod: vfat   28672  1
> lsmod: fat81920  1 vfat
> lsmod: ext4  761856  1
> lsmod: crc16  16384  1 ext4
> lsmod: mbcache24576  1 ext4
> lsmod: jbd2  143360  1 ext4
> lsmod: crc32c_generic 16384  3
> lsmod: sd_mod 57344  3
> lsmod: t10_pi 20480  1 sd_mod
> lsmod: crc64_rocksoft 20480  1 t10_pi
> lsmod: crc64  20480  1 crc64_rocksoft
> lsmod: crc_t10dif 20480  1 t10_pi
> lsmod: crct10dif_common   16384  1 crc_t10dif
> lsmod: ahci_qoriq 16384  0
> lsmod: ahci_platform  16384  3
> lsmod: libahci_platform   20480  2 ahci_platform,ahci_qoriq
> lsmod: libahci40960  3 
> libahci_platform,ahci_platform,ahci_qoriq
> lsmod: libata303104  4 
> libahci,libahci_platform,ahci_platform,ahci_qoriq
> lsmod: usb_storage73728  0
> lsmod: scsi_mod  229376  3 sd_mod,usb_storage,libata
> lsmod: scsi_common16384  3 scsi_mod,usb_storage,libata
> lsmod: cdc_ether  20480  0
> lsmod: usbnet 45056  1 cdc_ether
> lsmod: r8152 110592  0
> lsmod: mii20480  2 usbnet,r8152
> lsmod: xhci_plat_hcd  20480  0
> lsmod: xhci_hcd  253952  1 xhci_plat_hcd
> lsmod: at803x 32768  0
> lsmod: xgmac_mdio 20480  0
> lsmod: acpi_mdio  16384  1 xgmac_mdio
> lsmod: mdio_devres16384  1 xgmac_mdio
> lsmod: of_mdio20480  2 

Re: Debian 11.3.0 and Realtek RTL1882ec wireless adaptor

[Lennart Sorensen]

On Fri, Apr 22, 2022 at 08:46:16AM +0100, Dinny wrote:
> Debian-live-11.3.0-amd64-mate.iso
> Laptop Geoflex110 (latest model).
> 
> Does not recognise Realtek RTL1882ec wireless adaptor.

Did you mean RTL8821ec?  I can't find info on an RTL1882ec.

Either way you probably need the firmware-realtek from non-free for it
to work, which is of course not included in the live image.

-- 
Len Sorensen

Re: Debian not bootable after installing Ubuntu

[Lennart Sorensen]

On Wed, Apr 06, 2022 at 12:19:50PM -0400, Jeremy Bicha wrote:
> Hi,
> 
> I'm emailing this list because I didn't know a more specific place to
> report this bug.
> 
> What I Did
> --
> - I used GNOME Boxes 42 (from my Ubuntu 22.04 LTS host).
> - I clicked + then Download an Operating System and chose Debian Testing.
> - I believe this uses
> https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-dvd/debian-testing-amd64-DVD-1.iso
> and
> https://salsa.debian.org/libvirt-team/osinfo-db/-/blob/debian/sid/data/install-script/debian.org/debian-preseed-desktop.xml.in
> - I increased the virtual disk size a bit on the confirm prompt (to like 25 
> GB)
> - That install worked and I got a functioning Debian GNOME Testing install.
> 
> - Then I used today's daily build of Ubuntu 22.04 (pre-release) to
> install Ubuntu.
> - It resized the Debian partition and I had to manually tweak it just
> a bit to get a big enough partition for Ubuntu alongside Debian.
> - After installing Ubuntu, there was a Debian option in the grub boot
> menu installed by Ubuntu.
> - Debian failed to boot. I'm attaching a screenshot. It says:
> error: bad shim signature.
> error: you need to load the kernel first.
> 
> Maybe this is as easy as telling osinfo-db to also install a signed
> kernel. Maybe the signing thing is more complicated. I'm not really
> going to spend more time on this issue but I wanted to pass it along
> so that someone else who is interested could try to fix it.

Sounds like you installed debian with secureboot enabled, and then
installed ubuntu which replaced the boot loader which of course breaks
the secureboot chain of trust and it correctly identified the tampering
and prevented the boot of an insecure temperated environment.

I could be wrong.  I personally don't use secureboot on my systems.

-- 
Len Sorensen

Re: debian-installer for Arm EBBR systems

[Lennart Sorensen]

On Thu, Nov 18, 2021 at 01:38:09PM +, Steve Capper wrote:
> Hello,
> We have an issue installing Debian on some EBBR (Embedded Base Boot 
> Requirements) based systems. Specifically, on EBBR platforms, UEFI 
> SetVariable() is not required at runtime[1] (it is, however, required for 
> boot time services). So, from within Linux, efibootmgr may not work for the 
> end-user; but EFI applications that employ boot time services, would be able 
> to set boot variables. 
> 
> When working through a Debian install, one workaround we have is to "Execute 
> a shell" when the GRUB install phase throws an error, and then:
> # chroot /target
> # update-grub
> # mkdir /boot/efi/EFI/BOOT
> # cp -v /boot/efi/EFI/debian/grubaa64.efi /boot/efi/EFI/BOOT/bootaa64.efi
> 
> Before continuing with the rest of the install.
> 
> The question from our side is; would it be possible to please put some sort 
> of workaround for EBBR systems into the Debian install logic if EFI 
> SetVariable() fails? For example, a bootaa64.efi could be placed on the 
> target system in the removable path that is either: 1) a copy of grub, or 2) 
> could be an EFI utility that sets the Debian EFI boot variable?

I am curious how the people in charge of this spec were imagining anyone
ever installing an OS on the system?

Perhaps someone should go fix their bad spec instead.  I thought the idea
of having UEFI was to finally be able to treat arm systems as pretty
generic and use a normal installer on them and avoid the mess that has
been custom u-boot on arm systems in the past.

But I am just a user.  Not like you can even buy any 64 bit arm servers,
since they only ever get announced but never actually become available
to buy unless you are a cloud data center owner apparently.  Developers
don't seem to be able to actually get one to work with.

-- 
Len Sorensen

Re: partman, growlight, discoverable partitions, and fun

[Lennart Sorensen]

On Mon, Sep 27, 2021 at 03:18:48PM +0200, John Paul Adrian Glaubitz wrote:
> Whether a tool that was developed new from scratch is automatically better is 
> not a given. The burden of proof is on the person trying to introduce the new 
> software, not on the people maintaining the current set of software.
> 
> And claiming that parted is in pure maintenance mode is not true either. It 
> has a paid developer working on the project and is receiving updates and 
> improvements.
> 
> Whether growlight is better and more suitable for Debian needs to be 
> technically proven, not just by arguing that it’s the newer project.

I would have thought that if libparted was missing 1 or 2 features,
it would make more sense to add those features than to write a new tool
duplicating most of the functionality.

Well unless working with the maintainers of libparted is imposible.
There are a few projects like that but I don't remember ever seeing
complains about libparted.  Now you have two tools both missing some
features.  Hardly an improvement.

-- 
Len Sorensen

Re: Installer annoyance - a bug?

[Lennart Sorensen]

On Sun, Jun 06, 2021 at 07:48:06AM -0500, Richard Owlett wrote:
> There is *functional/quality/?* difference between an install from a
> physical CD/DVD and from an "equivalent" flash drive.
> 
> I have a very atypical use case:
>   1. internet is *not* available to support installation.
>   2. my goal is what I consider a minimalist GUI
> 
> When I first used Squeeze:
>   1. an internet install was impractical as I was on dial-up.
>   2. physical CD/DVDs were readily available
>   3. after booting into a minimal command line system my custom
>  system could easily be installed using apt-get
> 
> Although I now have high speed connectivity, my data cap is low enough to
> strongly discourage ANY installation related internet usage.
> 
> I can easily install a command line system. BUT installing desired GUI
> components via apt-get is impossible because it searches for a
> *non-existent* physical CD/DVD.
> 
> An install using a preseed file is possible but I find it cumbersome.
> 
> Is there some way, during the initial installation, to drop to a terminal to
> specify additional packages to be installed. As preseeding can do
> essentially the same thing the required framework must exist.

Well to save bandwidth at home, you could use jigdo to download the first
bluray image and write that to a 32GB USB drive.  That should cover most
of the packages you are likely to ever want to install.  And it avoids
the 'swapping disks' that may not be as simple on a usb drive.

This is assuming you have somewhere you could go with lots of bandwidth
to run jigdo to download a 25GB image.

-- 
Len Sorense

Re: problem with GPT/UEFI in debian 11 / debian 10.9 installer

[Lennart Sorensen]

On Mon, Apr 26, 2021 at 08:24:59PM +0300, Alexandru Goia wrote:
> Greetings !
> I tried to install debian 11 on my machine, but since it is a Dell
> with UEFI and GPT, i have not succeded. Still, Ubuntu 2020.10
> went ok. Can you put in debian-installer the option to format/create
> a EFI partition ?

The debian installer certainly does do that if booted in UEFI mode.
Many systems allow you to boot USB devices in legacy or UEFI mode.
You have to boot in UEFI mode to install with GPT and UEFI.  If you boot
legacy mode, then it won't.

Also you of course must be using the amd64 installer not the i386
installer (probably just about no one should use that anymore).

-- 
Len Sorensen

Re: Speed up installation: activate eatmydata-udeb by default and include eatmydata package in /pool

[Lennart Sorensen]

On Tue, Apr 06, 2021 at 05:35:19PM -0400, Cmdte Alpha Tigre Z wrote:
> Pardon my ignorance.
> I could not resist to answer to this proposal.
> 
> I read this page: https://www.flamingspork.com/projects/libeatmydata/
> 
> It looks like it is not good idea to use it for critical information.
> 
> However, your results show that it would be relevant to include
> such package into the first ISO, if it is not so big, of course.
> It sounds like a good idea to speed up the instalation process
> for some cases.
> 
> But, I would not enable it by default.  If the package really
> behaves as its name suggests,
> I would not risk every user
> of Debian to have a faulty installation.  What would happen
> if someone wants to install Debian an suddenly, the installer
> eats some data it shouldn't have.
> 
> Even if it does not access wrong places, in the worst case
> you could have installed an ill OS and don't notice
> it will someday fail, and not gracefully.
> 
> My humble opinion is that it should be available to use,
> but not enabled by default.

The only time eatmydata does any harm is if the system looses power or
resets during the install since the data isn't constantly flushed to disk
to maintain a consistent state.  During an install, there is nothing of
value on the system yet, so doing everything as quickly as possible and
then when everything is done, then you issue a sync command to ensure
everything is flushed to disk saves a ton of time with no risk at all
(in fact since the install takes less time, the changes of a power
interruption happening during the install is lowered).

In no way does eatmydata make it possible for the data of the resulting
install to be corrupt.  As long as the filesystem is cleanly unmounted
or flushed before you reset, you are fine.  That should already happen
by the fact the install does a clean reboot at the end.

Using it on a normal system is a different story since anything you modify
while using it could be lost in case the system is reset unexpectedly,
but since the install has no user data, there is nothing to risk.

So when the page says to not use when you care about the data, that
is correct.  But a fresh install is entirely made of stuff you don't
care about, until it is completely done, then you care.  Using it for
running testsuites where everything is just temporary data also makes
sense to speed that up.  If you are editing something real, don't use it.

-- 
Len Sorensen

Bug#985853: debian-installer: Whitespace before a commented line in preseed file causes line to be parsed

[Lennart Sorensen]

On Thu, Mar 25, 2021 at 09:45:17AM +1030, Andrew McDonnell wrote:
> Package: debian-installer
> Version: 20190702+deb10u8
> Severity: important
> Tags: d-i
> 
> In a preseed file I accidentally had a space before a comment character, which
> caused my preseed to fail in unexpected ways. I could not find anythying that
> stood out in the documentation (e.g.
> https://www.debian.org/releases/buster/amd64/apbs04.en.html or
> https://www.debian.org/releases/stable/amd64/apbs03.en.html) stating that this
> would occur.
> 
> The specific example in my case looked like this:
> 
> #_preseed_V1
> d-i debian-installer/locale string en_AU
> d-i keyboard-configuration/xkb-keymap select us
> d-i keymap select us
> ... etc ...
> # Example of fetching a script to run
>  #d-i preseed/run string http://10.1.2.3/my-script.sh
> 
> 
> My install was hanging and when I entered a console and looked in the syslog,
> it was attempting to access that script for which the IP address does not 
> exist
> on my network. I finally started to understand the problem when I did this, 
> the
> latter finally triggered a parse error in the installer console:
> 
>  #d-iWHATpreseed/run string http://10.1.2.3/my-script.sh
> 
> 
>  #d-iWHATpreseed/runISstringHAPPENINGhttp://10.1.2.3/my-script.sh
> 
> at this point I saw the white space, removed it and the problem went away.
> 
> (I am also unsure whether "d-iWHAT" is also a bug or just some default 
> applying
> if the item owner is not found)
> 
> So I guess that either
> - whitespace is disallowed before a comment character and this should be added
> to https://www.debian.org/releases/stable/amd64/apbs03.en.html - it mentioned
> whitespace between fields but not at the start of a line
> - this is a bug

Well none of the examples ever have spaces before # for comments.
The documentation page you linked to doesn't even mention comments at all.
I would agree that perhaps it should.  I have certainly encountered file
types before where comments had to have # at the start of the line.

-- 
Len Sorensen

Re: XFS file system creation fails (https://chuangtzu.ftp.acc.umu.se/cdimage/unofficial/non-free/cd-including-firmware/weekly-builds/amd64/iso-cd/firmware-testing-amd64-netinst.iso)

[Lennart Sorensen]

On Wed, Feb 03, 2021 at 07:33:36AM +1300, Richard Hector wrote:
> Two different libraries? It seems to be complaining about libinih, not
> libnih.

Yes libinih appears to be under active development.

-- 
Len Sorensen

Bug#981115: please support multiple compose keys in keyboard-configuration

[Lennart Sorensen]

On Tue, Jan 26, 2021 at 10:33:07PM +0100, Martin wrote:
> On 2021-01-26 14:02, Lennart Sorensen wrote:
> > It is not that simple.
> ...
> > Simply manually putting in the config instead seems like a lot less work.
> 
> Thanks for the investigation, Lennart!
> 
> I probably stay with:
> 
> $ setxkbmap -option compose:caps
> $ setxkbmap -option compose:ralt

You could do them on one line too.

-- 
Len Sorensen

Bug#981115: please support multiple compose keys in keyboard-configuration

[Lennart Sorensen]

On Tue, Jan 26, 2021 at 05:24:14PM +0100, Martin wrote:
> Package: keyboard-configuration
> Version: 1.200
> Severity: wishlist
> 
> It is convenient to have compose keys for both hands, e.g.
> capslock and ralt, similar to the two shift keys.
> 
> When running 
> $ sudo dpkg-reconfigure keyboard-configuration
> users can only select one compose key.
> 
> I assume, that multiple comma separated values would work.

It is not that simple.  While xkboptions supports specifying the compose
option multiple times, it is not a comma separated list.  Right now
the config for keyboard-configuration stores a single value for the
compose key in the debconf database and is able to match that against a
simple switch statement.  If it was changed to a comma separated list,
it would require splitting before being able to match each key against
the switch statement.  The code that turns the compose key value into
the right xkboptions would need to be expanded to handle multiple values
in a loop.  Quite a lot of current assumptions would need to be tossed
away and replaced with code that is quite a bit more complicated.  I am
sure it could be done but I am not sure if anyone would be willing to
put in the effort for something that is probably very rarely wanted.

Simply manually putting in the config instead seems like a lot less work.

-- 
Len Sorensen

Bug#967896: Maybe this is related to this upstream kernel bug

[Lennart Sorensen]

https://bugzilla.kernel.org/show_bug.cgi?id=201813 looks pretty much
the same.  It sounds like it has been fixed in a newer kernel and/or
firmware for the card, but I don't know what the chances of such changes
being backported to the stable kernels are.

-- 
Len Sorensen

Re: Does mdadm in the installer read its config file?

[Lennart Sorensen]

On Fri, Sep 11, 2020 at 04:56:34AM +, Andy Smith wrote:
> Hello,
> 
> TL;DR: the Debian installer uses an mdadm.conf located at
> /tmp/mdadm.conf.
> 
> On Thu, Sep 10, 2020 at 04:18:27PM +, Andy Smith wrote:
> > I have confirmed that creating a new array from the d-i shell using
> > mdadm commands manually does result in a new array without a bbl (so
> > this invocation of mdadm did read /etc/mdadm/mdadm.conf):
> 
> I made a shell history mistake and ended up examining the wrong
> device, so in fact I did not confirm this. I ended up testing a
> device that I had previously forced to have its bbl removed, that's
> why the bbl was gone.
> 
> > ~ # mdadm -v --create /dev/md2 --assume-clean --level=1 --raid-devices=2 
> > /dev/sd[ab]3
> 
> …array made with /dev/sd[ab]3…
> 
> > ~ # mdadm --examine /dev/sda1
> 
> …but I examined sda1 by mistake.
> 
> So. Going through this manual creation again, what I see is that
> if I force mdadm to read its config file then:
> 
> ~ # swapoff /dev/md2
> ~ # mdadm --stop /dev/md2 
> mdadm: stopped /dev/md2
> ~ # mdadm --zero-superblock /dev/sda3
> ~ # mdadm --zero-superblock /dev/sdb3
> ~ # mdadm --create -v --config=/etc/mdadm/mdadm.conf /dev/md2 --assume-clean 
> --level=1 --raid-devices=2 /dev/sd[ab]3
> mdadm: Note: this array has metadata at the start and
> may not be suitable as a boot device.  If you plan to
> store '/boot' on this device please ensure that
> your boot-loader understands md/v1.x metadata, or use
> --metadata=0.90
> mdadm: size set to 1951744K
> Continue creating array? y
> mdadm: Defaulting to version 1.2 metadata
> mdadm: array /dev/md2 started.
> ~ # mdadm --examine /dev/sda3
> /dev/sda3:
> …
> (no bbl)
> …
> 
> but if I just call mdadm as normal, it does not read its config
> file:
> 
> ~ # mdadm --stop /dev/md2 
> mdadm: stopped /dev/md2
> ~ # mdadm --zero-superblock /dev/sda3
> ~ # mdadm --zero-superblock /dev/sdb3
> ~ # mdadm --create -v /dev/md2 --assume-clean --level=1 --raid-devices=2 
> /dev/sd[ab]3
> mdadm: Note: this array has metadata at the start and
> may not be suitable as a boot device.  If you plan to
> store '/boot' on this device please ensure that
> your boot-loader understands md/v1.x metadata, or use
> --metadata=0.90
> mdadm: size set to 1951744K
> Continue creating array? y
> mdadm: Defaulting to version 1.2 metadata
> mdadm: array /dev/md2 started.
> ~ # mdadm --examine /dev/sdb3
> …
>   Bad Block Log : 512 entries available at offset 72 sectors
> …
> 
> So that'd explain why d-i's usage of mdadm doesn't obey the config
> file. Yet the man page for mdadm says:
> 
> --config=
> Specify   the   config   file  or  directory.   Default  is
> to use /etc/mdadm/mdadm.conf…
> 
> I have now tried this in a real system and there the config file is
> respected. I am really confused at this point.
> 
> So I installed strace in the d-i shell, and…
> 
> ~ # strace -e trace=open -o strace.log mdadm --create -v /dev/md2 
> --assume-clean --level=1 --raid-devices=2 /dev/sd[ab]3
> …
> ~ # grep .conf strace.log 
> open("/tmp/mdadm.conf", O_RDONLY)   = 3
> open("/tmp/mdadm.conf.d", O_RDONLY) = -1 ENOENT (No such file or 
> directory)
> 
> Uh, alright then.
> 
> ~ # cp /etc/mdadm/mdadm.conf /tmp/
> ~ # mdadm --create -v /dev/md2 --assume-clean --level=1 --raid-devices=2 
> /dev/sd[ab]3
> ~ # mdadm --examine /dev/sda3
> /dev/sda3:
> (no bbl)
> 
> I assume there is a good reason for d-i having an mdadm binary that
> wants to use /tmp/ and not /etc/mdadm/ for its config directory.

/tmp is probably a writable tmpfs and /etc is probably a read only CD 
filesystem.

-- 
Len Sorensen

Re: NIC not detected, unable to install (weekly + daily mini-iso)

[Lennart Sorensen]

On Wed, Apr 15, 2020 at 10:42:33PM +0200, Camaleón wrote:
> Umm... this is an old netbook, the NIC adapter has always been working, 
> it's a very common chipset.
>  
> Good point. 
> 
> While this is a 2 GiB RAM netbook, last time I checked only i386 and 
> -pae kernel were working, but I can try again with amd64 image. 
> 
> (testing right now...)
> 
> Well, the net-iso (64 bits) just loads fine. Logs here say (I must have 
> mispelled the ID before):

Well it is an atom based machine.  Some were 64 bit capable, some
were not.

> «r8169 :01:00.0 unknown chip XID 240». 

Yeah the driver does not have that id in it.  I guess it was a version
used only by HP/Compaq and no one ever tried to run linux on it or at least
no one that did cared about wired networking.  It might be a trivial case
of adding the id to match one of the other revisions to make it work,
but without the datasheet it is hard to know.

> Again, no wired NIC available.
> 
> My netbook is a Compaq Mini CQ10-520ES, currently running a looong-
> standing Debian testing version and... well, okay, kernel says the same,
> the NIC card is not being recognized, same message «unknown chip XID 
> 240».
> 
> As this computer always uses the wireless adapter, I simply ignored the
> wired NIC had been unavailable until now. 
> 
> This can be relevant:
> https://answers.launchpad.net/ubuntu/+source/gnome-nettool/+question/689563

Given it has HP as the subsystem id in the link, I suspect this id is
a custom branded chip made for HP which hence has a unique ID, but is
probably otherwise identical to another id.

The wireless probably requires firmware, so it might work if booted with
the non-free firmware version of the installer.

-- 
Len Sorensen

Re: NIC not detected, unable to install (weekly + daily mini-iso)

[Lennart Sorensen]

On Wed, Apr 15, 2020 at 07:45:42PM +0200, Camaleón wrote:
> Hello,
> 
> Tried the mini-iso image to install testing (i386), with both, daily and 
> weekly files. To my surprise, the installer was unable to detect the wired
> NIC adapter and wifi required a non-free firmware that I was unable to 
> load (I tried by following the instructions and copying the files on a 
> secondary USB stick, but no way).
> 
> Kernel log showed something like «R8169 Unknown Chip XID 5A4».

If it was XID 54A then it makes sense.  That chip was added to the kernel
in november 2019, and is part of 5.5 kernel and newer.

Did you actually mean to install 32bit rather than 64bit given it must
be a new machine?

-- 
Len Sorensen

Re: Debian 10.2 LinuxCenter Peterburg

[Lennart Sorensen]

On Fri, Feb 28, 2020 at 09:34:22PM +1100, Hugh McMaster wrote:
> Both of these work correctly. What I was actually thinking of was an
> issue with `adduser  sudo`. It now requires a reboot instead
> of just logging out and in as a normal user.

That makes no sense.  It should not require a reboot, but it does require
logging out.

> You can log in as the root user using Cinnamon by default.

Well it is up to the login manager if it allows root or not.  Some don't.

-- 
Len Sorensen

Re: Debian 10.2 LinuxCenter Peterburg

[Lennart Sorensen]

On Thu, Feb 27, 2020 at 10:36:07PM +1100, Hugh McMaster wrote:
> Hallo Holger,
> 
> On Wed, 26 Feb 2020 at 03:01, Holger Wansing  wrote:
> > I have just tested with an 10.3 netinst amd64 image, and it works as it
> > should.
> > So, you will need to give more information, in order to be able to help you.
> > - which installation image did you use exactly?
> > - please provide the installation logs.
> 
> The behaviour described is present in the weekly Debian Testing net
> install image (I used amd64).
> 
> After using the graphical installer in a virtual machine, setting the
> root and standard user passwords, and finally restarting, the root
> password is not accepted, so the user cannot login as root or use sudo
> as a normal user.

Can you use 'su -l' as a normal user to become root?

Can you switch to tty1 (left control+left alt+F1) and login as root there?

Not being able to login to the GUI as root is expected.

-- 
Len Sorensen

Re: Debian 10.2 LinuxCenter Peterburg

[Lennart Sorensen]

On Thu, Feb 20, 2020 at 12:35:46AM +0300, Pichugin_EN wrote:
> The root password is set during installation
> 
> but after installation, the root password is not accepted

It should work on the console.

It should work for 'su -'

It should not work for ssh and probably should not work to login to
the GUI.

-- 
Len Sorensen

Re: Booting Debian freezes on “[OK] Started GNOME Display Manager”

[Lennart Sorensen]

On Wed, Dec 11, 2019 at 04:07:45PM +0300, Billy Andriamahazomandimby wrote:
> Dear Debian Help,
> Firstly, it is a pleasure to have an opportunity to write you this Email.
> As a follow up of my Email from yesterday, I would like to send you
> additional details regarding my problem in which I cannot get Debian to
> boot properly.
> My Laptop Brand and Model:
> Lenovo ideapad 330-15ARR
> BIOS Version: 7VCN46WW
> EC Version: 7VEC46WW
> MTM 81D200AQTX
> Lenovo SN (the serial number)
> UUID Number (UUID number)
> CPU: AMD Ryzen 3 2200U with Radeon Vega Mobile Gfx
> System Memory: 8192 MB
> Hard Disk: ST1000LM035-1RK172
> ODD PLDS DVD-RW DA9AESH
> 
> I also directly asked a question on unix.stackexchange.com
> 
> concerning
> the issue so that you can clearly look at it in case that you need
> additional information.

I wonder if that AMD GPU requires firmware for graphical mode to work.
I see some reports of getting a blank screen if trying to start X without
firmware loaded for some of the RX Vega chips.

This might help: https://wiki.debian.org/Firmware

-- 
Len Sorensen

Bug#942128: installation-guide-amd64: security apt resource

[Lennart Sorensen]

On Thu, Oct 10, 2019 at 07:50:33PM +0200, Pavel Kosina wrote:
> Package: installation-guide-amd64
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> In installation of debian 10, testing, there is bad entry to
> /etc/apt/sources.list - installation procedure reports error when trying
> contact old security repository (up to 9).
> 
> The instalation procedure should use the new one:
> deb http://security.debian.org testing-security main contrib non-free
> deb-src http://security.debian.org testing-security main contrib non-free
> 
> Thank you.
> 
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.2.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), 
> LANGUAGE=cs_CZ.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled

Did you mean Debian 11 (Buster is 10 and is stable release right now)?

-- 
Len Sorensen

Bug#935931: Re: Bug#935931: debian-installer: Reinstalling Debian on a current Debian installation without erasing or fomatting the home folder

[Lennart Sorensen]

On Mon, Sep 30, 2019 at 12:51:33PM -0400, Daniel wrote:
> Dear Lennart,
> 
> I hope that when one opens a "whishlist bug" at least there is a chance to
> have a confrontation.
> 
> The main point I want to address is when you do a "smart installation" it is
> supposed to perform a clean installation hence the only folder that must to
> be untouched is "/home". The same concept when you have "/" and "/home" in
> separated partitions and you perform a clean installation. I think that is
> pretty trivial, the smart parts are:
> 
> * the installer is able to check for a previous Debian installation before
> to begin the process;
> 
> * and in case it founds a previous installation, the installer, is able to
> perform a fresh installation without overwriting the "/home" folder.

Well I believe you have the option to not format a mountpoint during
the install already, so at least that part should be pretty easy.

> I can confirm that ElementaryOS and POP!_OS, that share the same installer,
> can do that.

Well hopefully someone will try to contribute that then.  I suspect the
main thing is finding someone that wants to implement it and do the work
to add it and maintain it.

> Last point I want touch is about the swap partition. With the SSD and the OS
> able to boot in a bunch of seconds the hibernation doesn't make any sense
> today. For example I have 16GB of ram, based on the standard rules I should
> use at least 1.5x of the ram if not the double. It means that I should use
> 32GB just to hibernate my session, no way... With the SSD disks the lesser
> you write on the disk the better, I put just 2GB of swap-file and
> "swappiness" at 1 and the swap is never used and I didn't waste 30GB of
> space.

Only advantage to huibernation is not having to close all the things
you are working on and opening them again after the next boot.  I do
find hibernation takes too long with a lot of ram and hence never do it
myself. :)

> To conclude I think I elaborated everything clearly, I see a lot of benefits
> and improvement with the suggestions I gave to Debian, I also think that are
> pretty trivial to implement. I don't want introduce a Windows behavior of
> "reinstall when it broken", but back to time when I hadn't a fast internet
> connection it was faster download the full ISO and performing a fresh
> installation rather than doing a "dist-upgrade".

I remember upgrades over dial up.  Still did not make me want to go
download full iso images elsewhere.  It could do it while I slept.
Things have gotten a lot bigger since then though.  I have seen people
keep a subset mirror of Debian on a USB drive that they would update with
rsync once in a while at work, and bring home to use for upgrades where
the connection was slow.  Still in place upgrades of course, not using
the installer.

> The bottom line is with a smart installer you don't need to separate your
> disk(s) in partitions but you can throw everything in "/" including the
> "swap" as swap-file that you can modify freely based on your needs (if you
> can't live without hibernation[1]). There is also a dynamic swap manager
> available on Debian as well: https://github.com/Tookmund/Swapspace

-- 
Len Sorensen

Bug#935931: Re: Bug#935931: debian-installer: Reinstalling Debian on a current Debian installation without erasing or fomatting the home folder

[Lennart Sorensen]

On Sat, Sep 28, 2019 at 11:27:29PM -0400, Daniel wrote:
> Hi Nicholas,
> 
> thanks for your reply, I really appreciated your constructive approach.
> 
> I use Debian since 2007 and I did a lot of installation, I personally use a
> FrankenDebian (testing with pinning toward SID and Experimental) however
> when I install Debian on other machines I install definitely the current
> stable available. I have been performing exclusively desktop installations
> and while I consider the best option separating /home recently I found
> myself not able to get the right balance between "/", "/home" and "swap".
> The default "/" assigned is often too small while sometimes I wasted
> gigabyte never used. The "swap" with the amount of ram available today is
> always more accessory and with the SSD disk the trend is to reduce its use
> the most. Eventually I stopped to create a "swap" partition in favor of a
> "swap-file" (like Raspian e.g.); hence I also stopped to create "/" and
> "/home" but just "/" and still as LVM; at this point you don't have anymore
> issue with the space and if you need you can add all the disks you want
> because it is still a LVM partition.
> 
> Now the case I am figuring out is the one you didn't separe "/" and "/home"
> (however the installer is still creating "swap") but you need to reinstall
> Debian because you screwed it up for some reason. Now a smart installer
> before to start everything takes its time to check the disk and discovers
> that you have, along a crypted disk and a LVM group, also a previous version
> of Debian hence check the users and it asks you if you want keep all the
> users, just one, etc... and then it reinstalls the system and recovers the
> setting from the user(s) you selected, without creating a FrankenDebian but
> just a fresh and **smart** installation.
> 
> This leads in my opinion in creating a further voice for the Debian install:
> **the desktop installation**; Standard and Advanced are eventually too
> generic and do not target properly the desktop cases. If the D-I was
> properly able to read LUKS and LVM during the installation time, and if was
> also able to perform a smart installation as described in the paragraph
> above, a Desktop installation should be:
> 
> 1. Create an encrypted partition by default (LUKS + LVM);

I rarely do that, but I can see why some people want it.

> 2. install everything in / ;

I do tend to prefer that for most setups myself.

> 3. not create a "swap partition" but a swap-file.

My understanding is that suspend to disk works much easier with a swap
partition still, but my information could be out of date on that.
And of course swap smaller than ram makes suspend to disk not possible.

> I also add that:
> 
> 4. should deactivate root user by default, which is now considering a best
> practice;

Not sure I agree it is considered best practices.  A lot of distributions
do it, but not all.  I do prefer root login to work from the console if
I have to fix something.

> 5. should deactivate the source repos and asking to activate the "contrib"
> and "non-free" repos (like in Advanced Mode).
> 
> 
> I don't see any complicated tasks to achieve, others Linux distro already
> started to move in this direction while other *nix operative systems already
> do that since a long time.

Other distributions (Certainly the case for redhat based stuff in the
past) had to do it since they didn't have a working in place upgrade.
That rather makes it required that the installer can do an upgrade and
detect existing settings.  Debian seems to have always aimed for an in
place upgrade that worked, so the installer really only had the purpose
of the initial install.  It's one of the things that made me switch to
Debian over 20 years ago.  I have never had to do a reinstall of a Debian
system except on a machine that lost the disk and I didn't have a backup
of it (nothing important was kept on that system).  I really should
have replaced that other disk in the RAID1 within a reasonable amount
of time. :)

> The only issues I see here are the resistance to the changes and the fact
> that actually the D-I has some issue to recognize the encrypted partitions
> and if you want reinstall Debian you can't preserve any of the partitions
> you want because it will consider the encrypted disks as blanks.

Collecting all those settings does not sound like a trivial job, and based
on the normal use case of a Debian install, I sure don't see the value
in it.  How do you even decide which settings should be preserved and
which should not?  What if one of the settings is what broke your system?
If you screw up the system, go fix it.  You will learn something from it.
Blowing away the system and installing it again means you learn nothing,
waste a bunch of time, and will likely do it again in the future.  I have
certainly broken my installs over the years and had to fix it, but it has
always been possible.  Running unstable and experimental stuff at times

Re: Question about building a full bootable image using (Debian 7)

[Lennart Sorensen]

On Sat, Sep 28, 2019 at 01:21:19PM +, g4jht wrote:
> Hi, I am sending this to you guys in a sort of last resort desperation.
>  As it only relates to Debian as that is my current build environment.
> 
> Help Please.
> 
> My problem how to build a bootable iso image file (not of Debian)
> 
> I have an iso file [for an early version of UNIX (x86_32 code)].  I have
> stripped the files into a directory, then copied them (via tar)  into my iso
> build directory, made my modifications I am OK up to that point.

Copying the files from a CD does not include copying any boot code from
the CD.  Assuming it ever was bootable.

> My Question is:
> How do I create a new bootable iso image file from my build directory ready
> for burning onto a DVD.
> I tried just burning the build directory tree but did not boot (I suspected
> as much but did it anyway).
> I am obviously missing as step maybe tools. target is a 486 bare machine and
> a P6 machine in both cases without an O/S, what on the DVD will eventually
> end up on the HD, once the DVD "works".
> Any help appreciated, and I know this sort of an oddball question.
> 
> [please CC me directly with your solution, thank you.
> 
> regards, Dave :-) (Ps not a newbie).

How you make a bootable CD depends on the boot system supported
by the target system, and which boot loader you have.  On x86
machines, the boot system for CD has usually been 'el torito'
https://en.wikipedia.org/wiki/El_Torito_(CD-ROM_standard)

Certainly the mkisofs/xorriso/etc tools have options to tell it where
the boot loader floppy image or HD style boot files are.  Booting from
HD/USB is totally different, so making it boot from CD/DVD has nothing
to do with booting from HD.  Very few 486 machines can even boot from
CD at all in my experience.  It just wasn't a thing yet.  I remember
having to make boot floppies to install Windows NT4 on a Pentium Pro
in 1997, because the Adapter 2940UW firmware didn't support 'el torito
no emulation' boot yet, which NT used, while linux installs could boot
because they used 'el torito floppy emulation' boot mode instead.  At a
later time a firmware update for the scsi controller added the needed
support to allow directly booting NT and newer linux installers that
used the other mode.

-- 
Len Sorensen

Bug#929752: Changing quote signs in GPL allowed? [Was: Bug#929752: installation-guide: left quotes in gpl.xml are not correctly rendered in pdf ]

[Lennart Sorensen]

On Tue, Aug 06, 2019 at 08:30:56PM +0200, Holger Wansing wrote:
> I was about to commit these changes, however it came to my mind if such
> changes to the GPL are allowed?
> 
> At least the English variant of the GPL is 'official' and is not to be
> changed, so what about changing the quoting signs into   
> entities?

gpl.xml isn't official.  It isn't one of the files from the FSF.
There is a gpl-2.0.dbk[1] version available which in fact does use 
and  while every other file format uses ` and '.  So at least
there is precedence for using  tags instead.  After all if you
decided to use the docbook file as your source text, you would get the
quotes desired.

[1] https://www.gnu.org/licenses/old-licenses/gpl-2.0.dbk

-- 
Len Sorensen

Re: Support for non-Debian distros

[Lennart Sorensen]

On Fri, Aug 02, 2019 at 02:09:20PM +0300, Nagakamira wrote:
> Hi, I found certain distros which are using dpkg package manager as its
> default package management system. There's about 2: UHU Linux and Ataraxia
> Linux (and Yocto but .deb format can be used optionally). But they aren't
> based on Debian (or on its derivative). For example, UHU and Ataraxia are
> using repositories which are compatible with APT. That would be great if
> you can add support for them.

Just because they can use apt doesn't mean the packages are compatible
with debian.  And if they work with apt, then you can add the repositories
to your sources.list yourself.  If that doesn't work then almost certainly
those packages are not debian compatible.

Even ubuntu packages are not always compatible with debian and ubuntu
is actually based on debian.

-- 
Len Sorensen

Bug#929476: Debian 9 installation.

[Lennart Sorensen]

On Fri, May 24, 2019 at 11:10:43AM +0200, mb wrote:
> Package: installation-reports
> 
> Boot method: USB pen drive prepared in Windows10 with RUFUS (MBR, GPT, iso, 
> dd: always same problem) or with UBUNTU 18 dd command
> Image version: 
> https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/debian-9.9.0-amd64-DVD-1.iso
>   
> 
> Date: from 19 May to 24 May 2019
> 
> Machine: Acer spin 3
> Processor: I3
> Memory: 8 GByte
> Partitions: unallocated 52 GByte on sdd disk for dual boot with Windows10 Home
> 
> Output of lspci -knn (or lspci -nn):
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O ]
> Detect network card:[ ]
> Configure network:  [ ]
> Detect CD:  [E ]
> Load installer modules: [ ]
> Detect hard drives: [ ]
> Partition hard drives:  [ ]
> Install base system:[ ]
> Clock/timezone setup:   [ ]
> User/password setup:[ ]
> Install tasks:  [ ]
> Install boot loader:[ ]
> Overall install:[ ]
> 
> Comments/Problems:
> 
> The installation in Graphic mode after the language, country and locales 
> stops because cannot find the CD.
> It is not clear what is such "CD"? All installation software isn't in 
> thedebian-9.9.0-amd64-DVD-1.iso  
> 
>   file loaded on the USB pen drive?
> 
> Googled a lot, it seems most of people face a lot of trouble with Debian 
> installation but no solutions available.
> Is this Debian only for very expert users? I'm Using UBUNTU since 2012, even 
> when I was a complete newbie I succeed into dual boot installation,
> With Debian it seems I have to spend months for learning very advanced 
> knowledge or gathering information.
> I understood Debian was an operating  system accessible to everybody not 
> dedicated to very specialized Information technology people only.

Most people don't have a problem installing.  Of course searching will
mostly find the people that did have problems since people without
problems usually don't post anything to say "everything worked fine".

That laptop is very new and it is possible some part of the hardware
isn't supported by the kernel in Debian 9.  It was released in 2017
after all, quite a bit before that laptop existed.

You could try the installer for testing (The Debian 10 in development
right now) to see if that works better.  I suspect Debian 10 will make
it out sometime this year.

-- 
Len Sorensen

Re: Intel X553 NICs/ixgbe netinstall issues

[Lennart Sorensen]

On Thu, May 09, 2019 at 07:22:30AM +0100, Rory Campbell-Lange wrote:
> Target systems have A2SDi-8C-HLN4F motherboards each with 4 no. Intel
> x553 NICs.
> 
> The stable netinstall ixgbe module does not load the interfaces, even
> when modprobed by hand.
> 
> Buster netinstall 20190429-03:57 works fine. However I can't find a way
> of downgrading the installation to "stable", as suggested at
> 
> https://wiki.debian.org/DebianInstaller/FAQ#Q:_How_can_I_install_sid_.28unstable.29_with_DebianInstaller.3F

It suggests the exact opposite.  It suggests you can install stable and
then upgrade to unstable.  You can't downgrade.  It doesn't suggest that
at all.  Never could.  It suggests that people that want unstable can
use the working stable installer and upgrade to unstable rather than
try the potentially broken installer in testing.  Of course if stable
isn't working on your hardware, then installing stable is very very hard.

> I've tried expert mode in both console and graphical mode.
> 
> I'm not sure if the inability to downgrade the installation is a bug or
> policy. If the former I'm happy to report it.

It's a matter of reality.  Packages can support upgrading from previous
versions because they know what previous versions existed and how they
worked.  An old package can't downgrade from something that didn't exist
when it was made.  It doesn't make any logical sense.

> Tips on compiling the ixgbe module for stable on a machine with only a
> BMC and no NICs gratefully received; else how to downgrade a testing
> netinstall to stable.

Compiling a kernel module tends to only work for the kernel version
it was meant for, so the kernel in stable likely is too old for your
hardware and a newer module won't compile for it.  A newer kernel (like
the backport kernel) might work though.

I would think the simplest method to install would be
to get a supported USB or PCIe network card, use that to
install and then install the backport kernel, or possibly
use the out of tree ixgbe driver from intel as per
https://gist.github.com/DisasteR/db93d2db1ea82ecbc92a46eff3031b4f#install-ixgbe-module-with-dkms-support

-- 
Len Sorensen

Bug#925556: UEFI or not, can't mount /dev

[Lennart Sorensen]

On Tue, Mar 26, 2019 at 07:13:21PM +, Steve McIntyre wrote:
> On Wed, Mar 27, 2019 at 02:58:36AM +0800, 積丹尼 Dan Jacobson wrote:
> >Package: debian-installer
> >
> >Guess what, seen with ASUS X370-A:
> 
> Dan, you know better than this. A useful bug report needs much more
> information. For a start, what image did you use to install with? This
> looks like it *might* be on first boot after installation, but you're
> leaving me to guess at that. How did you partition, etc.? Were there
> any errors reported during installation?
> 
> Please help us to help you...

Well the picture appears to show root is sdb2 on a disk with sdb1 and
sdb2 partitions, and it can't mount /dev apparently because there is no
/dev directory on the root filesystem to mount it on.

At least that's what it looks like in the picture.

Clearly the initramfs was able to mount /dev and run fsck, but mounting
it to /root/dev to transfer to the real rootfs failed due to a missing
directory.

-- 
Len Sorensen

Re: Installer - add BIOS boot partition?

[Lennart Sorensen]

On Sat, Jan 12, 2019 at 05:55:50PM +1300, Richard Hector wrote:
> Ok - as long as I remember to install to both. There's no option to
> install to both in one invocation, is there? Or a config file that
> records which drives are/might be used for booting?

Hmm, I recall having it give a checklist in the past, but I could be
remembering wrong.

Certainly if I run dpkg-reconfigure grub-pc, it offers me a checklist
of which devices to install grub on, so having both sda and sdb selected
works fine.

-- 
Len Sorensen

Re: Installer - add BIOS boot partition?

[Lennart Sorensen]

On Fri, Jan 11, 2019 at 02:31:22PM +1300, Richard Hector wrote:
> That worked great, thanks. Though it seems the '1.0MB' free before my
> first partition wasn't big enough (or not aligned right?) so I had to
> start from scratch.
> 
> Incidentally, could/should I have made that RAID1? I created bios
> partitions on both my disks, and have grub-install-ed to both. The
> partitions do seem to be identical.

It might be possible to make it raid 1, although if you tell grub
to install to both of them, that should work fine, and in fact you
probably need that anyhow to get the bootstrap code into the MBR sector
on both disks.  I think you are fine the way it is.  That partition is
essentially an extension of the MBR sector for grub code so being per
disk makes sense.

And yes the partition tool won't let you create partitions that don't
start on a 1MB alignment, so even though there was enough room for a
partition there (of almost 1MB) it won't let you.  Not that loosing 1MB
is a big deal.  Having to start over probably wasn't that big a deal
either in this case.

-- 
Len Sorensen

Re: Installer - add BIOS boot partition?

[Lennart Sorensen]

On Thu, Jan 10, 2019 at 11:04:16PM +1300, Richard Hector wrote:
> Hi all,
> 
> I've just done most of an installation on a BIOS machine, with a pair of
> new 4TB disks, which require GPT.
> 
> Grub fails to install, which I possibly should have predicted - though I
> thought di might have either coped or warned me.
> 
> It seems I need a BIOS boot partition, and that it should fit in the
> space before my first existing partition, is that right? Any tips on
> creating such a thing, preferably from within the di environment?
> 
> Or do I need to do some partitioning before starting the installer?
> Links to relevant references or howtos welcome.

If you use guided partitioning the installer creates a 1MB partition
with 'use as' set to 'Reserved BIOS boot area' which then shows as type
'biosgrub'.

So that would be the type to create yourself.

-- 
Len Sorensen

Bug#838503: debian-installer: mdadm should not start syncing RAID1 arrays at full speed during installation

[Lennart Sorensen]

On Fri, Dec 07, 2018 at 12:22:38AM +, Steve McIntyre wrote:
> I've no idea why he things this is a regression. But this is something
> we should probably change anyway - installing on RAID is pointlessly
> slow here unless you know how to work around it. And it's been that
> way since ~forever.

For some reason I thought the limit used to be lower many years ago,
but I can't find any evidence of that.  Certainly the 20 max is a
default in the kernel since before it moved to git.  Perhaps the kernel
changed at some point and is more aggresive in going to the max than it
used to be?

But yes, I also think having the limit lower in the installer makes sense.
You are not protecting anything valuable yet at that point and would
like to get your system ready to use as soon as possible.

-- 
Len Sorensen

Re: Bug#905793: Why does the Installer formats given swap

[Lennart Sorensen]

On Fri, Aug 10, 2018 at 10:08:52AM +0200, Herbert Kaminski wrote:
> Am Thu, 9 Aug 2018 14:14:15 -0400
> schrieb lsore...@csclub.uwaterloo.ca (Lennart Sorensen):
> 
> > [...] 
> > Well 99.9% of installs don't have another linux on the system, 
>^
> Interesting. How did you get that figure?

Totally made it up. :)

I suspect I guessed low in fact.

-- 
Len Sorensen

Bug#905793: Why does the Installer formats given swap

[Lennart Sorensen]

On Thu, Aug 09, 2018 at 07:37:15PM +0200, John Landmesser wrote:
> Package: debian-installer
> 
> 
> is there a reason why the installer defaults to format given swap partition?
> 
> I now know that you can opt out to format swap, but i don't understand that
> formatting swap is default!
> 
> I had several Linux on same PC and after installing aditional debian, the
> other Linux didn't find their swap anymore because UUID has changed.
> 
> I fixed it but i thought: "Debian, that should be a no go, formatting given
> swap"
> 
> So i'm curious for the reason for this behaviour!

Well 99.9% of installs don't have another linux on the system, so any
swap partition would be a new one that you just created, so you want
it formatted, or it wouldn't be used.

Maybe it would be possible to make it default to not format a swap
partition if that partition already exists and isn't being created
from scratch.

The installer at least has the option to not format it for the extremely
unusual case of wanting to reuse an existing swap partition.

-- 
Len Sorensen

Re: g++-8 and g++-7 installed, reproducing a FTBFS

[Lennart Sorensen]

On Wed, Jul 25, 2018 at 05:51:37PM +0200, Geert Stappers wrote:
> Acknowledge.
> 
> How to enforce that  g++  is g++-8 ?
> 
> If it is `apt-get source gcc-defaults && cd gcc-defaults && debuild -uc -us`,
> please say so.

Well g++ 1.178 on my system depends on g++-8 version 8.1.0-1 so I think
that makes sure version 8 is the default.

If your g++ package is older, you would want a newer version.

-- 
Len Sorensen

Re: Boot Order

[Lennart Sorensen]

On Tue, Feb 27, 2018 at 09:01:18PM -0500, Dan Norton wrote:
> Why insert itself anywhere in the first place? The machine booted
> before the installation. To start installing, the installation medium
> is placed in a CD drive or USB port and the machine is rebooted. During
> installation, other OSs are detected by the installer. The installer
> forms the grub menu with the latest install first and the other OSs
> following. Installer finishes by reminding the admin to remove the
> installation medium and it reboots the machine. The latest install
> boots unless the admin intervenes. Where in this process is a
> requirement to tinker with the UEFI menu?

How are you supposed to get grub to run at all if you don't add a boot
entry for it?  The grub is installed by this installer after.

There is nothing that makes the latest install boot unless you add it
to the boot order.  On legacy bios it was different because there you
just put what you wanted into the MBR boot sector and the BIOS was
typically configured to boot from the harddisk.  UEFI does not work
that way.  UEFI uses an explicit entry specifying which filename to boot
from which harddisk.  So an entry is created specifying to boot the
grub_x64.efi file from the FAT partition containing the bootloaders.

Now there are some default filenames that UEFI will look for if not
explicitly told, but they are not always supported and most installers
don't use those filenames because it isn't reliable, and the explicit
entry is the official way to do it.

The installer has no way to tell what else was on your system already
and how it booted.

-- 
Len Sorensen

Re: Boot Order

[Lennart Sorensen]

On Mon, Feb 26, 2018 at 05:42:36PM -0500, Dan Norton wrote:
> I would hate to have to do something because windows does it :-)
> 
> No one's yet mentioned secure boot as a justification. AIUI some
> manufacturers are making it so that you can't even disable secure boot.
> How will you multi-boot linux and windows, or replace windows entirely
> with such a machine?

Secureboot has nothing to do with it.  All secureboot means is that it
won't boot something that isn't signed by a trusted key.  So if enabled
you wouldn't be able to even boot the installer if it wasn't signed.

I have not yet seen a machine where you can't disable secureboot.
For Windows 8 it was a requirement to allow disabling it (but to have
it enabled by default) to get a Windows 8 Lego on the box.  I think
Windows 10 has the same requirement.  Now on some machines you have to
set a UEFI admin password before you get the option to disable secureboot
for some reason.

-- 
Len Sorensen

Re: Boot Order

[Lennart Sorensen]

On Fri, Feb 23, 2018 at 10:18:00PM -0500, Dan Norton wrote:
> Installing either stretch or buster via netinst results in changes to
> the bios menu. Under "UEFI Boot Sources" the term "Hard Drive" is
> replaced with "debian" and this entry is put first in the boot order.
> 
> The PC is:
> Hewlett-Packard HP Pro 3400 Series MT/2ABF, BIOS 7.16 03/23/2012
> 
> Please tell me the justification for putting "debian" in the menu and
> having it boot first, ahead of CD/DVD/USB. Thanks.

With UEFI, adding an entry to the boot meny is what you do when you
install an OS you want to be able to boot.  UEFI does not rely on the
boot sector anymore the way legacy BIOS did.

Adding it first makes sense since why install it if you don't want to
use it?  Advanced users can always rearrange the order if they want
something else.  No way an installer could guess where in an existing
list to insert itself.  First is the only sane default option.

Having a system default to booting from USB or CD makes no sense and is
rather unsafe too.

Installing windows does the same thing, as it should.

-- 
Len Sorensen

Bug#888515: debian-installer: UEFI boot menu (grub) misses the help screen

[Lennart Sorensen]

On Fri, Jan 26, 2018 at 05:16:38PM +0100, Samuel Thibault wrote:
> Hello Grub maintainers, any idea about this?

Is this too much of a hack:



menuentry ' ' {true}
menuentry 'Help:' {true}
submenu '  Prerequesites for installing Debian.' {
menuentry 'PREREQUISITES FOR INSTALLING DEBIAN' {true}
menuentry ' ' {true}
menuentry 'You must have at least 105 megabytes of RAM to use this 
Debian' {true}
menuentry 'installer.' {true}
menuentry ' ' {true}
menuentry 'You should have space on your hard disk to create a new disk 
partition' {true}
menuentry "of at least 680 megabytes to install the base system.  
You'll need more" {true}
menuentry 'disk space to install additional packages, depending on what 
you wish' {true}
menuentry 'to do with your new Debian system.' {true}
menuentry ' ' {true}
menuentry 'See the Installation Guide or the FAQ for more information; 
both' {true}
menuentry 'documents are available at the Debian web site, 
http://www.debian.org/' {true}
menuentry ' ' {true}
menuentry 'Thank you for choosing Debian!' {true}
}
submenu '  Boot methods for special ways of using this CD-ROM' {
menuentry 'BOOT METHODS' {true}
menuentry ' ' {true}
menuentry 'Available boot methods:' {true}
menuentry ' ' {true}
menuentry 'installgui' {true}
menuentry '  Start the installation using the graphical installer -- 
this is the' {true}
menuentry 'install' {true}
menuentry '  Start the installation using the text mode installer' 
{true}
menuentry 'expertgui' {true}
menuentry '  Start the installation in expert mode, for maximum 
control, using' {true}
menuentry '  the graphical installer' {true}
menuentry 'expert' {true}
menuentry '  Start the installation in expert mode using the text mode 
installer' {true}
}

Obviously the text has to be corrected I just copied from isolinux pages
as an example.

-- 
Len Sorensen

Bug#888513: huge graphical bug

[Lennart Sorensen]

On Fri, Jan 26, 2018 at 04:21:08PM +0100, melissa M. wrote:
> Package: debian-installer
> Version: stable
> Severity: grave
> 
> hi maintainer,
> 
> big graphical bug with the installer netinstall of Debian Stretch 9.3, but
> also Testing and Sid.
> 
> Ditto with the installer mini iso-Stretch 9.3
> 
> I created my bootable usb drive with "dd", unetbootin, etcher, but the big
> graphical bug still present :(
> 
> I have a laptop pc Toshiba Satellite P870-338 with the Optimus technology
> (graphics chipset intel i7 3630qm and nvidia GT 630m) with a bios 100% uefi
> 
> this is the screen that I get with the installer, it is impossible to
> install in these conditions.
> http://pix.toile-libre.org/upload/original/1516915180.jpg
> 
> I think I might be an isolated case, but I still haven't found solution to
> resolve this bug very annoying.
> 
> the bug has been present since two years...
> 
> is there a workaround ??
> a parameter to pass to the kernel ??
> 
> this bug est present on the mini iso, and the iso netinstall (testing,
> stable and sid). :'(
> 
> please consider my bug report.

Does it happen in both graphical and text mode install?

-- 
Len Sorensen

Re: Easier installer?

[Lennart Sorensen]

On Sun, Nov 19, 2017 at 12:26:58PM +0100, Thomas Lange wrote:
> > On Sun, 19 Nov 2017 11:56:35 +0100, Thomas Lange 
> >  said:
> 
> > JFTR, I just look at an openSuse Tumbleweed installation. They are
> > using a world map for selecting the timezone.
> And Linux Mint is showing a world map with timezones, but no country borders.

Do they have a zoom?  Otherwise some timezones would be very very hard
to select.

-- 
Len Sorensen

Re: Easier installer?

[Lennart Sorensen]

On Sat, Nov 18, 2017 at 09:20:36PM +, Ben Hutchings wrote:
> Implementing locale selection using a map also runs the risk of getting
> your software banned in countries that disagree with where you put the
> borders.

Also tricky in the non-gui installer, which at least some systems have
to use (serial or ssh install on systems without graphics).

Sure those systems are probably not as likely to be the typical simple
user cases.

-- 
Len Sorensen

Re: Where can I find out more regarding debian-mac-testing-amd64-netinst.iso

[Lennart Sorensen]

On Thu, Nov 16, 2017 at 08:51:08AM -0800, Colin Williams wrote:
> It might be good to document that somewhere. Still haven't had any luck
> with the installer but that's similar to all the other distros tried.

https://wiki.debian.org/MacMiniIntel

-- 
Len Sorensen

Re: Where can I find out more regarding debian-mac-testing-amd64-netinst.iso

[Lennart Sorensen]

On Wed, Nov 15, 2017 at 06:26:33PM -0800, Colin Williams wrote:
> Yes I fumbled the block partition information on top of the block device
> but gave it another shot. sudo dd bs=4M
> if=/home/colin/Downloads/debian-mac-testing-amd64-netinst.iso of=/dev/sde
> and it still wasn't bootable. However as mentioned previously the debian
> daily build found here
> https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/
> booted to the splash screen. No luck beyond that when playing with the
> options.
> 
> debian-testing-amd64-netinst.iso

Well apparently the -mac- versions of the iso only contain BIOS boot,
not UEFI boot and are intended for some early x86 macs with very buggy
firmware.  Apparently newer machines should work fine with the normal
installer.

-- 
Len Sorensen

Bug#881626: busybox: enable telnetd

[Lennart Sorensen]

On Tue, Nov 14, 2017 at 06:59:41PM +, Holger Levsen wrote:
> you are aware that this would only cause (these) people to switch away
> from Debian, but not from telnet?

I honestly believe they just haven't tried.  As long as you indulge them,
they will keep training new people with bad habits.  It won't go away
until you make it go away.  Sometimes you really do have to tell
people no.

> also, I miss your removal requests for the telnetd and ftpd and
> (countless) other packages.
> 
> to the original poster: what's wrong with installing telnetd? its only
> 103kb in size...

Well at least in a separate package you don't accidentally get it just
by installing busybox.

-- 
Len Sorensen

Bug#881626: busybox: enable telnetd

[Lennart Sorensen]

On Mon, Nov 13, 2017 at 05:16:26PM +, Luca Boccassi wrote:
> Package: busybox
> Version: 1.27.2-1
> Severity: wishlist
> Tags: patch
> 
> Dear Maintainers,
> 
> Please consider enabling telnetd in the busybox package. A tiny and
> trivial patch to set the config is attached inline. A rebuild with that
> change seems to work fine.
> 
> As much as I wish it wasn't the case, telnet is still widely used,
> especially in the ISP/telco world. Telcos networking engineers expect
> to be able to telnet into boxes in their network even today.
> 
> Having telnetd available without having to rebuild busybox would be
> extremely handy when using Debian (or derivatives) in small boxes (eg:
> arm64) inside a telecommunication provider's network.

Anything that makes it more work for you and hence gives more incentive
for you to get the clueless people that want to keep using telnet to
change is a good thing.  Allowing telnet access ought to be made as
difficult as possible.

People have been saying to not use telnet for about 20 years now.
They better have learned by now.

-- 
Len Sorensen

Re: bts reassign 878722 partman-auto

[Lennart Sorensen]

On Fri, Nov 10, 2017 at 04:19:14PM +, Ben Hutchings wrote:
> This is true, but I don't think it's a good reason not to implement a
> mostly-reliable heuristic.
> 
> If there are multiple disks, there are usually going to be just 2 of
> them, one of which contains the installer.  In any installer build
> other than netboot, it will look for its own disk in order to load
> udebs.  Once it has done that, it can determine that the other disk is
> the one to install on.  That's a pretty good heuristic.

I think more than one disk in the machine isn't that unusual.

> Aside from that, we can also make a guess based on the bus type:
> 
> - ATA: probably internal

eSATA is not that unusual.

> - NVMe: probably internal
> - USB: probably external
> - MMC/SD: ambiguous (eMMC must be internal, and Linux has a notion of
> 'non-removable' slots, but I don't think userland has this info)
> 
> If we could get more information about MMC/SD slots then we should be
> able to implement an heuristic that would work for >99% of cases.

You can certainly try to make a good guess, but it certainly still needs
to be confirmed.

-- 
Len Sorensen

Re: bts reassign 878722 partman-auto

[Lennart Sorensen]

On Tue, Nov 07, 2017 at 09:56:31PM +0100, Michael Kesper wrote:
> Yes sure but why can't I correct it after the fact?
> Even "rescanning disks" does not let you chose any other disks.
> 
> Is there a way of chosing "first internal disk" then?
> Imagine I want to create one installation medium for laptops which only
> differ whether they are set up with a NVM or a sata SSD.
> I did not find any documentation helping me with this.

I can't think of any reliable way to determine what is an internal or
external disk, and the concept of 'first' doesn't even have meaning.

-- 
Len Sorensen

Bug#849400: debian-installer: LUKS on rootfs and boot

[Lennart Sorensen]

On Wed, Sep 27, 2017 at 01:47:52PM +0200, Ben Hutchings wrote:
> DO NOT use a fat32 partition for /boot!
> 
> It will appear to work, but the first upgrade of a package that
> installs into /boot will fail because dpkg cannot create a hard link
> there.

Maybe /boot/efi was what was meant.

-- 
Len Sorensen

Re: Problem when installing stretch with btrfs

[Lennart Sorensen]

On Wed, Sep 20, 2017 at 06:04:16PM +0200, Pierre Couderc wrote:
> Mmm, why ? is  legacy mode a problem ?

Well depends what you want to do.  Generally legacy mode requires the
disk be partitioned in DOS style partitions (MBR) which has a limit of
2TB disks, while UEFI requires GPT which does not have that limit.

Also you are limited to 4 primary partitions with MBR, while GPT allows
128 partitionts.  You can get past the 4 primary limit with extended
partitions, but they are a hassle sometimes.

UEFI booting is probably more future proof if you want to be able to
move a disk to another system later, although at the same time MBR is
more legacy machine compatible.

UEFI does not support installing the boot loader on a software raid
partition and having it work as simply as MBR did with grub.  It has to
be a plain partition on the disk of the type ESP with FAT32 or other
compatible filesystem, which is a bit annoying.  It might be possible
to do a software raid partition for that if you pick the type that has
the meta data at the end (but that is not the default), since then it
would still look like a normal disk to the firmware.

> > Usually the boot menu will list the same USB key twice.  Once for UEFI
> > boot and once for legacy boot.
> > 
> In fact my boot asks me nothing...(Asus P8H67_M_LE board)

Well to get a boot menu you usually have to hit F8 or F12 or something.
Default boot could be anything.

-- 
Len Sorensen

Re: Problem when installing stretch with btrfs

[Lennart Sorensen]

On Wed, Sep 20, 2017 at 05:19:14PM +0200, Pierre Couderc wrote:
> On 09/20/2017 04:38 PM, Steve McIntyre wrote:
> > On Wed, Sep 20, 2017 at 04:32:06PM +0200, Pierre Couderc wrote:
> > > On 09/20/2017 03:06 PM, Steve McIntyre wrote:
> > > > What does fdisk show on sdb for you?
> > > Normal results :
> > > root@nous:/# fdisk -l /dev/sdb
> > > Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
> > > Units: sectors of 1 * 512 = 512 bytes
> > > Sector size (logical/physical): 512 bytes / 512 bytes
> > > I/O size (minimum/optimal): 512 bytes / 512 bytes
> > > Disklabel type: dos
> > > Disk identifier: 0x9c9fb5db
> > > 
> > > Device Boot   StartEndSectors  Size Id Type
> > > /dev/sdb1  *   204819537911951744  953M ef EFI (FAT-12/16/32)
> > > /dev/sdb2   1953792 3907028991 3905075200  1.8T 83 Linux
> > > 
> > > and on sda the same results you get on your sdc !!
> > OK, that's good.
> > 
> > ...
> > 
> > > > Right. Either you're not booted in EFI mode, or /sys is not
> > > > mounted. Grub is assuming you're on a normal BIOS-boot machine. Make
> > > > sure that you have /sys mounted, and /dev/sdb1 mounted on /boot/efi,
> > > > then run
> > > > 
> > > > # grub-install --target x86_64-efi
> > > > 
> > > > and see what it does.
> > > > 
> > > root@nous:/# mount /dev/sdb1 /boot/efi
> > > root@nous:/# mount /dev/sdb1 /boot/efi
> > > mount: /dev/sdb1 is already mounted or /boot/efi busy
> > >/dev/sdb1 is already mounted on /boot/efi
> > > root@nous:/# grub-install --target x86_64-efi
> > > grub-install: error: /usr/lib/grub/x86_64-efi/modinfo.sh doesn't exist.
> > > Please specify --target or --directory.
> > > root@nous:/# ls /usr/lib/grub
> > > grub-mkconfig_lib  i386-pc
> > > 
> > > I thank you very much of your help - and I am honoured - but I could 
> > > follow
> > > some hoto if find one, but I do not find one.
> > > It is surprising, I suppose am not the first to try make a btrfs raid1...
> > Actually, that's not your problem. My best guess is that you've done
> > an installation booted in BIOS mode, not UEFI mode. That's why you've
> > got grub-pc installed rather than grub-efi-amd64. Do you actually care
> > about booting via UEFI, or are you just looking for a bootable system?
> > If the latter, simply reformat your ESP (/dev/sdb1) to be a normal
> > ext2 or ext3 partition and use that as /boot. You could even do a RAID
> > /boot using sdb1 and sdc1 together...
> > 
> I am sure that my "bios" is UEFI.
> But I have done as you say, in case it exists an hypothetical  "BIOS mode"
> in UEFI :
> 
> root@nous:~# grub-install /dev/sdb1
> Installing for i386-pc platform.
> grub-install: warning: File system `ext2' doesn't support embedding.
> grub-install: error: filesystem `btrfs' doesn't support blocklists.
> 
> And it fails (as usual with a initramfs prompt)...

if you had booted in UEFI mode rather than legacy compatibility mode,
grub should have said:

"Installing for x86_64-efi platform."

i386-pc platform means it is running in legacy mode.

You really should boot the installer in UEFI mode instead.

Usually the boot menu will list the same USB key twice.  Once for UEFI
boot and once for legacy boot.

-- 
Len Sorensen

Re: Run debootstrap twice

[Lennart Sorensen]

On Wed, Aug 16, 2017 at 08:14:27PM +0100, Brian Potkin wrote:
> And, also unfortunately, you don't say why it is not possible. Talk
> about information underload!

The assumption is that you have no files, so that debootstrap can extract
debs, then when enough is there, it can redo the packages properly with
dpkg and end up with a sane state for the packaging system.

If there are already files there, how would debootstrap have a clue how
to end up in a sane state where all the files present are accounted for
in the packaging system?

It only works now, because debootstrap is the only thing that puts files
there and hence knows what to do to make the package system state match
what is there.  It has to require that no files exist when it starts to
end up with something sane.

-- 
Len Sorensen

Bug#870628: Please warn about slow starts on USB

[Lennart Sorensen]

On Thu, Aug 03, 2017 at 07:55:09PM +0200, Samuel Thibault wrote:
> The gtk initrd is like 38MB, at USB 1.0 speed (1.5Mbps) that's almost
> two minutes yes.  I however wonder how old a computer needs to be to be
> only 1.0...

I have never seen a machine with only 1.0 USB that could boot from USB.
I don't think the concept of booting from USB existed until we had USB 2.
It was just too slow to comprehend trying.

And how could a 64bit machine have only USB 1.0?  Not a chance.

Now if the USB key happens to be a Kingston Datatraveller G3 like the
one on my desk, then I can believe it taking forever and crashing.
That thing is an unreliable piece of crap that somehow claims to be USB3.

-- 
Len Sorensen

Bug#868994: text too small to read on text based installer on high resolution screen

[Lennart Sorensen]

On Thu, Jul 20, 2017 at 11:30:26AM +1000, Jason Lewis wrote:
> Package: installation-reports
> 
> Boot method: usb stick
> Image version:
> http://saimei.ftp.acc.umu.se/cdimage/unofficial/non-free/cd-including-firmware/9.0.0+nonfree/amd64/iso-cd/firmware-9.0.0-amd64-netinst.iso
> Date: 2017-07-20
> 
> Machine: Dell Precision 5520
> Processor: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
> Memory: 32gb
> Partitions: n/a
> 
> Output of lspci -knn (or lspci -nn):
> 00:00.0 Host bridge [0600]: Intel Corporation Device [8086:5910] (rev 05)
> Subsystem: Dell Device [1028:07bf]
> 00:01.0 PCI bridge [0604]: Intel Corporation Skylake PCIe Controller
> (x16) [8086:1901] (rev 05)
> Kernel driver in use: pcieport
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Device
> [8086:591b] (rev 04)
> Subsystem: Dell Device [1028:07bf]
> 00:04.0 Signal processing controller [1180]: Intel Corporation Skylake
> Processor Thermal Subsystem [8086:1903] (rev 05)
> Subsystem: Dell Device [1028:07bf]
> 00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-H USB 3.0
> xHCI Controller [8086:a12f] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> Kernel driver in use: xhci_hcd
> Kernel modules: xhci_pci
> 00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise
> Point-H Thermal subsystem [8086:a131] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> 00:15.0 Signal processing controller [1180]: Intel Corporation Sunrise
> Point-H Serial IO I2C Controller #0 [8086:a160] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> 00:15.1 Signal processing controller [1180]: Intel Corporation Sunrise
> Point-H Serial IO I2C Controller #1 [8086:a161] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> 00:16.0 Communication controller [0780]: Intel Corporation Sunrise
> Point-H CSME HECI #1 [8086:a13a] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> 00:16.3 Serial controller [0700]: Intel Corporation Sunrise Point-H KT
> Redirection [8086:a13d] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> Kernel driver in use: serial
> 00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-H SATA
> controller [AHCI mode] [8086:a102] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> Kernel driver in use: ahci
> Kernel modules: ahci
> 00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Express
> Root Port #1 [8086:a110] (rev f1)
> Kernel driver in use: pcieport
> 00:1c.1 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Express
> Root Port #2 [8086:a111] (rev f1)
> Kernel driver in use: pcieport
> 00:1d.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Express
> Root Port #9 [8086:a118] (rev f1)
> Kernel driver in use: pcieport
> 00:1d.4 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Express
> Root Port #13 [8086:a11c] (rev f1)
> 00:1d.6 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Express
> Root Port #15 [8086:a11e] (rev f1)
> Kernel driver in use: pcieport
> 00:1f.0 ISA bridge [0601]: Intel Corporation Sunrise Point-H LPC
> Controller [8086:a154] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> 00:1f.2 Memory controller [0580]: Intel Corporation Sunrise Point-H PMC
> [8086:a121] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> 00:1f.3 Audio device [0403]: Intel Corporation Device [8086:a171] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> 00:1f.4 SMBus [0c05]: Intel Corporation Sunrise Point-H SMBus
> [8086:a123] (rev 31)
> Subsystem: Dell Device [1028:07bf]
> 01:00.0 3D controller [0302]: NVIDIA Corporation Device [10de:13b6] (rev a2)
> Subsystem: Dell Device [1028:07bf]
> 02:00.0 Network controller [0280]: Intel Corporation Device [8086:24fd]
> (rev 78)
> Subsystem: Intel Corporation Device [8086:0050]
> Kernel modules: iwlwifi
> 03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A
> PCI Express Card Reader [10ec:525a] (rev 01)
> Subsystem: Dell Device [1028:07bf]
> Kernel driver in use: rtsx_pci
> Kernel modules: rtsx_pci
> 04:00.0 Non-Volatile memory controller [0108]: Toshiba America Info
> Systems Device [1179:010f] (rev 01)
> Subsystem: Toshiba America Info Systems Device [1179:0001]
> Kernel driver in use: nvme
> Kernel modules: nvme
> 06:00.0 PCI bridge [0604]: Intel Corporation DSL6340 Thunderbolt 3
> Bridge [Alpine Ridge 2C 2015] [8086:1576]
> Kernel driver in use: pcieport
> 07:00.0 PCI bridge [0604]: Intel Corporation DSL6340 Thunderbolt 3
> Bridge [Alpine Ridge 2C 2015] [8086:1576]
> Kernel driver in use: pcieport
> 07:01.0 PCI bridge [0604]: Intel Corporation DSL6340 Thunderbolt 3
> Bridge [Alpine Ridge 2C 2015] [8086:1576]
> Kernel driver in use: pcieport
> 07:02.0 PCI bridge [0604]: Intel Corporation DSL6340 Thunderbolt 3
> Bridge [Alpine Ridge 2C 2015] [8086:1576]
>   

Bug#824648: win32-loader: reproduced error (0xc000007b g2ldr.mbr)

[Lennart Sorensen]

On Tue, Jul 18, 2017 at 10:40:30AM +0200, standard wrote:
> Package: win32-loader
> Followup-For: Bug #824648
> 
> I tried to install Debian (9.0) on a Tablet with Windows 10 Home. 
> * SSD-Harddrive with GPT
> * 2 GB RAM
> * 64 bit CPU
> * UEFI-BIOS
> 
> After restart I got the error 0xc07b and error message for g2ldr.mbr
> 
> As it turned out, the UEFI (and Windows) was only 32 bit(!)

Yes Windows requires UEFI to match in bit level.

> Eventuelly I managed to create a bootable USB key. It needed a 
> EFI/BOOT/bootia32.efi file to work.
> 
> The problem might be related to the 32 bit system instead of 64 bit.

At least in Debian 8, I believe the only media to support 32bit UEFI
was the i386/amd64 multiarch net install image.  I know I have used that
one successfully on an intel system with 32bit UEFI.

I didn't check if Debian 9 has similar limits on 32bit UEFI support in
the installer.  It is a pretty rare system type to encounter fortunately.

-- 
Len Sorensen

Bug#866085: At least it should be the option to not download

[Lennart Sorensen]

On Wed, Jun 28, 2017 at 08:52:31AM +0200, Narcis Garcia wrote:
> If you *will* be connected to the internet you *will* need to install
> security updates;
> Internet is not the only source for packages (). If someone
> installs Debian on 3 computers (or repeats installation 3 times), it
> shouldn't mean to use 3x internet traffic repeating installer downloads.
> 
> A) This user can save and reuse packages cache and apply updates at the
> convenient moment.
> B) When repeating install at the same computer (e.g. changing install
> decisions such as partitioning, architecture, etc.) the user only needs
> updates on final one.
> 
> Most of internet uses on the world have really low bandwidth accessing
> to the internet, and making (some) unnecessary downloads can be a money
> & time problem.
> 
> +
> I've participated on an "install party" where only half of Debian
> installs could be done because of this issue.

If you are doing an install party, set up a proxy server.  That really
really helps a lot.

-- 
Len Sorensen

Re: Trouble stacking mdadm, multipath and lvm at boot

[Lennart Sorensen]

On Mon, Jun 26, 2017 at 02:21:43PM -0400, E V wrote:
> I'm trying to get mdadm to assemble an array on some multipath disks
> at boot. System is a fresh install of stretch. By default it seems the
> mdadm array auto assembles before the multipath devices are created
> and thus doesn't use the dm- multi path devices but just the sdx
> devices, which prevents the multipath devices from ever getting
> created. Adding the DEVICE lines in mdadm.conf for the
> /dev/mapper/mpathx devices kind of reverses the problem. Now the
> multipath devices do get created, but the array(and thus the lvol &
> filesystem) never gets assembled on boot. In the old init days I'd
> probably add a script that runs mdadm --assemble and mount at the end
> of boot, but not sure what the right way to handle this in systemd is.
> mdadm.conf lines:
> 
> DEVICE /dev/mapper/mpathb /dev/mapper/mpathc /dev/mapper/mpathd
> /dev/mapper/mpathe
> ARRAY /dev/md/0
> devices=/dev/mapper/mpathb,/dev/mapper/mpathc,/dev/mapper/mpathd,/dev/mapper/mpathe
> metadata=1.2 spares=1 name=tst3:0
> UUID=7809f500:667e7a8f:45222d03:7405415b
> 
> 
> Thoughts or suggestions?

Why not let mdadm manage multipath instead of getting dm involved?

-- 
Len Sorensen

Re: WiFi install

[Lennart Sorensen]

On Mon, Jun 19, 2017 at 10:07:20PM +0100, Steve McIntyre wrote:
> No, there are *unofficial* non-free versions of the live images
> available too, for exactly this purpose.

Oh that handy.

-- 
Len Sorensen

Re: WiFi install

[Lennart Sorensen]

On Sun, Jun 18, 2017 at 06:48:11PM -0700, Charles Chambers wrote:
> Has anyone else tried to install 9.0 over WiFi yet?  I have two laptops
> that require the nonfree repositories for wifi drivers, but the live DVDs
> for 8.x have issues with installing over WiFi.

The official installer does not include non-free, so if your wifi requires
that, you will have to supply the firmware on a usb key or something when
the installer needs it, or by using a non-free installer image instead
(which probably only exists for netinst, not the live images).

-- 
Len Sorensen

Re: speech-enabled expert/rescue/autoinstall keyboard shortcuts

[Lennart Sorensen]

On Thu, Mar 23, 2017 at 02:56:02AM +0100, Samuel Thibault wrote:
> MENGUAL Jean-Philippe, on mer. 22 mars 2017 03:57:37 +0100, wrote:
> > And what about affecting shift-s or ctrl-s to run tts in the rescue
> > mode?
> 
> That's not really simple to implement actually. One has to have a way to
> start rescue mode anyway.
> 
> And it seems that just like me, people don't actually use the shortcuts,
> so I have commited stealing them for speech.  I have updated the manual
> and the wiki.

Well make sure it isn't control-s since that's already taken by XOFF.

-- 
Len Sorensen

Re: partman - tmpfs?

[Lennart Sorensen]

On Tue, Feb 21, 2017 at 04:15:23PM +0100, Alexander Skwar wrote:
> Hm, on Ubuntu 16.04:
> 
> $ sudo systemctl enable tmp.mount
> Failed to execute operation: No such file or directory

Apparently a differnet issues caused it to be slightly changed.

You now need:

cp /usr/share/systemd/tmp.mount /etc/systemd/system/tmp.mount
systemctl enable tmp.mount

That does work.

> And all the wikis and howtos that I can find, say that
> /etc/fstab is to be modified on Ubuntu.

That was before systemd.

-- 
Len Sorensen

Re: partman - tmpfs?

[Lennart Sorensen]

On Mon, Feb 20, 2017 at 04:24:33PM +0100, Alexander Skwar wrote:
> I'd like to create a debian-installer partman recipe for unattended
> installation of Ubuntu 16.04 systems, where tmpfs should be used for
> /tmp.
> 
> I tried having this in my preseed file:
> 
> 
> d-i partman-auto/expert_recipe string \
>   EveryWareDesktop :: \
>   1 1 1 free  \
>   $bios_boot{ }   \
>   method{ biosgrub }  \
>   . \
>   768 768 768 fat32   \
>   $primary{ } \
>   method{ efi }   \
>   format{ }   \
>   . \
>   100 1000 10 ext3\
>   $defaultignore{ }   \
>   $primary{ } \
>   method{ lvm }   \
>   device{  }\
>   vg_name{ system }   \
>   . \
>   4096 4096 4096 linux-swap   \
>   $lvmok{ } in_vg{ system }   \
>   lv_name{ swap } \
>   method{ swap } format{ }\
>   . \
>   4096 8192 10240 ext4\
>   $lvmok{ } in_vg{ system }   \
>   lv_name{ root } \
>   method{ format } format{ }  \
>   use_filesystem{ } filesystem{ ext4 }\
>   label{ root }   \
>   mountpoint{ / } \
>   options/noatime{ noatime }  \
>   options/data{ data=writeback }  \
>   options/user_xattr{ user_xattr }\
>   options/grpquota{ grpquota }\
>   options/usrquota{ usrquota }\
>   . \
>   1 2 3 tmpfs \
>   method{ format } format{ }  \
>   use_filesystem{ } filesystem{ tmpfs }   \
>   mountpoint{ /tmp }
> 
> 
> 
> But this did not create a "/tmp" line in the resulting /etc/fstab.
> 
> Would anyone maybe have a working example at hand?
> 
> I could, of course, also use a script which is run in the target
> during installation, but I'd rather have partman do this for me ;)

As far as I can tell the correct way to enable /tmp being tmpfs with
systemd on debian (I would think Ubuntu is the same) is:

systemctl enable tmp.mount

Not sure how to preseed that, but I don't think you do it by messing
with fstab entries.

Maybe something like:

preseed/late_command="systemctl enable tmp.mount"

-- 
Len Sorensen

Bug#855415: installation-reports: Debian-Testing fails to reboot after installation.

[Lennart Sorensen]

On Fri, Feb 17, 2017 at 07:14:11PM +0100, Michael Siemmeister wrote:
> Last week I tried to install Debian in a virtual-box. Currently I use
> Debian 8.7 for running the virtual-box program. I managed to install
> Debian stable without any problems. Then I cloned the virtual-box and
> tried an upgrade to Debian-testing. I think, it worked. After a while
> I shut down the virtual-machine. When trying to reboot, it did not
> start properly. I just got some messages like 'Created slice User
> Slice of Debian-gdm.', 'Starting User Manager ofr UID 117.', and
> finally 'Started Daily apt activities.'. Then the virtual display just
> starts blinking. Nothing else happens. After three minutes or so the
> display freezes.
> 
> Then I thought, okay, maybe the virtualbox program has got a bug. So,
> I downloaded the Debian-Testing-DVD-1 via jigdo-lite and copied it to
> a USB drive. I tried to install Debian-Testing on an old laptop, a
> Toshiba Satellite from 2009. Unfortunately I don' remember the exact
> model number. I had already installed Debian Stable without any
> problems on that laptop some months ago. The Debian-Testing installer
> worked fine and finally, it asked me to reboot the PC. After rebooting
> similar problems occured. There was a message about the graphics card
> and after 30 seconds the display started blinking. Nothing else
> happened.
> 
> As I have written above these errors only occured with Debian-Testing.
> Debian-Stable worked fine on Virtualbox and the Toshiba laptop. So, I
> don't think there are some hardware problems.

If you are running virtualbox on jessie, that would be version 4.3.36.
I do find a lot of problems reported with gnome 3 and virtual box 4.x.

I wonder if virtualbox 5.1.8 in jessie-backports would solve the problem.

I also wonder if having virtualbox 4.x as host with 5.x guest utilities
installed could cause problems (I suspect the guest utilities are
automatically installed and for stretch they would be version 5.x,
not 4.x).

After all gnome3 mandates 3D accaleration, and having drivers that don't
match the hardware (virtualbox in this case) could be a problem.

-- 
Len Sorensen

Re: Multibboot vanishes swap UUID

[Lennart Sorensen]

On Wed, Feb 08, 2017 at 04:18:32PM +0100, foo fighter wrote:
> 
> Hi,
> 
> 
> 
> I have an issue with Debian multiboot environments which 
> reuse SWAP-partitions. As a default option, each installation 
> formats the SWAP partition (if SWAP partitions are used) as far 
> as I understand. This changes the UUID of the SWAP partition(s). In 
> /etc/fstab, the UUID of the SWAP partitions is referenced as a constant. In 
> other existing installations, the old UUID of the SWAP partition (overwritten 
> by the new installation) is no valid or found during boot (systemd 
> timeout).
> 
> 
> 
> Shouldnt we preserve a UUID of an existing 
> SWAP-partition?
> 
> 
> Distro: Debian stretch
> 
> 
> Any ideas?

Don't format swap if you want to keep the UUID.

Of course reusing swap would be a very bad idea if you ever tried to
use suspend to disk.

Personally I don't understand wanting more than one system installed,
since that's the one I use.  What would I use another system for?
Experiments and testing I do in chroots or virtual machines.

-- 
Len Sorensen

Bug#815187: Similar problem

[Lennart Sorensen]

On Sat, Feb 04, 2017 at 11:33:02PM +1000, David wrote:
> Hi. I'm a noob but I think I had a similar problem.
> Legacy BIOS on laptop with 2 identical SATA disks.
> Windows 7 on /dev/sda1. Installed jessie 8.7.1 from USB on /dev/sdb2 (swap
> on sdb1)
> Grub wanted to install to /dev/sda MBR but I wanted to keep the windows
> installation native and boot Debian from /dev/sdb using BIOS boot options.
> So I specified /dev/sdb MBR as target for grub.
> Completed without error but then not bootable from /dev/sdb. Once it said
> "Missing operating system" but mostly there was just a blinking cursor
> Fixed by booting from a Live CD,  installing grub from there using steps in
> this post
> http://howtoubuntu.org/how-to-repair-restore-reinstall-grub-2-with-a-ubuntu-live-cd
> Installed without errors and now working as desired.
> I'm happy to provide any logs that would help but might need some guidance
> to find the relevant info.

It is quite likely that the bios swaps the device ID of sda and sdb when
you choose to boot sdb, which then means grub would get confused since
it was installed expecting sdb to be the second disk, but when booted
it is suddenly the first disk instead.

I suspect to make it happy would require convincing grub that sdb is in
fact the first hd in the system (In older grub versions one would do
this by changing the device.map file in /boot/grub but I don't recall
if that is still used).

Or you could change the order of the disks in the bios (somehow) before
booting the installer and hopefully sdb would be the first disk then
from grub's point of view.

This is my guess at the problem at least.

-- 
Len Sorensen

Re: Do I have to do anything to make sure ext4lazyinit works as being advertised ?

[Lennart Sorensen]

On Wed, Feb 01, 2017 at 02:27:39PM +0530, shirish शिरीष wrote:
> Basically the article's statement is wrong.
> There is no such thing as explicit itable initialization IO bandwidth
> restriction in MB/s. itable initialization rate is controlled by init_itable=N
> see: https://www.kernel.org/doc/Documentation/filesystems/ext4.txt
> """
> The lazy itable init code will wait n times the
> number of milliseconds it took to zero out the
> previous block group's inode table.  This
> minimizes the impact on the system performance
> while file system's inode table is being initialized.
> """
> By default init_itable=10, so it use 1/10th bandwidth of the disk.
> And if we back to original article this means author used generic
> HDD with 160Mb/s sequential write performance.

Oh OK, that sounds even better.

> My patch was fix for bug which was spotted on large disk arrays,
> 36 in my case. So itable initialization was active all the time
> while holding global lock.
> 
> From this, it seems there aren't any limits except for 10% of whatever
> the link between

Why would a large array make a difference to the algorithm if it aims
to use 1/10 of the bandwidth?

-- 
Len Sorensen

Re: Do I have to do anything to make sure ext4lazyinit works as being advertised ?

[Lennart Sorensen]

On Wed, Feb 01, 2017 at 04:53:34AM +0530, shirish शिरीष wrote:
> hmm From what little I understand, it always the slowest interface
> that needs to be supported.
> 
> And IIUC , in ext4lazyinit's case it is probably some of the MMC cards
> due to which the 16 MB/S transmission is kept - although some of them
> are at 104 MB/S as well.
> 
> https://en.wikipedia.org/wiki/MultiMediaCard#Table
> 
> Whereas USB are at -
> 
> https://en.wikipedia.org/wiki/USB_3.1
> 
> USB 2.0 - 35 MB/S
> 
> USB 3.0 - 400 MB/S
> 
> USB 3.1 - Gen 1 - 400 MB/S
> 
> USB 3.2 - Gen 2 - 1280 MB/S
> 
> For HDD -
> 
> https://en.wikipedia.org/wiki/Serial_ATA
> 
> SATA 1 - starts at 150 MB/S

Well they wanted to keep the rate low enough that you could still use the
disk while it was doing the background init work.  Most disks can do more
than 16MB/s so that leaves some for other use, like doing your install.

> Another query - if instead ext4lazyinit IF -
> 
> mkfs.ext4 -E lazy_itable_init=0,lazy_journal_init=0 /dev/mapper/fc-root
> 
> is applied then would it would start formatting and making inodes at a
> much faster rate - i.e. slowest between the USB Drive and HDD in a
> typical workstation - which probably would be a jump 3-4 times the
> speed that ext4lazyinit would employ.

Well it would have to do the whole init up front, meaning you have to
wait for all of it to finish before doing the install.

> WDYT ?
> 
> If yes, how as a user could I apply/use the above command while using
> debian-installer ?

Not sure.  It has been a while since I poked at the installer code.

I don't think it's worth trying to poke at it.  I think the default
behavour sounce very sensible and I doubt for most use cases doing it
differently would be an improvement, most like it would make it worse.

-- 
Len Sorensen

Re: Do I have to do anything to make sure ext4lazyinit works as being advertised ?

[Lennart Sorensen]

On Wed, Feb 01, 2017 at 12:46:48AM +0530, shirish शिरीष wrote:
> Hi all,
> 
> Warning - is a bit of a long read.
> 
> >From what all I read and understood, ext4lazyinit simply makes you
> start using the hdd without creating all the inodes for your system.
> The only way that you know ext4lazyinit is working is when you see it
> via iotop. But when using debian-installer is there something I could
> do, umm...some switch or something to make sure that ext4lazyinit
> works in the background ?
> 
> To elaborate it a bit further. Let's say I get one of those monster
> drives (which are probably insanely expensive atm)
> https://www.hgst.com/products/hard-drives/ultrastar-he12
> 
> While I would go bankrupt if I got this sort of hdd today, such drives
> were probably is the reason why ext4lazyinit was invented.
> 
> FWIW I would be working with a 3/4 TB HDD in the near future hence
> want to be ready before-hand.
> 
> Now let's say I use the current debian-installer for stretch - say
> either the net installer or the CD version -
> 
> http://cdimage.debian.org/cdimage/stretch_di_rc1/amd64/iso-cd/debian-stretch-DI-rc1-amd64-netinst.iso
> 
> http://cdimage.debian.org/cdimage/stretch_di_rc1/amd64/iso-cd/debian-stretch-DI-rc1-amd64-xfce-CD-1.iso
> 
> The reason to use ext4lazyinit is light at my end is pretty erratic
> and many a times a UPS is not available.
> 
> Having ext4lazyinit would be great if I am able to finish the
> installation fast and let it do inode creation on future boot-ups
> while I do the rest of the configuration, setting up the machine.
> updating/upgrading packages etc.
> 
> Now I have few queries -
> 
> a. Are my assumptions wrong ?

About the doing the init on a future boot, yes you are wrong.

> b. I don't know how much part of this question is debian-kernel
> related and how much of it is debian-installer related hence sending
> the mail to both the lists ?
> 
> AIUI ext4lazyinit is a filesystem utility created for kernel during
> the end of 2.6.32.x series, hence couple of years ago - hence it
> relates to debian-kernel the most.

2.6.37 apparently.

> Current kernel is 4.9 in Debian stretch -
> 
> [$] uname -r
> 
> 4.9.0-1-amd64
> 
> I do not know much of debian-installer support is/was needed to make
> sure the feature works as desired - hence the need to also mail
> debian-boot.
> 
> I ask as I still have memories of 2-3 years sitting all night long at
> friend's places who had access to an offline UPS to partition, format
> and then do the installation. The partitioning and formatting taking
> the most time even with the Large-File Support under ext3.
> 
> Looking forward to know.

I believe it is on by default.  However, the lazy init takes
place in the background on first mount (so that means during
the install), not some later boot.  It apparently will use
up to 16MB/s for initializing in the background according to
https://www.thomas-krenn.com/en/wiki/Ext4_Filesystem

I suspect it is already doing the best you are going to get.

-- 
Len Sorensen

Bug#852323: debian-installer: grub-installer not convert root= entry to UUID

[Lennart Sorensen]

On Mon, Jan 23, 2017 at 04:03:06PM +, Steve McIntyre wrote:
> On Mon, Jan 23, 2017 at 06:43:27PM +0300, Andrey Jr. Melnikov wrote:
> >Package: debian-installer
> >Severity: important
> >Tags: d-i
> >
> >
> >Installation procedure of grub2 dont't transform root= entry from /dev/sd?? 
> >to UUID notation. 
> >This lead to unbootable system after install.
> 
> Hmmm. It normally does this reliably in my experience. What version of
> d-i did you use, and did you follow through the menus as normal? Is
> there anything special about your setup?

Well the log indicates the use of a GPT partition table with BIOS boot
and not creating the GPT bios boot partition.  So at least that qualifies
as not normal.

Perhaps that is an indication that the system is supposed to be EFI
booted but somehow the installer was booted in the wrong mode.

-- 
Len Sorensen

Bug#261415: network installation always asks for proxy

[Lennart Sorensen]

On Sat, Jan 21, 2017 at 11:31:37PM -0800, Josh Triplett wrote:
> I do think we ought to attempt autodetection for this.  As long as a
> means exists for preseeders and expert installs to specify one anyway
> (for optional caching proxies), autodetecting by default seems like a
> good idea, to eliminate one of the more highly technical questions in
> the install.

Just how would you autodetect if a proxy should be used?  You can detect
if internet access works without one perhaps, but that doesn't mean a
proxy isn't desired.  I have actually encountered a network where the
firewall allowed access to one debian mirror without going through the
proxy, but security required going through a proxy.  Good luck detecting
that mess correctly.

-- 
Len Sorensen

Bug#851947: Debian 8.7.1 installation problem

[Lennart Sorensen]

On Fri, Jan 20, 2017 at 11:25:37AM +0200, :-) wrote:
> Package: installation-reports
> 
> Boot method: UEFI from USB flash drive
> Image version: http://cdimage.debian.org/debian-cd/current/amd64/iso-cd/
> Date: 19.01.2017
> 
> Machine: HP ProBook 4540s
> Processor: Intel Core i5-3230M
> Memory: 8GB
> Partitions: GPT partition table, sda1 12 GB SWAP, sda2 35GB root
> 
> Output of lspci -knn (or lspci -nn):
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [E]
> Detect network card:[ ]
> Configure network:  [ ]
> Detect CD:  [ ]
> Load installer modules: [ ]
> Detect hard drives: [ ]
> Partition hard drives:  [ ]
> Install base system:[ ]
> Clock/timezone setup:   [ ]
> User/password setup:[ ]
> Install tasks:  [ ]
> Install boot loader:[ ]
> Overall install:[ ]
> 
> Comments/Problems:
> 
> I downloaded debian-8.7.1-amd64-CD-1.iso and made an UEFI bootable USB
> Flash Drive (UFD) via RUFUS 2.11. I booted from UFD and chose
> "Install" (Result is the same if I choose "Install graphical"). The
> next screen appeared in color stripes like a rug. I tried to change
> any available video options in GRUB, editting the command line with
> 'E'. It didn't help. I tried to switch off the discrete video
> controller (AMD Radeon HD 7500/7600 series) from UEFI BIOS and install
> with Intel HD 4000. It didn't help. I have had the same issue with
> previous versions of Debian too. With Ubuntu I haven't had that
> problem, but I want a classic Debian. I tried to install it on HP
> EliteDesk 705 G1 booting from the same UFD with the same boot method.
> The installation was successfull.

Why did you not just write the iso raw to the USB key?  It is already
a bootable image.

Using any of the other tools for converting iso's to bootable USB just
tends to break things.

Of course that might very well not have anything to do with the graphics
messing up.  I have recently hit one machine where 1280x1024 didn't work
because it tried to use vesa, and the ati card for some reason decided
to use 75HZ refresh with a monitor that said it could only do 60Hz.
1024x768 worked fine of course.  It was a rather old machine though.

Since it didn't work with the intel graphics, that does seem to rule
out the video card.  Maybe the monitor is the problem, although quite
how it could do that I am not sure.  Since ubuntu worked, clearly
something is wrong in software.

Does the grub menu appear fine with graphics?

-- 
Len Sorensen

Bug#851740: bug report installing 9.0 RC1

[Lennart Sorensen]

On Wed, Jan 18, 2017 at 10:56:58AM +0100, bkk wrote:
> Package: installation-reports
> 
> Boot method: Installer bootet via USB
> Image version: 
> http://cdimage.debian.org/cdimage/stretch_di_rc1/amd64/iso-cd/debian-stretch-DI-rc1-amd64-netinst.iso
> Date: 2017-01-18 09:45
> 
> Machine: SUPERMICRO X10SBA-L-O-P
> Processor: Intel Celeron J1900 (cpu family:6, model: 55, stepping:8)
> Memory: 4GB
> Partitions:
> 
> Disk /dev/sda: 931,5 GiB, 1000204886016 bytes, 1953525168 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x51e39a8b
> 
> Device Boot  StartEndSectors   Size Id Type
> /dev/sda1  *  2048 1945382911 1945380864 927,6G 83 Linux
> /dev/sda2   1945384958 19535237118138754   3,9G  5 Extended
> /dev/sda5   1945384960 19535237118138752   3,9G 82 Linux swap / 
> Solaris
> 
> 
> 
> Output of lspci -knn (or lspci -nn):
> 
> 00:00.0 Host bridge [0600]: Intel Corporation Atom Processor Z36xxx/Z37xxx 
> Serie s SoC Transaction Register [8086:0f00] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx 
> Series  SoC Transaction Register [15d9:0816]
> Kernel driver in use: iosf_mbi_pci
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Atom Processor 
> Z36xx x/Z37xxx Series Graphics & Display [8086:0f31] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx 
> Series  Graphics & Display [15d9:0816]
> Kernel driver in use: i915
> Kernel modules: i915
> 00:13.0 SATA controller [0106]: Intel Corporation Atom Processor E3800 Series 
> SA TA AHCI Controller [8086:0f23] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor E3800 Series SATA 
> AHC I Controller [15d9:0816]
> Kernel driver in use: ahci
> Kernel modules: ahci
> 00:1a.0 Encryption controller [1080]: Intel Corporation Atom Processor 
> Z36xxx/Z3 7xxx Series Trusted Execution Engine [8086:0f18] 
> (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx 
> Series  Trusted Execution Engine [15d9:0816]
> 00:1c.0 PCI bridge [0604]: Intel Corporation Atom Processor E3800 Series PCI 
> Exp ress Root Port 1 [8086:0f48] (rev 0e)
> Kernel driver in use: pcieport
> Kernel modules: shpchp
> 00:1c.2 PCI bridge [0604]: Intel Corporation Atom Processor E3800 Series PCI 
> Exp ress Root Port 3 [8086:0f4c] (rev 0e)
> Kernel driver in use: pcieport
> Kernel modules: shpchp
> 00:1c.3 PCI bridge [0604]: Intel Corporation Atom Processor E3800 Series PCI 
> Exp ress Root Port 4 [8086:0f4e] (rev 0e)
> Kernel driver in use: pcieport
> Kernel modules: shpchp
> 00:1d.0 USB controller [0c03]: Intel Corporation Atom Processor Z36xxx/Z37xxx 
> Se ries USB EHCI [8086:0f34] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx 
> Series  USB EHCI [15d9:0816]
> Kernel driver in use: ehci-pci
> Kernel modules: ehci_pci
> 00:1f.0 ISA bridge [0601]: Intel Corporation Atom Processor Z36xxx/Z37xxx 
> Series  Power Control Unit [8086:0f1c] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor Z36xxx/Z37xxx 
> Series  Power Control Unit [15d9:0816]
> Kernel driver in use: lpc_ich
> Kernel modules: lpc_ich
> 00:1f.3 SMBus [0c05]: Intel Corporation Atom Processor E3800 Series SMBus 
> Contro ller [8086:0f12] (rev 0e)
> Subsystem: Super Micro Computer Inc Atom Processor E3800 Series SMBus 
> Co ntroller [15d9:0816]
> Kernel driver in use: i801_smbus
> Kernel modules: i2c_i801
> 02:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network 
> Conne ction [8086:1533] (rev 03)
> Subsystem: Super Micro Computer Inc I210 Gigabit Network Connection 
> [15d 9:1533]
> Kernel driver in use: igb
> Kernel modules: igb
> 03:00.0 Ethernet controller [0200]: Intel Corporation I210 Gigabit Network 
> Conne ction [8086:1533] (rev 03)
> Subsystem: Super Micro Computer Inc I210 Gigabit Network Connection 
> [15d 9:1533]
> Kernel driver in use: igb
> Kernel modules: igb
> 
> 
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[O]
> Configure network:  [E]
> Detect CD:  [ ]
> Load installer modules: [O]
> Detect hard drives: [O]
> Partition hard drives:  [O]
> Install base system:[E]
> 

Bug#851620: partman-md: doesn't warn about not being able to embed in the end

[Lennart Sorensen]

On Mon, Jan 16, 2017 at 10:46:44PM +0100, Samuel Thibault wrote:
> Package: partman-md
> Version: 77
> Severity: wishlist
> 
> Hello,
> 
> partman-md doesn't warn when disks to be used for RAID are partitioned
> with GPT without a bios boot partition for embedding (and I haven't seen
> documentation about the issue in the installer manual).

I suspect it might be a case of using gpt when not running in UEFI mode
is not normally done.

Normally people are either running UEFI mode and hence use GPT, or
they are using legacy BIOS and hence stick to DOS MBR partition table.
Given you don't have to go to GPT until your disk is 2TB or larger,
it has been OK for most people on legacy systems.

Of course since lilo is also a boot loader option in the installer,
one could argue whether there ought to be grub specific checks in the
partitioning tool.  I believe the warning you saw only came when the
grub install part did its checks much later, which is of course when
the grub code would be run.  Yes that's certainly a bit late given you
have to go back and do it all again if you want to use grub.

-- 
Len Sorensen

Re: stretch hd-media - boot error for USB-FDD on S5000PAL

[Lennart Sorensen]

On Mon, Jan 16, 2017 at 11:56:41AM +0300, dbsubscr...@mail.ru wrote:
> I use the server on S5000PAL. For remote reinstallation of system to me
> it is necessary to choose in BIOS for USB disks the Force FDD mode. It
> will allow to consider USB the separate device and allows to choose him
> at single loadings on this version of BIOS.
> 
> I use a loading image
> stretch/main/installer-amd64/current/images/hd-media/boot.img.gz.
> 
> The image is copied on usb a disk through dd. The section 1Gb turns
> out. 
> 
> When loading with USB the message of "Boot error" is given at once
> 
> I have tried to zapusat releases of boot.img.gz for the previous dates
> and only the release from 20160106 was loaded without problems. 
> 
> The image of hd-media of the jessie distribution kit is loaded without
> problems. 

In floppy mode?

> BIOS servers it is updated to the latest version. 
> 
> Use of USB on this server works in the HDD mode, but demands
> indications of an order of loading in the list of HDD devices. And to
> use USB for single loading it is impossible.

The hdmedia has a partition table and expects to be booted as a harddisk.
Making it a floppy can't possibly be expected to work since floppy
booting is totally different than hard disk booting.

That is not a way to solve boot problems.

-- 
Len Sorensen

Bug#848929: installation-reports: no problem

[Lennart Sorensen]

On Thu, Dec 22, 2016 at 11:28:27AM +, Holger Levsen wrote:
> interesting. 

Yes.

> as another data point, for reproducible-builds we're running four i386 build
> nodes on virtual amd64 hardware, with 36GB ram each, and at least building the
> Debian archive works nicely.

But are they amd64 installs with 32bit chroots for building, or are they
i386 pae installs?

-- 
Len Sorensen

Bug#848929: installation-reports: no problem

[Lennart Sorensen]

On Tue, Dec 20, 2016 at 10:33:24PM +0100, Rudi Pfau wrote:
> Package: installation-reports
> Severity: normal
> 
> 
> 
> -- Package-specific info:
> 
> Boot method: network
> Image version: Debian 8.6.0.i386 1
> Date: 
> 
> Machine: self build tower
> - board: Asus X99-A II
> - RAM:   32GB (4*8G)
> - SSD:1TB Cruical MX300
> - CPU:   INTEL i7-6800K 3.4 GHz
> - GPU:   ASUS ROG Strix Radeon RX 460

So did you actually mean to install a 32 bit OS on a nice 64 bit machine
with 32 GB ram?

Just curious.  Obviously it will work, but I don't find much reason to
have a 32 bit system these days myself.

-- 
Len Sorensen

Re: debootstrap InRelease file support

[Lennart Sorensen]

On Mon, Oct 31, 2016 at 04:57:11PM +0100, Philip Hands wrote:
> The fixed function that does the work in the new release is here:
> 
>   http://sources.debian.net/src/debootstrap/1.0.86/functions/#L529
> 
> as you can see, it's pure shell.

I like it. :)

-- 
Len Sorensen

Bug#842591: debootstrap-udeb: fails to validate InRelease (BADSIG)

[Lennart Sorensen]

On Mon, Oct 31, 2016 at 04:18:55PM +0100, Cyril Brulebois wrote:
> No, the “certainly did” and “worked fine” bits are wrong.
> 
> And that's not just me, we've had users report it, Philip Hands saw it
> as well. So no it did *NOT* work (in the specific case where it actually
> matters).

Yes, turns out sed doesn't do \a, but it does work if \a in sed is
replaced by [[:cntrl:]].  Doesn't make the line any prettier.

> Well that's the case in Debian right now, even in d-i! So your “busybox
> head does not appear to support it.” was wrong (that happens, no big
> deal), and I'm not so fond of being called a liar when I report test
> results for stuff I actually checked.

Well the version I looked at didn't have it, so apparently it was slightly
more than 3 years old.  It is a recent addition.

> Anyway, back to getting the next d-i release ready now that this issue
> is fixed.

Yep.

-- 
Len Sorensen

Re: debootstrap InRelease file support

[Lennart Sorensen]

On Mon, Oct 31, 2016 at 04:06:43PM +0100, Cyril Brulebois wrote:
> I think a crucial point is that something's being documented in standards
> doesn't mean it actually works in real life, everywhere, in all versions
> of all implementations. (There's also the topic of possible differences in
> interpretations.)

That is certainly true.  Bugs happen.

So I did miss something.  sed does not support \a.

One option that does work in d-i based on the posix spec would be
something like this:

sed '1,/^$/d;/^-BEGIN PGP SIGNATURE-$/,$d' < "$inreldest" | tr '\n' 
'\a' | sed 's/[[:cntrl:]]$//' | tr '\a' '\n' > "$reldest"

Of course that is deleting the control character at the end of the file,
not just if it is \a, although given the input isn't supposed to contain
any control characters that might be OK.

Apparently sed in d-i is really close to only doing what posix says it
has to do and hence no support for \a.

So if there is any desire to remove the need for having head support
negative offsets, then the above might be an option.

> > > That's entirely correct. Running from within d-i is mandatory though…
> > 
> > Well yes, that part should certainly work.
> 
> should → must

Sure.

> > Now why did GPG decide to throw away the last character in the input
> > anyhow.  Such a stupid choice.
> 
> We're not here to discuss GPG choices, or bugs.

Nope, just pondering.  Seems like such a dumb choice.

> > So it does mean if it hsa InRelease signature, then you need head that
> > supports negative offsets, so any decent linux system should be fine,
> > and any recent busybox with enough advanced features.
> 
> We don't *need* head with negative offsets. That was just a random idea I
> had at the time, which I checked to be working fine. The bug closure and
> the committed implementation show there's no *need* for that…

Well there doesn't seem to be any simple way to delete the last newline
with just shell tools.  head seems like the best one so far, when using
the extention.

-- 
Len Sorensen

Re: debootstrap InRelease file support

[Lennart Sorensen]

On Sun, Oct 30, 2016 at 06:41:44PM +0100, Cyril Brulebois wrote:
> This doesn't look exactly right; feel free to look at #842591.

I wonder why sed and tr don't work in d-i given I checked the options
used are all supposed to be posix compliant, unless I missed something.

> That's entirely correct. Running from within d-i is mandatory though…

Well yes, that part should certainly work.

Now why did GPG decide to throw away the last character in the input
anyhow.  Such a stupid choice.

So it does mean if it hsa InRelease signature, then you need head that
supports negative offsets, so any decent linux system should be fine,
and any recent busybox with enough advanced features.  And otherwise,
I suppose one could run debootstrap with the option to ignore signatures
if desperate.

Certainly head is simpler and cleaner looking.

-- 
Len Sorensen

Bug#842591: debootstrap-udeb: fails to validate InRelease (BADSIG)

[Lennart Sorensen]

On Sun, Oct 30, 2016 at 05:28:57PM +0100, Cyril Brulebois wrote:
> Package: debootstrap-udeb
> Version: 1.0.85
> Severity: grave
> Justification: renders package unusable
> 
> The (re)addition of InRelease support broke debootstrap(-udeb) in a d-i
> context. The sed|tr|sed dance doesn't kill the final newline, which
> leads to a BAD signature.

The one I proposed certainly did.  It worked fine and was portable.
Just a touch ugly perhaps.

> My original proposal was to use head -c -1, which while not specified by
> posix actually just works. Reasons include:
>  1. Tests agree.
>  2. busybox's coreutils/head.c has:
> case 'c':
> count_bytes = 1;
>   …
> if (negative_N) {
> if (count_bytes) {
> print_except_N_last_bytes(fp, count);
> } else {
> print_except_N_last_lines(fp, count);
> }
> } else {
> print_first_N(fp, count, count_bytes);
> }

Well only if you have ENABLE_FEATURE_FANCY_HEAD and it was only added
in 2013, so rather recent addition.

> It might be suboptimal to use this for the time being, as it /might/
> limit portability. On the other hand, the idea was to get a d-i release
> out of the door.
> 
> I'll give it some thoughts in the upcoming hours, and decide how to fix.

-- 
Len Sorensen

Re: Booting Debian on NVMe Dirive with killer E2400 ethernet next to Impossible!!!!

[Lennart Sorensen]

On Sun, Oct 23, 2016 at 07:46:03PM -0700, Humberto Hassey wrote:
> Finally got it to work!! here is the procedure, I hope it helps someone
> else:
> 
> Step 1 start the installation with the Debian DVD and go through it unitl
> it sais Grub failed
> 
> Step 2 in a separate USB memory and with a working debian system do:
> 
> sudo apt-get -t jessie-backports download grub-efi-amd64
> sudo apt-get -t jessie-backports download grub2-common
> sudo apt-get -t jessie-backports download grub-efi-amd64-bin
> sudo apt-get -t jessie-backports download efibootmngr
> sudo apt-get -t jessie-backports download libefvar0
> 
> sudo apt-get -t jessie-backports download linux-base
> sudo apt-get -t jessie-backports download Initramfs-tools
> sudo apt-get -t jessie-backports download linux-image-4XXX (i dont
> remember
> just pick your 4.x image)

Why did it need an updated linux-image?  Was that NVMe related or video
related or something else?  The only machine I tried NVMe boot on had
a new enough CPU that video had problems with 3.16, and of course being
I used the testing installer it already had a newer kernel.

I could see the grub installer getting new regexes added in jessie.
I doubt adding a newer kernel to the installer is considered an option.

> Step3 on the system that you are installing go into a terminal
> 
> cd /target
> mount --rbind /sys sys/
> mount --rbind /dev dev/
> mount --rbind /run run/
> chroot . /bin/bash
> 
> Step 4 insert your usb and do cd /var/ ls and figure out its name usually
> /dev/sdb1
> 
> Step 5 mount your usb with the packages
> mkdir ./cosas
> mount /dev/sdb1 ./cosas
> cd cosas
> 
> Step 6 start installing the linux kernel packages, then the grub starting
> in this order
> linux-base
> initramfs-tools
> linux-imagex
> libefvar0
> efibootmngr
> grub-efi-amd64-bin
> grub2common
> grubefi-amd64
> 
> Step 7
> exit the console by typing exit
> 
> step 8
> finish the installation
> 
> step9
> Reboot
> 
> step 10 Enjoy.

I am wondering if going to a shell, editing the grub installer to update
the disk names and then continuing (without adding any new packages)
would be sufficient.

-- 
Len Sorensen

Re: Booting Debian on NVMe Dirive with killer E2400 ethernet next to Impossible!!!!

[Lennart Sorensen]

On Mon, Oct 24, 2016 at 03:49:45AM +0100, Ben Hutchings wrote:
> That really ought to be fixed in jessie, if it doesn't require big
> changes to grub (and whatever else).  I already did a stable update of
> initramfs-tools to make it handle nvme devices properly.

As far as I understood it, the grub changes are only in the regex's used
to match /dev/ names for disks.

-- 
Len Sorensen

Re: Booting Debian on NVMe Dirive with killer E2400 ethernet next to Impossible!!!!

[Lennart Sorensen]

On Sun, Oct 23, 2016 at 01:43:49PM -0700, Humberto Hassey wrote:
> Hello I am a Debian user and just bought a nice laptop from system 76, I
> wiped ubuntu and proceed to install Debian, well it turns our that Debian
> does not recognize my network card, and the Grub packed on the installer
> does not recognize the NVMe drive correctly, so I can not boot, nor connect
> to the internet in order to download the grub-efi from backports..
> 
> I tried getting a shell from the install DVD and chrooting into the
> installation to install the previously downloaded grub-efi-amd64 and
> linux-image 4.7xxx from backports, but the installation fails saying there
> are unmet dependencies...

On new hardware, you might be better of trying stretch instead, which
is probably only about half a year or so from release anyhow.

I know NVMe install works, because I tried it, with the testing (stretch)
installer.  Jessie does not support it, at least last I checked.

-- 
Len Sorensen

Re: debootstrap InRelease file support

[Lennart Sorensen]

On Wed, Oct 19, 2016 at 12:33:03AM +0200, Cyril Brulebois wrote:
> Julien Cristau  (2016-09-16):
> > On Fri, Sep  2, 2016 at 20:35:12 +0200, Julien Cristau wrote:
> > 
> > > On Mon, Aug 15, 2016 at 12:12:02 +0200, Ansgar Burchardt wrote:
> > > 
> > > > If you restore support for `InRelease` and want to use `gpgv`, please
> > > > split `InRelease` into two files, i.e. `Release` and `Release.gpg`, and
> > > > verify that the signature actually covers all of `Release`.
> > > > 
> > > Here's an attempt at doing that.  Only lightly tested.
> > > 
> > Ansgar pointed out on IRC that so far nothing in debootstrap requires
> > awk on the host.  I haven't found a way to kill the last newline with
> > sed in a quick attempt, and I don't know how big of a deal requiring awk
> > would be, so help welcome.
> 
> Late to the party, but maybe shorter than the (funny though) tr|sed|tr
> dance: head -c -1 lets you remove the last character of a file.
> 
> (Tested to work OK inside d-i with debian-8.6.0-amd64-i386-netinst.iso)

Yes but not posix.  busybox head does not appear to support it.

My understanding is debootstrap intends to run almost anywhere.

-- 
Len Sorensen

Bug#841236: installation-reports: After install of Debian 8.6, Debian won't boot probably due to problem with nvidia

[Lennart Sorensen]

On Tue, Oct 18, 2016 at 08:59:35PM +0200, Remi Vanicat wrote:
> Package: installation-reports
> Severity: important
> 
> Dear Maintainer,
> 
> -- Package-specific info:

> 
> Boot method: CD
> Image version: 
> http://cdimage.debian.org/debian-cd/8.6.0/multi-arch/iso-cd/debian-8.6.0-amd64-i386-netinst.iso
> Date: 
> 
> Machine: ASUS ROG G752VM-GC006T

I believe that model ships with SSD RAID enabled, which currently makes
linux unable to see the SSD since the intel controller has hijacked the
NVMe device and hidden it behind the AHCI controller  (even though it
isn't a SATA device) in a weird mode.

You would have to turn off that mode in the BIOS (if possible, Lenovo
currently is unwilling to allow it on some of their modela for examples).

I imagine at some point intel will get around to adding support for
their crazy mode to linux but it hasn't happened so far.

It also makes backups and recovery for windows a nightmware since the
standard drivers don't see the SSD either and you have to somehow get
the intel raid drivers loaded before it shows up.

-- 
Len Sorensen

Bug#841062: installation-reports

[Lennart Sorensen]

On Mon, Oct 17, 2016 at 11:49:05AM +0200, Erwan Prioul wrote:
> Package: installation-reports
> 
> Boot method: ISO image
> Image version: 
> http://cdimage.debian.org/mirror/cdimage/daily-builds/daily/current/ppc64el/iso-cd/debian-testing-ppc64el-netinst.iso
> Date: Mon Oct 17 00:44:56 2016
> 
> Machine: qemu VM / P8 baremetal / powerVM
> Processor: ppc64el
> Memory: 4Gb
> Partitions: 
> /dev/sda1 JFS (more than 10Gb)
> /dev/sda3 swap
> 
> Initial boot:   [O]
> Detect network card:[O]
> Configure network:  [O]
> Detect CD:  [O]
> Load installer modules: [O]
> Detect hard drives: [O]
> Partition hard drives:  [O]
> Install base system:[O]
> Clock/timezone setup:   [O]
> User/password setup:[O]
> Install tasks:  [O]
> Install boot loader:[E]
> Overall install:[E]
> 
> Comments/Problems:
> 
> When partitionning the disk, I chose the guided partitionning to use the 
> entire disk and one partition, then I changed the file system of the main 
> partition to JFS instead of ext4.
> Everything went right until the grub installation.
> It failed with:
> 
> Install the GRUB boot loader on a hard disk
> ---
> 
> !! ERROR: Unable to install GRUB in /dev/sda1
> 
> Executing 'grub-install /dev/sda1' failed.
> 
> This is a fatal error.
> 
> from /var/log/syslog:
> Oct 17 00:51:19 grub-installer: info: Installing grub on '/dev/sda1'
> Oct 17 00:51:19 grub-installer: info: grub-install does not support 
> --no-floppy
> Oct 17 00:51:19 grub-installer: info: Running chroot /target grub-install 
> --force "/dev/sda1"
> Oct 17 00:51:19 grub-installer: Installing for powerpc-ieee1275 platform.
> Oct 17 00:51:20 grub-installer: grub-install: error:
> Oct 17 00:51:20 grub-installer:  unknown filesystem.
> Oct 17 00:51:20 grub-installer: error: Running 'grub-install  --force 
> "/dev/sda1"' failed.
> Oct 17 01:09:20 main-menu[974]: (process:5214): File descriptor 3 
> (pipe:[9531]) leaked on lvdisplay invocation. Parent PID 5736: /bin/sh
> Oct 17 01:09:20 main-menu[974]: (process:5214): File descriptor 4 
> (/dev/pts/4) leaked on lvdisplay invocation. Parent PID 5736: /bin/sh
> Oct 17 01:09:20 main-menu[974]: (process:5214): File descriptor 5 
> (/dev/pts/4) leaked on lvdisplay invocation. Parent PID 5736: /bin/sh
> Oct 17 01:09:20 main-menu[974]: (process:5214): File descriptor 6 
> (/dev/pts/4) leaked on lvdisplay invocation. Parent PID 5736: /bin/sh
> Oct 17 01:09:20 main-menu[974]: (process:5214):   Volume group "sda" not found
> Oct 17 01:09:20 main-menu[974]: (process:5214):   Cannot process volume group 
> sda
> Oct 17 01:09:20 main-menu[974]: WARNING **: Configuring 'grub-installer' 
> failed with error code 1
> Oct 17 01:09:20 main-menu[974]: WARNING **: Menu item 'grub-installer' failed.

I just tried it and it worked fine.

I picked the default guided partitioning, then changed the root partition
(partition 2) from ext4 to JFS.  I did NOT delete and create any
partitions from the default guided setup.

I think, based on your error, that you deleted partition 1 (8MB the PReP
boot partition) which is required for installing the boot loader in IBM
power systems.  Or maybe you change the use type to JFS from PReP boot.

Partition 1 (PReP boot) does NOT contain a filesystem and is not mounted.
Grub is written to it raw and the firmware loads the contents of the
partition into ram and executes it raw.

-- 
Len Sorensen

Re: Install on Orange Pi Plus eMMC work but no reboot

[Lennart Sorensen]

On Fri, Oct 07, 2016 at 02:48:30PM +0200, Jean-Christian de Rivaz wrote:
> On some system, maybe. Not on the Orange Pi Plus

Well I guess it is one of the exceptions.

> Well, I understand the technical part. But from a user point, when he see
> the Orange Pi Plus in the board list of the Debian installer, I think it's
> normal that he expect to be able to install a working system like the Debian
> installer do for a PC.

The problem with arm systems with u-boot is that you are dealing with
embedded systems, not standard machines.  They have options for how to
boot (on some systems u-boot needs a recompile depending on if you boot
from eMMC or SD, so that's a pain).

Given debian for armhf can run on just about any modern arm system,
the only bit it doesn't cover is installing the boot loader since
that is board specific (and sometimes board configuration specific).
Having a wiki or other document listing what else needs to be done for
a given system would be handy (and probably exists for at least some of
the systems).

> You mean the flash-kernel package and not by the flash-kernel-installer ?

flash-kernel takes care of the kernel and the boot script.  It doesn't
install u-boot.  At least not at this time.

> Yes, but only at the installer time on that board. As soon as you reboot it
> without the SD card or without FEL OTG injection of u-boot, you are left
> with a useless board.

Well it is still fixable with a tiny bit of one time work.

I must admit that for various arm boards I have played with I have never
used the installer.  I have used debootstrap to create a rootfs and then
put it and the required bits on uSD or eMMC or wherever I wanted it.
Some of the boards have needed a custom kernel build of course, although
some didn't.

> Agree, but again take the point of view of a user that simply want to
> install Debian on the Orange Pi Plus. By fare, the simplest way is to write
> a SD card image of the Debian installer into a SD card and insert it into
> the board slot. It could be netboot, or hd.media with an additional
> partition for the ISO image. Both will work to install Debian on the eMMC.
> Any others way require more work. Anyway, actually either methods will let
> the user with a useless board.

Well the simplest would be to just dump a premade image on uSD and leave
it there and forget eMMC.  Of course eMMC often has better performance
than uSD and it is nice to have a method for file transfers (although
USB keys and ethernet are often more convinient).

-- 
Len Sorensen