And I had ended with an invalid fstab, in the sense that it had a line in it for swap and the swap volume didn't exist anymore.
There was also another line for another volume (both LVM) that didn't exist.
And I was in the "rescue shell" tying things up, and my computer started to freeze. This was after a reboot. And that was after I had changed the partition setup (shrunk one, created a new one in the remaining space).
Prior to that, I had to shrink the Physical Volume of the LVM for that partition, and afterwards of course shrink the encrypted mapping device, and then shrink the partition.
Now I may have made a mistake in the size of the LUKS container as opposed to the Physical Volume. I had thought that the size of the LUKS container (in sectors) would have to be equal to the size of the Physical Volume (in sectors) plus the offset of the LUKS volume. So the offset is 4096 for those volumes/mappings/configurations, so you create the Physical Volume the size of the LUKS block minus 4096, in sectors. However, you have to resize the Physical volume in sectors, so what you do is that you first shrink the PV to a number of sectors (and hope it matches the wanted number of Physical Extents) (which it will show, after, when you do pvdisplay) but it is impossible to view the final number of sectors the physical volume has, because you can only display it in physical extents.
Furthermore, it will tell you what number of sectors it is resizing to, but not where it came from, and, also, it will say it has resized something even when it hasn't. When you don't specify a size, it will grow to the size of the enclosed device, which is the only thing you can count on.
Turned out after reboot that a pvresize -tv wanted to shrink the PV to one extent less, which means it does have some header. But I don't know how big it is or how many sectors it wants. So, after, I grew the partition by 2 MB, resized the LUKS (also happens automatically), and resized the PV (which said it did something, but it may have remained the same) and the number of extents is now correct and it doesn't want to resize it to a lower value (obviously) and this means that currently the PV size must be the LUKS size minus 8192 sectors. Or, conversely, the PV size must now be the size in the number of extents times 4 MB, plus 2 MB. I don't really know because it gives so little information.
So I reboot and it still hangs.
Nothing can be the matter anymore, and it still hangs. It has found all its sizes automatically now, there is no possibility of having some incorrect size or it would have bolted. And my system still hangs.
I boot up the regular mode and I get emergency mode. I check the journal and it cannot load the swap. No biggy, right?
Apparently, it is a very big thing. I am now in the regular session. This session is loaded from my harddisk. It doesn't hang. I made no changes other than comment out the swap line and another mount line.
So I tried (through fstab) to load a swap device that didn't exist, the whole path didn't exist anymore. I reboot and the system gets lockups within 5 minutes each time. I remove the line, reboot, and no lockups for at least 30 minutes now.
Are you telling me the seriousness of having an invalid swap line is true?
Did my system hang because of this and this alone? It would be pretty weird if a malconfigured LVM caused hangs because it would require reads or writes (at least) to the final ~2MB of the final configured volume (logical volume) and that never could happen like that, since the volume was not used (or mounted). I'm just guessing right. Further, the live session of the same installation did nothing odd even when it loaded the same LVM and did the same things.
I'm really a bit incredulous here.
And yes I do weird stuff with my computer now and then ;-).
There was also another line for another volume (both LVM) that didn't exist.
And I was in the "rescue shell" tying things up, and my computer started to freeze. This was after a reboot. And that was after I had changed the partition setup (shrunk one, created a new one in the remaining space).
Prior to that, I had to shrink the Physical Volume of the LVM for that partition, and afterwards of course shrink the encrypted mapping device, and then shrink the partition.
Now I may have made a mistake in the size of the LUKS container as opposed to the Physical Volume. I had thought that the size of the LUKS container (in sectors) would have to be equal to the size of the Physical Volume (in sectors) plus the offset of the LUKS volume. So the offset is 4096 for those volumes/mappings/configurations, so you create the Physical Volume the size of the LUKS block minus 4096, in sectors. However, you have to resize the Physical volume in sectors, so what you do is that you first shrink the PV to a number of sectors (and hope it matches the wanted number of Physical Extents) (which it will show, after, when you do pvdisplay) but it is impossible to view the final number of sectors the physical volume has, because you can only display it in physical extents.
Furthermore, it will tell you what number of sectors it is resizing to, but not where it came from, and, also, it will say it has resized something even when it hasn't. When you don't specify a size, it will grow to the size of the enclosed device, which is the only thing you can count on.
Turned out after reboot that a pvresize -tv wanted to shrink the PV to one extent less, which means it does have some header. But I don't know how big it is or how many sectors it wants. So, after, I grew the partition by 2 MB, resized the LUKS (also happens automatically), and resized the PV (which said it did something, but it may have remained the same) and the number of extents is now correct and it doesn't want to resize it to a lower value (obviously) and this means that currently the PV size must be the LUKS size minus 8192 sectors. Or, conversely, the PV size must now be the size in the number of extents times 4 MB, plus 2 MB. I don't really know because it gives so little information.
So I reboot and it still hangs.
Nothing can be the matter anymore, and it still hangs. It has found all its sizes automatically now, there is no possibility of having some incorrect size or it would have bolted. And my system still hangs.
I boot up the regular mode and I get emergency mode. I check the journal and it cannot load the swap. No biggy, right?
Apparently, it is a very big thing. I am now in the regular session. This session is loaded from my harddisk. It doesn't hang. I made no changes other than comment out the swap line and another mount line.
So I tried (through fstab) to load a swap device that didn't exist, the whole path didn't exist anymore. I reboot and the system gets lockups within 5 minutes each time. I remove the line, reboot, and no lockups for at least 30 minutes now.
Are you telling me the seriousness of having an invalid swap line is true?
Did my system hang because of this and this alone? It would be pretty weird if a malconfigured LVM caused hangs because it would require reads or writes (at least) to the final ~2MB of the final configured volume (logical volume) and that never could happen like that, since the volume was not used (or mounted). I'm just guessing right. Further, the live session of the same installation did nothing odd even when it loaded the same LVM and did the same things.
I'm really a bit incredulous here.
And yes I do weird stuff with my computer now and then ;-).
Comment