/boot too small
Hello, During an update, I get Error Summary - Disk Requirements: At least 7MB more space needed on the /boot filesystem. How can I fix it without currently resizing /boot? Thank drwx--. 5 root root 4096 May 14 08:36 grub2 lrwxrwxrwx. 1 root root45 Mar 7 13:24 symvers-6.7.7-100.fc38.x86_64.xz -> /lib /modules/6.7.7-100.fc38.x86_64/symvers.xz -rw---. 1 root root 81850041 Mar 7 13:24 initramfs-6.7.7-100.fc38.x86_64.img -rw-r--r--. 1 root root269378 Mar 1 01:00 config-6.7.7-100.fc38.x86_64 -rw-r--r--. 1 root root 8851783 Mar 1 01:00 System.map-6.7.7-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14794568 Mar 1 01:00 vmlinuz-6.7.7-100.fc38.x86_64 lrwxrwxrwx. 1 root root45 Feb 13 17:38 symvers-6.7.4-100.fc38.x86_64.xz -> /lib /modules/6.7.4-100.fc38.x86_64/symvers.xz -rw---. 1 root root 81905180 Feb 13 17:37 initramfs-6.7.4-100.fc38.x86_64.img -rw-r--r--. 1 root root269327 Feb 5 01:00 config-6.7.4-100.fc38.x86_64 -rw-r--r--. 1 root root 8850577 Feb 5 01:00 System.map-6.7.4-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14806856 Feb 5 01:00 vmlinuz-6.7.4-100.fc38.x86_64 lrwxrwxrwx. 1 root root46 Jan 25 13:39 symvers-6.6.13-100.fc38.x86_64.xz -> /li b/modules/6.6.13-100.fc38.x86_64/symvers.xz -rw---. 1 root root 42503616 Jan 25 13:39 initramfs-6.6.13-100.fc38.x86_64.img -rw-r--r--. 1 root root266375 Jan 20 01:00 config-6.6.13-100.fc38.x86_64 -rw---. 1 root root 8786049 Jan 20 01:00 System.map-6.6.13-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14676712 Jan 20 01:00 vmlinuz-6.6.13-100.fc38.x86_64 -rw-r--r--. 1 root root147744 Jan 7 01:00 memtest86+x64.bin drwx--. 4 root root 4096 Jun 20 2023 efi drwxr-xr-x. 2 root root 4096 Jun 20 2023 extlinux -rw---. 1 root root 103940590 Jul 21 2022 initramfs-0-rescue-c60d54440c4d444a9eb5a084a65edf40.img -rwxr-xr-x. 1 root root 11802352 Jul 21 2022 vmlinuz-0-rescue-c60d54440c4d444a9eb5a084a65edf40 drwxr-xr-x. 3 root root 4096 Jul 21 2022 loader drwx--. 2 root root 16384 Jul 21 2022 lost+found === Patrick DUPRÉ | | email: pdu...@gmx.com === -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot too small
Hi, for an immediate workaround, remove the oldest kernel. Here are the steps together with an example output: 1) List installed kernel-core packages: # rpm -qa | grep kernel-core | sort kernel-core-6.8.4-200.fc39.x86_64 kernel-core-6.8.6-200.fc39.x86_64 kernel-core-6.8.7-200.fc39.x86_64 2) Remove the oldest one # dnf remove Dependencies resolved. PackageArch Version Repository Size Removing: kernel-corex86_64 6.8.4-200.fc39@updates66 M Removing dependent packages: kernel x86_64 6.8.4-200.fc39@updates 0 kernel-modules x86_64 6.8.4-200.fc39@updates58 M kernel-modules-corex86_64 6.8.4-200.fc39@updates32 M kernel-modules-extra x86_64 6.8.4-200.fc39@updates 2.4 M Transaction Summary Remove 5 Packages Freed space: 159 M 3) profit you have extra ~160 MB now. System update should have enough space to install the new kernel now. 4) Once finished, I'd recommend you to try to enlarge your /boot/ partition a bit (e.g. 100 - 500 MB ?) to avoid this problem permanently. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Tue, May 14, 2024 at 9:44 AM Patrick Dupre via users wrote: > > Hello, > > During an update, I get > > Error Summary > - > Disk Requirements: >At least 7MB more space needed on the /boot filesystem. > > > How can I fix it without currently resizing /boot? > Thank > > drwx--. 5 root root 4096 May 14 08:36 grub2 > lrwxrwxrwx. 1 root root45 Mar 7 13:24 > symvers-6.7.7-100.fc38.x86_64.xz -> /lib > /modules/6.7.7-100.fc38.x86_64/symvers.xz > -rw---. 1 root root 81850041 Mar 7 13:24 > initramfs-6.7.7-100.fc38.x86_64.img > -rw-r--r--. 1 root root269378 Mar 1 01:00 config-6.7.7-100.fc38.x86_64 > -rw-r--r--. 1 root root 8851783 Mar 1 01:00 > System.map-6.7.7-100.fc38.x86_64 > -rwxr-xr-x. 1 root root 14794568 Mar 1 01:00 vmlinuz-6.7.7-100.fc38.x86_64 > lrwxrwxrwx. 1 root root45 Feb 13 17:38 > symvers-6.7.4-100.fc38.x86_64.xz -> /lib > /modules/6.7.4-100.fc38.x86_64/symvers.xz > -rw---. 1 root root 81905180 Feb 13 17:37 > initramfs-6.7.4-100.fc38.x86_64.img > -rw-r--r--. 1 root root269327 Feb 5 01:00 config-6.7.4-100.fc38.x86_64 > -rw-r--r--. 1 root root 8850577 Feb 5 01:00 > System.map-6.7.4-100.fc38.x86_64 > -rwxr-xr-x. 1 root root 14806856 Feb 5 01:00 vmlinuz-6.7.4-100.fc38.x86_64 > lrwxrwxrwx. 1 root root46 Jan 25 13:39 > symvers-6.6.13-100.fc38.x86_64.xz -> /li > b/modules/6.6.13-100.fc38.x86_64/symvers.xz > -rw---. 1 root root 42503616 Jan 25 13:39 > initramfs-6.6.13-100.fc38.x86_64.img > -rw-r--r--. 1 root root266375 Jan 20 01:00 config-6.6.13-100.fc38.x86_64 > -rw---. 1 root root 8786049 Jan 20 01:00 > System.map-6.6.13-100.fc38.x86_64 > -rwxr-xr-x. 1 root root 14676712 Jan 20 01:00 vmlinuz-6.6.13-100.fc38.x86_64 > -rw-r--r--. 1 root root147744 Jan 7 01:00 memtest86+x64.bin > drwx--. 4 root root 4096 Jun 20 2023 efi > drwxr-xr-x. 2 root root 4096 Jun 20 2023 extlinux > -rw---. 1 root root 103940590 Jul 21 2022 > initramfs-0-rescue-c60d54440c4d444a9eb5a084a65edf40.img > -rwxr-xr-x. 1 root root 11802352 Jul 21 2022 > vmlinuz-0-rescue-c60d54440c4d444a9eb5a084a65edf40 > > drwxr-xr-x. 3 root root 4096 Jul 21 2022 loader > drwx--. 2 root root 16384 Jul 21 2022 lost+found > > > === > Patrick DUPRÉ | | email: pdu...@gmx.com > === > -- > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot too small
On 14/05/2024 08:54, Michal Schorm wrote: Hi, for an immediate workaround, remove the oldest kernel. Here are the steps together with an example output: 1) List installed kernel-core packages: # rpm -qa | grep kernel-core | sort kernel-core-6.8.4-200.fc39.x86_64 kernel-core-6.8.6-200.fc39.x86_64 kernel-core-6.8.7-200.fc39.x86_64 2) Remove the oldest one # dnf remove Dependencies resolved. PackageArch Version Repository Size Removing: kernel-corex86_64 6.8.4-200.fc39@updates66 M Removing dependent packages: kernel x86_64 6.8.4-200.fc39@updates 0 kernel-modules x86_64 6.8.4-200.fc39@updates58 M kernel-modules-corex86_64 6.8.4-200.fc39@updates32 M kernel-modules-extra x86_64 6.8.4-200.fc39@updates 2.4 M Transaction Summary Remove 5 Packages Freed space: 159 M 3) profit you have extra ~160 MB now. System update should have enough space to install the new kernel now. 4) Once finished, I'd recommend you to try to enlarge your /boot/ partition a bit (e.g. 100 - 500 MB ?) to avoid this problem permanently. Michal Schorm Software Engineer Core Services - Databases Team Red Hat I had the same problem a few days ago and did the same. I posted this reply but HyperKitty doesn't find it. So.. But I installed f40 a few days ago, and today "dnf upgrade" installed kernel-6.8.8 but *not* vmlinuz-6.8.8, so booting failed. My /boot partition is 450 GB, and I now have two bootable f40 kernels and a recent rescue kernel. There's no room for another. You probably don't have a "recovery" option. I now have "installonly_limit=2" in /etc/dnf/dnf.conf, but a new "dnf upgrade" after that said there was "nothing to do". What did work was ( while running 6.8.7): sudo dnf remove kernel-core-6.8.8 sudo dnf upgrade and then when "systemctl list-jobs" was clear, "sudo systemctl reboot" I, too, would prefer to have a bigger /boot, but this info might help. John P -- On Tue, May 14, 2024 at 9:44 AM Patrick Dupre via users wrote: Hello, During an update, I get Error Summary - Disk Requirements: At least 7MB more space needed on the /boot filesystem. How can I fix it without currently resizing /boot? Thank drwx--. 5 root root 4096 May 14 08:36 grub2 lrwxrwxrwx. 1 root root45 Mar 7 13:24 symvers-6.7.7-100.fc38.x86_64.xz -> /lib /modules/6.7.7-100.fc38.x86_64/symvers.xz -rw---. 1 root root 81850041 Mar 7 13:24 initramfs-6.7.7-100.fc38.x86_64.img -rw-r--r--. 1 root root269378 Mar 1 01:00 config-6.7.7-100.fc38.x86_64 -rw-r--r--. 1 root root 8851783 Mar 1 01:00 System.map-6.7.7-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14794568 Mar 1 01:00 vmlinuz-6.7.7-100.fc38.x86_64 lrwxrwxrwx. 1 root root45 Feb 13 17:38 symvers-6.7.4-100.fc38.x86_64.xz -> /lib /modules/6.7.4-100.fc38.x86_64/symvers.xz -rw---. 1 root root 81905180 Feb 13 17:37 initramfs-6.7.4-100.fc38.x86_64.img -rw-r--r--. 1 root root269327 Feb 5 01:00 config-6.7.4-100.fc38.x86_64 -rw-r--r--. 1 root root 8850577 Feb 5 01:00 System.map-6.7.4-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14806856 Feb 5 01:00 vmlinuz-6.7.4-100.fc38.x86_64 lrwxrwxrwx. 1 root root46 Jan 25 13:39 symvers-6.6.13-100.fc38.x86_64.xz -> /li b/modules/6.6.13-100.fc38.x86_64/symvers.xz -rw---. 1 root root 42503616 Jan 25 13:39 initramfs-6.6.13-100.fc38.x86_64.img -rw-r--r--. 1 root root266375 Jan 20 01:00 config-6.6.13-100.fc38.x86_64 -rw---. 1 root root 8786049 Jan 20 01:00 System.map-6.6.13-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14676712 Jan 20 01:00 vmlinuz-6.6.13-100.fc38.x86_64 -rw-r--r--. 1 root root147744 Jan 7 01:00 memtest86+x64.bin drwx--. 4 root root 4096 Jun 20 2023 efi drwxr-xr-x. 2 root root 4096 Jun 20 2023 extlinux -rw---. 1 root root 103940590 Jul 21 2022 initramfs-0-rescue-c60d54440c4d444a9eb5a084a65edf40.img -rwxr-xr-x. 1 root root 11802352 Jul 21 2022 vmlinuz-0-rescue-c60d54440c4d444a9eb5a084a65edf40 drwxr-xr-x. 3 root root 4096 Jul 21 2022 loader drwx--. 2 root root 16384 Jul 21 2022 lost+found === Patrick DUPRÉ | | email: pdu...@gmx.com === -- -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedo
Re: /boot too small
> On 14 May 2024, at 08:38, Patrick Dupre via users > wrote: > > How can I fix it without currently resizing /boot? How big is your /boot? What does this report? df -h /boot If its 1GB then that should be lots of space and its worth checking where the space has been used up. Have a look with ncdu or du to see what directories are taking up the space. There have been people that reported full /boot and found unexpected backup files in there. Barry -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot too small
df -h /boot Filesystem Size Used Avail Use% Mounted on /dev/sda6 488M 445M 6.5M 99% /boot Sent: Tuesday, May 14, 2024 at 10:02 AM From: "Barry Scott" To: "Community support for Fedora users" Cc: "Patrick Dupre" Subject: Re: /boot too small On 14 May 2024, at 08:38, Patrick Dupre via users wrote: How can I fix it without currently resizing /boot? How big is your /boot? What does this report? df -h /boot If its 1GB then that should be lots of space and its worth checking where the space has been used up. Have a look with ncdu or du to see what directories are taking up the space. There have been people that reported full /boot and found unexpected backup files in there. Barry -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot too small
On Tue, May 14, 2024 at 3:38 AM Patrick Dupre via users < users@lists.fedoraproject.org> wrote: > Hello, > > During an update, I get > > Error Summary > - > Disk Requirements: >At least 7MB more space needed on the /boot filesystem. > > > How can I fix it without currently resizing /boot? > Remove old kernels. Something like `dnf remove kernel-*6.6.13-100*` and `dnf remove kernel-*6.7.4-100*`. You could also delete the rescue kernel and regenerate it later. Something like `rm /boot/*rescue*`. > drwx--. 5 root root 4096 May 14 08:36 grub2 > lrwxrwxrwx. 1 root root45 Mar 7 13:24 > symvers-6.7.7-100.fc38.x86_64.xz -> /lib > /modules/6.7.7-100.fc38.x86_64/symvers.xz > -rw---. 1 root root 81850041 Mar 7 13:24 > initramfs-6.7.7-100.fc38.x86_64.img > -rw-r--r--. 1 root root269378 Mar 1 01:00 config-6.7.7-100.fc38.x86_64 > -rw-r--r--. 1 root root 8851783 Mar 1 01:00 > System.map-6.7.7-100.fc38.x86_64 > -rwxr-xr-x. 1 root root 14794568 Mar 1 01:00 > vmlinuz-6.7.7-100.fc38.x86_64 > lrwxrwxrwx. 1 root root45 Feb 13 17:38 > symvers-6.7.4-100.fc38.x86_64.xz -> /lib > /modules/6.7.4-100.fc38.x86_64/symvers.xz > -rw---. 1 root root 81905180 Feb 13 17:37 > initramfs-6.7.4-100.fc38.x86_64.img > -rw-r--r--. 1 root root269327 Feb 5 01:00 config-6.7.4-100.fc38.x86_64 > -rw-r--r--. 1 root root 8850577 Feb 5 01:00 > System.map-6.7.4-100.fc38.x86_64 > -rwxr-xr-x. 1 root root 14806856 Feb 5 01:00 > vmlinuz-6.7.4-100.fc38.x86_64 > lrwxrwxrwx. 1 root root46 Jan 25 13:39 > symvers-6.6.13-100.fc38.x86_64.xz -> /li > b/modules/6.6.13-100.fc38.x86_64/symvers.xz > -rw---. 1 root root 42503616 Jan 25 13:39 > initramfs-6.6.13-100.fc38.x86_64.img > -rw-r--r--. 1 root root266375 Jan 20 01:00 > config-6.6.13-100.fc38.x86_64 > -rw---. 1 root root 8786049 Jan 20 01:00 > System.map-6.6.13-100.fc38.x86_64 > -rwxr-xr-x. 1 root root 14676712 Jan 20 01:00 > vmlinuz-6.6.13-100.fc38.x86_64 > -rw-r--r--. 1 root root147744 Jan 7 01:00 memtest86+x64.bin > drwx--. 4 root root 4096 Jun 20 2023 efi > drwxr-xr-x. 2 root root 4096 Jun 20 2023 extlinux > -rw---. 1 root root 103940590 Jul 21 2022 > initramfs-0-rescue-c60d54440c4d444a9eb5a084a65edf40.img > -rwxr-xr-x. 1 root root 11802352 Jul 21 2022 > vmlinuz-0-rescue-c60d54440c4d444a9eb5a084a65edf40 > > drwxr-xr-x. 3 root root 4096 Jul 21 2022 loader > drwx--. 2 root root 16384 Jul 21 2022 lost+found > Jeff -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot too small
Note sure this with post to list with the Bold marked text, but sending it to your email as well. If list rejects it will repost without Rich Text, and Perhaps mark lines with (B) that were bold?? Good Luck. A couple of things I would recommend. Have an old Lenovo R61 notebook that also has a 500M boot so changed the installonly reduced by at least 1 from the default 3. First change /etc/dnf/dnf.conf to have installonly_limit=2 Then would remove the rescue kernel files since those are the largest and probable least useful. Probable just move them to another partition that has space. Pulled data from email and put in spreadsheet and changed size to ~MB and name. Would remove or move these files to another partition with space. That would leave the latest 2 kernels. 99 initramfs-0-rescue-c60d54440c4d444a9eb5a084a65edf4 78 initramfs-6.7.4-100.fc38.x86_64.img 78 initramfs-6.7.7-100.fc38.x86_64.img 40 initramfs-6.6.13-100.fc38.x86_64.img 14 vmlinuz-6.7.4-100.fc38.x86_64 14 vmlinuz-6.7.7-100.fc38.x86_64 13 vmlinuz-6.6.13-100.fc38.x86_64 11 vmlinuz-0-rescue-c60d54440c4d444a9eb5a084a65edf40 8 System.map-6.7.7-100.fc38.x86_64 8 System.map-6.7.4-100.fc38.x86_64 8 System.map-6.6.13-100.fc38.x86_64 0 config-6.7.7-100.fc38.x86_64 0 config-6.7.4-100.fc38.x86_64 0 config-6.6.13-100.fc38.x86_64 That should make lots of space. The recue kernel would probable be rebuilt on next kernel update or dnf reinstall kernel-core. Unless you have disabled that?? ++ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mi...@guam.net mailto:msetze...@gmail.com mailto:msetze...@gmx.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ ++ -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Can an vsFTP server get swamped?
Hi All,
I have a customer with four Windows workstations that
backup with Cobian Reflector to a local Fedora vsFTP server
vsftpd-3.0.5-6.fc40.x86_64
Every so often, Cobian errors out with:
ERR 2024-05-12 21:38:58 An error occurred while uploading the file
"C:\Users\accounting\AppData\Roaming\Mozilla\Firefox\Profiles\boteqaxu.default-1441211636453\storage\default\https+++shop.nordstrom.com\cache\morgue\44\{a7c30849-26e1-400f-9127-3cc779dc912c}.final"
to "/MyDocsBackup/backup1/Mozilla 2024-05-12 21;31;27
(Full)/Firefox/Profiles/boteqaxu.default-1441211636453/storage/default/https+++shop.nordstrom.com/cache/morgue/44":
Only one usage of each socket address (protocol/network address/port) is
normally permitted 192.168.202.10:10098
But if I re-run the task, it goes through without issue.
By chance if several of the workstations start backing
up at the same time, can the vsFTP server get swamped?
Is there a way to increase vsFTP's sockets?
P
Many thanks,
-T
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Can an vsFTP server get swamped?
On 14 May 2024 at 4:04, ToddAndMargo via users wrote:
Date sent: Tue, 14 May 2024 04:04:46 -0700
To: Community support for Fedora users
Subject:Can an vsFTP server get swamped?
Send reply to: Community support for Fedora users
From: ToddAndMargo via users
Copies to: ToddAndMargo
> Hi All,
>
> I have a customer with four Windows workstations that
> backup with Cobian Reflector to a local Fedora vsFTP server
>
> vsftpd-3.0.5-6.fc40.x86_64
>
> Every so often, Cobian errors out with:
>
> ERR 2024-05-12 21:38:58 An error occurred while uploading the file
> "C:\Users\accounting\AppData\Roaming\Mozilla\Firefox\Profiles\boteqaxu.default-1441211636453\storage\default\https+++shop.nordstrom.com\cache\morgue\44\{a7c30849-26e1-400f-9127-3cc779dc912c}.final"
>
> to "/MyDocsBackup/backup1/Mozilla 2024-05-12 21;31;27
> (Full)/Firefox/Profiles/boteqaxu.default-1441211636453/storage/default/https+++shop.nordstrom.com/cache/morgue/44":
>
> Only one usage of each socket address (protocol/network address/port) is
> normally permitted 192.168.202.10:10098
>
>
> But if I re-run the task, it goes through without issue.
>
> By chance if several of the workstations start backing
> up at the same time, can the vsFTP server get swamped?
>
> Is there a way to increase vsFTP's sockets?
> P
Note sure if you are talking about passive ports.
check your /etc/vsftpd/vsftpd.config normall at end.
I've set mine up with these settings?
pasv_enable=YES
pasv_min_port=11000
pasv_max_port=11010
Might also need to make sure that these ports are routed to the
machine if it is behind a router..
Just a thought.
> Many thanks,
> -T
> --
> ___
> users mailing list -- users@lists.fedoraproject.org
> To unsubscribe send an email to users-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
++
Michael D. Setzer II - Computer Science Instructor (Retired)
mailto:mi...@guam.net
mailto:msetze...@gmail.com
mailto:msetze...@gmx.com
Guam - Where America's Day Begins
G4L Disk Imaging Project maintainer
http://sourceforge.net/projects/g4l/
++
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: /boot too small
Back on 05/03/2024 I posted the question: "How to increase size of /boot partition" I had the same problem. As was noted by some, I had not upgraded for a long, long time: "This type of layout and partition sizes is ancient. /tmp isn't even a partition now." So, I decided to re-install. I pretty much used the installation default partitioning except that I made /boot 2GB (a little future proofing). This also allowed me to go from ext4 to btrfs (except /boot of course). Richard On 5/14/24 12:38 AM, Patrick Dupre via users wrote: Hello, During an update, I get Error Summary - Disk Requirements: At least 7MB more space needed on the /boot filesystem. How can I fix it without currently resizing /boot? Thank drwx--. 5 root root 4096 May 14 08:36 grub2 lrwxrwxrwx. 1 root root45 Mar 7 13:24 symvers-6.7.7-100.fc38.x86_64.xz -> /lib /modules/6.7.7-100.fc38.x86_64/symvers.xz -rw---. 1 root root 81850041 Mar 7 13:24 initramfs-6.7.7-100.fc38.x86_64.img -rw-r--r--. 1 root root269378 Mar 1 01:00 config-6.7.7-100.fc38.x86_64 -rw-r--r--. 1 root root 8851783 Mar 1 01:00 System.map-6.7.7-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14794568 Mar 1 01:00 vmlinuz-6.7.7-100.fc38.x86_64 lrwxrwxrwx. 1 root root45 Feb 13 17:38 symvers-6.7.4-100.fc38.x86_64.xz -> /lib /modules/6.7.4-100.fc38.x86_64/symvers.xz -rw---. 1 root root 81905180 Feb 13 17:37 initramfs-6.7.4-100.fc38.x86_64.img -rw-r--r--. 1 root root269327 Feb 5 01:00 config-6.7.4-100.fc38.x86_64 -rw-r--r--. 1 root root 8850577 Feb 5 01:00 System.map-6.7.4-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14806856 Feb 5 01:00 vmlinuz-6.7.4-100.fc38.x86_64 lrwxrwxrwx. 1 root root46 Jan 25 13:39 symvers-6.6.13-100.fc38.x86_64.xz -> /li b/modules/6.6.13-100.fc38.x86_64/symvers.xz -rw---. 1 root root 42503616 Jan 25 13:39 initramfs-6.6.13-100.fc38.x86_64.img -rw-r--r--. 1 root root266375 Jan 20 01:00 config-6.6.13-100.fc38.x86_64 -rw---. 1 root root 8786049 Jan 20 01:00 System.map-6.6.13-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14676712 Jan 20 01:00 vmlinuz-6.6.13-100.fc38.x86_64 -rw-r--r--. 1 root root147744 Jan 7 01:00 memtest86+x64.bin drwx--. 4 root root 4096 Jun 20 2023 efi drwxr-xr-x. 2 root root 4096 Jun 20 2023 extlinux -rw---. 1 root root 103940590 Jul 21 2022 initramfs-0-rescue-c60d54440c4d444a9eb5a084a65edf40.img -rwxr-xr-x. 1 root root 11802352 Jul 21 2022 vmlinuz-0-rescue-c60d54440c4d444a9eb5a084a65edf40 drwxr-xr-x. 3 root root 4096 Jul 21 2022 loader drwx--. 2 root root 16384 Jul 21 2022 lost+found === Patrick DUPRÉ | | email: pdu...@gmx.com === -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
qemu guest converted via v2v has no network
Hi; I have just installed Fedora 40 and all the kvm/qemu/libvirt bits I can run virt-manager and install a new guest and when I start the guest it comes up automatically with a valid network / ip address I also converted a fedora 38 vm that has a gui interface and it also works fine However, I have several ALMA 8 VMWare vm's and I am able to convert them like this: # virt-v2v -i vmx /data/vmware/Alma-HA-DR-Data3/Alma-HA-DR-Data3.vmx -o libvirt -of qcow2 -os default -n default where the original VMware folder is at /data/vmware/Alma-HA-DR-Data3 It converts and I can start the guest but it has no network, I see the standard network device but it has no ip address, trying to bring it up with the following command has no effect: # ifconfig enp1s0 up The guest NIC details (in the guest details ) show this: Network source: Virtual network 'default' :NAT Device model: virtio Mac address: 00:0c:29:4f:14:c3 IP Address: Unknown Link State: active The guest NIC details xml tab shows this: portid="35431ccd-cdd2-4cde-b2ec-8310b912e188" bridge="virbr0"/> function="0x0"/> Thanks in advance for any advice -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot too small
On Tue, 2024-05-14 at 08:27 -0700, richard emberson wrote: > Back on 05/03/2024 I posted the question: > "How to increase size of /boot partition" > I had the same problem. > > As was noted by some, I had not upgraded for a long, long time: > "This type of layout and partition sizes is ancient. /tmp isn't even a > partition now." Does /boot still need to be its own partition, these days? /boot/efi has to be, but that's mapped into /boot, already. -- NB: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the list. The following system info data is generated fresh for each post: uname -rsvp Linux 6.2.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 16:51:53 UTC 2023 x86_64 -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: qemu guest converted via v2v has no network
On 5/14/24 10:48 AM, Sbob wrote: However, I have several ALMA 8 VMWare vm's and I am able to convert them like this: # virt-v2v -i vmx /data/vmware/Alma-HA-DR-Data3/Alma-HA-DR-Data3.vmx -o libvirt -of qcow2 -os default -n default where the original VMware folder is at /data/vmware/Alma-HA-DR-Data3 It converts and I can start the guest but it has no network, I see the standard network device but it has no ip address, trying to bring it up with the following command has no effect: # ifconfig enp1s0 up What do the logs show? The guest NIC details xml tab shows this: portid="35431ccd-cdd2-4cde-b2ec-8310b912e188" bridge="virbr0"/> function="0x0"/> That looks ok. Does the guest support virtio networking? -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: qemu guest converted via v2v has no network
Where do I find the logs? On 5/14/24 2:46 PM, Samuel Sieb wrote: On 5/14/24 10:48 AM, Sbob wrote: However, I have several ALMA 8 VMWare vm's and I am able to convert them like this: # virt-v2v -i vmx /data/vmware/Alma-HA-DR-Data3/Alma-HA-DR-Data3.vmx -o libvirt -of qcow2 -os default -n default where the original VMware folder is at /data/vmware/Alma-HA-DR-Data3 It converts and I can start the guest but it has no network, I see the standard network device but it has no ip address, trying to bring it up with the following command has no effect: # ifconfig enp1s0 up What do the logs show? The guest NIC details xml tab shows this: portid="35431ccd-cdd2-4cde-b2ec-8310b912e188" bridge="virbr0"/> function="0x0"/> That looks ok. Does the guest support virtio networking? -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot too small
On Tue, May 14, 2024 at 8:13 PM Tim via users wrote: > Does /boot still need to be its own partition, these days? > /boot/efi has to be, but that's mapped into /boot, already. Definitely not. And it actually creates all kinds of problems when separated. The best *trivial* setup and usage should be having everything on BTRFS (except EFI, as you said), and maintain some amount of snapshots you can revert to anytime in case of any issues. When /boot is on the BTRFS, the snapshot contains the whole system, and ensures bootability of the snapshots. When /boot is on a standalone partition, the snapshot contains kernel modules, but not the actual kernel. When booting a new kernel (from /boot) with old kernel modules (from the snapshot), the modules can't be loaded, leaving you with a kind of crippled system. (bootable, but only partly usable) Which is far from what people would usually expect. -- A better, but more complicated setup consists of various snapshots of various subvolumes which are mounted to various locations. (e.g. standalone subvolumes for /home, games, backups, ... whatever) Often managed by some software (snapper, timeshit, ... not sure about the specific names), rather than the btrfs commands themselves. -- I managed to craft a setup that changes which snapshot (or which OS) will boot by changing just a single symlink. That too would be (likely ?) impossible with /boot on a separate partition. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Tue, May 14, 2024 at 8:13 PM Tim via users wrote: > > On Tue, 2024-05-14 at 08:27 -0700, richard emberson wrote: > > Back on 05/03/2024 I posted the question: > >"How to increase size of /boot partition" > > I had the same problem. > > > > As was noted by some, I had not upgraded for a long, long time: > >"This type of layout and partition sizes is ancient. /tmp isn't even a > > partition now." > > Does /boot still need to be its own partition, these days? > > /boot/efi has to be, but that's mapped into /boot, already. > > > -- > > NB: All unexpected mail to my mailbox is automatically deleted. > I will only get to see the messages that are posted to the list. > > The following system info data is generated fresh for each post: > > uname -rsvp > Linux 6.2.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 16:51:53 > UTC 2023 x86_64 > -- > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot too small
Poking about I see that the default workstation disk layout: https://docs.fedoraproject.org/en-US/workstation-docs/disk-config/ has /boot on a ext4 partition and everything else on btrfs. Also, the replacement for Anaconda will not happen until Fedora 41: https://forums.fedoraforum.org/showthread.php?332111-Fedora-40-will-remain-with-existing-anaconda So, are you saying that with Fedora 41, it will be the default for the /boot partition to use btrfs? Or, is this something that works for you? Thanks. Richard On 5/14/24 3:38 PM, Michal Schorm wrote: On Tue, May 14, 2024 at 8:13 PM Tim via users wrote: Does /boot still need to be its own partition, these days? /boot/efi has to be, but that's mapped into /boot, already. Definitely not. And it actually creates all kinds of problems when separated. The best *trivial* setup and usage should be having everything on BTRFS (except EFI, as you said), and maintain some amount of snapshots you can revert to anytime in case of any issues. When /boot is on the BTRFS, the snapshot contains the whole system, and ensures bootability of the snapshots. When /boot is on a standalone partition, the snapshot contains kernel modules, but not the actual kernel. When booting a new kernel (from /boot) with old kernel modules (from the snapshot), the modules can't be loaded, leaving you with a kind of crippled system. (bootable, but only partly usable) Which is far from what people would usually expect. -- A better, but more complicated setup consists of various snapshots of various subvolumes which are mounted to various locations. (e.g. standalone subvolumes for /home, games, backups, ... whatever) Often managed by some software (snapper, timeshit, ... not sure about the specific names), rather than the btrfs commands themselves. -- I managed to craft a setup that changes which snapshot (or which OS) will boot by changing just a single symlink. That too would be (likely ?) impossible with /boot on a separate partition. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Tue, May 14, 2024 at 8:13 PM Tim via users wrote: On Tue, 2024-05-14 at 08:27 -0700, richard emberson wrote: Back on 05/03/2024 I posted the question: "How to increase size of /boot partition" I had the same problem. As was noted by some, I had not upgraded for a long, long time: "This type of layout and partition sizes is ancient. /tmp isn't even a partition now." Does /boot still need to be its own partition, these days? /boot/efi has to be, but that's mapped into /boot, already. -- NB: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the list. The following system info data is generated fresh for each post: uname -rsvp Linux 6.2.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 16:51:53 UTC 2023 x86_64 -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot too small
Michal Schorm wrote: >The best *trivial* setup and usage should be having everything on >BTRFS (except EFI, as you said), >and maintain some amount of snapshots you can revert to anytime in >case of any issues. I look forward to a complete set of instructions for this approach in the Fedora documentation web site. I'm sure many of us will want to adopt this approach. -- Dave Close, Compata, Irvine CA "'Always' and 'never' are two d...@compata.com, +1 714 434 7359words you should always remember dhcl...@alumni.caltech.edu never to use." --Wendell Johnson -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot too small
Once upon a time, Michal Schorm said: > On Tue, May 14, 2024 at 8:13 PM Tim via users > wrote: > > Does /boot still need to be its own partition, these days? > > /boot/efi has to be, but that's mapped into /boot, already. > > Definitely not. It does for a variety of cases, such as an encrypted root filesystem. -- Chris Adams -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: qemu guest converted via v2v has no network
On 5/14/24 3:06 PM, Sbob wrote: Where do I find the logs? The logs from the Linux system that you ran the "ifconfig" on. -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: 2 sets of backups with Backups?
You might also take a look at Back In Time (https://backintime.readthedocs.io/) ~~R Defenestrated since 1990 On 5/7/24 22:11, Frederic Muller wrote: On 30/04/2024 16:54, Patrick O'Callaghan wrote: On Tue, 2024-04-30 at 16:44 +0700, Frederic Muller wrote: Hi! I currently do weekly backups with Backups and Duplicity> I was thinking to add another batch job of daily backup, faster, for specific files and folders that are updated daily. Unfortunately Backups doesn't seem to give the options for 2 batches, or selecting single files. How would you do about that then? I have a NAS to which I plan to copy those files. I use Borgmatic, which runs nightly and has a config file for what I want to backup and how long to keep it. It's also deduplicating and optionally encrypts. poc Thank you very much. I was not aware of this application and will look into it. Fred -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot too small
On Wed, May 15, 2024 at 1:29 AM richard emberson wrote: > Poking about I see that the default workstation disk layout: >https://docs.fedoraproject.org/en-US/workstation-docs/disk-config/ > has /boot on a ext4 partition and everything else on btrfs. > Also, the replacement for Anaconda will not happen until Fedora 41: > > https://forums.fedoraforum.org/showthread.php?332111-Fedora-40-will-remain-with-existing-anaconda > > So, are you saying that with Fedora 41, it will be the default for the /boot > partition to use btrfs? > Or, is this something that works for you? It is something that works for me. Back when I started poking around BTRFS, going from person to person, asking tons of questions of what would or would not be possible, which resulted in un-clogging the pipes that blocked widespread BTRFS adoption in Fedora, the full system on BTRFS layout was what I was suggesting. I'm so glad people were willing to adopt BTRFS (both Fedora developers allowing that and actually making that happen; and the users alike), but I feel like the job is half-done. The biggest obstacle of any change to the default FS layouts is - in my opinion - GRUB. The GRUB configuration can be so clean, brief and nice, even for very complicated setups - when you tailor it exactly to your needs. However making auto-generated configurations that would work for everyone, covering most possible configurations is an entirely different thing - which GRUB doesn't handle well IMO. Sorrows of dual booting and similar themes are common on discussion.fedoraproject.org. Even though I see the BTRFS adoption in Fedora as quite a success. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, May 15, 2024 at 1:29 AM richard emberson wrote: > > Poking about I see that the default workstation disk layout: >https://docs.fedoraproject.org/en-US/workstation-docs/disk-config/ > has /boot on a ext4 partition and everything else on btrfs. > Also, the replacement for Anaconda will not happen until Fedora 41: > > https://forums.fedoraforum.org/showthread.php?332111-Fedora-40-will-remain-with-existing-anaconda > > So, are you saying that with Fedora 41, it will be the default for the /boot > partition to use btrfs? > Or, is this something that works for you? > > Thanks. > Richard > On 5/14/24 3:38 PM, Michal Schorm wrote: > > On Tue, May 14, 2024 at 8:13 PM Tim via users > > wrote: > >> Does /boot still need to be its own partition, these days? > >> /boot/efi has to be, but that's mapped into /boot, already. > > > > Definitely not. > > And it actually creates all kinds of problems when separated. > > > > The best *trivial* setup and usage should be having everything on > > BTRFS (except EFI, as you said), > > and maintain some amount of snapshots you can revert to anytime in > > case of any issues. > > > > When /boot is on the BTRFS, the snapshot contains the whole system, > > and ensures bootability of the snapshots. > > > > When /boot is on a standalone partition, the snapshot contains kernel > > modules, but not the actual kernel. > > When booting a new kernel (from /boot) with old kernel modules (from > > the snapshot), the modules can't be loaded, leaving you with a kind of > > crippled system. (bootable, but only partly usable) > > Which is far from what people would usually expect. > > > > -- > > > > A better, but more complicated setup consists of various snapshots of > > various subvolumes which are mounted to various locations. (e.g. > > standalone subvolumes for /home, games, backups, ... whatever) > > Often managed by some software (snapper, timeshit, ... not sure about > > the specific names), rather than the btrfs commands themselves. > > > > -- > > > > I managed to craft a setup that changes which snapshot (or which OS) > > will boot by changing just a single symlink. > > That too would be (likely ?) impossible with /boot on a separate partition. > > > > -- > > > > Michal Schorm > > Software Engineer > > Core Services - Databases Team > > Red Hat > > > > -- > > > > On Tue, May 14, 2024 at 8:13 PM Tim via users > > wrote: > >> > >> On Tue, 2024-05-14 at 08:27 -0700, richard emberson wrote: > >>> Back on 05/03/2024 I posted the question: > >>> "How to increase size of /boot partition" > >>> I had the same problem. > >>> > >>> As was noted by some, I had not upgraded for a long, long time: > >>> "This type of layout and partition sizes is ancient. /tmp isn't even > >>> a partition now." > >> > >> Does /boot still need to be its own partition, these days? > >> > >> /boot/efi has to be, but that's mapped into /boot, already. > >> > >> > >> -- > >> > >> NB: All unexpected mail to my mailbox is automatically deleted. > >> I will only get to see the messages that are posted to the list. > >> > >> The following system info data is generated fresh for each post: > >> > >> uname -rsvp > >> Linux 6.2.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 16:51:53 > >> UTC 2023 x86_64 >
Re: /boot too small
On Wed, May 15, 2024 at 1:45 AM Chris Adams wrote: > Once upon a time, Michal Schorm said: > > On Tue, May 14, 2024 at 8:13 PM Tim via users > > wrote: > > > Does /boot still need to be its own partition, these days? > > > /boot/efi has to be, but that's mapped into /boot, already. > > > > Definitely not. > > It does for a variety of cases, such as an encrypted root filesystem. I do have full disk encryption /boot included. Or do you want your kernels to be tampered with by anyone that gets hands onto your computer? It is a bit more complex, but not that much. The main trick was to automatically bake an extra decryption key into the kernel every time it's installed, so you don't need to put it in twice. (Once for GRUB to find the kernel, second time for kernel to be able to touch the FS) -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, May 15, 2024 at 1:45 AM Chris Adams wrote: > > Once upon a time, Michal Schorm said: > > On Tue, May 14, 2024 at 8:13 PM Tim via users > > wrote: > > > Does /boot still need to be its own partition, these days? > > > /boot/efi has to be, but that's mapped into /boot, already. > > > > Definitely not. > > It does for a variety of cases, such as an encrypted root filesystem. > > -- > Chris Adams > -- > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
