The following proposal comes out of the discussion at this weeks Server SIG meeting[1]
Fedora Server will have: * / (root) will be a minimum of 2 GiB and a maximum of 15 GiB * SWAP will continue to be calculated automatically based on available RAM on the system * All unused space will be assigned to a volume group and available to be assigned to new partitions or extend existing partitions. * Anaconda will continue to handle the appropriate EFI and /boot settings
We also discussed during the meeting whether we should have a separate /var partition by default, but the general sense was that we might be better served by developing a mechanism to allow partitions to be split from existing mount points, which would be more flexible going forward.
As we did not have quorum in the meeting by the point we got to this proposal, I'm taking it to the list for discussion and votes.
For the record, the current behavior of the partitioning scheme is for / to be given up to 50 GiB of space and then any remaining space after that is assigned to a separate /home partition.
[1] https://meetbot.fedoraproject.org/fedora-meeting-1/2016-03-15/serversig.2016...
On 03/15/2016 12:17 PM, Stephen Gallagher wrote:
The following proposal comes out of the discussion at this weeks Server SIG meeting[1]
Fedora Server will have:
- / (root) will be a minimum of 2 GiB and a maximum of 15 GiB
- SWAP will continue to be calculated automatically based on available RAM on the system
- All unused space will be assigned to a volume group and available to be assigned to new partitions or extend existing partitions.
- Anaconda will continue to handle the appropriate EFI and /boot settings
This was approved at this week's meeting. I have submitted an update for testing in upcoming composes: https://bodhi.fedoraproject.org/updates/fedora-productimg-server-24-2.fc24
This can be tested with any current Fedora Server 24 install media (such as the Alpha candidates). Simply add the following to the end of the kernel boot line after booting the DVD or netinstall:
On Tue, Mar 22, 2016 at 1:50 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On 03/15/2016 12:17 PM, Stephen Gallagher wrote:
The following proposal comes out of the discussion at this weeks Server SIG meeting[1]
Fedora Server will have:
- / (root) will be a minimum of 2 GiB and a maximum of 15 GiB
- SWAP will continue to be calculated automatically based on available RAM on the system
- All unused space will be assigned to a volume group and available to be assigned to new partitions or extend existing partitions.
- Anaconda will continue to handle the appropriate EFI and /boot settings
This was approved at this week's meeting. I have submitted an update for testing in upcoming composes: https://bodhi.fedoraproject.org/updates/fedora-productimg-server-24-2.fc24
This can be tested with any current Fedora Server 24 install media (such as the Alpha candidates). Simply add the following to the end of the kernel boot line after booting the DVD or netinstall:
This isn't working. I'm using Fedora-Server-netinst-x86_64-24_Alpha-1.7.iso in Boxes and also virt-manager, include the updates image as a boot parameter, but it's not loading in the environment and I'm not sure why.
The journal shows the command line entry and that it matches: [ 0.000000] localhost kernel: Command line: BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-24 quiet updates=https://sgallagh.fedorapeople.org/f24-server.img
[ 4.382596] localhost dracut-cmdline[236]: Using kernel command line parameters: rd.driver.pre=scsi_dh_alua rd.driver.pre=scsi_dh_emc rd.driver.pre=scsi_dh_rdac BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-24 quiet updates=https://sgallagh.fedorapeople.org/f24-server.img ... [ 11.270044] localhost dracut-initqueue[696]: fetching live updates from https://sgallagh.fedorapeople.org/f24-server.img [ 11.283040] localhost dracut-initqueue[696]: % Total % Received % Xferd Average Speed Time Time Time Current [ 11.283355] localhost dracut-initqueue[696]: Dload Upload Total Spent Left Speed [ 12.079138] localhost dracut-initqueue[696]: [237B blob data]
That's not the correct size though; on the web site it's 838K.
... [ 12.357761] localhost dracut-pre-pivot[1215]: Applying updates to live image...
There's nothing in /tmp to indicate it's applied. Nothing in any of the anaconda logs either.
Adam's Coconut robot says the updates image test passed. But I'm not sure which compose ISO is used to test this.
On Wed, Mar 23, 2016 at 4:14 PM, Chris Murphy lists@colorremedies.com wrote:
On Tue, Mar 22, 2016 at 1:50 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On 03/15/2016 12:17 PM, Stephen Gallagher wrote:
The following proposal comes out of the discussion at this weeks Server SIG meeting[1]
Fedora Server will have:
- / (root) will be a minimum of 2 GiB and a maximum of 15 GiB
- SWAP will continue to be calculated automatically based on available RAM on the system
- All unused space will be assigned to a volume group and available to be assigned to new partitions or extend existing partitions.
- Anaconda will continue to handle the appropriate EFI and /boot settings
This was approved at this week's meeting. I have submitted an update for testing in upcoming composes: https://bodhi.fedoraproject.org/updates/fedora-productimg-server-24-2.fc24
This can be tested with any current Fedora Server 24 install media (such as the Alpha candidates). Simply add the following to the end of the kernel boot line after booting the DVD or netinstall:
This isn't working. I'm using Fedora-Server-netinst-x86_64-24_Alpha-1.7.iso in Boxes and also virt-manager, include the updates image as a boot parameter, but it's not loading in the environment and I'm not sure why.
The journal shows the command line entry and that it matches: [ 0.000000] localhost kernel: Command line: BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-24 quiet updates=https://sgallagh.fedorapeople.org/f24-server.img
[ 4.382596] localhost dracut-cmdline[236]: Using kernel command line parameters: rd.driver.pre=scsi_dh_alua rd.driver.pre=scsi_dh_emc rd.driver.pre=scsi_dh_rdac BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-24 quiet updates=https://sgallagh.fedorapeople.org/f24-server.img ... [ 11.270044] localhost dracut-initqueue[696]: fetching live updates from https://sgallagh.fedorapeople.org/f24-server.img [ 11.283040] localhost dracut-initqueue[696]: % Total % Received % Xferd Average Speed Time Time Time Current [ 11.283355] localhost dracut-initqueue[696]: Dload Upload Total Spent Left Speed [ 12.079138] localhost dracut-initqueue[696]: [237B blob data]
That's not the correct size though; on the web site it's 838K.
... [ 12.357761] localhost dracut-pre-pivot[1215]: Applying updates to live image...
There's nothing in /tmp to indicate it's applied. Nothing in any of the anaconda logs either.
Adam's Coconut robot says the updates image test passed. But I'm not sure which compose ISO is used to test this.
Nevermind, it works. For whatever reason, there's no updates image anywhere, and no indication it's been applied in /tmp which is what I've been used to looking for with past anacondas.
I do get a 15GiB fedora-root LV, and installing all add-ons on the DVD, there's only 1.9GiB installed. After installing Xfce and a bunch of developer tools, I still have 12+GiB free. So I think free space is not a problem for installation and updates.
Where it gets thorny is when the sysadmin copies VMs or a database of any decent size onto the server. They might get a surprise if they're not checking free space in advance somewhere. But in Cockpit, resize for root is discoverable, it works, and it's done live. The docker.service and docker-storage-setup.service aren't enabled by default. On the plus side, they can install Docker, never actually use it, and docker-storage-setup won't take 40% of the free space in the VG for the docker thin pool. On the minus side, they have to be aware they need to enable these two things and reboot (or start them) in order to get things going.
So yeah, getting the word out I think will help with expectations. But at this point I'm not seeing any big problems.
Thanks for testing! Would you mind giving positive karma to the bodhi update for fedora-productimg-server?
Sent from my Galaxy Tab® S2<div> </div><div> </div><!-- originalMessage --><div>-------- Original message --------</div><div>From: Chris Murphy lists@colorremedies.com </div><div>Date: 3/23/2016 7:19 PM (GMT-05:00) </div><div>To: server@lists.fedoraproject.org </div><div>Subject: Re: Proposal: Changes to Fedora Server default partitioning scheme </div><div> </div>On Wed, Mar 23, 2016 at 4:14 PM, Chris Murphy lists@colorremedies.com wrote:
On Tue, Mar 22, 2016 at 1:50 PM, Stephen Gallagher sgallagh@redhat.com wrote:
On 03/15/2016 12:17 PM, Stephen Gallagher wrote:
The following proposal comes out of the discussion at this weeks Server SIG meeting[1]
Fedora Server will have:
- / (root) will be a minimum of 2 GiB and a maximum of 15 GiB
- SWAP will continue to be calculated automatically based on available RAM on the system
- All unused space will be assigned to a volume group and available to be assigned to new partitions or extend existing partitions.
- Anaconda will continue to handle the appropriate EFI and /boot settings
This was approved at this week's meeting. I have submitted an update for testing in upcoming composes: https://bodhi.fedoraproject.org/updates/fedora-productimg-server-24-2.fc24
This can be tested with any current Fedora Server 24 install media (such as the Alpha candidates). Simply add the following to the end of the kernel boot line after booting the DVD or netinstall:
This isn't working. I'm using Fedora-Server-netinst-x86_64-24_Alpha-1.7.iso in Boxes and also virt-manager, include the updates image as a boot parameter, but it's not loading in the environment and I'm not sure why.
The journal shows the command line entry and that it matches: [ 0.000000] localhost kernel: Command line: BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-24 quiet updates=https://sgallagh.fedorapeople.org/f24-server.img
[ 4.382596] localhost dracut-cmdline[236]: Using kernel command line parameters: rd.driver.pre=scsi_dh_alua rd.driver.pre=scsi_dh_emc rd.driver.pre=scsi_dh_rdac BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-24 quiet updates=https://sgallagh.fedorapeople.org/f24-server.img ... [ 11.270044] localhost dracut-initqueue[696]: fetching live updates from https://sgallagh.fedorapeople.org/f24-server.img [ 11.283040] localhost dracut-initqueue[696]: % Total % Received % Xferd Average Speed Time Time Time Current [ 11.283355] localhost dracut-initqueue[696]: Dload Upload Total Spent Left Speed [ 12.079138] localhost dracut-initqueue[696]: [237B blob data]
That's not the correct size though; on the web site it's 838K.
... [ 12.357761] localhost dracut-pre-pivot[1215]: Applying updates to live image...
There's nothing in /tmp to indicate it's applied. Nothing in any of the anaconda logs either.
Adam's Coconut robot says the updates image test passed. But I'm not sure which compose ISO is used to test this.
Nevermind, it works. For whatever reason, there's no updates image anywhere, and no indication it's been applied in /tmp which is what I've been used to looking for with past anacondas.
I do get a 15GiB fedora-root LV, and installing all add-ons on the DVD, there's only 1.9GiB installed. After installing Xfce and a bunch of developer tools, I still have 12+GiB free. So I think free space is not a problem for installation and updates.
Where it gets thorny is when the sysadmin copies VMs or a database of any decent size onto the server. They might get a surprise if they're not checking free space in advance somewhere. But in Cockpit, resize for root is discoverable, it works, and it's done live. The docker.service and docker-storage-setup.service aren't enabled by default. On the plus side, they can install Docker, never actually use it, and docker-storage-setup won't take 40% of the free space in the VG for the docker thin pool. On the minus side, they have to be aware they need to enable these two things and reboot (or start them) in order to get things going.
So yeah, getting the word out I think will help with expectations. But at this point I'm not seeing any big problems.
On Wed, 2016-03-23 at 16:14 -0600, Chris Murphy wrote:
Adam's Coconut robot says the updates image test passed. But I'm not sure which compose ISO is used to test this.
All the openQA tests show the ISO that was used for testing. e.g.:
https://openqa.fedoraproject.org/tests/10651
shows a remote updates.img test passing for today's nightly (click on the 'Settings' tab and you can see the kernel param and ISO URL).
https://openqa.fedoraproject.org/tests/10575
is the same for Alpha-1.7 (though you do have to know that Fedora-24- 20160322.4 is the same thing as Alpha-1.7, in that case; openQA always runs on compose IDs, even for labelled 'candidate' / 'production' composes).
On Wed, 2016-03-23 at 21:40 -0700, Adam Williamson wrote:
On Wed, 2016-03-23 at 16:14 -0600, Chris Murphy wrote:
Adam's Coconut robot says the updates image test passed. But I'm not sure which compose ISO is used to test this.
All the openQA tests show the ISO that was used for testing. e.g.:
https://openqa.fedoraproject.org/tests/10651
shows a remote updates.img test passing for today's nightly (click on the 'Settings' tab and you can see the kernel param and ISO URL).
https://openqa.fedoraproject.org/tests/10575
is the same for Alpha-1.7 (though you do have to know that Fedora-24- 20160322.4 is the same thing as Alpha-1.7, in that case; openQA always runs on compose IDs, even for labelled 'candidate' / 'production' composes).
As for the wiki - we *could* provide an openQA job link for every coconut report as a comment, but I think it might make the page a bit messy.
On Thu, Dec 12, 2024 at 4:08 PM Roke Beedell via server < server@lists.fedoraproject.org> wrote:
Stephen Gallagher wrote:
Fedora Server will have:
- / (root) will be a minimum of 2 GiB and a maximum of 15 GiB
Do you recall what it was previously?
The previous behavior had been shared with the Fedora desktop installations, and if I remember correctly it was "Minimum 2GiB, used all available space".
That said, I'm curious why this is worth asking about more than eight years later.
server@lists.fedoraproject.org