Created attachment 675278 [details] yum error showing 'no space left on device' Description of problem: Currently, installing from DVD the "Development and Creativity Workstation (AND Also select ALL Ad-dons)" anaconda apparently gets out of space for yet unknown reasons (since logs show that all packages were installed). Version-Release number of selected component (if applicable): RC2 (18.37.11) How reproducible: currently unclear, seems memory related (1gb) Steps to Reproduce: 0. Boot anaconda without any kernel parameter 1. Enter SOFTWARE SELECTION (using CDROM as INSTALLATION SOURCE) 2. Select: Development and Creativity Workstation (AND Also select ALL Ad-dons) 3. Enter STORAGE: INSTALLATION DESTINATION and select one disk (mine is 9.2gb) 4. Do MANUAL PARTITIONING setting the 'scheme' to BTRFS 5. Partition it with: /, /boot as BTRFS subvol 8.98gb and swap of 256mb. 6. Once Anaconda accepts the storage configuration, 'begin installation' 7. Anaconda starts installing, set a root password and wait. 8. Black Screen Actual results: Black Screen Expected results: Success or an Error (and the rejection of the storage configuration, if it is invalid) Additional info: It is the first time i tried to install this package combination, it is unclear if it is memory or storage space related (or both). For example, with 786mb and similar disk layout "Cannot allocate memory" was found in the tmpPy** file. I am testing again with higher ram and disk to at least check that i can install it on any guest and then separate ram issue from space issue (if there are actually any). From the affected system: $ cat df-h.out Filesystem Size Used Avail Use% Mounted on rootfs 1008M 715M 293M 71% / devtmpfs 483M 0 483M 0% /dev tmpfs 498M 0 498M 0% /dev/shm tmpfs 498M 6.2M 492M 2% /run tmpfs 498M 0 498M 0% /sys/fs/cgroup /dev/sr0 4.3G 4.3G 0 100% /run/install/repo /dev/mapper/live-rw 1008M 715M 293M 71% / tmpfs 498M 130M 369M 26% /tmp /dev/sda1 8.9G 7.8G 859M 91% /mnt/sysimage /dev/sda1 8.9G 7.8G 859M 91% /mnt/sysimage/boot devtmpfs 483M 0 483M 0% /mnt/sysimage/dev /dev/tmpfs 498M 0 498M 0% /mnt/sysimage/dev/shm /dev/tmpfs 498M 0 498M 0% /dev/shm
Created attachment 675279 [details] packaging.log
Created attachment 675280 [details] anaconda.log
Created attachment 675281 [details] program.log
Created attachment 675282 [details] storage.log
I did not see how much space do i need, i believe that anaconda does not tell me so i am dependent of anaconda accepting or rejecting the storage configuration. ~~~~~~~~~~~~~~~~~~~~~~~~~ * VERSION: RC2 (18.37.11) * GUEST RAM: 2048mb * GUEST DISK: 20gb * VM: ULQ-TST-1 0. Boot anaconda without any kernel parameter 1. Enter SOFTWARE SELECTION (using CDROM as INSTALLATION SOURCE) 2. Select: Development and Creativite Workstation (AND Also select ALL Addons) 3. Enter STORAGE: INSTALLATION DESTINATION and select one disk (mine is 20gb) 4. Do MANUAL PARTITIONING setting the 'scheme' to BTRFS 5. Partition it with: /, /boot as BTRFS subvol 19gb and swap of 1gb. 6. Once Anaconda accepts the storage configuration, 'begin installation' 7. Anaconda starts installing, set a root password and wait. 8. Anaconda completes the installation ok. This at least proves that there is nothing wrong with the packages itself. ~~~~~~~~~~~~~~~~~~~~~~~~~ So, it might be ram size or maybe the storage size. Maybe it is too close and anaconda fails to realize that / and /boot share the space?
Reartes, why don't you retry the same procedure as in #description (the same hardware configuration), just with increased RAM? That would be helpful to rule out memory issues. If you enlarge the RAM _and_ the disk, that doesn't help much.
Created attachment 675375 [details] error displayed inside anaconda I reproduced the problem with 10 GB disk and 1 GB RAM using "Development and Creativity Workstation (AND Also select ALL Ad-dons)". /tmp/tmp* contains: > Installing vte3-0.34.2-3.fc18.x86_64 (1827/2535) > error: Couldn't fork %post(vte3-0.34.2-3.fc18.x86_64): Cannot allocate memory > Installing cyrus-sasl-2.1.23-36.fc18.x86_64 (1828/2535) > error: Couldn't fork %pre(cyrus-sasl-2.1.23-36.fc18.x86_64): Cannot allocate memory Screenshot of anaconda error attached.
I increased the RAM to 1.5 GB and installation succeeded fine. So either you need more RAM or a bigger swap. It's a question how can anaconda present more helpful information than it currently does. It could definitely check RAM usage and/or look for "Cannot allocate memory" messages in the log and provide a helpful hint in the error message, something like ("You might have insufficient system memory, try increasing it or enlarging your swap partition"). But I don't think this is an F18 blocker.
Created attachment 675715 [details] screenshot of manual partitioning (2gb ram guest + 512mb swap) wich results in black screen * VERSION: RC2 (18.37.11) * GUEST RAM: 2048mb * GUEST DISK: 9.2gb * VM: BTRFS-1 0. Boot anaconda without any kernel parameter 1. Enter SOFTWARE SELECTION (using CDROM as INSTALLATION SOURCE) 2. Select: Development and Creativity Workstation (AND Also select ALL Ad-dons) 3. Enter STORAGE: INSTALLATION DESTINATION and select one disk (mine is 9.2gb) 4. Do MANUAL PARTITIONING setting the 'scheme' to BTRFS 5. Partition it with: /, /boot as BTRFS subvol 8.98gb and swap of 512mb. 6. Once Anaconda accepts the storage configuration, 'begin installation' 7. Anaconda starts installing, set a root password and wait. 8. Anaconda ends in a black screen, no error in /tmp.
Created attachment 675716 [details] screenshot of the 'pane is dead' vt1
Created attachment 675717 [details] anaconda.log
Created attachment 675718 [details] program.log
Created attachment 675719 [details] storage.log
Created attachment 675720 [details] tmp* package file
Created attachment 675721 [details] syslog file
Created attachment 675723 [details] X.org log file
Maybe OFF-TOPIC but please check comment #14 for: Installing tomcat-servlet-3.0-api-7.0.32-1.fc18.noarch (85/2535) /var/tmp/rpm-tmp.eM7usa: line 1: /usr/sbin/update-alternatives: No such file or directory warning: %post(tomcat-servlet-3.0-api-0:7.0.32-1.fc18.noarch) scriptlet failed, exit status 127
Also: Installing 1:texlive-base-2012-8.20121115_r28267.fc18.noarch (434/2535) /var/tmp/rpm-tmp.N2x9Hg: line 1: rm: command not found /var/tmp/rpm-tmp.N2x9Hg: line 2: rm: command not found
$ cat btrfs-filesystem-df-mnt-sysimage-boot.out Data: total=7.37GB, used=6.35GB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=705.31MB, used=544.74MB Metadata: total=8.00MB, used=0.00 $ cat btrfs-filesystem-df-mnt-sysimage.out Data: total=7.37GB, used=6.35GB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=705.31MB, used=544.74MB Metadata: total=8.00MB, used=0.00 $ cat btrfs-filesystem-show-sda2.out Label: 'fedora' uuid: a68a0ea6-8e9c-4063-9105-1e27fc64f657 Total devices 1 FS bytes used 6.88GB devid 1 size 8.78GB used 8.78GB path /dev/sda2 Btrfs Btrfs v0.19 > Total devices 1 FS bytes used 6.88GB I will try one more time with more ram and the same disk layout.
-1 blocker, this has always been the case really. We have a hard floor on memory amount, and in some releases it's more accurate than others, but it's always been the case you can wind up with an install scenario that needs more than the coded minimum RAM, and if you don't have enough, it'll run but fail in some messy way. It's very hard to 'fix', I believe.
Discussed at the 2013-01-09 Fedora 18 go/no-go meeting [1]. While this is an unfortunate failure mode, this has been true of previous releases and is very difficult to fix. Since this is not a regression, it was decided to reject this bug as a blocker for F18 final. [1] http://meetbot.fedoraproject.org/fedora-meeting-2/2013-01-09/f18_final_gono-go_meeting.2013-01-09-19.00.txt
I returned and the new try also ended in a black screen. (vt1 shows the pane is dead) * VERSION: RC2 (18.37.11) * GUEST RAM: 12288mb (Yes, 12gb ram) * GUEST DISK: 9.2gb * VM: BTRFS-1 0. Boot anaconda without any kernel parameter 1. Enter SOFTWARE SELECTION (using CDROM as INSTALLATION SOURCE) 2. Select: Development and Creativite Workstation (AND Also select ALL Addons) 3. Enter STORAGE: INSTALLATION DESTINATION and select one disk (mine is 9.2gb) 4. Do MANUAL PARTITIONING setting the 'scheme' to BTRFS 5. Partition it with: /, /boot as BTRFS subvol 8.98gb and swap of 512mb. 6. Once Anaconda accepts the storage configuration, 'begin installation' 7. Anaconda starts installing, set a root password and wait. $ cat tmpXWxGZs usage: plymouth [ --verbose | -v ] { --targetdir | -t } <initrd_directory> So, it also fails with 12gb of ram (but the same disk layout...)
Created attachment 676087 [details] anaconda.log (12gb)
Created attachment 676088 [details] program.log (12gb)
Created attachment 676089 [details] storage.log (12gb)
Created attachment 676090 [details] syslog file (12gb)
Created attachment 676092 [details] packaging.log (12gb)
Created attachment 676093 [details] X.org log file (12gb)
Reartes, I think it's pretty clear there are two issues: a) insufficient RAM prints unhelpful message during package installation - comment 7 and comment 8. My HDD was a bit larger than yours, that might explain why the installation succeeded for me. b) small HDD results in a black screen - from unknown reason the installation completes, but then you see only a black screen. You haven't mentioned whether you can successfully boot the system if you hard-reset it. Because you have provided lots of logs here, let's keep this bug report related to issue b). I reported issue a) separately - bug 893987.
@Kamil Páral Ok, i fully agree with comment #29. ~~~~~~~~~~~~~~~~~~ I performed these additional tests: CONTROL#1: 10240mb (/ and /boot subvolumes) BTRFS partition CONTROL#2: STANDARD PARTITIONS (8789mb /, 512mb /boot, 384 SWAP) CASE#1: 8900mb (/ and /boot subvolumes) BTRFS partition CASE#2: 9000mb (/ and /boot subvolumes) BTRFS partition CASE#3 9000mb (only /) BTRFS partition, STANDARD PARTITIONS (/boot 512mb, SWAP 384mb) In each test, the previous partitions were first deleted from within manual partitioning. I tried to avoid re-using the btrfs partition in each test. All test were done on this guest: * VERSION: RC4 (18.37.11) * GUEST RAM: 2048mb * GUEST DISK: 23gb * VM: BTRFS-1 I will put each test in its own comment.
Created attachment 677017 [details] screenshot of manual partitioning CONTROL #1: BTRFS (WORKING) ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 0. Boot anaconda without any kernel parameter 1. Enter SOFTWARE SELECTION (using CDROM as INSTALLATION SOURCE) 2. Select: Development and Creativity Workstation (AND Also select ALL Addons) Both Installation Options and 'anaconda.log' says the needed space is: 8.68gb 3. Enter STORAGE: INSTALLATION DESTINATION and select one disk (mine is 23gb) 4. Do MANUAL PARTITIONING setting the 'scheme' to BTRFS 5. Partition it with: /, /boot as BTRFS subvol 10.24gb and swap of 384mb. Note: the btrfs specfic partition size is 10240. 6. Once Anaconda accepts the storage configuration, 'begin installation' 7. Anaconda starts installing, set a root password and wait. 8. Anaconda finishes ok. 9. Do not reboot, switch to vt2 and execute: # cd /mnt/sysimage # touch foo # rm foo ok, this works ok. # dd if=/dev/zero of=./nukefile.out It will create a 1.4gb file. (It also issued a "No space left on device") # touch foo # rm foo # rm nukefile Ok, this works out. No issues. 10. BTRFS Info: # btrfs fi df /mnt/sysimage Data: total=7.97GB, used=6.67GB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.00GB, used=557.60MB Metadata: total=8.00MB, used=0.00 # btrfs fi show /dev/sda2 Label: 'fedora' uuid: cd746acf-4b2b-4c65-999c-daf93d8bf8e9 Total devices 1 FS bytes used 7.21GB devid 1 size 10.00GB used 10.00GB path /dev/sda2 Btrfs Btrfs v0.19
Created attachment 677018 [details] control#1 program.log
Created attachment 677019 [details] control#1 anaconda.log
Created attachment 677020 [details] control#1 storage.log
Created attachment 677021 [details] control#1 X.log
Created attachment 677023 [details] control#1 packaging.log
Created attachment 677025 [details] screenshot of manual partitioning CONTROL #2: STANDARD PARTITIONS (WORKING) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 0. Boot anaconda without any kernel parameter 1. Enter SOFTWARE SELECTION (using CDROM as INSTALLATION SOURCE) 2. Select: Development and Creativity Workstation (AND Also select ALL Ad-dons) Both Installation Options and 'anaconda.log' says the needed space is: 8.68gb 3. Enter STORAGE: INSTALLATION DESTINATION and select one disk (mine is 23gb) 4. Do MANUAL PARTITIONING setting the 'scheme' to PLAIN Now, 9915-1400 = 8515 which is lower than 8789. Both 8900 and 9000 with btrfs failed. Try Standard Partitions. 5. Partition it with: / (8789), /boot (512mb), SWAP of 384mb. (All standard partitions). 6. Once Anaconda accepts the storage configuration, 'begin installation' 7. Anaconda starts installing, set a root password and wait. 8. Anaconda finishes ok. (And it was VERY FAST compared to btrfs.) >> With 'standard partition' scheme, anaconda installed ok. (of course) >> After installing, du shows /boot is 41mb and / is 7.4gb. >> Also df shows for /boot [size=504M, used=57M, avaiable=422M] and for >> / [size=8.5G, used=7.5G, avaiable=566M] (94% used).
Created attachment 677026 [details] screenshot of manual partitioning Case #1: BTRFS: ENOSPC ~~~~~~~~~~~~~~~~~~~~~~ 0. Boot anaconda without any kernel parameter. 1. Enter SOFTWARE SELECTION (using CDROM as INSTALLATION SOURCE) 2. Select: Development and Creativity Workstation (AND Also select ALL Ad-dons) Both Installation Options and 'anaconda.log' says the needed space is: 8.68gb 3. Enter STORAGE: INSTALLATION DESTINATION and select one disk (mine is 23gb) 4. Do MANUAL PARTITIONING setting the 'scheme' to BTRFS Now, 9915-1400 = 8515 which is lower than 8789. Let's try 8900. 5. Partition it with: /, /boot as BTRFS subvol 8.9gb and swap of 384mb. Note: the btrfs specific partition size is 8900mb. 6. Once Anaconda accepts the storage configuration, 'begin installation' 7. Anaconda starts installing, set a root password and wait. 8. Anaconda issues a RED STOP error, this time agains 'gnome-shell' 9. Do not reboot, switch to vt2 and execute: # cd /mnt/sysimage # touch foo # rm foo # dd if=/dev/zero of=./nukefile.out It will create a 408mb file. (It also issued a "No space left on device") # touch foo "No space left on device" # rm nukefile The file could be deleted without error. # mv foo foo2 "No space left on device" Well, in the logs: error: unpacking of archive failed on file /usr/share/locale/fa/LC_MESSAGES/gnome-shell.mo: cpio: rename failed - No space left on device >> So, in this case it failed because 'rename' stopped working. >> There was still 408mb free space. 10. BTRFS Info: # btfs fi df /mnt/sysimage Data: total=7.29GB, used=6.28GB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=701.00MB, used=543.83MB Metadata: total=8.00MB, used=0.00 # btrfs fi show /dev/sda2 Label: 'fedora' uuid: e76dbf70-7710-427f-b111-0ebadd025687 Total devices 1 FS bytes used 6.81GB devid 1 size 8.69GB used 8.69GB path /dev/sda2 Btrfs Btrfs v0.19 # df -h Filesystem Size Used Avail Use% Mounted on rootfs 1008M 715M 294M 71% / devtmpfs 975M 0 975M 0% /dev tmpfs 990M 0 990M 0% /dev/shm tmpfs 990M 5.9M 985M 1% /run tmpfs 990M 0 990M 0% /sys/fs/cgroup /dev/sr0 4.3G 4.3G 0 100% /run/install/repo /dev/mapper/live-rw 1008M 715M 294M 71% / tmpfs 990M 130M 861M 14% /tmp /dev/sda2 8.7G 7.4G 1.1G 88% /mnt/sysimage /dev/sda2 8.7G 7.4G 1.1G 88% /mnt/sysimage/boot devtmpfs 975M 0 975M 0% /mnt/sysimage/dev /dev/tmpfs 990M 0 990M 0% /mnt/sysimage/dev/shm /dev/tmpfs 990M 0 990M 0% /dev/shm
Created attachment 677027 [details] case#1 program.log
Created attachment 677028 [details] case#1 anaconda.log
Created attachment 677029 [details] case#1 storage.log
Created attachment 677030 [details] case#1 X.log
Created attachment 677032 [details] case#1 packaging.log
Created attachment 677033 [details] case#1 tmpXXXX file Installing systemtap-2.0-4.fc18.x86_64 (2526/2535) Installing gnome-shell-3.6.2-3.fc18.x86_64 (2527/2535) error: unpacking of archive failed on file /usr/share/locale/fa/LC_MESSAGES/gnome-shell.mo: cpio: rename failed - No space left on device
Created attachment 677034 [details] case#1 syslog
Created attachment 677035 [details] control#1 syslog I forgot to upload it before.
Case #2: BTRFS: ENOSPC ~~~~~~~~~~~~~~~~~~~~~~ 0. Boot anaconda without any kernel parameter 1. Enter SOFTWARE SELECTION (using CDROM as INSTALLATION SOURCE) 2. Select: Development and Creativity Workstation (AND Also select ALL Addons) Both Installation Options and 'anaconda.log' says the needed space is: 8.68gb 3. Enter STORAGE: INSTALLATION DESTINATION and select one disk (mine is 23gb) 4. Do MANUAL PARTITIONING setting the 'scheme' to BTRFS Now, 9915-1400 = 8515 which is lower than 8789. Since 8900 failed, try 9000. 5. Partition it with: /, /boot as BTRFS subvol 9gb and swap of 384mb. Note: the btrfs specfic partition size is 9000mb. 6. Once Anaconda accepts the storage configuration, 'begin installation' 7. Anaconda starts installing, set a root password and wait. 8. Anaconda ends in a BLACK SCREEN 9. Do not reboot, switch to vt2 and execute: # cd /mnt/sysimage # touch foo # rm foo # mkdir foodir # rmdir foodir It worked. # dd if=/dev/zero of=./nukefile.out It will create a 83mb file. (It also issued a "No space left on device") # touch foo "No space left on device" # mkdir foodir # rmdir foodir It worked. # mv bin/tar bin/tarx "No space left on device" # touch foo # rm foo Now it works again.... 10. BTRFS Info: # btrfs fi df /mnt/sysimage Data: total=7.38GB, used=6.52GB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=706.00MB, used=545.25MB Metadata: total=8.00MB, used=0.00 # btrfs fi show /dev/sda2 Label: 'fedora' uuid: 5d654f61-db94-4b9b-b45f-c26f5a28b6b5 Total devices 1 FS bytes used 7.05GB devid 1 size 8.79GB used 8.79GB path /dev/sda2 Btrfs Btrfs v0.19 # df -h rootfs 1008M 715M 293M 71% / devtmpfs 975M 0 975M 0% /dev tmpfs 990M 0 990M 0% /dev/shm tmpfs 990M 5.9M 985M 1% /run tmpfs 990M 0 990M 0% /sys/fs/cgroup /dev/sr0 4.3G 4.3G 0 100% /run/install/repo /dev/mapper/live-rw 1008M 715M 293M 71% / tmpfs 990M 130M 861M 14% /tmp /dev/sda2 8.8G 7.6G 883M 90% /mnt/sysimage /dev/sda2 8.8G 7.6G 883M 90% /mnt/sysimage/boot devtmpfs 975M 0 975M 0% /mnt/sysimage/dev /dev/tmpfs 990M 0 990M 0% /mnt/sysimage/dev/shm /dev/tmpfs 990M 0 990M 0% /dev/shm
Created attachment 677036 [details] case#2 program.log
Created attachment 677037 [details] case#2 anaconda.log
Created attachment 677038 [details] case#2 storage.log
Created attachment 677039 [details] case#2 X.log
Created attachment 677040 [details] case#2 packaging.log
Created attachment 677041 [details] case#2 syslog
Created attachment 677042 [details] case#2 tmpXXXX file
Created attachment 677044 [details] screenshot of manual partitioning Case #3: BTRFS: ENOSPC ~~~~~~~~~~~~~~~~~~~~~~ 0. Boot anaconda without any kernel parameter 1. Enter SOFTWARE SELECTION (using CDROM as INSTALLATION SOURCE) 2. Select: Development and Creativity Workstation (AND Also select ALL Ad-dons) Both Installation Options and 'anaconda.log' says the needed space is: 8.68gb 3. Enter STORAGE: INSTALLATION DESTINATION and select one disk (mine is 23gb) 4. Do MANUAL PARTITIONING setting the 'scheme' to BTRFS Now, i will try 9000 but without a /boot subvolume. (swap and /boot as standard partitions) 5. Partition it with only / as BTRFS 9gb, swap of 384mb and /boot of 512mb. Note: the btrfs specific partition size is 9000mb. 6. Once Anaconda accepts the storage configuration, 'begin installation' 7. Anaconda starts installing, set a root password and wait. 8. Anaconda ends in a BLACK SCREEN 9. Do not reboot, switch to vt2 and execute: # cd /mnt/sysimage # touch foo # rm foo # mkdir foodir # rmdir foodir It worked. # dd if=/dev/zero of=./nukefile.out It will create a 19mb file. (It also issued a "No space left on device") # touch foo "No space left on device" # mkdir foodir "No space left on device" But there should be 19mb free space, enough for a 0-byte file or directory. # mv bin/tar bin/tarx "No space left on device" # touch foo # rm foo Now it works again.... But why a 'transient' ENOSPC error? 10. BTRFS Info: # btfs fi df /mnt/sysimage Data: total=7.38GB, used=6.51GB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=706.00MB, used=545.32MB Metadata: total=8.00MB, used=0.00 # btrfs fi show /dev/sda3 Label: 'fedora' uuid: 3def5fc8-7fbc-490a-880b-adafe851461a Total devices 1 FS bytes used 7.04GB devid 1 size 8.79GB used 8.79GB path /dev/sda3 Btrfs Btrfs v0.19 # df -h Filesystem Size Used Avail Use% Mounted on rootfs 1008M 715M 293M 71% / devtmpfs 975M 0 975M 0% /dev tmpfs 990M 0 990M 0% /dev/shm tmpfs 990M 5.9M 985M 1% /run tmpfs 990M 0 990M 0% /sys/fs/cgroup /dev/sr0 4.3G 4.3G 0 100% /run/install/repo /dev/mapper/live-rw 1008M 715M 293M 71% / tmpfs 990M 130M 861M 14% /tmp /dev/sda3 8.8G 7.6G 894M 90% /mnt/sysimage /dev/sda1 504M 29M 451M 6% /mnt/sysimage/boot devtmpfs 975M 0 975M 0% /mnt/sysimage/dev /dev/tmpfs 990M 0 990M 0% /mnt/sysimage/dev/shm /dev/tmpfs 990M 0 990M 0% /dev/shm >> In this case it appears to have run out of space. >> Please note than one can install to a 8789mb / of type 'standard >> partition' and still end with +550mb free space but fail with >> a 9000mb / btrfs (and no other subvolumes). >> Also note that with a btrfs / of 9000mb (no other subvolumes), >> dd could write only 19mb and with a shared (/ and /boot) btrfs >> of 8900mb dd could write about 400mb! This is weird!!! >> The reason for the 'black screen' in Anaconda might be related >> to the weird way in which package script are failing, some failures >> do produce a "RED STOP" error at XXX Package, but others just results >> in the black screen.
Created attachment 677045 [details] case#3 program.log
Created attachment 677046 [details] case#3 anaconda.log
Created attachment 677047 [details] case#3 storage.log
Created attachment 677048 [details] case#3 X.log
Created attachment 677049 [details] case#3 syslog
Created attachment 677050 [details] case#3 packaging.log
Created attachment 677051 [details] case#3 tmpXXXX file
In Case#1, #2, and #3 i did a '#rm nukefile' but that info is missing in each case description. I was able to do it.
BTRFS considerations for ENOSPC: https://btrfs.wiki.kernel.org/index.php/ENOSPC
Created attachment 677064 [details] screenshot of manual partitioning CASE #4: BTRFS (BLACK SCREEN + UNBOTABLE SYSTEM + ???) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (It is BIGGER than CONTROL#1 which succeeded !!) 0. Boot anaconda without any kernel parameter 1. Enter SOFTWARE SELECTION (using CDROM as INSTALLATION SOURCE) 2. Select: Development and Creativity Workstation (AND Also select ALL Ad-dons) Both Installation Options and 'anaconda.log' says the needed space is: 8.68gb 3. Enter STORAGE: INSTALLATION DESTINATION and select one disk (mine is 23gb) 4. Do MANUAL PARTITIONING setting the 'scheme' to BTRFS 5. Partition / and /boot as BTRFS size 11.26gb, swap of 512mb Note: the btrfs specific partition size is 11264mb. 6. Once Anaconda accepts the storage configuration, 'begin installation' 7. Anaconda starts installing, set a root password and wait. 8. Anaconda ends in a BLACK SCREEN. Unexpected at this size. 9. BTRFS Info: # btfs fi df /mnt/sysimage Data: total=8.97GB, used=6.66GB System, DUP: total=8.00MB, used=4.00KB System: total=4.00MB, used=0.00 Metadata, DUP: total=1.00GB, used=557.16MB Metadata: total=8.00MB, used=0.00 # btrfs fi show /dev/sda3 Label: 'fedora' uuid: 52323040-f22d-4f04-aa42-7d54c52ed3f5 Total devices 1 FS bytes used 7.20GB devid 1 size 11.00GB used 11.00GB path /dev/sda2 Btrfs Btrfs v0.19 # df -h Filesystem Size Used Avail Use% Mounted on rootfs 1008M 715M 293M 71% / devtmpfs 975M 0 975M 0% /dev tmpfs 990M 0 990M 0% /dev/shm tmpfs 990M 6.1M 984M 1% /run tmpfs 990M 0 990M 0% /sys/fs/cgroup /dev/sr0 4.3G 4.3G 0 100% /run/install/repo /dev/mapper/live-rw 1008M 715M 293M 71% / tmpfs 990M 47M 944M 5% /tmp /dev/sda2 11G 7.8G 2.4G 77% /mnt/sysimage /dev/sda2 11G 7.8G 2.4G 77% /mnt/sysimage/boot devtmpfs 975M 0 975M 0% /mnt/sysimage/dev /dev/tmpfs 990M 0 990M 0% /mnt/sysimage/dev/shm /dev/tmpfs 990M 0 990M 0% /dev/shm 10. Reboot, the installed system does not boot. No GRUB2 screen is shown. >> @Kamil Páral >> You haven't mentioned whether you can successfully boot the >> system if you hard-reset it. I do not believe i can say that no, black screen and no error also mean no boot. I do still heavily suspect BTRFS for this.
Created attachment 677066 [details] case#4 program.log
Created attachment 677067 [details] case#4 anaconda.log
Created attachment 677068 [details] case#4 storage.log
Created attachment 677069 [details] case#4 X.log
Created attachment 677070 [details] case#4 syslog
Created attachment 677071 [details] case#1 packaging.log No errors this time. Case #4 seems like a genuine 'black screen' only. But i still don't trust btrfs.
Thanks for your thorough testing. One thing is clear from the first log (Attachment 675278 [details]) -- "No space left on device" errors are being ignored during kernel installation. There are dozens of such error messages, yet the first error should have been fatal. The offender appears to be dracut. [snippets from Attachment 675278 [details]] ... cp: cannot remove ‘/var/tmp/initramfs.o64Sgo//lib/modules/3.6.10-4.fc18.x86_64/kernel/drivers/ata/ata_generic.ko’: No space left on device dracut-install: ERROR: installing '//lib/modules/3.6.10-4.fc18.x86_64/kernel/drivers/ata/ata_generic.ko' ... /usr/lib/dracut/dracut-logger.sh: line 316: echo: write error: No space left on device ... /sbin/dracut: line 1071: /boot/initramfs-3.6.10-4.fc18.x86_64.img: No space left on device F: dracut: creation of /boot/initramfs-3.6.10-4.fc18.x86_64.img failed /usr/lib/dracut/dracut-logger.sh: line 316: echo: write error: No space left on device ... mkinitrd failed warning: %posttrans(kernel-3.6.10-4.fc18.x86_64) scriptlet failed, exit status 1
I'm not seeing the ENOSPC at all. I'm not seeing any Btrfs errors in fact, but maybe I've missed something. What does btrfs fi show and btrfs fi df <mountpoint> show in these cases?
OK I should have read more first, I see the confusion. I think that this is not an anaconda bug however. I think the question of how btrfs fi df and fi show report used space is a known issue that needs work. It comes up on the linux-btrfs list pretty regularly. This particular case would be more useful to post to the linux-btrfs@ list when using the debug kernel, to see if it reports more information than what I'm seeing in the logs supplied. There appears to be no more space on the disk, all space is allocated to either data or metdata chunks. But those allocations themselves are not yet full, and it seems what you're trying to create doesn't fill either one of them. So that could be a bug. But I think what you'll also find is that for file systems of this size, and usage, the recommendation will be to mkfs.btrfs with the -M flag, which mixes data and metadata together. Both can use all space, but both must also use the same profile, which means single for data and metadata, not DUPlicate metadata. That saves space too.
For CommonBugs, I'm ambivalent on this case. It's such a small file system as to be next to useless anyway. So I'm not sure this qualifies as common. Again, with any reasonable allocation for a VM, let alone an actual physical disk, this issue simply doesn't come up. I would say it clutters commonbugs with obscure things, and discourages people from reading through them all. I don't know if we vote on common bugs, but I'd be -1 on this and the related bug 893758.
I opened bug 894837, it covers the intermittent / spurious / transient ENOSPC errors that btrfs gives under certain conditions. These happens on an installed system, so it is not related to anaconda at all.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.