Bug#1082741: Debian testing Trixie installer issue

[Pascal Hambourg]

On 25/09/2024 at 12:04, Bit Cubic wrote:


Installing debian testing (Trixie) with the "graphical install" option
is not possible, the process stops immediately after launch, with a
black screen with various errors in the same screen(perhaps from the
x.org server) including:
"Fatal server error: no screen found (EE)"
and lastly:
"(debconf:841): GTK-WARNING: 16:05:14:030: cannot open display: :0"
and the error recurs in an infinite loop.


FWIW I can reproduce this in a virt-manager/QEMU x86 virtual machine 
with QXL graphics. It does not happen with virtio graphics (which uses 
modesetting) though.



At this point the PC is blocked and a hardware reset is required to restart.


I can switch to the shell in tty2 with Ctrl+Alt+F2.

Bug#1078871: installer: reserve first 16 MiB space in default recipes for ARM devices?

[Pascal Hambourg]

Control: tags -1 patch

On 17/08/2024 at 16:34, Holger Wansing wrote:

Hi arm people,

could you please comment on this bug, please?

Is there a need for some change?


I opened a merge request:
>https://salsa.debian.org/installer-team/partman-auto/-/merge_requests/18>

Feedback welcome.
I cannot test it as I do not have any ARM hardware.

Bug#896826: #896826 partman-auto: Wrong minimal disk size calculation when using expert_recipe and lvm partitions

[Pascal Hambourg]

On 17/09/2024 at 22:28, Holger Wansing wrote:


We have just overworked the partitioning recipes and some related things, so
maybe your issue is also fixed now.


Unfortunately I doubt the recent changes fix this issue. Most changes 
take place in built-in recipes so do not affect expert recipes. Even the 
patches in MR17 won't help, they aim to fix the opposite bug (calculated 
minimal disk size is lower than it should).


Fixing this bug properly is not simple and the proposed patch does not 
cover all cases.

Bug#1081888: [RFD] Update partman-auto/cap-ram default value to re-allow hibernation

[Pascal Hambourg]

Package: partman-auto
Version: 167
Tags: d-i

Dear maintainers,

The debconf setting partman-auto/cap-ram was introduced to deal with the 
very special case of systems with more RAM than disk space with previous 
recipes setting the minimum (and maximum in most cases) swap size to 
100% of RAM size. On the other hand, the maximum swap size of 1GB caused 
by its default value breaks hibernation in many cases.


partman-auto 167 provides updated recipes with new limits. Swap maximum 
size is now the lower of 100% of RAM size or ~5% or disk space. This 
should be enough to deal with the above special case while allowing 
hibernation on systems with enough disk space.


But partman-auto/cap-ram still gets in the way. I believe it is time to 
update its default value: either disable it completely, or raise it to a 
value which does not prevent hibernation on the majority or systems, 
e.g. 64GB. I hope a consensus can be reached.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 08/09/2024 at 18:34, Holger Wansing wrote:

Am 8. September 2024 15:35:16 MESZ schrieb Pascal Hambourg 
:

Another open point is the current partman-auto/cap-ram=1024 MB
default value which limits swap size and may prevent hibernation.


Yes, I am aware of this point.
I didn't mentioned this probably, but I planned to not touch this
setting for the next upload.

I guess it might get a difficult discussion, to get this setting changed.


With the new swap limits in recipes, I hope a compromise can be reached 
to at least raise its default value, if not disable it.



Thus I would like to upload the status quo, so people get this into the
official images with the possibility for wide testing, and then we will
go the next step...


OK then, let's tackle one problem after another. I removed the draft flag.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 08/09/2024 at 13:20, Holger Wansing wrote:

Pascal Hambourg  wrote (Sun, 8 Sep 2024 11:53:28 +0200):


I also wrote a crude script which generates recipe files for the 5
architectures updated in this MR from a reduced set of parameters:

(...)

Cool! We should definetely include this into the package.
Since you made a separate branch for this, feel free to create a new MR.


Ok. Glad you like the idea.


Otherwise, we are still stuck on the 16MiB offset thingy.


Another open point is the current partman-auto/cap-ram=1024 MB default 
value which limits swap size and may prevent hibernation.



May I propose we push this out, as it is now?
It's a big change already, and would warrant an upload in this state.

As already mentioned by josch, we could then discuss the 16MiB issue
separately.


Either way is fine with me. You developers/maintainers have the final 
word. Thank you for your support.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 30/08/2024 at 13:32, Holger Wansing wrote:

Am 27. August 2024 23:46:41 MESZ schrieb Pascal Hambourg 
:


Looking at partman-auto-lvm code more closely, it seems that the lvmok
flag check happens only after calling choose_recipe. So I guess the
check should be moved into choose_recipe (in partman-auto).

(...)

Patch ready and tested. Shall I add it to the MR or open a new one ?

(...)

Ok, so I think we include it in this MR then.


Patch included. I also updated existing recipes and added new server and 
small_disk recipes for armhf, ppc64el and riscv64.


I also wrote a crude script which generates recipe files for the 5 
architectures updated in this MR from a reduced set of parameters:


<https://salsa.debian.org/pham/partman-auto/-/blob/recipe_generator/build_recipes?ref_type=heads>

It does the tedious partition priority value calculations from simple 
percentage-like values. With the current parameters, the generated files 
are the same as in the current state of this MR (commit b3a0376f). It 
allowed me to spot and fix a missing tag in some new recipes I created 
manually. It comes in handy to test other size limits, and maybe it 
could help generating recipe files on further updates.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 29/08/2024 at 22:12, Holger Wansing wrote:

Am 29. August 2024 20:25:05 MESZ schrieb Pascal Hambourg 
:

On 28/08/2024 at 18:43, Holger Wansing wrote:

Am 27. August 2024 23:46:41 MESZ schrieb Pascal Hambourg 
:


Looking at partman-auto-lvm code more closely, it seems that the lvmok
flag check happens only after calling choose_recipe. So I guess the
check should be moved into choose_recipe (in partman-auto).


Ok. I would propose to move such change into a separate discussion/
bug report. Putting onto my to-do list.


Patch ready and tested. Shall I add it to the MR or open a new one ?


As I already wrote, I would like to keep that separate from this one.
So, any problem with pushing this into a new MR?


The problem is with reverting "Add LVM support to the small_disk 
recipe". If the fix is added to this MR, then "Add LVM support to the 
small_disk recipe" can be reverted right away. If the fix is included in 
another MR, then the revert commit will depend on which architectures 
have the small_disk recipe at the time of the merge (only default+EFI, 
or all). Unless you don't want to revert it, of course (which makes the 
fix a bit pointless).

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 28/08/2024 at 18:43, Holger Wansing wrote:

Am 27. August 2024 23:46:41 MESZ schrieb Pascal Hambourg 
:


Looking at partman-auto-lvm code more closely, it seems that the lvmok
flag check happens only after calling choose_recipe. So I guess the
check should be moved into choose_recipe (in partman-auto).


Ok. I would propose to move such change into a separate discussion/
bug report. Putting onto my to-do list.


Patch ready and tested. Shall I add it to the MR or open a new one ?


Fine, but what do we do with the small_disk recipe now ?


What about simply activating it for LVM as well?


Done. I also updated the description as you requested.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 27/08/2024 at 22:54, Holger Wansing wrote:

Am 27. August 2024 21:47:14 MESZ schrieb Pascal Hambourg 
:


<https://people.debian.org/~holgerw/d-i__new-limits_and_fix-envelope-calculation/attempt_2/10G-disk__1G-RAM/use-entire-disk__separate-home-var-tmp.png>

/home is smaller than the minimum size defined by the recipe. It
should not happen. I cannot even figure out how such a result is
possible. The multi recipe minimum disk size is 11GB so it should
not have been available with a 10.7GB disk. I need to investigate.


Good catch!
I also noticed some inconsistency here, but I did not mention it,
considering it being a corner case:

when entering the menu (use entire disk ->  )
the first time, the "separate home+tmp+var" choice was not provided,
but in my tests I restarted the partitioning step multiple times, and
so, when choosing "guided partioning" -> "use entire disk" ->  once more again, it was surprisingly there!


I suspect this is caused by the "reuse" feature. It allows to reuse 
existing partitions of the same type (biosgrub, efi, swap) as partitions 
defined in the recipe with the "reusemethod" flag instead of creating 
them when partitioning using the largest free space. But it seems it is 
used when checking the minimum size regardless of whether using the 
largest free space or a whole disk (same code path). I need to figure 
out how to disable it when using whole disks.


By the way, the reuse feature does not check if an existing partition 
size is greater than or equal to the minimum size defined in the recipe. 
IMO it should. Also existing swap partitions should not be reused, or at 
least not forcefully formated, because it may belong to another system.



This was my initial intent. I removed the lvmok flag (and /boot) from
the small_disk recipe and expected it to be ignored when using LVM.
Looking at partman-auto-lvm code more closely, it seems that the lvmok
flag check happens only after calling choose_recipe. So I guess the
check should be moved into choose_recipe (in partman-auto).


Ok. I would propose to move such change into a separate discussion/
bug report. Putting onto my to-do list.


Fine, but what do we do with the small_disk recipe now ?

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 27/08/2024 at 12:42, Holger Wansing wrote:


And I did some tests again; the results are at [2].
To give a short summary: the results are really really great !!!
(I tested all default recipes).


I wonder if / should not grow a bit faster (higher priority).

Also, this caught my eye:


/home is smaller than the minimum size defined by the recipe. It should 
not happen. I cannot even figure out how such a result is possible. The 
multi recipe minimum disk size is 11GB so it should not have been 
available with a 10.7GB disk. I need to investigate.



Just two small notes:
- the text for the new small_disk recipe should be changed, it says
   it's for disks "< 1G" but I think you meant "< 10G".


Actually I just forgot to update the existing description, good catch. I 
will do it.



- when choosing "use LVM" the small_disk recipe is provided as choice,
   but it fails when I try it.
   Could it be changed, so it just works?
   (Not highest priority, but using LVM in such case of small disk would
   allow, to add another disk later and get rid of the "low diskspace"
   issue without reinstalling - at least when the machine hardware/housing
   allows to add one more disk).


I did not consider this use case. Wouldn't it be simpler to use manual 
partitioning ?



   Or otherwise the entry should be not visible.


This was my initial intent. I removed the lvmok flag (and /boot) from 
the small_disk recipe and expected it to be ignored when using LVM. 
Looking at partman-auto-lvm code more closely, it seems that the lvmok 
flag check happens only after calling choose_recipe. So I guess the 
check should be moved into choose_recipe (in partman-auto).



BTW: I could not test the ESP part, since my test image cannot boot via EFI.
My remastering somehow breaks the EFI boot capabilities...


Indeed, the EFI partition/El Torito image is missing. A workaround it to 
extract the EFI partition from the original image, copy it to an other 
disk/image and boot from it. It should then find the CD.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 26/08/2024 at 08:34, Holger Wansing wrote:

Am 26. August 2024 00:33:48 MESZ schrieb Pascal Hambourg 
:


Maybe the firmware packages in /firmware and /pool are not

deduplicated in your image ?

Need to check:
I used an instruction for remastering of the image from
https://wiki.debian.org/DebianInstaller/Preseed/EditIso
and would be surprised about such effects...
But in fact that seems to be the issue.
The firmware deduplication thingy is rather new, and therefore not
respected in that guide already.


IIRC, /firmware used to contain symlinks to actual firmware debs located 
in /pool. But at some point some people complained that they could not 
copy the image contents to a FAT filesystem which does not support 
symlinks, so they were replaced with ISO9660 "hard links".



If you provide the minimum disk size required to reach /boot maximum
size, I can adjust the priority accordingly.


I think 25G should be fine.
(Can ESP get the same values BTW?)


Yes. The actual threshold is not very accurate due to the current 
algorithm granularity (priorities are normalized on a base 100 and 
rounded to integers). I updated the MR with two new commits:

- increase / minimum size and tweak ESP and /boot priorites
- add small_disk recipe for 3GB-10GB disks

New minimum disk sizes (with EFI and LVM):
- atomic 10GB
- home   10.5G
- multi  12.5GB
- server 10GB

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 25/08/2024 at 22:48, Holger Wansing wrote:

Pascal Hambourg  wrote (Sun, 25 Aug 2024 22:03:28 
+0200):

On 25/08/2024 at 19:03, Holger Wansing wrote:



I have prepared a netinst image for testing now with both above mentioned MRs:
https://people.debian.org/~holgerw/d-i__new-limits_and_fix-envelope-calculation/



(960 MB, sorry)


Wow, what makes it so much bigger than the 12.6 netinst image (662MB) ?


That's a follow-up from the GR decision, to include firmware in the
installation images, I think.


12.* netinst images also include non-free firmware. Firmware size has 
increased, but not so much (106MiB -> 193MiB).



For the test image, I took the daily netinst image from yesterday and just
replaced the partman-auto and partman-auto-lvm udebs.
In other words, the latest netinst images are that big!


AFAICS, the daily amd64 netinst images are only ~750MB. Maybe the 
firmware packages in /firmware and /pool are not deduplicated in your 
image ?



