[bug submitter is no longer reachable; mail address does not exist ]
Am 18. September 2024 00:16:03 MESZ schrieb Pascal Hambourg
:
>
>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
>MR1
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.
Hi Pierre,
Garinot Pierre wrote:
>* What was the outcome of this action?
> Partitionning fails with the following message in syslog:
> "partman-auto: Available disk space (2147) too small for expert recipe(3994);
> skipping"
>
>* What outcome did you exp
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
Your message dated Tue, 10 Sep 2024 21:57:44 +
with message-id
and subject line Bug#929322: fixed in partman-auto 167
has caused the Debian Bug report #929322,
regarding partman-auto: Should increase size of / in multi and home recipes
to be marked as done.
This means that you claim that the
Your message dated Tue, 10 Sep 2024 21:57:44 +
with message-id
and subject line Bug#1076952: fixed in partman-auto 167
has caused the Debian Bug report #1076952,
regarding [RFD] partman-auto: Update guided partitioning size limits for
current and future needs
to be marked as done.
This
Your message dated Tue, 10 Sep 2024 21:57:44 +
with message-id
and subject line Bug#1076823: fixed in partman-auto 167
has caused the Debian Bug report #1076823,
regarding partman-auto: please increase default size of /boot
to be marked as done.
This means that you claim that the problem has
Your message dated Tue, 10 Sep 2024 21:57:44 +
with message-id
and subject line Bug#1076753: fixed in partman-auto 167
has caused the Debian Bug report #1076753,
regarding partman-crypto: Default size for /boot partition too low
to be marked as done.
This means that you claim that the
Thank you for your contribution to Debian.
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 10 Sep 2024 22:40:04 +0200
Source: partman-auto
Architecture: source
Version: 167
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team
Changed
partman-auto_167_source.changes uploaded successfully to localhost
along with the files:
partman-auto_167.dsc
partman-auto_167.tar.xz
partman-auto_167_amd64.buildinfo
Greetings,
Your Debian queue daemon (running on host usper.debian.org)
Thank you for your contribution to Debian.
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 10 Sep 2024 21:38:23 +0200
Source: partman-crypto
Architecture: source
Version: 126
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team
partman-crypto_126_source.changes uploaded successfully to localhost
along with the files:
partman-crypto_126.dsc
partman-crypto_126.tar.xz
partman-crypto_126_amd64.buildinfo
Greetings,
Your Debian queue daemon (running on host usper.debian.org)
partman-auto-lvm_96_source.changes uploaded successfully to localhost
along with the files:
partman-auto-lvm_96.dsc
partman-auto-lvm_96.tar.xz
partman-auto-lvm_96_amd64.buildinfo
Greetings,
Your Debian queue daemon (running on host usper.debian.org)
Thank you for your contribution to Debian.
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 10 Sep 2024 21:28:43 +0200
Source: partman-auto-lvm
Architecture: source
Version: 96
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team
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
Hi,
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
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
Hi,
Pascal Hambourg wrote (Sun, 8 Sep 2024 11:53:28 +0200):
> On 30/08/2024 at 13:32, Holger Wansing wrote:
> >>>>> Am 27. August 2024 23:46:41 MESZ schrieb 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
3: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 s
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
Hi,
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
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
tem.
I would like to leave these for another discussion as well...
>>> 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 se
. 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 (i
hardware/housing
>>allows to add one more disk).
>
>I did not consider this use case. Wouldn't it be simpler to use manual
>partitioning ?
Yes, for sure!
I just wanted to save the installer-team from "the small_disk recipe does not
work" bugreports :-)
>
>&g
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 cal
iskspace"
issue without reinstalling - at least when the machine hardware/housing
allows to add one more disk).
Or otherwise the entry should be not visible.
BTW: I could not test the ESP part, since my test image cannot boot via EFI.
My remastering somehow breaks the EFI boot capabili
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/Debi
w-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
, 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
in the
installation images, I think.
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!
> > Screenshots from tests with 4 different disk sizes are at the same URL
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
Hi,
Holger Wansing wrote (Sun, 25 Aug 2024 16:53:28 +0200):
> 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)
Screenshots from tests with 4 different disk sizes are
Hi,
Holger Wansing wrote (Sun, 25 Aug 2024 13:09:32 +0200):
> Hi,
>
> Pascal Hambourg wrote (Sat, 24 Aug 2024 20:48:39
> +0200):
> > On 23/08/2024 at 17:52, Holger Wansing wrote:
> > >
> > > @Pascal: Would you be able to provide a merge request for th
Hi,
Pascal Hambourg wrote (Sat, 24 Aug 2024 20:48:39
+0200):
> 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 min
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
<https://salsa.debian.org/installer-team/partman-auto-lvm/-/merge_requests/5>
Note:
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
t 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
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.
;> - 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
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"
Hi,
Pascal Hambourg wrote (Sun, 18 Aug 2024 23:46:13
+0200):
> 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/
>
> Tha
Pascal Hambourg writes:
> 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'd
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
Am 18. August 2024 21:50:53 MESZ schrieb Pascal Hambourg
:
>
>> 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 ?
>T
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
, 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/part
minfo' has "MemTotal = 2021952 kB" for example, when I start
> >qemu
> >with '-m 2048M', so I assume everything is fine with the VM, right?
> >Or am I missing something?)
>
> Ah, I forgot about
>
> partman-auto/cap-ram=1024
>
&g
ith '-m 2048M', so I assume everything is fine with the VM, right?
>Or am I missing something?)
Ah, I forgot about
partman-auto/cap-ram=1024
as default setting for this feature.
Sorry.
--
Sent from /e/ OS on Fairphone3
Hi,
Pascal Hambourg wrote (Sun, 18 Aug 2024 12:33:50
+0200):
> <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.
Many thanks for this!
(I can better go testi
[Sorry about the slow reply -- school holidays are making me afk a lot.]
Holger Wansing writes:
> Hi,
>
> Am 9. August 2024 22:08:09 MESZ schrieb Pascal Hambourg
> :
>>On 09/08/2024 at 17:05, Philip Hands wrote:
>>
>>> I tend to install servers with something like the multi recipe, except
>>> i
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-a
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 s
Forward to the correct bug
Ursprüngliche Nachricht
Von: Diederik de Haas
Gesendet: 17. August 2024 13:17:18 MESZ
An: Pascal Hambourg , Holger Wansing
, 1076...@bugs.debian.org, Philip Hands
CC: "José Ángel Pastrana" , Vagrant Cascadian
Betreff: Bug#1076952: [RF
On Fri Aug 16, 2024 at 8:39 AM CEST, Pascal Hambourg wrote:
> 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 ? I
Hi,
Pascal Hambourg wrote (Fri, 16 Aug 2024 08:39:18
+0200):
> 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
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 (= recip
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 ?
> Currently, partman-auto has the following recipes for ARM:
/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)
On Thu Aug 15, 2024 at 5:50 PM CEST, Pascal Hambourg wrote:
> On 15/08/2024 at 16:25, Diederik de Haas wrote:
> >> 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 withi
rved 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
n ([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.
>
>
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 y
On Thu Aug 15, 2024 at 8:26 AM CEST, Holger Wansing wrote:
> Am 15. August 2024 00:47:22 MESZ schrieb Diederik de Haas
> :
> >On ARM devices it would be very useful if the first 16MB would be
> >(automatically) reserved.
> >The U-Boot bootloader is normally put in the first part of the boot
> >dev
Hi,
Am 15. August 2024 00:47:22 MESZ schrieb Diederik de Haas
:
>On Fri Aug 9, 2024 at 10:08 PM CEST, Pascal Hambourg wrote:
>> 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.
>
>I'm
On Fri Aug 9, 2024 at 10:08 PM CEST, Pascal Hambourg wrote:
> 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.
I'm not 100% sure if this fits into this subject/discussion, but ...
On AR
Hi,
Am 9. August 2024 22:08:09 MESZ schrieb Pascal Hambourg
:
>On 09/08/2024 at 17:05, Philip Hands wrote:
>
>> 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
gnore{ } 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
Holger Wansing writes:
> Hi,
>
> Am 8. August 2024 08:16:03 MESZ schrieb 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.
>>
>>Wha
Hi,
Am 8. August 2024 08:16:03 MESZ schrieb 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 thi
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 ?
- /s
s could be focused on desktops/laptops,
> which use something like Swap=RAM, to allow hibernation.
> Having such concept, would probably allow to get rid of the
> partman-auto/cap-ram thingy, which solved one problem by creating a new
> one...
FWIW: +1
I found it odd that the default
built-in.
The other (already existing) recipes could be focused on desktops/laptops,
which use something like Swap=RAM, to allow hibernation.
Having such concept, would probably allow to get rid of the partman-auto/cap-ram
thingy, which solved one problem by creating a new one...
> The issue
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 al
Hello Pascal,
I would like to suggest /var/log recipe. I think it is a valuable recipe
for production environments.
For example, imagine a simple partitioning with / recipe for all. On
more than one occasion, whether a process writes up too fast in /var/log
recipe, it would exhaust free spac
Hi,
Pascal Hambourg wrote (Mon, 5 Aug 2024 00:04:42 +0200):
> 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 obscu
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 reac
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
Processing control commands:
> tags -1 + pending
Bug #1076823 [partman-auto] partman-auto: please increase default size of /boot
Added tag(s) pending.
--
1076823: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076823
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Control: tags -1 + pending
MR!13 has just been merged.
"Debian Bug Tracking System" wrote (Tue, 23 Jul 2024
19:54:03 +):
> Processing control commands:
>
> > found -1 166
> Bug #1076823 [partman-auto] partman-auto: please increase default size of
> /boot
&
Processing control commands:
> reassign -1 partman-auto
Bug #1076753 [src:partman-crypto] partman-crypto: Default size for /boot
partition too low
Bug reassigned from package 'src:partman-crypto' to 'partman-auto'.
No longer marked as found in versions partman-crypto/1
Control: reassign -1 partman-auto
Control: found -1 166
Control: tags -1 + pending
Pascal Hambourg wrote (Tue, 23 Jul 2024 08:22:04
+0200):
> On 23/07/2024 at 01:49, Thomas Mayer wrote:
> >
> > when selecting "Guided - use entire disk and set up encrypted LVM" wit
Processing control commands:
> found -1 166
Bug #1076823 [partman-auto] partman-auto: please increase default size of /boot
Marked as found in versions partman-auto/166.
--
1076823: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076823
Debian Bug Tracking System
Contact
Control: found -1 166
--
Holger Wansing
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
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
Source: partman-crypto
Version: 125
Severity: normal
Tags: d-i
Dear Maintainer,
when selecting "Guided - use entire disk and set up encrypted LVM" with
a 256GiB disk, only 510MiB are used for the unecrypted /boot partition.
With file sizes of 250MB for initrd.img-6.9.9-amd64 this is
Package: partman-crypto
Version: 125
After the fix for #1017542 was applied (version 125 of partman-crypto), a
warning message is printed on each boot on new installations. It's only
cosmetic, but it would still be nice if that warning could be removed...
boot message (from 125 on
by default. Restore the upstream default and make
> > /tmp/ a tmpfs. Can be overridden with: touch
> > /etc/systemd/system/tmp.mount or: systemctl mask tmp.mount
>
> Does a /tmp entry in /etc/fstab also override the default ?
>
> In either case, what about partman-au
/etc/systemd/system/tmp.mount or: systemctl mask tmp.mount
Does a /tmp entry in /etc/fstab also override the default ?
In either case, what about partman-auto/recipes*/multi recipes which
create a dedicated /tmp partition or logical volume ?
Thank you for your contribution to Debian.
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 07 Jul 2024 21:40:26 +0200
Source: partman-basicfilesystems
Architecture: source
Version: 166
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System
partman-basicfilesystems_166_source.changes uploaded successfully to localhost
along with the files:
partman-basicfilesystems_166.dsc
partman-basicfilesystems_166.tar.xz
partman-basicfilesystems_166_amd64.buildinfo
Greetings,
Your Debian queue daemon (running on host
silently ignored.
Some general suggestions:
- Log to syslog the selection of the recipe and the failure to apply / select
one. Notice that increasing the debug level with DEBCONF_DEBUG=5 on kernel
parameter did not help to pinpoint the issue (=recipe still ignored silently).
- Implement a partman
Your message dated Thu, 06 Jun 2024 21:08:38 +
with message-id
and subject line Bug#1065592: fixed in partman-efi 104
has caused the Debian Bug report #1065592,
regarding partman-efi: add build support for loongarch64
to be marked as done.
This means that you claim that the problem has been
partman-efi_104_source.changes uploaded successfully to localhost
along with the files:
partman-efi_104.dsc
partman-efi_104.tar.xz
partman-efi_104_amd64.buildinfo
Greetings,
Your Debian queue daemon (running on host usper.debian.org)
Thank you for your contribution to Debian.
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 06 Jun 2024 22:21:01 +0200
Source: partman-efi
Architecture: source
Version: 104
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team
Changed
partman-auto_166_source.changes uploaded successfully to localhost
along with the files:
partman-auto_166.dsc
partman-auto_166.tar.xz
partman-auto_166_source.buildinfo
Greetings,
Your Debian queue daemon (running on host usper.debian.org)
Thank you for your contribution to Debian.
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 02 Jun 2024 13:53:57 +0200
Source: partman-auto
Architecture: source
Version: 166
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team
Changed
partman-target_129_source.changes uploaded successfully to localhost
along with the files:
partman-target_129.dsc
partman-target_129.tar.xz
partman-target_129_amd64.buildinfo
Greetings,
Your Debian queue daemon (running on host usper.debian.org)
Thank you for your contribution to Debian.
Accepted:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 28 May 2024 20:33:55 +0200
Source: partman-target
Architecture: source
Version: 129
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team
1 - 100 of 2298 matches
Mail list logo
