Re: update-grub causes a system lockup
On 1/12/21 1:39 AM, Dennis Clarke wrote: > > I made a few minor edits to /etc/default/grub and then : > > root@ceres:~# update-grub > [ 303.211729] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! > [grub-probe:261] > [ 303.306793] Modules linked in: sg(E) envctrl(E) display7seg(E) > flash(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) > crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) t10_pi(E) > crc_t10dif(E) crct10dif_generic(E) crct10dif_common(E) ata_generic(E) > pata_cmd64x(E) sym53c8xx(E) libata(E) scsi_transport_spi(E) scsi_mod(E) > sunhme(E) > (...) > Also this has been happening for months. I would suggest installing a 4.x kernel and see if that helps. I know that 5.x kernels can be a bit unstable on certain older SPARC machines. If the issue goes away with an older kernel, try bisecting to find the commit that introduced the issue. Either way, it's good to have something which allows to reproduce the bug. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
update-grub causes a system lockup
I made a few minor edits to /etc/default/grub and then : root@ceres:~# update-grub [ 303.211729] watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [grub-probe:261] [ 303.306793] Modules linked in: sg(E) envctrl(E) display7seg(E) flash(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E) crct10dif_common(E) ata_generic(E) pata_cmd64x(E) sym53c8xx(E) libata(E) scsi_transport_spi(E) scsi_mod(E) sunhme(E) [ 303.716582] CPU: 0 PID: 261 Comm: grub-probe Tainted: GE 5.10.0-1-sparc64 #1 Debian 5.10.5-1 [ 303.845889] TSTATE: 11001606 TPC: 0094c4f0 TNPC: 0094c4f4 Y: Tainted: GE [ 303.993559] TPC: [ 304.043951] g0: f800068f5ec0 g1: 0098 g2: g3: 0196df50 [ 304.158439] g4: f8000ac388a0 g5: 5ff099f6 g6: f8000b6fc000 g7: 0ef10180 [ 304.272918] o0: 00f24960 o1: f8000b6ff8ec o2: f800042833d0 o3: [ 304.387399] o4: o5: sp: f8000b6fef81 ret_pc: 0094c4c0 [ 304.506456] RPC: [ 304.556875] l0: 00f24800 l1: l2: 00664c00 l3: 000661c58e90 [ 304.671360] l4: 0002 l5: f8000b6ff8f0 l6: 00e12000 l7: 0001 [ 304.785838] i0: f8000ad93048 i1: f8000b47b600 i2: 00f24800 i3: 00f24978 [ 304.900318] i4: 00ec i5: 10076818 i6: f8000b6ff031 i7: 00665838 [ 305.014814] I7: [ 305.066356] Call Trace: [ 305.098501] [<00665838>] chrdev_open+0x98/0x1e0 [ 305.167245] [<0065ae30>] do_dentry_open+0x170/0x420 [ 305.240529] [<0065ca68>] vfs_open+0x28/0x40 [ 305.304691] [<00671348>] path_openat+0x988/0x1100 [ 305.375707] [<00673dd0>] do_filp_open+0x50/0x100 [ 305.445573] [<0065cd30>] do_sys_openat2+0x70/0x180 [ 305.517732] [<0065d268>] sys_openat+0x48/0xc0 [ 305.584186] [<00406174>] linux_sparc_syscall+0x34/0x44 ~ At this point I have to signal a break to the console. I am not yet sure exactly which binary causes this problem but I am going with a wild guess that somewhere in /usr/sbin/grub-mkconfig we end up with a show stopping fault. I am walking through it line by line and trying to find the culprit. Also this has been happening for months. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed
Hello! On 1/11/21 2:53 PM, Dennis Clarke wrote: > I am doing a re-install with the "default" installer and I choose the > most trivial config options. Which is to say the partition options were > whatever seems most trivial. Full disk. New partition table. Everything > in one partition. The default seems to be 512MB ext2 bootable /boot and > then a large slice and 1G of swap. > > Eventually I see a big red box : > > [!!] Configure the package manager > apt configuration problem > An attempt to configure apt to install additional packages from the > media failed. > > Here I select "continue" and things seem to move along. You should have checked what's in the log in the other terminal so you know the actual problem was. > I guess there is something oddball in the expert level menu option but > we don't really test for that. OKay, this works in the easy mode option. I alone simply don't have the capacity to test (and fix!) all possible paths in the installer. If you run into such problem, try to reproduce it with a daily snapshot of the installer on one of the officially supported architectures and then file a bug against debian-installer. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed
On 1/9/21 1:12 AM, John Paul Adrian Glaubitz wrote: > On 1/9/21 1:53 AM, Dennis Clarke wrote: >> >> I think this is pretty much well known but I will report it here >> regardless. From the latest sparc64 installer images I eventually >> see grub-ieee1275 fails. >> (...) >> Jan 4 19:00:02 in-target: Get:1 http://deb.debian.org/debian-ports >> sid/main sparc64 grub2-common sparc64 2.04-11 [719 kB] >> Jan 4 19:00:04 in-target: Err:2 http://deb.debian.org/debian-ports >> sid/main sparc64 grub-ieee1275-bin sparc64 2.04-11 >> Jan 4 19:00:04 in-target: 503 Backend unavailable, connection >> timeout [IP: 2a04:4e42:58::644 80] >> Jan 4 19:00:04 in-target: Get:3 http://deb.debian.org/debian-ports >> sid/main sparc64 grub-ieee1275 sparc64 2.04-11 [542 kB] >> Jan 4 19:00:05 in-target: Fetched 1261 kB in 4s (316 kB/s) >> Jan 4 19:00:05 in-target: E >> Jan 4 19:00:05 in-target: : >> Jan 4 19:00:05 in-target: Failed to fetch >> http://deb.debian.org/debian-ports/pool-sparc64/main/g/grub2/grub-ieee1275-bin_2.04-11_sparc64.deb >> 503 Backend unavailable, connection timeout [IP: 2a04:4e42:58::644 80] >> Jan 4 19:00:05 in-target: >> Jan 4 19:00:05 in-target: E >> Jan 4 19:00:05 in-target: : >> Jan 4 19:00:05 in-target: Unable to fetch some archives, maybe run >> apt-get update or try with --fix-missing? >> Jan 4 19:00:05 in-target: >> Jan 4 19:00:05 grub-installer: info: Calling 'apt-install >> grub-ieee1275' failed > > I have no clue which image you used and I'm not sure what you did to end up > in a situation > where the installer would try to download the grub2 packages over the net > which are actually > on the installation ISO, so they don't have to be downloaded. > > I also just verified that by installing the latest sparc64 ISO inside an LDOM > in offline mode > and grub2 was installed without any issues with no package mirror being set > up. I am doing a re-install with the "default" installer and I choose the most trivial config options. Which is to say the partition options were whatever seems most trivial. Full disk. New partition table. Everything in one partition. The default seems to be 512MB ext2 bootable /boot and then a large slice and 1G of swap. Eventually I see a big red box : [!!] Configure the package manager apt configuration problem An attempt to configure apt to install additional packages from the media failed. Here I select "continue" and things seem to move along. Then, after a little while everything seems to just work neatly. I guess there is something oddball in the expert level menu option but we don't really test for that. OKay, this works in the easy mode option. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Bug#979757: scummvm: Please disable Ultima on the remaining big-endian targets as well
Source: scummvm Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc ppc64 X-Debbugs-Cc: debian-al...@lists.debian.org,debian-powe...@lists.debian.org,,debian-h...@lists.debian.org,,debian-...@lists.debian.org,debian-sparc@lists.debian.org,debian-ri...@lists.debian.org,debian-i...@lists.debian.org Hi! The fix for #975492 [1] unfortunately covered a few of the big-endian targets we have in Debian only, namely s390x, which is why src:scummvm is still failing to build from source on alpha, hppa, powerpc, ppc64, riscv64 and sparc64 [2]. It would FTBFS on m68k and sh4 as well but the buildds currently don't run the testsuites there on these targets as these buildds are QEMU-based. Could you disable Ultima on the following targets as well? - alpha - hppa - ia64 - m68k - powerpc - ppc64 - riscv64 - sh4 - sparc64 Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975492 > [2] https://buildd.debian.org/status/package.php?p=scummvm=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