The recipes give /boot a rather high priority: 5% of available space
(same as / which is much bigger), so the gap between the maximum and
minimum size (256MB) is reached with only 5.1GB extra disk space above
the minimum disk space (6.1GB for atomic and home, 8.7GB for multi).
Maybe I should lower the priority...


Maybe something should be changed.


If you provide the minimum disk size required to reach /boot maximum 
size, I can adjust the priority accordingly.



Otherwise, we can skip the whole calculation for /boot completely:
if /boot reaches its maximum on a 10G disk (which is near at the absolute
minimum disk size these days) we should better go with a fixed size
of 1G for /boot (and ESP).


Actually with / minimum size of 8GB, minimum disk size for the atomic 
recipe would be raised to 10GB, so the threshold would be raised to ~15GB.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 25/08/2024 at 19:03, Holger Wansing wrote:



I have prepared a netinst image for testing now with both above mentioned MRs:
https://people.debian.org/~holgerw/d-i__new-limits_and_fix-envelope-calculation/


Thank you.


(960 MB, sorry)


Wow, what makes it so much bigger than the 12.6 netinst image (662MB) ?
It will barely fit in my good old 1GB USB stick...


Screenshots from tests with 4 different disk sizes are at the same URL as
above.
As can be seen, /boot is 1G of size in most cases, even on a 10G disk.
I guess that not how it's supposed to be?


Actually it is: parted shows that the exact /boot size with atomic/home 
on 10GiB (10.73GB) is 1001MB and is the expected result per the 
specification algorithm. It is close to the maximum 1024MB because 10GiB 
is close to the "threshold" disk size which allows /boot to reach its 
maximum size (~11.2GB). 868MB with multi is also the expected result.


All other disk sizes are above the threshold, so /boot size is maximum.

The recipes give /boot a rather high priority: 5% of available space 
(same as / which is much bigger), so the gap between the maximum and 
minimum size (256MB) is reached with only 5.1GB extra disk space above 
the minimum disk space (6.1GB for atomic and home, 8.7GB for multi). 
Maybe I should lower the priority...

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 23/08/2024 at 17:52, Holger Wansing wrote:


@Pascal: Would you be able to provide a merge request for this in
partman-auto-lvm, please?


After fixing a few typo's and minimal testing, I opened 



Note: partman-lvm-auto may be used to perform custom recipes defining 
explicit PVs and/or on multiple disks. Such use cases should not be 
affected but feedback would be welcome.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 23/08/2024 at 17:52, Holger Wansing wrote:

Am 23. August 2024 00:15:44 MESZ schrieb Pascal Hambourg 
:


It is clearly a bug in partman-auto-lvm because the resulting sizes do not match 
the partman-auto-recipe specification. It remained unnoticed only because the EFI 
and /boot partitions had fixed sizes in recipes.


Ok, so if noone objects, I would vote for this solution.
@Pascal: Would you be able to provide a merge request for this in
partman-auto-lvm, please?


This is still totally untested so I just pushed the branch I had started 
to work on a while ago to my fork:

<https://salsa.debian.org/pham/partman-auto-lvm/-/tree/fix-add_envelope?ref_type=heads>
The week was tiring and I need a break before doing more.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 22/08/2024 at 17:19, Holger Wansing wrote:

Pascal Hambourg  wrote (Thu, 22 Aug 2024 13:59:12 
+0200):

On 19/08/2024 à 07:50, Holger Wansing wrote:

Am 18. August 2024 21:50:53 MESZ schrieb Pascal Hambourg 
:


Should the "small_disk" recipes be resurrected ?


I wasn't aware of such recipes, but what could be the benefit?

(...)

The benefit would be to allow automatic partitioning in less disk space
than "normal" recipes when you do not need a desktop environment. Only
biosgrub|esp, / and swap, no LVM, no separate /boot unless the
architecture requires it.


But that's nearly the same as the atomic recipe, isn't it?


No, it would have lower minimum size for / and would not support LVM in 
order to save the space for a separate /boot.



I think there is no real value in adding one more recipe.


A "small_disk" recipe would support much lower disk sizes than the other 
recipes.



I asked several times if there were intended use cases for built-in
recipes which could be used as guidelines, but I have not seen any clear
answer yet.


Probably since such guidelines are not trivial to formulate: much different
szenarios, a wide ranch of hardware and similar might result in a higher
amount of entries to choose from, and too much choices are not always an
advantage...


It does not have to include many use cases. It could be simple, e.g.:
- "atomic", "home" and "multi" are intended for workstations with a 
desktop environment;

- "server" is intended for servers with data in /srv;
- "small_disk" is intended for systems without a desktop environment on 
disks too small for other recipes.



The /boot partition size is bigger than I expected in all LVM
case(...)

Just leave it as is, ignoring the 260MB difference?


IMO the difference is too big to be ignored. Also it makes the partition
reach its maximum size (768M -> 1GB) with any disk size. If you're going
that way, it would be more consistent to define a fixed size of 1GB in
the recipe to hide the issue.

I believe that the only real solution is to fix the lvm partition
minimum size in partman-auto-lvm as described above, even though it may
affect existing custom LVM/crypto recipes. Keeping bugs for
compatibility is not good.


First, this is again a trade-off here.
And we can assume, that when LVM is used, the disk space is not of minimal
size, thus having the boot partition a bit bigger does not matter in LVM
cases (or in other words: when LVM is used, /boot will most probably reach
its max size anyway (?) ).
I'm unsure if I consider this a bug...


It is clearly a bug in partman-auto-lvm because the resulting sizes do 
not match the partman-auto-recipe specification. It remained unnoticed 
only because the EFI and /boot partitions had fixed sizes in recipes.



So, keep the logic simple, as a trade-off?


I'd prefer to fix the logic in partman-auto-lvm so that it matches the 
specification.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

Apologies for the late answer...

On 19/08/2024 à 07:50, Holger Wansing wrote:

Am 18. August 2024 21:50:53 MESZ schrieb Pascal Hambourg 
:



I wonder, if we could grow up the root partition in "separate /home" and
"separate /home, /var, /tmp" a bit (only relevant on small disks, most 
probably).


By raising the minimal / partition size or its priority ?
The former also raises the minimal disk space requirement, whereas the latter 
is detrimental to other partitions growth. As above, it is a trade-off.


