[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

GRUB on sparc64 (was Re: nasty bug in /usr/sbin/grub-probe)



Hello,

Based on my tests, I plan to continue using SILO on my Ultra 30 sparc64
system. I will be happy to test future versions of GRUB as they become
available (I have a blank disk set aside just for that).

My justifications for continuing to use SILO include the following:

1) I've heard that SILO doesn't support ext4; however, I only plan to
use ext3.

2) SILO allows the Sun Boot partition to be hidden. Once SILO has been
installed, the Sun Boot partition doesn't need to be mounted (though it
can be mounted if necessary to make minor changes to the silo.conf
file). IMO, mounting the ext2 Sun Boot partition as /boot is somewhat
risky, since the system can become unbootable if a mistake is made.

3) I use multiple GNU/Linux distributions. After setting
"GRUB_DISABLE_OS_PROBER=false" in /etc/default/grub, I was not able to
get GRUB to properly detect multiple installations. Perhaps GRUB wants
to see all of the kernel and initrd files in the Sun Boot partition, but
in my Gentoo installation, I have the kernel and initrd in /boot (a
local directory in /). The error message while booting Gentoo was
something to the effect that I must load a kernel first. I'm sure I
could make this work eventually, perhaps by putting all of my kernel and
initrd files in the Sun Boot partition, but I don't want to do that.

4) GRUB displays an out-of-memory error when the system boots, though
this error doesn't seem to affect anything (other than my confidence in
GRUB).

5) With SILO, I can use symbolic links to point to the specific kernel
and initrd that I want to boot for each distribution. I know I can
manually edit the grub.cfg file to do something similar with GRUB, but
by default that's not how GRUB works (and the system updates grub.cfg
without asking for my permission during "apt-get dist-upgrade" whenever
there's a new kernel). I don't want or need GRUB to keep a running list
of all the kernels and initrd files on my system. For example, the
following silo.conf file can be used to boot Debian 7, Debian SID, or
Gentoo (and I plan to add Void eventually). For Debian SID and Gentoo,
/boot/vmlinuz and /boot/initrd.img are symbolic links in each local
/boot directory to the kernel and initrd that I want to use at any given
time:

-----
default=Debian_sid
read-only
timeout=100

image=/boot/vmlinuz-3.2.0-4-sparc64
   partition=4
   root=/dev/sda4
   label=Debian_7
   initrd=/boot/initrd.img-3.2.0-4-sparc64

image=/boot/vmlinuz
   partition=5
   root=/dev/sda5
   label=Debian_sid
   initrd=/boot/initrd.img

image=/boot/vmlinuz
   partition=6
   root=/dev/sda6
   label=Gentoo
   initrd=/boot/initrd.img
-----

On a separate note, please consider adding dump/restore to the
installation CD so users can use CD rescue mode to restore filesystems
that were previously backed-up using dump. And an ftp client and
net-tools would be nice too, for those old-timers amongst us who still
use ifconfig and route.

Thanks to everyone who keeps Debian SID running on old sparc64 hardware!

-Stan

