[yast-devel] openQA broken for Storage-NG
Hi, Our openQA tests for storage-ng are all red since two days ago. There are two different errors. One of then [1] appears in the upgrade process and the problem is that yast-update is requiring enum_mappings.rb file, but that file was removed from storage-ng package due to it is not necessary after introducing the libstorage wrapper. So, the solution is to avoid this dependency in yast-update. The second error [2], and apparently not related with the first one, appears after installing, when system is booting. Grub is complaining with this message: "error: file /boot/grub2/i386-pc/normal.mod not found". I guess this problem arose after adding BtrFS to the proposal, but I don't sure. Although the first error should be easy to solve, the second one looks tricky. Tomorrow I will try to solve them, but sure I need help with the second one. Any volunteer for helping? :) [1] https://yast-openqa.suse.cz/tests/3941#step/upgrade_select/5 [2] https://yast-openqa.suse.cz/tests/3943#step/grub_test/5
On Tue, 11 Apr 2017 18:56:47 +0100
José Iván López González
Hi,
Our openQA tests for storage-ng are all red since two days ago. There are two different errors. One of then [1] appears in the upgrade process and the problem is that yast-update is requiring enum_mappings.rb file, but that file was removed from storage-ng package due to it is not necessary after introducing the libstorage wrapper. So, the solution is to avoid this dependency in yast-update.
The second error [2], and apparently not related with the first one, appears after installing, when system is booting. Grub is complaining with this message: "error: file /boot/grub2/i386-pc/normal.mod not found". I guess this problem arose after adding BtrFS to the proposal, but I don't sure.
Although the first error should be easy to solve, the second one looks tricky. Tomorrow I will try to solve them, but sure I need help with the second one. Any volunteer for helping? :)
[1] https://yast-openqa.suse.cz/tests/3941#step/upgrade_select/5
I can try to check the second one tomorrow. Maybe it is related to snapshots? Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 04/11/2017 08:24 PM, Josef Reidinger wrote:
On Tue, 11 Apr 2017 18:56:47 +0100 José Iván López González
wrote: Hi,
Our openQA tests for storage-ng are all red since two days ago. There are two different errors. One of then [1] appears in the upgrade process and the problem is that yast-update is requiring enum_mappings.rb file, but that file was removed from storage-ng package due to it is not necessary after introducing the libstorage wrapper. So, the solution is to avoid this dependency in yast-update.
The second error [2], and apparently not related with the first one, appears after installing, when system is booting. Grub is complaining with this message: "error: file /boot/grub2/i386-pc/normal.mod not found". I guess this problem arose after adding BtrFS to the proposal, but I don't sure.
Although the first error should be easy to solve, the second one looks tricky. Tomorrow I will try to solve them, but sure I need help with the second one. Any volunteer for helping? :)
[1] https://yast-openqa.suse.cz/tests/3941#step/upgrade_select/5
I can try to check the second one tomorrow. Maybe it is related to snapshots?
I don't think is related to snapshots, but to some btrfs wizardly I fail to understand. I compared a working TW (yast-storage) and our ISO (yast-storage-ng). With our ISO ============ 1) At the end of installation, before bootloader is installed/configured - /dev/sda1 is mounted on /mnt and contains an empty boot/grub2/i386-pc - The corresponding subvol is mounted at /mnt/boot/grub2/i386-pc - The subvolume is empty as well 2) During the bootloader installation - /mnt/boot/grub2/i386-pc is populated with several files. 3) When the system is about to restart and everything is unmounted, you can do this checks: # First check mount /dev/sda1 /mnt ls /mnt/boot/grub2/i386-pc # Result: no files there # Second check (after umounting the previous) mount /dev/sda1 /mnt mount -o subvol=/@/boot/grub2/i386-pc /dev/sda1 /mnt/boot/grub2/i386-pc ls /mnt/boot/grub2/i386-pc # Result: the files are there, as expected 4) grub2 fails to find the corresponding files because it does not mount the subvolume and the files are not available if the subvolume is not mounted. With TW ============ 1) At the end of installation, before bootloader is installed/configured, everything is identical to our ISO 2) During the bootloader installation, everything look identical to my eyes as well. 3) When the system is about to restart and everything is unmounted, you can do this checks: # First check mount /dev/sda1 /mnt ls /mnt/boot/grub2/i386-pc # Result: the files are there, even if the subvolume is not mounted!! # Second check (after umounting the previous) mount /dev/sda1 /mnt mount -o subvol=/@/boot/grub2/i386-pc /dev/sda1 /mnt/boot/grub2/i386-pc ls /mnt/boot/grub2/i386-pc # Result: the files are there as well 4) grub2 succeeds. Not because it mounts the subvolume properly, (it does not) but because the files are available also if the subvolume is not mounted. I expected that in this last case the files were somehow being duplicated. That is, I was expecting a version of them in the root volume and also the same files copied again in the subvolume, with the latter "shadowing" the former when the subvolume was mounted. But that's not the case. If I modify the files in /mnt/boot/grub2/i386-pc while the subvol is not mounted and then I mount the volume, the changes are visible in the subvolume files. Conclusions: 1) I don't understand btrfs (time for some reading!) 2) Something is different in the way subvolumes are created/managed in both cases. Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 2017-04-17 13:06, Ancor Gonzalez Sosa wrote:
I don't think is related to snapshots, but to some btrfs wizardly I fail to understand.
I compared a working TW (yast-storage) and our ISO (yast-storage-ng).
With our ISO ============
1) At the end of installation, before bootloader is installed/configured
- /dev/sda1 is mounted on /mnt and contains an empty boot/grub2/i386-pc - The corresponding subvol is mounted at /mnt/boot/grub2/i386-pc - The subvolume is empty as well
2) During the bootloader installation
- /mnt/boot/grub2/i386-pc is populated with several files.
3) When the system is about to restart and everything is unmounted, you can do this checks:
# First check mount /dev/sda1 /mnt ls /mnt/boot/grub2/i386-pc # Result: no files there
# Second check (after umounting the previous) mount /dev/sda1 /mnt mount -o subvol=/@/boot/grub2/i386-pc /dev/sda1 /mnt/boot/grub2/i386-pc ls /mnt/boot/grub2/i386-pc # Result: the files are there, as expected
That sounds like the subvolume was not mounted while grub2 was written: Obviously the files went to the toplevel subvolume or to no subvolume at all (is this possible?), not to the correct subvolume. Or maybe the subvolume was not mounted with the correct mount options ("-o subvol=...")? But that would mean that that mount had silently failed. Or did it complain, and we just didn't react to the error properly?
Conclusions:
1) I don't understand btrfs (time for some reading!) 2) Something is different in the way subvolumes are created/managed in both cases.
I assume 2).
Kind regards
--
Stefan Hundhammer
On 04/18/2017 10:07 AM, Stefan Hundhammer wrote:
On 2017-04-17 13:06, Ancor Gonzalez Sosa wrote:
I don't think is related to snapshots, but to some btrfs wizardly I fail to understand.
I compared a working TW (yast-storage) and our ISO (yast-storage-ng).
With our ISO ============
1) At the end of installation, before bootloader is installed/configured
- /dev/sda1 is mounted on /mnt and contains an empty boot/grub2/i386-pc - The corresponding subvol is mounted at /mnt/boot/grub2/i386-pc - The subvolume is empty as well
2) During the bootloader installation
- /mnt/boot/grub2/i386-pc is populated with several files.
3) When the system is about to restart and everything is unmounted, you can do this checks:
# First check mount /dev/sda1 /mnt ls /mnt/boot/grub2/i386-pc # Result: no files there
# Second check (after umounting the previous) mount /dev/sda1 /mnt mount -o subvol=/@/boot/grub2/i386-pc /dev/sda1 /mnt/boot/grub2/i386-pc ls /mnt/boot/grub2/i386-pc # Result: the files are there, as expected
That sounds like the subvolume was not mounted while grub2 was written: Obviously the files went to the toplevel subvolume or to no subvolume at all (is this possible?), not to the correct subvolume.
Not really. In this case, the files were actually written in the subvolume, but NOT in the toplevel subvolume. That's why booting is failing. In the successful case (TW), the files were available also if the subvolume was not mounted.
Or maybe the subvolume was not mounted with the correct mount options ("-o subvol=...")? But that would mean that that mount had silently failed. Or did it complain, and we just didn't react to the error properly?
As far as I was able to see, the subvolume was mounted with the right options in both cases (TW and StorageNG) during the whole installation process.
Conclusions:
1) I don't understand btrfs (time for some reading!) 2) Something is different in the way subvolumes are created/managed in both cases.
Both options were not exclusive. ;-)
I assume 2).
Now the question is "what is different?" Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (4)
-
Ancor Gonzalez Sosa
-
Josef Reidinger
-
José Iván López González
-
Stefan Hundhammer