On a 20G disk, I get 4,7G for root, on a 50G disk that's 6,4G.
In current release, an installed GNOME or KDE desktop would consume the whole
root then, disk full (according to 
https://d-i.debian.org/manual/en.amd64/apds02.html)


Does this include the space required for two extra kernels ?
apt autoremove keeps two kernels and removes the older only after the newer is 
installed, so there can transiently be three kernel installed.


Those values are directly after installation I guess.
So without several kernel images.
That's why we should just have spare space on /.


Then what should be the proper minimum size for / ?


This is why I previously asked if there were intended use cases for built-in 
recipes which could be used as guidelines.
For example, "allow to install and use a desktop environment within [TBD] GB disk space", 
and/or "allow to install and use a minimal (non-graphical) system within [TBD] GB disk 
space".
Should the "small_disk" recipes be resurrected ?


I wasn't aware of such recipes, but what could be the benefit?


One unused "small_disk" recipe file remains in recipes-alpha and the 
description is still present in the debconf template.


The benefit would be to allow automatic partitioning in less disk space 
than "normal" recipes when you do not need a desktop environment. Only 
biosgrub|esp, / and swap, no LVM, no separate /boot unless the 
architecture requires it.


On 19/08/2024 at 12:41, Philip Hands wrote:

It would be nice if we could do something where one gets 1GB for systems
with tens or hundreds of GB, and have that scale down for tiny disks,
and scale up for huge, but we don't currently have a non-linear
possibility.


Maybe the recipe format could be extended to support multiple linear 
segments, e.g. :

min prio1 max1 prio2 max2...
meaning "use prio1 between min and max1, then prio2 between max1 and 
max2..."


But for now the only option is a trade-off between the minimum size and 
the priority.



BTW Do we really expect to be serving people with tiny disks with our
default multi recipe? I'd guess that they'd be more likely to either go
for everything on one partition, or configuring things to their exact
requirements.


I asked several times if there were intended use cases for built-in 
recipes which could be used as guidelines, but I have not seen any clear 
answer yet.


The /boot partition size is bigger than I expected in all LVM 
cases (...)
This offset can be compensated by reducing /boot minimal size 
in recipes where /boot exists only with LVM.


But it is not possible to do the same to the EFI partition or in recipes 
where /boot exists in both LVM and non-LVM schemes.

Another workaround could be to define the EFI partition twice in recipes:
- with $defaultignore and shifted minimum size,
- with $lvmignore and normal minimum size.
But it sounds like a hack again. 


I wasted quite some time working on this solution, calculating and 
testing the offsets in all cases. The offset compensation works very 
well, but then I realized what should have been obvious from the start: 
reducing partition minimum sizes in recipes affects the minimum disk 
space requirement and you could end up with smaller EFI and /boot 
partitions than intended, so this solution is flawed.


I also considered adding an explicit "lvm" partition with the proper 
parameters and $defaultignore flag to the recipes, so that 
partman-auto-lvm does not create one. But it would not work with 
partman-auto-crypto which uses a "crypto" partition instead of a "lvm" 
partition.


The only solution 
I can think of is to replace the LVM PV fixed arbitrary minimal size 
(and priority while we're at it) in partman-auto-lvm with the actual 
values. But this may affect existing custom LVM recipes in unpredictable 
ways. It is possible to apply the new behaviour only to built-in 
recipes, but then custom recipes based on new built-in recipes may 
produce unexpected results.


Just leave it as is, ignoring the 260MB difference?


IMO the difference is too big to be ignored. Also it makes the partition 
reach its maximum size (768M -> 1GB) with any disk size. If you're going 
that way, it would be more consistent to define a fixed size of 1GB in 
the recipe to hide the issue.


I believe that the only real solution is to fix the lvm partition 
minimum size in partman-auto-lvm as described above, even though it may 
affect existing custom LVM/crypto recipes. Keeping bugs for 
compatibility is not good.

Bug#1079267: discover: turn into transitional empty packages?

[Pascal Hambourg]

On 22/08/2024 at 09:09, Petter Reinholdtsen wrote:

[Chris Hofstaedtler]

I don't know of any way of removing packages on upgrades from users
systems, but at least the packages could become empty themselves.


Perhaps we can turn them into empty packages, add a description
specifying that they are transitional packages, and in the next release
add a conflict from a often installed package on these transitional
packages to get them removed?  Or will it work to let the transitional
discover package depend on some other package first, and then let the
other package conflict with discover in the next release?


The release notes have paragraphs about obsolete packages after upgrade:



Why not just remove the package from the archive (and mention it in 
release notes) ?

How will it be different from any other obsolete package ?

Bug#1079139: Failed boot after install

[Pascal Hambourg]

On 20/08/2024 tat 18:55, louigi 600 wrote:

I dint think it even loads the grub efi file. System bios  complains it
can't boot from that device.


Did you try an expert install with GRUB in the "removable media path" 
when prompted ?



There is something Debian does not like about my Dell Optiplex 7040


Or rather something that your Optiplex does not like about Debian, if it 
complains and Debian did not.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 18/08/2024 at 23:46, Pascal Hambourg wrote:


The /boot partition size is bigger than I expected in all LVM 
cases, and I understand why. My previous calculations compensated the 
LVM PV priority used by partman-auto-lvm but not the minimum size 
(100MB) which is considerably smaller than the actual sum of lvmok 
partition minimal sizes. According to my new calculations, it adds 
~260MB to /boot.


This offset can be compensated by reducing /boot minimal size 
(ironically it almost reverts to the previous value of 512MB) in recipes 
where /boot exists only with LVM.


But it is not possible to do the same to the EFI partition or in recipes 
where /boot exists in both LVM and non-LVM schemes. The only solution 
I can think of is to replace the LVM PV fixed arbitrary minimal size 
(and priority while we're at it) in partman-auto-lvm with the actual 
values. But this may affect existing custom LVM recipes in unpredictable 
ways. It is possible to apply the new behaviour only to built-in 
recipes, but then custom recipes based on new built-in recipes may 
produce unexpected results.


Another workaround could be to define the EFI partition twice in recipes:
- with $defaultignore and shifted minimum size,
- with $lvmignore + $cryptoignore and normal minimum size.
But it sounds like a hack again.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 18/08/2024 at 16:38, Holger Wansing wrote:


I have uploaded some screenshots from tests with different disk sizes to
https://people.debian.org/~holgerw/partman-auto___new-limits/


Thank you. The /boot partition size is bigger than I expected in all LVM 
cases, and I understand why. My previous calculations compensated the 
LVM PV priority used by partman-auto-lvm but not the minimum size 
(100MB) which is considerably smaller than the actual sum of lvmok 
partition minimal sizes. According to my new calculations, it adds 
~260MB to /boot.


This offset can be compensated by reducing /boot minimal size 
(ironically it almost reverts to the previous value of 512MB) in recipes 
where /boot exists only with LVM.


But it is not possible to do the same to the EFI partition or in recipes 
 where /boot exists in both LVM and non-LVM schemes. The only solution 
I can think of is to replace the LVM PV fixed arbitrary minimal size 
(and priority while we're at it) in partman-auto-lvm with the actual 
values. But this may affect existing custom LVM recipes in unpredictable 
ways. It is possible to apply the new behaviour only to built-in 
recipes, but then custom recipes based on new built-in recipes may 
produce unexpected results.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 18/08/2024 à 16:00, Philip Hands wrote:


If the disk they're installing onto is huge, then having the upper limit
for /boot be 0.5GB larger will go unnoticed, whereas running out of
space on /boot is generally pretty annoying, or worse.


How huge ? I do not mind raising the maximal /boot size but it involves 
doing a trade-off. With the current proposed 5% priority, which is quite 
big, the partition reaches 1GB in 12GB disk space and would reach 1.5GB 
in 22GB disk space. This is not huge at all. With 1% priority (the 
minimal value with the current algorithm granularity), the partition 
would reach 1.5GB in 80GB disk space (still not huge) but would now need 
32GB disk space to reach 1GB instead of 12GB.


On 18/08/2024 at 16:38, Holger Wansing wrote:


Pascal Hambourg  wrote (Sun, 18 Aug 2024 12:33:50 
+0200):

<https://salsa.debian.org/installer-team/partman-auto/-/merge_requests/15>

(...)

I would propose to change the template text for the new server recipe like
- Separate /var and /srv, swap < 1GB for servers
+ Separate /var and /srv, swap < 1GB (for servers)


Updated.


1.
I'm unable to produce swap partition bigger than 1G, even in a qemu VM with
2G or 4G of RAM


Sorry, I forgot to warn about partman-auto/cap-ram at first and added a 
note to the MR description later.



2.
I wonder, if we could grow up the root partition in "separate /home" and
"separate /home, /var, /tmp" a bit (only relevant on small disks, most 
probably).


By raising the minimal / partition size or its priority ?
The former also raises the minimal disk space requirement, whereas the 
latter is detrimental to other partitions growth. As above, it is a 
trade-off.



On a 20G disk, I get 4,7G for root, on a 50G disk that's 6,4G.
In current release, an installed GNOME or KDE desktop would consume the whole
root then, disk full (according to 
https://d-i.debian.org/manual/en.amd64/apds02.html)


Does this include the space required for two extra kernels ?
apt autoremove keeps two kernels and removes the older only after the 
newer is installed, so there can transiently be three kernel installed.



Of course, we cannot know, how users use their systems (DE installed: yes/no)
and 20G or 50G disk is probably small these days for default recipes, to get
good results for all cases?
And we might say, the "separate /home" recipe puts focus on the /home partition
and therefore shrinks root. I'm not sure, what's best here...


This is why I previously asked if there were intended use cases for 
built-in recipes which could be used as guidelines.
For example, "allow to install and use a desktop environment within 
[TBD] GB disk space", and/or "allow to install and use a minimal 
(non-graphical) system within [TBD] GB disk space".

Should the "small_disk" recipes be resurrected ?

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 17/08/2024 at 15:56, Pascal Hambourg wrote:

On 17/08/2024 at 12:30, Holger Wansing wrote:


Pascal, would you be able to form the proposed changes as they are currently
into code for a patch or a merge request, maybe for amd64 only, for now?
The details would be mostly as you stated in your first proposal, AFAICS.


Currently there are no specific recipes for amd64. amd64-efi recipes are 
used by all other efi architectures and non-efi amd64 uses the default 
recipes. I can prepare a merge request for these two sets of recipes.


<https://salsa.debian.org/installer-team/partman-auto/-/merge_requests/15>

I also attached the recipe files to this mail.
I have not tested them at all yet.

new_recipes.tar.gz
Description: application/gzip

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 17/08/2024 at 12:30, Holger Wansing wrote:


Pascal, would you be able to form the proposed changes as they are currently
into code for a patch or a merge request, maybe for amd64 only, for now?
The details would be mostly as you stated in your first proposal, AFAICS.


Currently there are no specific recipes for amd64. amd64-efi recipes are 
used by all other efi architectures and non-efi amd64 uses the default 
recipes. I can prepare a merge request for these two sets of recipes.

Bug#1078871: installer: reserve first 16 MiB space in default recipes for ARM devices?

[Pascal Hambourg]

Shouldn't this bug be advertised in debian-...@lists.debian.org so that 
people familiar with ARM platforms are aware of it ?

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 16/08/2024 at 00:27, Diederik de Haas wrote:

On Thu Aug 15, 2024 at 10:24 PM CEST, Pascal Hambourg wrote:

Then I guess a 16 MiB unused partition could be added to relevant
recipes. Now, which are the relevant recipes ? In other words, which
arch/subarch need it ?



recipes-armhf-efi (= recipes-amd64-efi)
recipes-armhf
recipes-arm64-efi (= recipes-amd64-efi)
recipes-arm64 (= recipes-armhf)


Rockchip makes both 32bit as 64bit ARM SoCs, so `recipes-armhf` is
relevant.


If only Rockchip SoCs need the reserved partition and are detected as a 
specific subarchitecture by archdetect, new specific recipes for this 
subarchitecture could be added.



I don't know if it's common, but AFAIK you can use U-Boot with EFI, but
it sounds 'weird' to add it to a recipe with AMD64 in its name...


Indeed. If some ARM EFI platforms need the reserved partition, then one 
of the recipes-arm*-efi symlinks could be replaced with a directory 
containing new specific recipes and the other could be changed to point 
to it.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 15/08/2024 at 21:00, Diederik de Haas wrote:

On Thu Aug 15, 2024 at 5:50 PM CEST, Pascal Hambourg wrote:

On 15/08/2024 at 16:25, Diederik de Haas wrote:


All that matter is that the first 16 MiB stay unused so that
U-Boot can be put there.


It is still unclear to me if it can be an unused partition or if it must
be unallocated space which can be used to create new partitions.
AFAIK, only the former can be done in recipes.


Either would work.


Then I guess a 16 MiB unused partition could be added to relevant 
recipes. Now, which are the relevant recipes ? In other words, which 
arch/subarch need it ?

Currently, partman-auto has the following recipes for ARM:

recipes-armel-kirkwood
recipes-armel-orion5x
recipes-armhf-efikasb
recipes-armhf-efi (=recipes-amd64-efi)
recipes-armhf
recipes-arm64-efi (=recipes-amd64-efi)
recipes-arm64 (=recipes-armhf)

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 15/08/2024 at 16:25, Diederik de Haas wrote:

On Thu Aug 15, 2024 at 3:46 PM CEST, Pascal Hambourg wrote:

On 15/08/2024 at 08:26, Holger Wansing wrote:

Am 15. August 2024 00:47:22 MESZ schrieb Diederik de Haas 
:


So it would be very helpful if the recipe(s) for ARM devices would
reserve the first 16MB automatically with plain partitioning.


What do you mean exactly by "plain partitioning" ? Manual partitioning ?
Guiding partitioning with all files in one filesystem ? Other ?


Partitioning NOT involving LVM.
I 'jumped in' when the subject of creating blank/reserved partitions
with LVM and then the question arose if that should also be used for
"plain" partitioning, which I interpreted as not using LVM.


Ah, now I understand why you quoted that part. But it is unrelated.

Guided partitioning (partman-auto-lvm) allows to reserve some 
unallocated space in the LVM VG, in other words not use all the 
available space in the VG. This is simply done by reducing the amount of 
free space used to perform the LVM recipe. Of course the location of the 
reserved space within the PV is unspecified, as is the location of LVs. 
The LVM PV partition still uses all the available disk space.


Allowing guided partitioning without LVM (partman-auto) to not use all 
the available space could also be done by reducing the amount of free 
space used to perform the recipe. I guess the unallocated space would be 
located at the end of the disk. The purpose was not to reserve a 
specific disk area but leave some free space for future allocation 
(create new partitions or extend the last partition, unlike LVM which 
allows to easily extend any LV).



I do not know any way to reserve unallocated space in recipes. The
recipes could create a 16-MiB unused partition but the table in [2]
lists a lot of special partitions within the first 16 MiB. Are these
actual partitions ? If yes, how are they supposed to be created ?


I think you technically could create those partitions, but those are not
relevant. All that matter is that the first 16 MiB stay unused so that
U-Boot can be put there.


It is still unclear to me if it can be an unused partition or if it must 
be unallocated space which can be used to create new partitions.

AFAIK, only the former can be done in recipes.


Looks like another incarnation of
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770666>


It looks like a different issue to me. IIUC these bug reports are about
parted_server erasing the boot loader location when creating a new
partition table, not the first partition overlapping with the boot
loader location.


AIUI bug #770666 is the same/similar as this 'Rockchip' issue.
Bug #751704 OTOH is related, but does deal with problems wrt partition
table.


AIUI, #751704 and #770666 are the same bug for different platforms and 
are unrelated with the first partition position. They are caused by 
parted erasing the first 9 KiB when creating a new partition table. The 
fix for #770666 only extended the fix for #751704 to handle more 
platforms. The 'Rockchip' issue you mention is unrelated as the boot 
loader is located after 32 KiB, beyond the erased area.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 15/08/2024 at 08:26, Holger Wansing wrote:

Am 15. August 2024 00:47:22 MESZ schrieb Diederik de Haas 
:


I'm not 100% sure if this fits into this subject/discussion, but ...


It is beyond the original scope (partition size limits) and I believe it 
would deserve its own discussion involving people who are familiar with 
ARM platforms.


Disclaimer: I have no experience nor knowledge about ARM (or any other 
architectures than x86) and its boot process.



The U-Boot bootloader is normally put in the first part of the boot
device and for Rockchip based devices that can extend to the 16MB
'mark'. AFAIK bootloaders for other SoCs are before that.

If you use the current recipes you end up with an unbootable system as
the U-Boot bootloader get overwritten with the / (root) partition and
the data on it.


AFAICS, the first partition in all non-EFI ARM recipes is /boot, not /.


Right now, the instruction is to choose manual partitioning and create
a 16MB partition ([1] says 32MB, but it should be 16MB [2]) and then the
normal partitions and after that you could remove that partition again.
And if you type in 16MB, then you need to 'hope' that it is actually
16MB and not something (a bit) smaller.


16 MB (~15.3 MiB) or 16 MiB (~16.8 MB) ?
In partman, 1 MB really means 10^6 bytes, not 1 MiB (2^20 bytes).


So it would be very helpful if the recipe(s) for ARM devices would
reserve the first 16MB automatically with plain partitioning.


What do you mean exactly by "plain partitioning" ? Manual partitioning ? 
Guiding partitioning with all files in one filesystem ? Other ?



[1] https://wiki.pine64.org/wiki/ROCK64_Software_Releases#Debian
[2] https://opensource.rock-chips.com/wiki_Partitions


I do not know any way to reserve unallocated space in recipes. The 
recipes could create a 16-MiB unused partition but the table in [2] 
lists a lot of special partitions within the first 16 MiB. Are these 
actual partitions ? If yes, how are they supposed to be created ?



Looks like another incarnation of



It looks like a different issue to me. IIUC these bug reports are about 
parted_server erasing the boot loader location when creating a new 
partition table, not the first partition overlapping with the boot 
loader location.

Bug#1078656: grub-pc: please use 'grub-install --disk-module=native /dev/sdX'

[Pascal Hambourg]

On 14/08/2024 at 03:59, Martin-Éric Racine wrote:


You're welcome to suggest a better recipe.


insmod chain
insmod boot # not sure it is useful
set root=usb0
chainloader +1

But once loaded, the MBR boot code needs to access the USB drive via 
BIOS disk services, and it won't work if the BIOS does not expose the 
USB drive.



Actually, it turns out that even installing this isn't practical on
anything else than media with a GTP partition. It won't fit into the
start of a DOS partition, whereas GTP always leaves plenty of empty
space at the start.


What are you talking about ? 'grub-install --disk-module=native 
/dev/sdX' ? Do you mean "GPT" instead of "GTP" ? Do you mean "DOS 
partition table" instead of "DOS partition" ?


By today standards (1-MiB alignment) there is as much unallocated space 
after a DOS partition table and a GPT partition table. Only very old 
partitioning tools used cylinder alignment with the first partition 
starting at sector 63, which leaves ~31 KiB for GRUB core image. A core 
image embedding native disk drivers may not fit there. Besides, GRUB can 
use the unallocated space after the partition table only on DOS, not on 
GPT. GPT must have a "BIOS boot" partition instead.

Bug#1078656: grub-pc: please use 'grub-install --disk-module=native /dev/sdX'

[Pascal Hambourg]

On 13/08/2024 at 22:02, Martin-Éric Racine wrote:


I've been trying to implement a chainloader (see below at
/etc/grub.d/40_custom) to boot off external USB disks as needed.
Finding external disks requires using GRUB's 'nativedisk'


Only with flawed BIOS which cannot boot from USB or do not expose all 
drives. I observed that some BIOS expose only a USB drive when booting 
from it, but others expose all USB drives regardless of the boot device.



but once that has been executed, the rest of the script cannot be
completed because Debian's grub-install enforces BIOS device names
(hd0,msdos1) instead of bus names (ata0,msdos1).


I doubt this is the reason why your custom menu entry fails. See my 
comments below.



Further investigating this suggests that if Debian used 'grub-install
--disk-module=native /dev/sdX' to install GRUB, this would work as
expected.


Native disk drivers do not work properly on all machines, so they cannot 
be enabled by default for a rare use case.



menuentry "USB chainloader" {
insmod part_msdos
insmod ext2
insmod fat
insmod iso9660


Why do you load these modules ? Chainloading a disk boot sector does not 
require to read any partition table nor filesystem.
Instead you should load the "chain" module which provides the 
"chainloader" command.



nativedisk
set root='ata0,msdos1'
chainloader (usb0)+1
}


Why do you set $root to an internal disk partition if you intend to 
chainload a USB drive ? Did you mean to set $prefix so that GRUB can 
find its directory and modules after switching to native disk drivers ?

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 09/08/2024 at 17:05, Philip Hands wrote:


While we're changing things, could we distinguish between LVM recipes
and non-LVM ones?


What would be the differences between LVM and non-LVM recipes ?

I do not see how to do this only in recipes, except by adding a dummy 
partition with $lvmignore{ } or $defaultignore{ } and a minimum size 
bigger than any storage capacity so that the recipe is rejected, which 
is clearly a hack. A cleaner way would be that partman-auto and 
partman-auto-lvm look for built-in recipes in different locations.



I tend to install servers with something like the multi recipe, except
instead of devoting the bulk of the disk to /home I instead leave it
unallocated (which I do by allocating a spare volume, with keep set to
avoid wasting time formatting it, and I then remove in the late script).
That then gives the flexibility of easily adding volumes or extending
them, as needed by the system.


Guided partitioning with LVM already provides a feature to reserve space 
in the VG. Maybe it could be extended to guided partitioning with plain 
partitions.



The other thing I tend to when using multiple partitions is allocate
1.5GB to /boot so that there's enough room for a grml image for use in
conjunction with the grml-rescueboot package.


Isn't this a niche use case ? My understanding was that guided 
partitioning was primarily intended for general purpose use cases.



Would it be worth making the upper limit for /boot be 1.5G, and using a
scaling factor (if possible) that will only use that much for disks
larger than 1TB, say, as then its a small enough proportion to be no
loss even if people don't use it for grml.


It is at least possible. The PRIORITY value in recipes represents a 
"scaling factor", in a rather convoluted way.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 07/08/2024 at 20:33, Holger Wansing wrote:


A recipe specific for server installations, which limits the swap to let's
say 1G or 2G, because the machine has enough RAM built-in.


What would be the other partitions in this "server" recipe ?
- /var/log as suggested by José Ángel Pastrana ?
- /srv ?


limiting the swap size to the lower of
100% RAM size and ~5% (open to discussion) disk space.


Any opinions about this ?

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 05/08/2024 at 17:47, Holger Wansing wrote:


Is there an intended use case for built-in recipes ?
Should there be different recipes for different uses cases ?
E.g.:
- minimal installation
- workstation with graphic desktop environment
- server


Doesn't sound like a bad idea IMO.
Could probably solve the long standing issue
"#987503 swap partition only 1 GB instead of at least 1 x RAM size"
stating that hibernation is broken for machines with RAM bigger than 1G...


Do you mean to create specific recipes for hibernation ?
The issue you mention is not caused by current recipes but the 
introduction of partman-auto/cap-ram=1024 as a default to address the 
case of systems with more RAM than disk space. My proposal above already 
aims to address both issues by limiting the swap size to the lower of 
100% RAM size and ~5% (open to discussion) disk space. Of course it also 
requires to disable partman-auto/cap-ram.


On Tue, 6 Aug 2024 07:07:17 +0200 José Ángel Pastrana 
 wrote:


I would like to suggest /var/log recipe. I think it is a valuable recipe 
for production environments.


Which kind of production environement ? Server, workstation ?
Isn't a separate /var enough in most cases ?
I also use a separate /var/log on unattended systems, but I do not 
bother doing it on my desktop or laptop.

Bug#1070085: Enhancing default home folder permissions for improved privacy

[Pascal Hambourg]

On 05/08/2024 at 01:07, Chris Hofstaedtler wrote:

On Tue, Apr 30, 2024 at 12:16:23AM +0200, Håvard F. Aasen wrote:

Could default home folder permissions lean towards greater privacy,
while administrators can adjust permissions to be less strict if
necessary?



What I would like is to have 'HOME_MODE' [4] uncommented.
[4] 
https://salsa.debian.org/debian/shadow/-/blob/master/debian/login.defs?ref_type=heads#L156


I vaguely remember the installer has an option for this, possibly
only on expert mode. If so, it would be good if the installer
default would change (or so).


I always use expert install and have never seen such option.


If the installer has no option for this, please reassign to
src:shadow, so we can think about it more.


AFAICS user-setup uses adduser if installed in the target system, 
useradd otherwise.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

On 24/07/2024 at 17:16, Pascal Hambourg wrote:


Poll: What should be the MIN, MAX and minimum disk size to reach MAX for


Here is a first proposal to start the discussion. The raw priority value 
in recipes is quite obscure, and it turns out that expressing it with 
the minimum disk size to reach MAX is not as easy as I expected, so I 
ended up expressing the priority as a percentage of available disk space 
(%free, not to be confused with a percentage of memory %RAM).



- EFI partition (similar requirements as /boot for systemd-boot ?)
- /boot
- swap


  -- old --- | --- new ---
  MIN PRIO   MAX | MIN  PRIO   MAX
efi   538M0%free N/A | 768M 5%free 1G
/boot 768M3%free 1G  | 768M 5%free 1G
swap  100%RAM 0%free N/A | 400M 5%free 100%RAM

Rationale:
- The ESP has the same size as /boot to support BLS/systemd-boot layout.
- swap=RAM allows hibernation in most use cases.
- Limit swap size to 5% disk space on small disk space with huge RAM.
- 400M swap is ~5% of the minimum disk size (~8G).



- / in atomic recipe


* "atomic" (all in / filesystem):
  - old - | --- new --
  MIN  PRIO MAX   | MIN   PRIOMAX
/ 900M 97%  unlim | 5G   85%free unlim

> - / in home recipe
> - /home in home recipe

* "home" (separated / and /home):
  - old - | --- new --
  MIN  PRIO MAX   | MIN   PRIOMAX
/ 1.5G 33%  30G   | 5G5%free 100G
/home   1G 66%  unlim | 1G   80%free unlim

Rationale:
- 5GB / should be enough to install a desktop environment.
- No need to limit / so much with plenty of disk space.
- I have seen users complaining about the 30GB / being almost full.

> - / in multi recipe
> - /var in multi recipe
> - /tmp in multi recipe (or should tmpfs be used ?)
> - /home in multi recipe

* "multi" (separated /, /var, /tmp and /home):
  - old - | --- new --
  MIN  PRIO MAX   | MIN   PRIOMAX
/   2G 18%  25G   | 4G5%free 100G
/var1G  6%  10G   | 2G2%free  40G
/tmp  256M  1%   2G   | 512M  1%free   3G
/home   4G 73%  unlim | 1G   77%free unlim

Rationale:
- Same as above.
- No need to limit /var so much with plenty of disk space.
- There are use cases which can require a lot of space in /var 
(databases, virtual machines...)
- /home does not necessarily require at least 4GB. Users installing on a 
small disk usually do not intend to store a lot of data.

- Why should /home minimum size be bigger than in the "home" recipe ?

Open questions:

Is there an intended use case for built-in recipes ?
Should there be different recipes for different uses cases ?
E.g.:
- minimal installation
- workstation with graphic desktop environment
- server

systemd >= 256~rc3-3 makes /tmp a tmpfs by default unless a mount is 
explicitly defined. It means that atomic and home recipes do not need to 
allocate space for /tmp in / any more. But on the other hand they may 
need to raise the minimum swap size because tmpfs can use swap space 
under memory pressure.
Should the multi recipes stop creating a /tmp partition for consistency 
with other recipes ?

Bug#1036948: edk2: please configure a grub menu entry for efi-shell-ARCH

[Pascal Hambourg]

In an attempt to move forward, I opened a draft merge request loosely 
based on Lionel's patch:



For now it is only a PoC limited to x64 and may be extended to other 
platforms if it receives positive feedback from maintainers.

Bug#972396: Comment on «initramfs-tools: Installation fails (no space left on device)»

[Pascal Hambourg]

On 31/07/2024 at 00:38, Thomas Hahn wrote:
On Fri, 26 Jul 2024 14:00:51 +0200 Pascal Hambourg 
 wrote:

 >
 > firmware-nvidia-graphics was installed on systems which already had
 > firmware-misc-nonfree because firmware-misc-nonfree recommends
 > firmware-misc-nonfree so that systems which rely on Nvidia firmware are
 > not disrupted.

Is it possible to only install it on systems, which have a NVIDIA 
graphics card?


Maybe firmware-misc-nonfree could check if a Nvidia GPU is present then 
trigger installation of firmware-nvidia-graphics instead of recommending 
firmware-nvidia-graphics. Sounds quite convoluted. Can apt be invoked 
from a package postinst script ?


I am using a separate boot partition, because the other main partititon 
is luks encrypted.


I don't see any other reason to have a separate partition.


There are many other reasons to have a separate /boot, here are those 
which come to my mind:

- the firmware does not support / physical storage
- the firmware cannot address the full / physical storage range
- the boot loader does not support / filesystem or block layer
- GRUB may not support some RAID, LVM, LUKS or filesystem features
- GRUB <= 2.12 has a bug with LVM metadata wrap-around
- filesystems spanning multiple disks (striped RAID, LVM, btrfs...) can 
be tricky for GRUB

Bug#1077635: debian-installer: RFC: provide UEFI shell under Advanced/Export options

[Pascal Hambourg]

On 31/07/2024 at 03:04, Dmitry Baryshkov wrote:


This is an RFC whether it would be possible to include UEFI shell into
the debian installer media. I understand that it won't work with
SecureBoot


The menu entry can be hidden when secure boot is enabled.


For example, on some of old Qualcomm-based laptops EFI vars are not
accessible or are read-only. Thus it is not possible to setup boot
configuration from the running Linux configuration.


Isn't it possible to work around this with grub-installer options 
"install in the removable media path" and "do not update EFI boot 
variables" ?

Bug#972396: Comment on «initramfs-tools: Installation fails (no space left on device)»

[Pascal Hambourg]

On 26/07/2024 at 13:27, Thomas Hahn wrote:

There was some changes with the firmware packages.


Yes, Nvidia firmware grew bigger (but not as much as the observed 
initramfs size increase) so they were moved from firmware-misc-nonfree 
to a new package firmware-nvidia-graphics, which is recommended by 
firmware-misc-nonfree so that existing systems which need Nvidia 
firmware are not disrupted.


firmware-nvidia-graphics was installed automatically on boxes which 
don't have a NVIDIA device in their system.


firmware-nvidia-graphics was installed on systems which already had 
firmware-misc-nonfree because firmware-misc-nonfree recommends 
firmware-misc-nonfree so that systems which rely on Nvidia firmware are 
not disrupted.


Doesn't firmware-misc-nonfree inform the user of this change on upgrade 
from a version which shipped firmware now shipped by other packages ?



This blows up the initrd images to almost 4 times the size.


This is not all firmware-nvidia-graphics fault but initramfs-tools 0.142 
which duplicates some firmware files in the initramfs. Bug fixed in 
initramfs-tools 0.143, but the initramfs will still be bigger than 
before due to the increased firmware size.

Bug#1076952: [RFD] partman-auto: Update guided partitioning size limits for current and future needs

[Pascal Hambourg]

Package: partman-auto
Version: 166
Tags: d-i

Dear maintainers,

Partition size limits in partman-auto recipes have issues:
- some limits are too low for current needs and should be raised;
- some limits are inconsistent across atomic, home and multi recipes;
- some priorities prevent the size from growing beyond the minimum.

I will take the example of amd64/efi recipes which are also used with 
most other EFI architectures. Sizes are in MB (decimal, not MiB). The 
recipe format is described in 
/usr/share/doc/debian-installer/devel/partman-auto-recipe.txt.gz from 
package debian-installer.


* recipes-amd64-efi/atomic
 538   538 1075 free iflabel=gpt method=efi
 512   512  768 ext2 $defaultignore /boot
 900 1   -1 default_fs $lvmok /
100%   512 200% linux-swap $lvmok

* recipes-amd64-efi/home
 538   538  1075 free iflabel=gpt method=efi
 512   512   768 ext2 $defaultignore /boot
1500  6000 3 default_fs $lvmok /
100%   512  200% linux-swap $lvmok
1000 1-1 default_fs $lvmok /home

* recipes-amd64-efi/multi
 538   538  1075 free iflabel=gpt method=efi
 512   512   768 ext2 $defaultignore /boot
2000  3500 25000 default_fs $lvmok /
1000  1500 1 default_fs $lvmok /var
100%   512  200% linux-swap $lvmok
 256   400  2000 default_fs $lvmok /tmp
4000 1-1 default_fs $lvmok /home

(Limits for /boot have just been changed to "768 800 1024" in the source 
repository to accommodate initramfs growth.


)

In addition to some MIN and MAX limits being obviously too low for 
current needs, we can see that:


- The EFI partition has MIN=PRIORITY (538) so its size is always MIN 
despite a higher MAX limit (1075).


- The MIN for / in atomic (900) is lower than the MIN in home (1500) 
which is lower than the MIN in multi (2000). It should be the opposite.


- The MIN for /home is lower in home (1000) than in multi (4000). Why ?

- If RAM size >= 512 MB then the swap partition has PRIORITY (512) <= 
MIN (100% RAM size), so its size is capped to MIN instead of MAX (200% 
RAM size). By default the RAM size is also capped to 1 GB so the maximum 
swap size is 1 GB, which prevents hibernation in many cases; but this is 
another story, see 
.


- The EFI partition is not created if the disk label is MSDOS even 
though it is supported by EFI boot. This can be an issue when using the 
largest available space.


Related unanswered bug report with patch raising / and /var MIN sizes:


I am filing this bug report to start a discussion about setting new 
limits which are more consistent and fit current and possibly future 
needs better. Of course this will increase the minimum disk size 
requirements for guided partitioning.


Poll: What should be the MIN, MAX and minimum disk size to reach MAX for
- EFI partition (similar requirements as /boot for systemd-boot ?)
- /boot
- swap
- / in atomic recipe
- / in home recipe
- /home in home recipe
- / in multi recipe
- /var in multi recipe
- /tmp in multi recipe (or should tmpfs be used ?)
- /home in multi recipe
- other platform-specific partitions you know about ?

Bug#1076753: partman-crypto: Default size for /boot partition too low

[Pascal Hambourg]

On 23/07/2024 at 01:49, Thomas Mayer wrote:


when selecting "Guided - use entire disk and set up encrypted LVM" with
a 256GiB disk, only 510MiB are used for the unecrypted /boot partition.


Guided partition sizes are not defined in partman-crypto but partman-auto.


With file sizes of 250MB for initrd.img-6.9.9-amd64 this is too small,
and even with initrd.img-6.9.8-amd64 at 80MB this can hardly keep more
than 3 kernel versions at once.


Such sizes are excessive and caused by a bug in initramfs-tools 0.142 
which duplicates firmware files, fixed in 0.143 (experimental). See 
other related bug reports:






Please consider raising the default size for this partition.


Work in progress, see 
.

Bug#1076695: debian-installer: /boot partition created by installer isn't big enough

[Pascal Hambourg]

On 22/07/2024 at 04:39, Cyril Brulebois wrote:

Jonathan Kamens  (2024-07-21):

Something changed recently in testing which caused the size of my
initrd to go up A Lot, e.g., on one computer from 70MB to 248MB.

(...)

Have you tried comparing before/after to see where this increase comes
from? Checking the compression settings would also make sense.


The significant initramfs size increase is caused by the combination of 
the new package firmware-nvidia-graphics, which provides firmware for 
Nvidia GPUs (injected by plymouth) and contains directory symlinks, and 
initramsf-tools < 0.143 which converts directory symlinks into real 
directories and duplicate their contents. It seems that initramfs-tools 
0.143, currently in experimental, fixes the issue.


Other related bug reports:

Bug#1076617: installation-guide: Severely outdated information wrt partitioning

[Pascal Hambourg]

(I replied to the list instead of the bug report, sorry for the duplicate)

On 19/07/2024 at 20:54, Diederik de Haas wrote:



There may be a bug here, in that the /boot partition was too small.
That has been fixed in the installer, but unfortunately we don't have
a general way to grow the partition on installed systems.


And there have been other reports that the kernel is getting too big.


It is mostly the initramfs which is getting too big.


Plymouth is installed by default and that includes the GPU modules and
the firmware for it.


Plymouth is installed by default (recommended) by desktop environment 
meta-packages. It adds GPU-related kernel modules and firmware files to 
the initramfs.



And the firmware files have been getting bigger
too, especially for nvidia where they just added firmware files which
are respectively 23MB and 38MB in size ... (sigh)


The initramfs built by initramfs-tools < 0.143 can be as big as 240 MB 
when firmware-nvidia-graphics is installed.



For ``/boot`` size it should minimally follow d-i's default,


D-i partman does not really define a default size for /boot. Guided 
partitioning with LVM currently sets a fixed size of 512 MB regardless 
of the disk size. Guided partitioning without LVM does not create a 
/boot partition. Manual partitioning does not have default size.



but I
actually think both should be updated to 1G in size, which should
(generally) not be a problem with current TBs NVMe drives.


Or changed to a variable size depending on the disk size.

Maybe it should also be noted that if systemd-boot is installed, the EFI 
system partition (ESP) or the extended boot loader partition (XBOOTLDR) 
must be big enough to contain the kernel images and initramfs.

Bug#875308: linklocal ipv6 addresses in debian-installer netcfg

[Pascal Hambourg]

On 06/07/2024 at 10:53, Marc Haber wrote:

On Sat, Jul 06, 2024 at 12:09:09AM +0200, Pascal Hambourg wrote:



When entering link local ipv6 addresses with interface suffixes
as gateway during the network configuration in the debian installer,
the installer detects the address to be malformed.


Why would you need to do this ? AFAICS entering the plain link-local IPv6
address without the interface suffix creates the expected default route.


That's a common misconception. Since link local addresses are from the
same network (fe80::/64) on all interfaces, a route pointing to a
link-local address, such as the VERY common fe80::1, is ambiguous and
therefore MUST be written like fe80::1%enp2s0


Not if the interface is specified in the command adding the route. E.g.

# ip route add default fe80::1 dev enp2s0


While we're at it, on a system with more than one interface, does D-I
allow to leave the default gateway field empty?


Yes, but AFAICS the Debian installer netcfg allows to select and 
configure only one "primary" interface, so the question seems irrelevant.


I made a few quick tests with the Debian 12.6 installer in expert mode.

With one interface, just entering fe80::1 in the gateway field produces 
the expected result: "ip -6 route" shows the correct default route via 
fe80::1 on the interface.


With two interfaces, "ip -6 route" show that the default route is 
correctly configured as above on the selected interface. The other 
interface is set down.


In both cases, the expected working /etc/network/interfaces is generated:

iface  inet6 static
address /
gateway fe80::1

So I see no need to append the interface suffix to a link-local IPv6 
gateway address.


The only issue I see is if you enter a DNS IPv6 link-local address: the 
interface suffix is required in /etc/resolv.conf so it should be 
appended there. Additionnally, either netcfg should append it in 
/etc/network/interfaces dns-nameservers, or ifupdown should append it 
when passing the address to resolvconf, or resolvconf should append it 
when generating /etc/resolv.conf.


I did not check the configuration generated for NetworkManager nor other 
supported network managers.

Bug#875308: linklocal ipv6 addresses in debian-installer netcfg

[Pascal Hambourg]

When entering link local ipv6 addresses with interface suffixes
as gateway during the network configuration in the debian installer,
the installer detects the address to be malformed.


Why would you need to do this ? AFAICS entering the plain link-local 
IPv6 address without the interface suffix creates the expected default 
route.

Bug#1074036: systemd-boot-installer/skip true halts the installer

[Pascal Hambourg]

Control: tags -1 patch

On 22/06/2024 at 08:04, ov2k.github wrote:


 Alternatively, move this code into an isinstallable script,
where a return value of 1 is appropriate.


This is what is proposed in

Bug#1072215: USB wireless Netgear WNA1100 fails to load

[Pascal Hambourg]

On 01/06/2024 at 10:08, Tom Overlund wrote:


Running the patched installer, the output was a bit different, and it
DID unload the module ("ath9k_htc: Driver unloaded"),


Thank you for testing. It is still not clear which method identified the 
actual module. I should make it more verbose. I suspect it is the search 
in loaded module "firmware" fields because IIRC (I wrote these patches 
quite some time ago) other methods require 
/sys/bus/usb/devices/3-3/3-3:1.0 to be present.



but it still output errors trying to unload the usb module


This is normal, the installer still tries to unload the primary module 
in case it guessed the module wrong.



and it did NOT try to configure the wireless network:


I also expected this because /sys/bus/usb/devices/3-3/3-3:1.0 is missing 
so the driver is unable to bind with the device.


Now we must find why /sys/bus/usb/devices/3-3/3-3:1.0 is missing and how 
to make it reappear. "udevadm monitor" may help.


PS: I am following a somehow similar issue in another bug report 
. But I still 
lack knowledge in the USB field.

Bug#1072215: USB wireless Netgear WNA1100 fails to load

[Pascal Hambourg]

On 31/05/2024 at 14:59, Tom Overlund wrote:


Can you tell me the best way to apply these patches? I tried:

$ apt-get source hw-detect
# apt-get build-dep hw-detect
$ cd hw-detect-1.159/
$ mkdir debian/patches

and copying the three .patch files there, followed by:

$ debuild -b -uc -us

I was hoping that would patch it automatically, but no such luck.


I don't know much about packaging, but comparing with other packages you 
may need to add the patch names to a file debian/patches/series. Or I 
guess you could just apply the patches manually with patch -p1 < patch" 
before building the package.

Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work

[Pascal Hambourg]

On 31/05/2024 at 13:51, Pascal Hambourg wrote:


Maybe running "udevadm trigger" during specific 
moments and recording its output may provide useful information:


Sorry, I meant "udevadm monitor".

Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work

[Pascal Hambourg]

On 31/05/2024 at 10:26, Roland Clobus wrote:


* Moment 1: the first d-i screen is shown. The USB device is seen by the 
kernel, but the module is not yet loaded

ls -d /sys/bus/usb/drivers/r8712u/1-3*
No such file or directory


As expected, the module is not loaded so /sys/bus/usb/drivers/r8712u 
does not exist.



ls -d /sys/bus/usb/drivers/usb/1-3*
/sys/bus/usb/drivers/usb/1-3
ls -d /sys/bus/usb/devices/1-3/1-3*
/sys/bus/usb/devices/1-3/1-3:1:0


The device is present.


* Moment 2: the d-i screen 'No Ethernet card was detected' is shown
(The firmware has been placed where it can be found, module r8712u has 
been removed and added)

ls -d /sys/bus/usb/drivers/r8712u/1-3*
No such file or directory
The module is loaded so /sys/bus/usb/drivers/r8712u should exist but is 
not associated with the device.



ls -d /sys/bus/usb/drivers/usb/1-3*
No such file or directory
ls -d /sys/bus/usb/devices/1-3/1-3*
No such file or directory


It looks like the device is not present any more. But there was no 
disconnect message in the kernel log. All I can see it the reset 
message, but AFAICS a reset should not remove the device. Maybe it was 
disabled or powered down.


I do not know enough about the kernel and USB subsystem to have any clue 
about what is wrong. Maybe running "udevadm trigger" during specific 
moments and recording its output may provide useful information:

- when the adapter is connected
- when the module is loaded without the firmware
- when the adapter is disconnected
- when the module is reloaded with the firmware

You do not have to run check-missing-firmware for this, you can run 
modprobe commands in a shell.


* Moment 3: I disconnect and reconnect the USB device in virt-manager 
and select 'Detect network hardware' from the d-i menu. d-i shows a list 
of SSIDs

ls -d /sys/bus/usb/drivers/r8712u/1-3*
/sys/bus/usb/drivers/r8712u/1-3:1.0


As expected, the device is associated with the driver.

Bug#1072215: USB wireless Netgear WNA1100 fails to load

[Pascal Hambourg]

Hello Tom,

On 30/05/2024 at 13:33, Tom Overlund wrote:


/var/log/syslog indicates it tried to load firmware for the USB WiFi
device, failed, but loaded the kernel module anyways. Then the
installer detected this, installed the package with the firmware, and
then got some errors about realoding USB modules.
It seems that check-missing-firmware failed to identify the correct 
kernel module. At this point, can you post the output of


ls -d /sys/bus/usb/drivers/ath9k_htc/3-3*
ls -d /sys/bus/usb/devices/3-3/3-3*

assuming the wireless adapter is identified as 3-3 ?

Then can you try the patches for hw-detect attached to 
 ?

Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work

[Pascal Hambourg]

On 26/05/2024 at 22:29, Roland Clobus wrote:


Your patch series works fine, the firmware is correctly identified and 
loaded. Unfortunately for me, it still needs a reconnect cycle.

See the attached syslog for their effect. (I've used sid)


Thank you for testing my patches but I did not expect them to solve the 
reattachment issue, only to identify the right module.


After the r8712u module is first loaded without the firmware then 
unloaded and reloaded, what is the output of


ls -d /sys/bus/usb/drivers/r8712u/1-3*
ls -d /sys/bus/usb/devices/1-3/1-3*

assuming the wireless adapter is identified as 1-3 ?

Bug#1071927: discover: Discover displaying packages wrong.

[Pascal Hambourg]

On 26/05/2024 at 05:58, user wrote:

Package: discover
Version: 2.1.2-10
Severity: normal
X-Debbugs-Cc: heterocycle_papill...@simplelogin.com

Dear Maintainer,

When I open Discover and type "antivirus" into the search bar, packages from
the KDE Store appear, but when I click on settings and then search for
"antivirus" I get packages from Debian only.


Package "discover" provides a hardware identification system. Aren't you 
confusing with plasma-discover ? If so, you can reassign this bug by 
replying with the following pseudo-header:


Control: reassign -1 plasma-discover 5.27.5-2

Bug#1071903: hw-detect: USB wireless adapter r8712u needs physical disconnect and reconnect for firmware to work

[Pascal Hambourg]

On 25/05/2024 at 22:10, Roland Clobus wrote:


When I run the Debian installer, the missing firmware file is correctly 
identified and installed by 'check-missing-firmware.sh'. However, the 
kernel module is mis-identified as 'usb'.


This is a more generic issue already reported in #1033679


Can you give a try to the attached patches ? They came to late for 
bookworm, maybe it is time to reconsider them.



Attached is a patch that allows the module to be identified correctly.
If desired, I can send the patch instead as a merge request on Salsa.


IMO $address should be included in the search pattern. Else if there is 
another device reported as "usb" then your patch will wrongly resolve it 
as r8712u too.


However, using 'modprobe -r r8712u' and 'modprobe r8712u' is not 
sufficient to enable the adapter, it still needs a physical reconnect.
In the attached screenshot from the installer (sid) the result of the 
patch is shown. Also in the QEMU environment, I need to disconnect and 
reconnect the USB device from the host.


Looks like a driver/device issue.

Bug#1070753: Can't see PPPoE concentrators via d-i but pppoe-discovery can

[Pascal Hambourg]

Control: tags -1 patch

Proposed patch:

Bug#1034812: Unbootable after install: UEFI installed to wrong ESP

[Pascal Hambourg]

On 17/05/2024 at 13:22, Jmkr wrote:

Pascal Hambourg wrote:


You can set an alternative name and location by running grub-install
with --bootloader-id= or with GRUB_DISTRIBUTOR= in
/etc/default/grub. It also affects the directory name in the ESP. But
depending on the grub package version, monolithic GRUB images (signed
for secure boot) do not support being installed in another location than
/EFI/debian (I have been advocating to fix this but no luck so far).


Thanks for this as well as the other info you provided - it is nice to know even if I may 
end up not using it (as I probably want to use "/EFI/debian" directory for GRUB 
with just custom EFI boot entry names).


You can run grub-install with --no-nvram to install GRUB without writing 
EFI boot variables. The Debian installer also has an option for this in 
expert mode. Then you can create a custom boot entry with efibootmgr.

Bug#1034812: Unbootable after install: UEFI installed to wrong ESP

[Pascal Hambourg]

On 10/05/2024 at 00:52, Jmkr wrote:

Pascal Hambourg wrote:


You could just run grub-install to reinstall GRUB into the new ESP and
register it in EFI boot variables.


I wanted to try the manual way to learn + to create my EFI boot entry with a customized 
name. I think GRUB installation can only create EFI boot entry with the name 
"debian", or is it possible to change that?


You can set an alternative name and location by running grub-install 
with --bootloader-id= or with GRUB_DISTRIBUTOR= in 
/etc/default/grub. It also affects the directory name in the ESP. But 
depending on the grub package version, monolithic GRUB images (signed 
for secure boot) do not support being installed in another location than 
/EFI/debian (I have been advocating to fix this but no luck so far).



No, because in manual partitioning it is up to the user to decide which
ESP(s) is/are suitable for the installation, and set the others as "do
not use".


But is there a reason why DI partitioning does not set all (or previously existing) ESPs 
by default to "do not use" and let the user change that manually


I don't know why it was designed this way.


(perhaps with a reminder message if the user forgets to set the ESP in UEFI 
mode)?


The installer already warns if the partitioning does set an ESP.


Maybe it would be more intuitive + it could avoid/minimize user errors? Or is a 
shared ESP so common that DI partitioning needs its current defaults?


Yes, the ESP is designed to be shared by all boot loaders.

Bug#1034812: Unbootable after install: UEFI installed to wrong ESP

[Pascal Hambourg]

On 09/05/2024 at 12:42, Jmkr wrote:


- I archived "/boot/efi/EFI/debian/grubx64.efi" from "/dev/sda1" to "/
Archive.tar".

- Then, I unmounted "/dev/sda1" from "/boot/efi" and mounted "/dev/sdb1" to
"/boot/efi" and extracted "/Archive.tar" in "/boot/efi" again.

- Later I changed UUID of ESP in "/etc/fstab" file to that of ESP on "/dev/
sdb1".

- Finally using EFIBOOTMGR I deleted the EFI boot entry my system used and
created a new entry for ESP on "/dev/sdb1".


You could just run grub-install to reinstall GRUB into the new ESP and 
register it in EFI boot variables.



Do the fixes mentioned above also address the manual partitioning case?


No, because in manual partitioning it is up to the user to decide which 
ESP(s) is/are suitable for the installation, and set the others as "do 
not use".

Bug#1055583: base-files: EFI System Partition should mount on /efi not /boot/efi

[Pascal Hambourg]

On 15/04/2024 at 13:51, Santiago Vila wrote:


In this bug report, I'm asked to provide /efi as a mount point for the 
EFI partition.


Given that base-files does not even contain /boot/efi (the supposedly 
"old" location),

I believe this is a decision for you to make, hence the reassign.


partman-efi sets /boot/efi as the mount point for the ESP because this 
is where grub-install expects the ESP to be mounted by default. Changing 
the ESP mount point first implies to either:
- change all relevant package and installer scripts to call grub-install 
with --efi-directory=/efi
- change grub-install --efi-directory default to /efi instead of or in 
addition to /boot/efi
- replace GRUB with a boot loader such as systemd-boot which expects the 
ESP to be mounted on /efi by default

Bug#1068833: discover: A game installed via Discover doesn't start

[Pascal Hambourg]

Control: reassign -1 plasma-discover 5.27.5-2

On Thu, 11 Apr 2024 21:49:48 + Ilkka Kallioniemi 
 wrote:

On Thu, 11 Apr 2024 21:45:53 +0200 Pascal Hambourg  
wrote:
> Discover is a hardware identification system. Aren't your confusing with
> plasma-discover ?

Yes, I am. Sorry for confusing those. How to fix the mixup I caused?


This mail should reassign the bug to the right package.

Bug#1068833: discover: A game installed via Discover doesn't start

[Pascal Hambourg]

On 11/04/2024 at 20:22, Ilkka Kallioniemi wrote:

Package: discover

(...)

When installing game MegaGlest using Discover, the installed game is not fully
installed.


Discover is a hardware identification system. Aren't your confusing with 
plasma-discover ?

Bug#996202: EFI Secure Boot for systemd-boot

[Pascal Hambourg]

On 05/03/2024 at 00:58, Luca Boccassi wrote:

On Mon, 4 Mar 2024 at 23:28, Steve McIntyre  wrote:


What's your plan for installing as the secondary boot loader for shim
to call?


'bootctl update' already recognises and prefers foo.efi.signed if
present, so installing to the ESP is easy (PR still doesn't add the
call, will probably add a trigger).

But as you know Shim right now compiles in the filename of the second
stage, so for now interested testers will have to manually rename the
file in the ESP from systemd-bootx64.efi to grubx64.efi, which is of
course not ideal - let's call it a technological preview.


What about the installation of shim files into the ESP along with 
systemd-boot ? Does bootctl take care of it ? If no, are there any plans 
to integrate it ?


Also, are there any plans to support multiple ESPs for boot redundancy 
(e.g. in software RAID setups) ?

Bug#769738: marked as done (debian-installer: Please automatically mount /usr in rescue mode)

[Pascal Hambourg]

On 02/03/2024 at 15:45, Debian Bug Tracking System wrote:

Your message dated Sat, 2 Mar 2024 15:42:38 +0100
with message-id 
and subject line Re: #769738: split usr is unsupported


Seriously ?


has caused the Debian Bug report #769738,
regarding debian-installer: Please automatically mount /usr in rescue mode
to be marked as done.


This bug is a duplicate of #1000239 which was fixed in rescue 1.86.

Bug#1065048: installation-reports: partition tool in d-i remembers choices; 'delete partition' (encrypted Part.) always stays 'yes'

[Pascal Hambourg]

On 29/02/2024 at 08:51, Frank Weißer wrote:


Comments/Problems: 2nd NIC gets eth0 on reboot, 2nd NIC gets eth1 :-(


eth* names are no persistent and may change at any boot.
But ethernet interface should get predictable names like enpXsY or enoX.
In /proc/interrupts we can see enp1s0.


randomized encrypted partitions default to 'delete partition' 'yes';
after choosing 'no' the first time it should default to 'no'


By "randomized" do you mean "plain dm-crypt with random key" ?


The only choice of extended filesystems to format the randomized
encrypted partition with is ext2, which the d-i writes to /etc/fstab.
But the d-i actually formats to ext4, so I end up in emergency mode on
reboot

the d-i also misses to write the 'tmp' parameter for the randomized
encrypted ext4 formatted partition in /etc/crypttab


These two remind me of Bug#995108 ("d-i: partman-crypto: plain dm-crypt 
device management issues").



I had submitted a patch but received no feedback so far.

Bug#1064906: Connman manages vnet virtual ethernet interfaces and assigns direct default route when DHCP fails

[Pascal Hambourg]

Package: connman
Version: 1.41-3

* My use case:
I run a virtual machine with virt-manager (KVM/QEMU). Each time the 
virtual machine is switched on, virt-manager creates a virtual ethernet 
interface vnetN with a different number and MAC address on the host and 
attaches it to the bridge virbr0. As a bridge member, vnetN is not 
supposed to receive any IP configuration.
Connman was installed on the host with LXDE and manages the physical 
ethernet and wireless interfaces with IPv4 and IPv6 automatic configuration.


* Problem description:
By default, connman manages vnetN with automatic methods and, after 
failing to use DHCP, assigns it a link-local IPv4 address (APIPA 
169.254.0.0/16) and a direct default IPv4 route with default metric (the 
highest priority). This default route conflicts with the existing IPv4 
default route associated with the physical network interface and breaks 
the host IPv4 connectivity outside the LAN.


syslog:

2024-02-27T14:40:24.211054+01:00 chantecler connmand[14215]: vnet0 {add} 
address 169.254.248.201/16 label vnet0 family 2
2024-02-27T14:40:24.211505+01:00 chantecler connmand[14215]: vnet0 {add} route 
169.254.0.0 gw 0.0.0.0 scope 253 
2024-02-27T14:40:24.211727+01:00 chantecler connmand[14215]: vnet0 {add} route 
0.0.0.0 gw 0.0.0.0 scope 253 
2024-02-27T14:40:24.211943+01:00 chantecler connmand[14215]: vnet0 {add} route 
0.0.0.0 gw 0.0.0.0 scope 253 


ip addr:

2: enp0s25:  mtu 1500 qdisc fq_codel 
state UP group default qlen 1000
inet 192.168.0.252/24 brd 192.168.0.255 scope global enp0s25
4: virbr0:  mtu 1500 qdisc noqueue state UP 
group default qlen 1000
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
8: vnet0:  mtu 1500 qdisc noqueue 
master virbr0 state UNKNOWN group default qlen 1000
inet 169.254.248.201/16 brd 169.254.255.255 scope global vnet0


ip route:
0.0.0.0 dev vnet0 scope link 
default dev vnet0 scope link 
default via 192.168.0.1 dev enp0s25 
169.254.0.0/16 dev vnet0 proto kernel scope link src 169.254.248.201 
192.168.0.0/24 dev enp0s25 proto kernel scope link src 192.168.0.252 
192.168.0.1 dev enp0s25 scope link 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 


* Workaround:
Add "vnet" to NetworkInterfaceBlacklist in /etc/connman/main.conf.

* Comments/questions:
1) Isn't it desirable to ignore "vnet" interfaces in the default 
configuration ? Or is there a use case where connman should manage vnet 
interfaces ?


2) What is the use case for creating a direct default IPv4 route when 
DHCP failed and an APIPA address was assigned, specially when another 
default route already exists ? Communicating with other hosts in the 
APIPA subnet on the same LAN does not require it. It may allow to send 
packets to other hosts in non-APIPA subnets on the same LAN, but usually 
they do not have a direct route to the APIPA subnet and are unable to reply.


3) If such use case exists, shouldn't this default route have a low 
priority (high metric) so that other default routes take precedence ?

Bug#1029788: Acknowledgement (connman breaks systemd/udev network interface name policy)

[Pascal Hambourg]

Control: found -1 1.41-3

After migrating to bookworm, I confirm the issue is still present.

Workaround: append ",eth,wlan" to NetworkInterfaceBlacklist in 
/etc/connman/main.conf so that connman ignores ethernet and wireless 
interfaces until they are renamed, assuming new names do not start with 
"eth" or "wlan" (default ones do not).

Bug#1064624: Hard to short-stroke an encrypted drive

[Pascal Hambourg]

On 27/02/2024 at 08:42, Philip Hands wrote:

Matthew Wilcox  writes:


I want "use largest contiguous space and set up encrypted LVM".
That would let me reserve 200GB of my SSD as unencrypted free space,
which will improve the write endurance of my SSD.


Can one achieve this by telling LVM to allocate less than the full size
of the device to the PV one puts on it?


AFAIK partman does not support it. But guided partitioning allows to 
reserve some free space in the VG, which achieves the same goal.



If one does that, I would guess that one could later extend the PV to
use more/all of the disk using pvresize, so that those that prefer space
over endurance could make that decission when they are running out of
space.


IMO reserving free space in the VG allows this more easily, as you do 
not need to resize the PV when you need to use the free space.


But both ways have the same issue with Matthew's use case: when/if 
partman-auto-crypto erases (=writes with random data) the whole 
underlying LUKS partition, all its blocks are marked "in use" by the SSD.

Bug#1064624: Hard to short-stroke an encrypted drive

[Pascal Hambourg]

On 26/02/2024 at 01:14, Matthew Wilcox wrote:



- create a logical volume in the free VG space
- blkdiscard the logical volume


Last time I checked, dm-crypt did not pass DISCARD requests through to
the underlying device because it's a security hazard.


AFAICS dm-crypt and cryptsetup have supported discard since Linux 3.1.

crypttab(5) states that "starting with Debian 10 (Buster), this option 
is added per default to new dm-crypt devices by the Debian Installer".


Discard can still be disabled at the filesystem or swap level, or you 
can disable dm-crypt discard after running blkdiscard.

Bug#1064624: Hard to short-stroke an encrypted drive

[Pascal Hambourg]

On 25/02/2024 at 23:55, Matthew Wilcox wrote:


I want "use largest contiguous space and set up encrypted LVM".
That would let me reserve 200GB of my SSD as unencrypted free space,
which will improve the write endurance of my SSD.


Alternatively, the installer allows to reserve free space in the encrypted
volume group.


That does not accomplish my goal of extending the life of my SSD.  The
SSD will see those blocks as "in use" because they have encrypted data
written to them


Not if you do not write anything to them, or if you TRIM them.

You may either
- tell the installer not to erase (=write) the encrypted partition (if 
guided partitioning prompts it, not sure)

or
- enable "discard" in /etc/crypttab (should be the default)
- create a logical volume in the free VG space
- blkdiscard the logical volume


(it cannot tell that they are encrypted blocks of zeroes
because, well, they're encrypted).


Irrelevant. Once written, even with plaintext zeroes, a block is 
considered used until it is TRIMmed.

Bug#1064624: Hard to short-stroke an encrypted drive

[Pascal Hambourg]

On 25/02/2024 at 05:40, Matthew Wilcox wrote:


The partitioner "guided partitioning" offers me:

  - use the largest continuous free space
  - use entire disk
  - use entire disk and set up LVM
  - use entire disk and set up encrypted LVM

I want "use largest contiguous space and set up encrypted LVM".
That would let me reserve 200GB of my SSD as unencrypted free space,
which will improve the write endurance of my SSD.


Alternatively, the installer allows to reserve free space in the 
encrypted volume group.



Also once I start partitioning, eg, "and set up LVM", I can't delete the
partitions again.


The installer allows to delete logical volumes, volume groups and 
unencrypted partitions formerly used as physical volumes, but not 
encrypted volumes nor their underlying partitions.

Bug#1064617: Passwords should not be changed frequently

[Pascal Hambourg]

On 25/02/2024 at 01:17, Matthew Wilcox wrote:


I just did an installation with the 2024-02-24
debian-testing-amd64-netinst.iso image.  I forget the exact wording
used, but when setting up a user, d-i printed advice that user passwords
should be changed frequently.  This is no longer current good advice
(since 2017):


This topic has some history, see

Bug#1064010: Kernel not compiling missing file drm_irq.h

[Pascal Hambourg]

On 15/02/2024 at 18:08, Joshua Brickel wrote:


Whe running apt-get upgrade I get erors about the kernel installing/building
and it tells me to look in the file  /var/lib/dkms/evdi/1.7.0/build/make.log


Are you doing an installation or an upgrade ? From/to which version(s) ?


make[2]: *** [/usr/src/linux-
headers-6.1.0-18-common/scripts/Makefile.build:255:
/var/lib/dkms/evdi/1.7.0/build/evdi_ioc32.o] Error 1
make[2]: *** Waiting for unfinished jobs
In file included from /var/lib/dkms/evdi/1.7.0/build/evdi_main.c:20:
/var/lib/dkms/evdi/1.7.0/build/evdi_drv.h:24:10: fatal error:
drm/drm_irq.h: No such file or directory
   24 | #include 


This looks like bug#1017058 
 which was 
fixed in evdi 1.12.0 available in bookworm. Your evdi version 1.7.0 
seems to be outdated, even bullseye has evdi 1.9.0.

Bug#1060422: partman-crypto: add support for new cryptsetup options for opal/sed

[Pascal Hambourg]

On 11/01/2024 at 12:56, Luca Boccassi wrote:


Yes it is a firmware feature, so it depends on the hardware, and in all
drives I know of that will be the case, yes. From that point of view,
to me it doesn't seem that far away from dm-crypt using the CPU's AES-
NI to actually encrypt/decrypt data, or anything else implemented in
hardware/firmware that the installer now supports out of the box with
non-free-firmware being enabled by default. If I am trusting Intel to
handle my data in their wifi firmware, and in their CPU microcode, and
memory controllers, and whatever else is on my hardware, it seems
strange to start worrying once the line is crossed into the NVME
firmware...


Correct me if I'm wrong, but aren't CPUs and wifi controllers 
pass-through devices which do not persistently store encryption keys or 
data and whose encrypted output can be inspected to check if they are 
doing the right thing so that you do not have to blindly trust them ?


Self-encrypted drives persistently store encryption keys and data. Can 
their encrypted output reliably be inspected ? Can they be trusted if 
the manufacturer implemented some hidden mechanism allowing to recover 
the data when customers lost their password (like BIOS manufacturers do) 
which will be leaked sooner or later ?

Bug#1060368: partman-auto: add basic support for loongarch64

[Pascal Hambourg]

Hello,

On 10/01/2024 at 04:15, zhangdandan wrote:


Support automatic partition adaptation partman-auto for debian-installer.
Please consider the patch (my local patch) I have attached.


I do not know anything about the loongarch64 architecture, but I can't 
help having questions about the proposed recipes. Do you have any 
pointers about the disk layout expected by this platform ? Or is it 
standard UEFI disk layout ?


- loong64 and loong64-efi recipes are identical, so why not use symlinks 
like other recipes do instead of duplicating files ?


- Why is a separate /boot partition created only if the partitioning 
scheme is GPT ?


- A regular FAT32 filesystem is explicitly mounted on /boot/efi. Is it 
intended to be used as an EFI system partition ?


- If yes, why doesn't it use the dedicated "efi" method ?

- Moreover, why does it have "lvmok" (meaning that it can be a LVM 
logical volume) ? Platform firmware usually cannot read LVM.

Bug#1059370: Installation did not work: Kernel panic, see below

[Pascal Hambourg]

I forgot to mention it, but please also reply to the bug report address, 
not only me.


On 27/12/2023 at 12:17, Christian Kirsch wrote:

Yes, thank you! I hadn't dared to execute these commands. But they
worked, very good.
So 'update-grub' and 'grub-install' fits the Problem.


I wonder which one was actually needed. I should have suggested to run 
one and reboot, then run the other one only if the issue persisted.


So maybe GRUB was not properly installed after all. But I am failing to 
figure out what could have gone wrong. Can you compress and attach the 
installation log (/var/log/installer/syslog) please ?



I also activated 'GRUB_DISABLE_OS_PROBER=false' so Ubuntu is also taken
along, for all cases (so said in germany...).
Then this process is finished for me and I thank you for your help,
Christian

Am Mittwoch, dem 27.12.2023 um 11:15 +0100 schrieb Pascal Hambourg:


Basically, the Debian installer just installs required grub packages and
runs grub-install and update-grub in the target system environment so if
GRUB loads and displays the menu, it is unlikely that the installer did
something wrong.

After booting into Debian through Ubuntu's GRUB menu, you can try to
re-run these commands and reboot with Debian GRUB. If it does not fix
the error, then the issue probably lies in GRUB itself and the bug
may be reassigned to grub2.

Bug#1059370: Installation did not work: Kernel panic, see below

[Pascal Hambourg]

Le 26/12/2023 à 20:35, Christian Kirsch wrote:

Thank you for your feedback.
I can probably support the assumption about Grub: I have installed
another partition with Ubuntu. Ubuntu recognizes the Debian partition
and updates the grub correctly. Debian can now be started from there.
This would mean that there is an error in the Debian iso file for the
grub management in the EFI-Partition.


Basically, the Debian installer just installs required grub packages and 
runs grub-install and update-grub in the target system environment so if 
GRUB loads and displays the menu, it is unlikely that the installer did 
something wrong.


After booting into Debian through Ubuntu's GRUB menu, you can try to 
re-run these commands and reboot with Debian GRUB. If it does not fix 
the error, then the issue probably lies in GRUB itself and the bug may 
be reassigned to grub2.



Am Sonntag, dem 24.12.2023 um 00:28 +0100 schrieb Pascal Hambourg:

On 23/12/2023 at 20:52, Christian Kirsch wrote:


When booting (first item), message on Debian screen:
"Arbeitsspeicher
erschöpft" ("Memory exhausted").


It matches the German translation for "out of memory" in GRUB.


Then start in a black terminal screen with Kernel panic: "Kernel
panic
- not syncing: VHS Unable to mount root fs on unknown-block(0,0)"


It looks like a consequence of GRUB failure to load the initramfs
properly.

Bug#1059370: Installation did not work: Kernel panic, see below

[Pascal Hambourg]

On 23/12/2023 at 20:52, Christian Kirsch wrote:


When booting (first item), message on Debian screen: "Arbeitsspeicher
erschöpft" ("Memory exhausted").


It matches the German translation for "out of memory" in GRUB.


Then start in a black terminal screen with Kernel panic: "Kernel panic
- not syncing: VHS Unable to mount root fs on unknown-block(0,0)"


It looks like a consequence of GRUB failure to load the initramfs properly.

Bug#1059167: installation-reports: installer hangs while recognizing network hardware

[Pascal Hambourg]

Hello Janusz,

On 20/12/2023 at 20:52, Janusz Bień wrote:


I understand the installer now includes non-free drivers,


No, only non-free firmware.


but I suspect  it missing one needed for my hardware, which is
Intel Ethernet Connection (7) I219-V
Intel Dual Band Wireless-AC 3168
(on the mainboard ASRock B360M-ITX/AC).


How does the installer hang ? Can you switch to the installer shell in 
tty2 with Ctrl+Alt+F2 ? If yes, can you post the output of


lspci -nnk

and attach (compressed) /var/log/syslog ?

Bug#1058806: HP EliteBook 860 G9 (4C148AV)

[Pascal Hambourg]

On 17/12/2023 à 23:03, Paul van der Vlis wrote:

Op 17-12-2023 om 22:36 schreef Pascal Hambourg:


It may be an initialization issue: this error has been observed when 
booting after Windows hibernation or Fast Startup state. 


There is Windows on the NVMe disk of the laptop. Fastboot and secureboot 
where off.


UEFI/BIOS "fast boot" is not the same as Windows "fast startup".

I have also tested if I could boot the installer with fastboot on or 
secureboot on. But that dit not work.


Debian should work with secure boot on.

Bug#1058806: HP EliteBook 860 G9 (4C148AV)

[Pascal Hambourg]

On 17/12/2023 at 14:31, Paul van der Vlis wrote:


Could it be the issue that was fixed in kernel 6.1.67-1 (available in 
proposed updates)?


The 12.4 installer kernel has the wireless bug but it is uncertain 
whether it affects the installer or not. What was wrong with the 
integrated Intel wireless controller ?


Do you still have the installer logs (/var/log/installer/syslog) ?


I will add the syslog. The error was "iwlwifi: probe of :00:14.3 
failed with error -110"


(Note for those who are reading this thread through the debian-boot 
mailing list: the mail with attachment was too big for the mailing list)


So it is not related with the recent wireless bug in 6.1.66.
It may be an initialization issue: this error has been observed when 
booting after Windows hibernation or Fast Startup state. See

https://bugzilla.kernel.org/show_bug.cgi?id=209641
https://bugzilla.kernel.org/show_bug.cgi?id=201319#c55
for possible workarounds if it happens again.


I see I did not use my Debian 12.4 stick, but a Debian 12.1 stick.


When you tried the installer again, which version was it ?


It's a bit strange install, I did install on an external USB SSD.


I do not think it is relevant.

Bug#1058806: HP EliteBook 860 G9 (4C148AV)

[Pascal Hambourg]

On 16/12/2023 at 23:38, Paul van der Vlis wrote:

Op 16-12-2023 om 22:16 schreef Pascal Hambourg:

On 16/12/2023 at 20:15, Paul van der Vlis wrote:

Image version: Debian 12.4

(...)
I needed an USB dongle to get network. After installation I did use a 
backport-kernel to get the wifi working.

(...)

I have tried it again, and cannot reproduce this problem.

It works with the kernel of the installer. Sorry for the mistake.


What did you try exactly ? The installer or the kernel installed by the 
installer ?


A mistake is hard to believe. Something happened.

Could it be the issue that was fixed in kernel 6.1.67-1 (available in proposed 
updates)?


The 12.4 installer kernel has the wireless bug but it is uncertain 
whether it affects the installer or not. What was wrong with the 
integrated Intel wireless controller ?


Do you still have the installer logs (/var/log/installer/syslog) ?

Bug#1058806: HP EliteBook 860 G9 (4C148AV)

[Pascal Hambourg]

Hello Paul,

On 16/12/2023 at 20:15, Paul van der Vlis wrote:

Image version: Debian 12.4
Machine: HP EliteBook 860 G9 (4C148AV)

(...)

Comments/Problems:
I needed an USB dongle to get network. After installation I did use a 
backport-kernel to get the wifi working.

(...)
00:14.3 Network controller: Intel Corporation Alder Lake-P PCH CNVi WiFi 
(rev 01)


According to /usr/share/misc/pci.ids, this device has PCI ID 8086:51f0 
which is listed in bookworm's iwlwifi module aliases.
Can you post the output of the following commands after booting with 
kernel 6.1 ?


lspci -nnkd ::280
dmesg | grep iwlwifi

Bug#1006708: hw-detect: Fails to reload iwlwifi module (modprobe: FATAL: Module iwlwifi is in use)

[Pascal Hambourg]

On 15/12/2023 at 20:27, Carsten Schoenert wrote:


https://salsa.debian.org/tijuca/hw-detect/-/commit/0e94654ca8ed0faa3790a52280342f388be3db9e


I think it would be better to add this stanza outside (before) the "for 
driver" loop. There are two cases, depending on the controller model:


1) iwlmvm is loaded

modprobe -r $module # fail because iwlwifi is used by iwlmvm
modprobe $module # no-op

for driver in $(find /sys/bus/*/drivers -name "$module"); do
if [ "$module" == "iwlwifi" ]; then
modprobe -r iwlmvm # ok, unloads iwlwifi too
modprobe $module # reloads iwlwifi
fi
...

2) iwlmvm is not loaded

modprobe -r $module -> ok
modprobe $module -> ok

for driver in $(find /sys/bus/*/drivers -name "$module"); do
if [ "$module" == "iwlwifi" ]; then
modprobe -r iwlmvm # no-op
modprobe $module # no-op
fi
...

It appears there are fail and/or no-op in both cases. This would be simpler:

if [ "$module" == "iwlwifi" ]; then
modprobe -r iwlmvm # no-op if not loaded
fi
modprobe -r $module # no-op if unloaded with iwlmvm, but safe
modprobe $module

for driver in $(find /sys/bus/*/drivers -name "$module"); do
...

Bug#1035096: GRUB not installed or installed to the wrong device

[Pascal Hambourg]

Control: forwarded 1035096 
https://salsa.debian.org/installer-team/grub-installer/-/merge_requests/17

Hello,

On 27/05/2023 at 17:24, Cyril Brulebois wrote:


Thanks for testing Pascal's patches. Let's see if we can get that
included early in the Trixie release cycle, before possibly thinking
about some backports via a point release.


Is it the right time to reconsider this patch ?

Bug#1006708: hw-detect: Fails to reload iwlwifi module (modprobe: FATAL: Module iwlwifi is in use)

[Pascal Hambourg]

Hello,

Le 13/12/2023 à 20:16, Cyril Brulebois a écrit :

Carsten Schoenert  (2023-12-13):

The "trick" is to unload the iwlmvm module instead and load afterwards
the module iwlwifi again.


See the very bottom of check-missing-firmware.sh (hw-detect repository),
the loop over $modules. You could try intercepting $module = iwlwifi,
and adding a modprobe -r theotherone beforehand.


Wouldn't it be more generic to check /sys/module/${module}/holders like 
is done for mhi ?


Note: iwldvm is also loaded by iwlwifi (for older hardware I guess) and 
depends on it, but AFAICS it is not loaded when the requested firmware 
is missing, so there is no need to unload it. Is it expected that the 
behaviour is different with hardware using iwlmvm ?

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

[Pascal Hambourg]

On 25/11/2023 at 22:29, David Hillman wrote:

On 11/25/23 01:37, Cyril Brulebois wrote:

Extracting /var/log/syslog would be useful to understand what's going on
there. (...)

Thanks Cyril.  This system is running Debian 12, so there is no 
/var/log/syslog.


Cyril meant the installer syslog, which is saved in /var/log/installer 
on the installed system at the end of the installation.


(Gmail will probably reject this mail though)

Bug#1056655: Missing dependencies for grub-install lzo and xz compression

[Pascal Hambourg]

Package: grub2-common
Version: 2.06-13+deb12u1
Severity: minor

Dear maintainer,

grub-install --compress=lzo calls lzop provided by package lzop.

grub-install --compress=xz calls xz provided by package xz-utils.

However grub2-common does not have any dependency on these packages.

These packages have optional and standard priorities, which do not 
guarantee that they are present in a base installation. Maybe they 
should be added to Suggests (at least for user information) ?

Bug#1055806: installation-reports: Installer doesn't recognize laptop's SSD, but calamares does

[Pascal Hambourg]

On 11/11/2023 à 21:43, Jessie wrote:


However, when detecting disks, the only disk available for install was the usb 
drive I had the installer on - it did not detect the 256gb UFS SSD.


It looks like UFS (Universal Flash Storage, not Unix filesystem) kernel 
modules are not included in d-i initrd or udebs.

Bug#1054373: Regression in monolithic EFI normal disk boot image with --removable and --bootloader-id

[Pascal Hambourg]

MR: https://salsa.debian.org/grub-team/grub/-/merge_requests/44

Bug#1054373: Regression in monolithic EFI normal disk boot image with --removable and --bootloader-id

[Pascal Hambourg]

Package: src:grub2
Version: 2.06-14

Commit 5171e04d ("Bundle unicode.pf2 in a squashfs memdisk attached to 
the signed EFI binary") removed (memdisk)/grub.cfg from monolithic EFI 
normal disk boot images.


So now the normal disk boot image looks for grub.cfg in /EFI/debian only 
and not in $cmdpath any more. This breaks boot from the removable media 
path when installed with --removable, and normal boot when installed 
with --bootloader-id or $GRUB_DISTRIBUTOR != "debian".


Expected behaviour: GRUB loads $cmdpath/grub.cfg and displays the menu.
Observed behaviour: GRUB does not load $cmdpath/grub.cfg and enters 
command-line mode instead of displaying the menu.


Proposed fix: add a new grub.cfg into normal disk boot images instead of 
re-adding the previously used one which seems to be intended for CD boot 
images.


Option A: the new embedded grub.cfg looks for grub.cfg in $cmdpath first 
then in $prefix as fallback.


Option B: the new embedded grub.cfg looks for grub.cfg in $cmdpath only.
Caveats:
- For boot from the removable media path to keep working when installed 
with --force-extra-removable, this change requires to patch grub-install 
to install grub.cfg into the removable media path too.
- For boot from live and installation ISO-hybrid images to keep working, 
this change requires to patch the image builders to install grub.cfg 
into the removable media path.


Note: option A may also require grub-install --force-extra-removable to 
install grub.cfg in /EFI/Boot in order to boot properly from the 
removable media path when combined with --no-nvram and --bootloader-id 
or $GRUB_DISTRIBUTOR != "debian", which was already broken.

Bug#1050979: debian-installer-12-netboot-amd64 Drive Order scrambled

[Pascal Hambourg]

On 15/09/2023 at 17:26, Todd Morgan wrote:

AFAIK /dev/sd* discovery and ordering was never guaranteed to be
deterministic nor persistent across boots nor match any hardware or
firmware ordering. One should not rely on these names, hence the use of
persistent identifiers such as UUID, device path or disk ID.


I agree. That is why I used UUID for the fstab entries. But this drive
ordering issue is specific to the installer. The preseed is expecting
a /dev/sd* type of entry in order for partman to partition the correct
drive...or in my case (using software RAID1) drives.


If I understand correctly, the issue is not drive ordering but the 
preseed capability to handle persistent drive identifiers.

Bug#1051611:

[Pascal Hambourg]

On 10/09/2023 at 16:59, G M wrote:

Install boot loader Grub - error.
Partitions: SCSI 20GB, Default partition layout for BIOS systems.


Failure to mount efivarfs in the target system. Looks like a duplicate 
of .

Bug#1051468: cannot install BIOS machine with mini.iso, error creating /target/sys/firmware/efi/efivars

[Pascal Hambourg]

On 08/09/2023 at 13:56, Marc Haber wrote :


I tried installing sid from mini.iso into a libvirt/qemu/kvm VM with
BIOS "firmware", choosing mainly default values, and ended up with the
system logging "grub-installer: error: Error creating
/target/sys/firmware/efi/efivars" and an error message "Failed to mount
/target/proc, Mounting the proc file system on /target/proc failed".


This issue has been discussed in #1031183 starting from

(it is a different issue from the original bug report, so a separate bug 
should have been filed) and a merge request is in progress.

Bug#1050979: debian-installer-12-netboot-amd64 Drive Order scrambled

[Pascal Hambourg]

On 01/09/2023 at 01:17, Todd Morgan wrote:


When using the same method to install Debian 12, I am noticing that the
installer is detecting the drives out of order. It does not match what the
server BIOS or HPE ILO5 displays. With each PXE installation attempt the
ordering can vary. Looking in /dev/disk/by-path you can see the symlinks
differ between install attempts. Sometimes the order matches the PCI bus
reference and sometimes it's jumbled up.


AFAIK /dev/sd* discovery and ordering was never guaranteed to be 
deterministic nor persistent across boots nor match any hardware or 
firmware ordering. One should not rely on these names, hence the use of 
persistent identifiers such as UUID, device path or disk ID.



This is an issue when you want to tell partman to use /dev/sda (the first
drive) for the installation and have grub installed properly on /dev/sda.


I advise to not hardcode /dev/sd* anywhere and use persistent 
identifiers instead.

Bug#1050287: r8168-dkms: can't compile in kernel 6.4.0-3-amd64

[Pascal Hambourg]

On Fri, 25 Aug 2023 16:04:42 +0300 l...@forum-debian.fr wrote:


Replace
#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,5,0)

By
#if LINUX_VERSION_CODE >= KERNEL_VERSION(6,4,10)


Indeed the gso split introduced in linux 6.5 was backported into linux 
6.4.10 (commit bbe07adbaf39c2c5a95c3ca7eb52b2119d50af7d). I did not find 
it in previous stable series.


PS: You can delete 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050328 which is a 
duplicate.


I don't think a bug report can be deleted and IIUC it should be closed 
only when the bug is fixed, so it should have been merged instead.

Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Pascal Hambourg]

On 13/07/2023 at 08:54, Arnaud Rebillout wrote:
Following up with that, it seems that the failure is due to a change in 
the kernel.


I'm testing 2 Kali netinst ISOs, one from last week (no problem), and a 
daily iso from today (which fails).


Last weekly iso had kernel 6.1.0-kali9-amd64. In this iso, `cat 
/proc/filesystems | grep efi` gives nothing, hence the grub-installer 
postinst doesn't try to mount the efivarfs.


Today's iso has kernel 6.3.0-kali1-amd64. In this iso, `cat 
/proc/filesystems | grep efi` gives `nodev efivarfs`, hence the 
grub-installer postinst tries to mount efivarfs, and fails.


FTR, this is due to the following change in linux 6.3:

commit 301de9a2055357375a4e1053d9df0f8f3467ff00
Author: Johan Hovold 
Date:   Thu Jan 19 17:42:53 2023 +0100

efivarfs: always register filesystem

The efivar ops are typically registered at subsys init time so that
they are available when efivarfs is registered at module init time.

Other efivars implementations, such as Google SMI, exist and can
currently be built as modules which means that efivar may not be
available when efivarfs is initialised.

Move the efivar availability check from module init to when the
filesystem is mounted to allow late registration of efivars.

Bug#1031183: grub-installer: postinst fails if efivarfs cannot be mounted

[Pascal Hambourg]

On 21/08/2023 at 11:56, Arnaud Rebillout wrote:

On 21/08/2023 04:03, Philip Hands wrote:

If you want to do your own tests, the mini.iso can be downloaded via:

https://salsa.debian.org/philh/grub-installer/-/jobs/4582667/artifacts/file/debian/output/debian-202306XX+salsaci+20230820+228-amd64-gtkmini.iso


Hello, I download it and tested it in a QEMU VM. I tested it two times: 
with and without UEFI enabled. I can report that installation succeeded 
in both cases.


Did anyone test with EFI boot and fallback to legacy mode in partman 
("do not force EFI installation") ?

Bug#1043226: debian-installer: Please consider moving root user setup to expert install, or change text

[Pascal Hambourg]

On 19/08/2023 at 10:28, Diederik de Haas wrote:

On Monday, 7 August 2023 18:25:07 CEST Jonathan Carter wrote:


Firstly, the instructions start off with "You need to set a password for
'root'", followed by seemingly uninteresting text about what a good password
should be, which makes it incredibly easy for users to miss the part that
sudo won't be set up for the first user.


Then just move the sudo text before the good password text.


So, many users, and especially newcomers to Debian, follow the instructions
in the first line and are then surprised when they can't use sudo from
their user from their newly installed system.


So what ? All they have to do is use su and add themselves to the sudoers.


Would it perhaps make more sense to move the root password setup to the
expert install d-i preseed entirely? Since this is likely only something
that expert users would require in the first place?


Unless there's something actually wrong about having an enabled root account
with a password, I would prefer if the option would stay.


Me too. Unless it changed recently, a root password is required to start 
the emergency shell when booting in recovery mode, so not having a root 
password makes fixing some problems harder.



move the explanation of what happens upward so that it's
more prominent and not so easy to miss.


Agreed. The good password text is relevant only when the user chooses to 
set a root password and not set up sudo for the first user.