Error with Logical Volume Management

[Alixxx-please]

I can't even access the log file, sorry for not using the error template.

So I'm trying to install Arch on my nvme and in the Disk configuration part I set "Use a best-effort default partition layout" with btrfs and CoW. But when I try to set LVM with btrfs still, it makes everything crash as you can see on the screenshot. I tried with ext4 to see what was the problem and still got errors with LVM, so I belive it is the problem.
Also, despite the commands shown I couldn't find any log file, so I can't give one unfortunately.
This happened on the last official iso, 2024-09-01.
If there is another way to get some logs I would like to know to properly help with the issue. Thanks!

[Torxed]

For some additional context, I recommended to post this issue based on this conversation: https://www.reddit.com/r/archlinux/comments/1fi228p/comment/lnfv1ay/?context=3 :)

[Alixxx-please]

I managed to get the logs! Sorry for the delay and thanks for your kindness 🙂
https://0x0.st/X3MS.log

[Alixxx-please]

This is the only thing preventing me from fully switching to Arch, is there a workaround or something I can do about it?

[svartkanin]

I haven't had time to look into this yet.
You could try to delete all existing partitions, then reboot and try the installation again.

[Alixxx-please]

Unfortunately it didn't solve the problem, still the same error. But thanks, and keep me updated if anything happens! 🫶🏻

[TheWiFiNerds]

I am also having this issue

[Alixxx-please]

Weird thing is that it used to work a few months ago, I used different settings but I remember setting btrfs with LVM 🤔

[Firebleu]

Hi !

I think LVM is experimental, maybe you need to wait a little bit.
Unfortunately I can't help you more, for my computer I use ext4 + Luks.
Maybe I can create a VM to see if I have the same problem.
Another thing, sometimes archinstall don't work very good maybe try to install arch with the wiki without the script.

I hope someone will come with an answer for you.

[Alixxx-please]

Seem to just be a lvm problem, and not just specifically a lvm + btrfs problem. Tried ext4 + lvm and here is the result error : https://0x0.st/XIQQ.log

[svartkanin]

After it crashes could you run the below command manually

lvs --reportformat json --unit B

maybe wait a bit and try it multiple times and check if the output eventually returns something in the

{
      "report": [
          {
              "lv": [
              ]
          }
      ]
      ,
      "log": [
      ]
  }

report->lvm block

[Alixxx-please]

I don't know how can I extract the text other than with this poor image. I believe it's at least readable, but I would appreciate a better way to send this if possible. Trying to upload the log file to 0x0.st doesn't include the command

[svartkanin]

Thanks, to export anything you can store the output to a file and then simply run

curl -F'[email protected]' https://0x0.st

So it seems that the vol was created eventually, the current logic will attempt to fetch the info 3 times within 10s or so and then fail. We can definitely increase the timeout but I'm not sure what the actual time to create any VG or VOL is...
We can try to fetch it forever and then would just "hang" there if it can never get the info back.

Would you mind exporting that output so it's better readable, I'm curious to what the log entry exactly says

[Alixxx-please]

Here is the output of the command : https://0x0.st/Xlpz.log

And I believe it errors because of the timeout, because it throws it at me almost a second after the installation started, everytime

[codefiles]

So it seems that the vol was created eventually, the current logic will attempt to fetch the info 3 times within 10s or so and then fail. We can definitely increase the timeout but I'm not sure what the actual time to create any VG or VOL is...
We can try to fetch it forever and then would just "hang" there if it can never get the info back.

I plan to replace all retry logic with use of udev_sync(), which should wait for the device to be ready.

[Alixxx-please]

Fix underway?

[svartkanin]

@Alixxx-please I have not tested this but you can give this patch a try and see if it works #2748

[Alixxx-please]

Sorry but how would I test this on a live iso please?
I believe I should use the live iso from Github Actions. I will let you know really soon!

[Alixxx-please]

I got a very similar error, but still one unfortunately. It also happened almost instantly after starting the installation
https://0x0.st/Xlwg.log

[svartkanin]

Could you try to reboot and then again

[Alixxx-please]

I believe I get the same error unfortunately 😕
https://0x0.st/Xlwh.log

[codefiles]

@svartkanin, why would you think it is acceptable to submit a pull request with my proposed solution? You did not discuss this with me or even add me as an author. That is very unprofessional of you and it is not the first time you have done this.

@Torxed, are you going to allow this to keep happening?

[svartkanin]

@codefiles this issue has been open for over a month now and there was no PR raised from your side thus far. You said "you're planning" to eventually fix all retries but didn't necessarily specify a time frame for it.

In the spirit of trying to resolve the issue and to see if your proposed eventual fix is actually solving this I was thinking of raising it to get it tested if it works. Yes I did not mention you in the PR and that was my fault for not giving credit for your solution.

I've declined the PR now so feel free to raise your own with a fix.

[Alixxx-please]

So if the first fix doesn't work, there's no other option at the moment?

[Alixxx-please]

..?