[opensuse-factory] chrooted update of factory
Hallo; when I update a factory installation chrooted by running the following script I see grub2-mount processes hanging around with 100% CPU for some minutes. Am I doing something wrong ? Or is this a bug in grub2-mount ? -------- Script--------- mount -t ext4 /dev/system2/root_factory /mnt mount -t ext4 /dev/disk/by-id/ata-SAMSUNG_SSD_830_Series_S0WKNYABB00183-part7 /mnt/boot mv /mnt/etc/resolv.conf /mnt/etc/resolv.conf.orig cp /etc/resolv.conf /mnt/etc/resolv.conf mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt zypper dup -l --download-as-needed mv /mnt/etc/resolv.conf.orig /mnt/etc/resolv.conf umount /mnt/sys /mnt/proc /mnt/dev /mnt/boot /mnt -------------------------------------- ------ Output of top------------------ Tasks: 350 total, 2 running, 348 sleeping, 0 stopped, 0 zombie %Cpu(s): 18.3 us, 1.0 sy, 0.0 ni, 80.4 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 16462708 total, 8558232 used, 7904476 free, 500344 buffers KiB Swap: 20971516 total, 0 used, 20971516 free, 5560028 cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9498 root 20 0 52964 31828 2092 R 99.65 0.193 3:05.27 grub2 - mount -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Fri, 20 Jun 2014 17:03:38 +0200
Markus Koßmann
Hallo; when I update a factory installation chrooted by running the following script I see grub2-mount processes hanging around with 100% CPU for some minutes. Am I doing something wrong ? Or is this a bug in grub2-mount ?
Quite possible. Could you strace it?
-------- Script--------- mount -t ext4 /dev/system2/root_factory /mnt mount -t ext4 /dev/disk/by-id/ata-SAMSUNG_SSD_830_Series_S0WKNYABB00183-part7 /mnt/boot
mv /mnt/etc/resolv.conf /mnt/etc/resolv.conf.orig cp /etc/resolv.conf /mnt/etc/resolv.conf mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt zypper dup -l --download-as-needed mv /mnt/etc/resolv.conf.orig /mnt/etc/resolv.conf umount /mnt/sys /mnt/proc /mnt/dev /mnt/boot /mnt
--------------------------------------
------ Output of top------------------ Tasks: 350 total, 2 running, 348 sleeping, 0 stopped, 0 zombie %Cpu(s): 18.3 us, 1.0 sy, 0.0 ni, 80.4 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem: 16462708 total, 8558232 used, 7904476 free, 500344 buffers KiB Swap: 20971516 total, 0 used, 20971516 free, 5560028 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 9498 root 20 0 52964 31828 2092 R 99.65 0.193 3:05.27 grub2 - mount
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Freitag, 20. Juni 2014, 19:19:46 schrieb Andrey Borzenkov:
В Fri, 20 Jun 2014 17:03:38 +0200
Markus Koßmann
пишет: Hallo; when I update a factory installation chrooted by running the following script I see grub2-mount processes hanging around with 100% CPU for some minutes. Am I doing something wrong ? Or is this a bug in grub2-mount ?
Quite possible. Could you strace it?
How do I attach strace to a grub2-mount process, which isn't started manually, but probably by one of the installation scripts run by rpm/zypper ? I can't start it manually because I don't know the parameters ( like image or mountpoint) which are used for grub2-mount in that installation script. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Fri, 20 Jun 2014 18:11:07 +0200
Markus Koßmann
Am Freitag, 20. Juni 2014, 19:19:46 schrieb Andrey Borzenkov:
В Fri, 20 Jun 2014 17:03:38 +0200
Markus Koßmann
пишет: Hallo; when I update a factory installation chrooted by running the following script I see grub2-mount processes hanging around with 100% CPU for some minutes. Am I doing something wrong ? Or is this a bug in grub2-mount ?
Quite possible. Could you strace it?
How do I attach strace to a grub2-mount process, which isn't started manually, but probably by one of the installation scripts run by rpm/zypper ?
strace -p
I can't start it manually because I don't know the parameters ( like image or mountpoint) which are used for grub2-mount in that installation script.
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am Freitag, 20. Juni 2014, 20:12:45 schrieb Andrey Borzenkov:
В Fri, 20 Jun 2014 18:11:07 +0200
Markus Koßmann
пишет: Am Freitag, 20. Juni 2014, 19:19:46 schrieb Andrey Borzenkov:
В Fri, 20 Jun 2014 17:03:38 +0200
Markus Koßmann
пишет: Hallo; when I update a factory installation chrooted by running the following script I see grub2-mount processes hanging around with 100% CPU for some minutes. Am I doing something wrong ? Or is this a bug in grub2-mount ?
Quite possible. Could you strace it?
How do I attach strace to a grub2-mount process, which isn't started manually, but probably by one of the installation scripts run by rpm/zypper ? strace -p
I can't start it manually because I don't know the parameters ( like image or mountpoint) which are used for grub2-mount in that installation script. This is a end of a grub2-mount strace output. There are a lot more read/lseek and break calls at the begin, but since I missed the start of the grub2-mount I don't have more relevant info about what it is trying to do.
read(3, "\246\6\f\0\24\0\f\1MACINTOSH.so?\7\f\0\24\0\f\1BIG5"..., 32768) =
32768
lseek(3, 13410271232, SEEK_SET) = 13410271232
read(3, "I\213t$\10\350\216\246\377\377H\205\333t\25H\213\5ZC
\0H\211\3H\213\5XC \0"..., 32768) = 32768
brk(0x3078000) = 0x3078000
brk(0x303c000) = 0x303c000
lseek(3, 14025064448, SEEK_SET) = 14025064448
read(3,
"\362\16\0\0\22\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\17\0\0\22\0\f\0"...,
32768) = 32768
brk(0x3078000) = 0x3078000
brk(0x303c000) = 0x303c000
brk(0x3078000) = 0x3078000
brk(0x303c000) = 0x303c000
lseek(3, 13926137856, SEEK_SET) = 13926137856
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`\n\0\0\0\0\0\0"...,
32768) = 32768
brk(0x3078000) = 0x3078000
brk(0x303c000) = 0x303c000
lseek(3, 12922454016, SEEK_SET) = 12922454016
read(3, "\314%\f\0\30\0\17\1winealsa.drv.so\0004(\f\0 \0\26\1"..., 32768) =
32768
lseek(3, 13808074752, SEEK_SET) = 13808074752
read(3,
"\24\0\0\0T\1\0\0\270\355\376\377\v\0\0\0\0\0\0\0\0\0\0\0\24\0\0\0l\1\0\0"...,
32768) = 32768
brk(0x3078000) = 0x3078000
brk(0x303c000) = 0x303c000
lseek(3, 12888047616, SEEK_SET) = 12888047616
read(3,
"\355\201\0\0h9\0\0\251\211\364N\251\211\364N\335\32\344N\0\0\0\0\0\0\1\0
\0\0\0"..., 32768) = 32768
brk(0x3078000) = 0x3078000
brk(0x303c000) = 0x303c000
lseek(3, 12888997888, SEEK_SET) = 12888997888
read(3,
"\355\201\0\0X\21\n\0\261\211\364N\261\211\364N4\245_M\0\0\0\0\0\0\1\0\20\5\0\0"...,
32768) = 32768
lseek(3, 14202011648, SEEK_SET) = 14202011648
read(3,
"&\27\0\0\0\0\0\0006\27\0\0\0\0\0\0F\27\0\0\0\0\0\0V\27\0\0\0\0\0\0"...,
32768) = 32768
brk(0x3078000) = 0x3078000
brk(0x303c000) = 0x303c000
lseek(3, 12922454016, SEEK_SET) = 12922454016
read(3, "\314%\f\0\30\0\17\1winealsa.drv.so\0004(\f\0 \0\26\1"..., 32768) =
32768
lseek(3, 14049837056, SEEK_SET) = 14049837056
read(3,
"\20Z\3\0\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0"...,
32768) = 32768
brk(0x3078000) = 0x3078000
brk(0x303c000) = 0x303c000
lseek(3, 12885622784, SEEK_SET) = 12885622784
read(3,
"\355\201\0\0\2709\0\0\236\211\364N\236\211\364N\320}`M\0\0\0\0\0\0\1\0
\0\0\0"..., 32768) = 32768
lseek(3, 13131481088, SEEK_SET) = 13131481088
read(3,
"^\233\0\0\0\0\0\0n\233\0\0\0\0\0\0~\233\0\0\0\0\0\0\216\233\0\0\0\0\0\0"...,
32768) = 32768
brk(0x3078000) = 0x3078000
brk(0x303c000) = 0x303c000
lseek(3, 12919078912, SEEK_SET) = 12919078912
read(3, "\246\6\f\0\24\0\f\1MACINTOSH.so?\7\f\0\24\0\f\1BIG5"..., 32768) =
32768
lseek(3, 14206992384, SEEK_SET) = 14206992384
read(3,
"\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\16\6\0\0\0\0\0"..., 32768)
= 32768
brk(0x3078000) = 0x3078000
brk(0x303c000) = 0x303c000
lseek(3, 14041874432, SEEK_SET) = 14041874432
read(3,
"\370\23\5\247&\0\220\24\5\335&\0\250\24\5\247&\0\300\24\5\301$\0\330\24\5\335&\0\360\24"...,
32768) = 32768
brk(0x3078000) = 0x3078000
brk(0x303c000) = 0x303c000
lseek(3, 12888932352, SEEK_SET) = 12888932352
read(3,
"\377\241\0\0\21\0\0\0\261\211\364N\261\211\364N\227\213\241M\0\0\0\0\0\0\1\0\0\0\0\0"...,
32768) = 32768
brk(0x3078000) = 0x3078000
brk(0x303c000) = 0x303c000
lseek(3, 12922388480, SEEK_SET) = 12922388480
read(3, "/#\f\0\f\0\1\2.\0\0\0)#\f\0\f\0\2\2..\0\0000#\f\0\34\0\22\1"...,
32768) = 32768
lseek(3, 12888932352, SEEK_SET) = 12888932352
read(3,
"\377\241\0\0\21\0\0\0\261\211\364N\261\211\364N\227\213\241M\0\0\0\0\0\0\1\0\0\0\0\0"...,
32768) = 32768
lseek(3, 14126186496, SEEK_SET) = 14126186496
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\247\0\0\0\0\0\0"...,
32768) = 32768
brk(0x3078000) = 0x3078000
brk(0x303c000) = 0x303c000
lseek(3, 12922388480, SEEK_SET) = 12922388480
read(3, "/#\f\0\f\0\1\2.\0\0\0)#\f\0\f\0\2\2..\0\0000#\f\0\34\0\22\1"...,
32768) = 32768
lseek(3, 12888309760, SEEK_SET) = 12888309760
read(3,
"\377\241\0\0\24\0\0\0\256\211\364N\256\211\364N\301\212\241M\0\0\0\0\0\0\1\0\0\0\0\0"...,
32768) = 32768
brk(0x3078000) = 0x3078000
brk(0x303c000) = 0x303c000
brk(0x3078000) = 0x3078000
brk(0x303c000) = 0x303c000
lseek(3, 13207732224, SEEK_SET) = 13207732224
read(3, "!<arch>\n/ 12979487"..., 32768) = 32768
brk(0x3078000) = 0x3078000
brk(0x303c000) = 0x303c000
lseek(3, 6848512, SEEK_SET) = 6848512
read(3,
"\244\201\0\0\322\32\n\0\260\211\364N\260\211\364N\345
On 2014-06-21 20:02, Markus Koßmann wrote:
Am Freitag, 20. Juni 2014, 20:12:45 schrieb Andrey Borzenkov:
This is a end of a grub2-mount strace output. There are a lot more read/lseek and break calls at the begin, but since I missed the start of the grub2-mount I don't have more relevant info about what it is trying to do.
You can trace a process and all the childs it starts, each one on a separate log file, with the PID number as part of the name. You also need to find whether strace or ltrace is more useful.
I#ve uploaded a incomplete strace ( begin is missing) of grub2-mount to http://susepaste.org/95801345. I seems that
It is empty, there is nothing there. But just a wild guess: disable os-probe in grub2 yast config. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2014-06-20 18:11, Markus Koßmann wrote:
How do I attach strace to a grub2-mount process, which isn't started manually, but probably by one of the installation scripts run by rpm/zypper ?
It could be done by stracing zypper and all children (with a separate log file per PID) - but that would be a lot. But my guess is that it is os-prober, so simply disable it in grub config. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 2014-06-20 17:03, Markus Koßmann wrote:
Hallo; when I update a factory installation chrooted by running the following script I see grub2-mount processes hanging around with 100% CPU for some minutes. Am I doing something wrong ? Or is this a bug in grub2-mount ?
-------- Script--------- mount -t ext4 /dev/system2/root_factory /mnt mount -t ext4 /dev/disk/by-id/ata-SAMSUNG_SSD_830_Series_S0WKNYABB00183-part7 /mnt/boot
mv /mnt/etc/resolv.conf /mnt/etc/resolv.conf.orig cp /etc/resolv.conf /mnt/etc/resolv.conf mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt zypper dup -l --download-as-needed mv /mnt/etc/resolv.conf.orig /mnt/etc/resolv.conf umount /mnt/sys /mnt/proc /mnt/dev /mnt/boot /mnt
--------------------------------------
It is long since I did this the last time. You may have to copy over "/etc/mtab" and edit it yourself, manually, so that it matches the situation as seen from inside the chrooted environment. I also did "export PBL_SKIP_BOOT_TEST=1". And I think you should also configure grub2, in yast, not to seek for other operating systems. On some real situations I have seen it takes many minutes at full cpu: it tried to mount extended partitions (which is of course impossible), for instance. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
participants (3)
-
Andrey Borzenkov
-
Carlos E. R.
-
Markus Koßmann