[arch-releng] ISO 2014.11.01: installing packages may cause system failure
As of ISO 2014.11.01 attempts to install packages within the live system itself can cause complete system failure, apparently due to problems affecting device mapper. The problem is a regression that can't be seen with ISO 2014.10.01. It doesn't always appear and I couldn't find out the exact conditions. But it seems the number / volume of packages that are about to be installed has to exceed some kind of threshold. Also, it doesn't affect running pacstrap the usual way. Attaching journalctl output from a KVM/QEMU instance (behaviour is the same booting "bare metal", though). Regards.
Peter Mattern <matternp@arcor.de> on Mon, 2014/11/10 17:14:
As of ISO 2014.11.01 attempts to install packages within the live system itself can cause complete system failure, apparently due to problems affecting device mapper.
The problem is a regression that can't be seen with ISO 2014.10.01. It doesn't always appear and I couldn't find out the exact conditions. But it seems the number / volume of packages that are about to be installed has to exceed some kind of threshold. Also, it doesn't affect running pacstrap the usual way.
Attaching journalctl output from a KVM/QEMU instance (behaviour is the same booting "bare metal", though).
The cowfile has a default size of 256MB now. Probably that filled up. Try to boot with cowfile_size=2G and try again. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}
Peter Mattern<matternp@arcor.de> on Mon, 2014/11/10 17:14:
As of ISO 2014.11.01 attempts to install packages within the live system itself can cause complete system failure, apparently due to problems affecting device mapper.
The problem is a regression that can't be seen with ISO 2014.10.01. It doesn't always appear and I couldn't find out the exact conditions. But it seems the number / volume of packages that are about to be installed has to exceed some kind of threshold. Also, it doesn't affect running pacstrap the usual way.
Attaching journalctl output from a KVM/QEMU instance (behaviour is the same booting "bare metal", though). The cowfile has a default size of 256MB now. Probably that filled up. Try to boot with cowfile_size=2G and try again. Any attempt to do so (2g, 1g, 256[m]b) results in kernel panic, the last
Am 10.11.2014 um 17:18 schrieb Christian Hesse: line before reading /init: line 48: arithmetic syntax error
Peter Mattern <matternp@arcor.de> on Mon, 2014/11/10 17:41:
Am 10.11.2014 um 17:18 schrieb Christian Hesse:
Peter Mattern<matternp@arcor.de> on Mon, 2014/11/10 17:14:
As of ISO 2014.11.01 attempts to install packages within the live system itself can cause complete system failure, apparently due to problems affecting device mapper.
The problem is a regression that can't be seen with ISO 2014.10.01. It doesn't always appear and I couldn't find out the exact conditions. But it seems the number / volume of packages that are about to be installed has to exceed some kind of threshold. Also, it doesn't affect running pacstrap the usual way.
Attaching journalctl output from a KVM/QEMU instance (behaviour is the same booting "bare metal", though).
The cowfile has a default size of 256MB now. Probably that filled up. Try to boot with cowfile_size=2G and try again.
Any attempt to do so (2g, 1g, 256[m]b) results in kernel panic, the last line before reading /init: line 48: arithmetic syntax error
I can not reproduce this and the parameter works as expected for me. So no idea what is wrong on your side... -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}
I had forgotten to connect ISO 2014.*11* to the VM back again. Now it's exactly as you supposed. With cowsize_file set to 2g the very same packages that triggered the behaviour can be installed, the number of packages that can be installed before the issue comes up increases when cowfile_size gets increased, all this applies to both hardware and VM. So I guess you'll consider this a feature, not a bug, in particular as the problem doesn't affect the ISO's actual purpose but only arises if it's "misused" as ordinary live media (which is something I for one pretty much like to do for testing purposes...)? Or is there any way to have the file's size adjusted automatically corresponding to available resources?
Peter Mattern <matternp@arcor.de> on Mon, 2014/11/10 21:22:
I had forgotten to connect ISO 2014.*11* to the VM back again.
Now it's exactly as you supposed. With cowsize_file set to 2g the very same packages that triggered the behaviour can be installed, the number of packages that can be installed before the issue comes up increases when cowfile_size gets increased, all this applies to both hardware and VM.
So I guess you'll consider this a feature, not a bug, in particular as the problem doesn't affect the ISO's actual purpose but only arises if it's "misused" as ordinary live media (which is something I for one pretty much like to do for testing purposes...)? Or is there any way to have the file's size adjusted automatically corresponding to available resources?
This is the corresponding change in archiso: https://projects.archlinux.org/archiso.git/commit/?id=edfdd37ba00bcb51e293f1... Not sure why this has been changed. I do build my own customized live media, so I do not care that much. ;) -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}
On 11/11/2014 04:07 AM, Christian Hesse wrote:
Peter Mattern <matternp@arcor.de> on Mon, 2014/11/10 21:22:
I had forgotten to connect ISO 2014.*11* to the VM back again.
Now it's exactly as you supposed. With cowsize_file set to 2g the very same packages that triggered the behaviour can be installed, the number of packages that can be installed before the issue comes up increases when cowfile_size gets increased, all this applies to both hardware and VM.
So I guess you'll consider this a feature, not a bug, in particular as the problem doesn't affect the ISO's actual purpose but only arises if it's "misused" as ordinary live media (which is something I for one pretty much like to do for testing purposes...)? Or is there any way to have the file's size adjusted automatically corresponding to available resources?
This is the corresponding change in archiso:
https://projects.archlinux.org/archiso.git/commit/?id=edfdd37ba00bcb51e293f1...
Not sure why this has been changed.
I do build my own customized live media, so I do not care that much. ;)
This was changed because: 1) Now the ext4 image is always 32G 2) A sane default for a fs that does not support sparse files. 3) Just works for the tasks on "releng" profile.
participants (3)
-
Christian Hesse
-
Gerardo Exequiel Pozzi
-
Peter Mattern