On 4/3/22 9:28 PM, Stan Johnson wrote:
> On 4/3/22 11:04 AM, John Paul Adrian Glaubitz wrote:
>> Hi Stan!
>>
>> On 4/3/22 16:39, Stan Johnson wrote:
>>> If this problem is expected to occur on an Ultra 5 or an Ultra 30,
>>> please let me know and I'll be happy to help with a git bisect, using a
>>> spare 9 GB disk for the installation.
>>
>> I think you should see the issue on both the Ultra 5 and Ultra 30.
>> ...
> 
> I wasn't able to get my Ultra 5 working; the video signal kept cycling
> on and off for some reason, and the CD drive wasn't seen, though it was
> seen well enough to boot the installation and get to the point where it
> said no CD drive was found.
> 
> But I was able to confirm that the "grub-probe" bug doesn't seem to
> affect the Ultra 30.
> 
> On the Ultra 30, the 28 Mar 2022 sparc64 CD booted, and a default
> installation, with guided entire-disk partitioning, worked. GRUB also
> works, including update-grub and grub-probe.
> 
> Disk layout:
> 
> # fdisk -l
> Disk /dev/sda: 136.73 GiB, 146815737856 bytes, 286749488 sectors
> Disk model: ST3146807LC
> Geometry: 255 heads, 2 sectors/track, 37965 cylinders
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: sun
> 
> Device         Start       End   Sectors   Size Id Type         Flags
> /dev/sda1          0   1000109   1000110 488.3M  1 Boot
> /dev/sda2    1000110 284748299 283748190 135.3G 83 Linux native
> /dev/sda3          0 286749029 286749030 136.7G  5 Whole disk
> /dev/sda4  284748300 286749029   2000730 976.9M 82 Linux swap
> 
> After setting "GRUB_DISABLE_OS_PROBER=false" in /etc/default/grub,
> update-grub also works as expected:
> 
> # update-grub
> Generating grub configuration file ...
> Found background image: /usr/share/images/desktop-base/desktop-grub.png
> Found linux image: /boot/vmlinux-5.16.0-6-sparc64
> Found initrd image: /boot/initrd.img-5.16.0-6-sparc64
> Found linux image: /boot/vmlinux-5.16.0-5-sparc64
> Found initrd image: /boot/initrd.img-5.16.0-5-sparc64
> Warning: os-prober will be executed to detect other bootable partitions.
> Its output will be used to detect bootable binaries on them and create
> new boot entries.
> done
> 
> # df
> Filesystem     1K-blocks    Used Available Use% Mounted on
> udev              749800       0    749800   0% /dev
> tmpfs             153120     912    152208   1% /run
> /dev/sda2      138536344 2884840 128541416   3% /
> tmpfs             765592       0    765592   0% /dev/shm
> tmpfs               5120       8      5112   1% /run/lock
> /dev/sda1         466027   98003    343039  23% /boot
> tmpfs             153112      72    153040   1% /run/user/111
> tmpfs             153112      64    153048   1% /run/user/1000
> 
> Here, grub-probe doesn't crash, but I may not be using the right
> arguments to trigger the crash:
> 
> # grub-probe /boot
> ext2
> # grub-probe -d /dev/sda1
> ext2
> # grub-probe -d /dev/sda2
> ext2
> 
> Note: /dev/sda2 is actually ext4.
> 
> -----
> 
> There were a few oddities, but only #6 is serious (apparently a libc
> bug, not a kernel bug).
> 
> 1) I see that /dev/sda1 is mounted as /boot, not /boot/grub. So all the
> kernels will end up in /dev/sda1. I haven't tested how (or whether) that
> will affect kernels for other operating systems (e.g. Gentoo).
> 
> 2) Please confirm that grub-install never needs to be run. It appears
> not to be needed, since update-grub updates /boot/grub/grub.cfg directly.
> 
> 3) At system boot, when GRUB runs, it complains that it is out of
> memory, but it seems to work anyway.
> 
> 4) During installation, the disk partitioner said "The disk has 562253
> cylinders which is greater than the maximum of 65536.", but that error
> didn't seem to affect anything.
> 
> 5) Before the installation, I had two Seagate 146 GB ST3146807LC disks
> installed. I replaced those disks with one 300 GB ST3300007LC disk.
> Although all the disks are Ultra U320 drives, the 300 GB disk wasn't
> seen by the installation CD, though it is seen as Target 0 by
> "scsi-probe" in the Sun PROM. For the installation, I re-installed one
> of the 146 GB disks as Target 0. I'll check later to see whether the 300
> GB drive is seen by the installed system.
> 
> 6) In Xfce, a login at the console worked once, but it is now failing
> consistently (even after a reboot), with this error message in dmesg:
> 
> xfce4-session[3980]: segfault at 0 ip fffff8010263c9b4 (rpc
> fffff801020efbb8) sp 000007feff8dc451 error 1 in
> libc-2.33.so[fffff801025b0000+164000]
> 
> I'll be running memtester to rule out bad memory. AFAIK, Xfce is the
> only desktop (in Debian) that works with my choice of init (sysvinit),
> so I'll likely end up using a text-only system on the Ultra 30 for
> Debian SID; I can always boot Debian 7.8 or a different distribution if
> I need an X desktop.
> 
> -Stan
> 


Reply to: