Bug#859509: partman-auto uses memory size to determine disk partitioning and fails on high ram installs

2020-02-28 Thread Raymond Burkholder

On 2020-02-28 1:41 p.m., Jelle de Jong wrote:
So I hit this issue installing on my HP server while with the same 
preseed succesfully installed on a few other systms


So I made a virtual machine put 20GB ram in there and an 8GB drive and 
could reproduce the problem.


How can we force partman-auto to not use memory size in its calculation.


Sometimes you  can't use partman-auto.  Sometimes you have to perform 
your own partition management.  This doesn't solve your problem, but 
does show how an example customized partitioning scheme might be 
configured.  This scheme does away with a swap partition. More ideas can 
be found at 
https://blog.raymond.burkholder.net/index.php?/archives/662-Using-Debian-PreSeed-files-and-a-PXEBoot-Server-to-Auto-Build-Hosts.html


There are many example schemes you can find with a search.

## **
# Partitioning scheme:
# Choices:
#partman-auto   partman-auto/choose_recipe  select
d-i partman-auto/choose_recipe  select  custom1

## **
# for internal use; can be preseeded
d-i partman-auto/expert_recipe  string  \
  custom1 ::  \
75 1000 100 ext4\
  $primary{ } $bootable{ }  \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ /boot }   \
  . \
1000 4000 5000 ext4 \
  $primary{ }   \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ / }   \
  . \
5000 1 10 btrfs \
  $primary{ }   \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ btrfs } \
  mountpoint{ /var }\
  . \
4000 8000 1 ext4\
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ /home }   \
  . \
1000 1000 4000 ext4 \
  method{ format } format{ }\
  use_filesystem{ } filesystem{ ext4 }  \
  mountpoint{ /tmp }\
  .





I found out it tries to make swap the same size as memory for suspend, 
but how to disable this??


d-i partman-auto/method string lvm
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-md/device_remove_md boolean true
d-i partman-lvm/confirm boolean true
d-i partman-lvm/confirm_nooverwrite boolean true
d-i partman-auto/choose_recipe select atomic
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
#d-i partman-swapfile/size string"{{ swap | default('512') }}"

Kind regards,

Jelle de Jong





Bug#859509: partman-auto uses memory size to determine disk partitioning and fails on high ram installs

2020-02-28 Thread Jelle de Jong
So I hit this issue installing on my HP server while with the same 
preseed succesfully installed on a few other systms


So I made a virtual machine put 20GB ram in there and an 8GB drive and 
could reproduce the problem.


How can we force partman-auto to not use memory size in its calculation.

I found out it tries to make swap the same size as memory for suspend, 
but how to disable this??


d-i partman-auto/method string lvm
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-md/device_remove_md boolean true
d-i partman-lvm/confirm boolean true
d-i partman-lvm/confirm_nooverwrite boolean true
d-i partman-auto/choose_recipe select atomic
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true
#d-i partman-swapfile/size string"{{ swap | default('512') }}"

Kind regards,

Jelle de Jong



Bug#859509:

2019-04-26 Thread Weller, Lennart
I can confirm this bug still exists with the most recent stretch
version as well as the testing version of buster rc1.

I ran into this issue when I was provisioning a HP DL380p G8 with a HP
Smart Array P420i RAID Controller. I was provisioning the machine with
a live boot initrd + kernel. Both OS versions with firmware cpio.gz
appended to the initramfs. The RAID controller is configured to only
expose a single device (showing up as /dev/sda in the installer shell).

Manually formatting the machine in the installer was not an option and
the installer cannot be continue at this point unless you manually
partition the drive in the shell.

Provisioning Ubuntu 18.04 and 19.04 on the same machine worked just
fine with the exact same method.