Re: Debian Installation on Ultra 30 (was Re: Updated Debian Ports installation images 2021-09-23)
Hi Adrian,
On 9/27/21 2:42 AM, John Paul Adrian Glaubitz wrote:
> Hello!
>
> On 9/26/21 07:34, Stan Johnson wrote:
>> Not knowing what the preferred size should be for a GRUB /boot
>> partition, I decided to let Guided Partioning use its defaults for
>> /dev/sda. As I recall, the partitioner warned that the number of
>> cylinders on the disk exceeded the maximum of 65536, but the creation of
>> filesystems and the rest of the installation proceeded anyway, without
>> any other noticeable errors.
>>
>> The layout for /dev/sda is as follows:
>>
>> # fdisk -l /dev/sda
>> 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
>>
>> -> Question 1: If I don't plan to install Solaris, is it safe to remove
>> the "Whole disk" partition (/dev/sda3)?
> I think so.
Yes, I've confirmed this in testing.
>
>> -> Question 2: What is the best size for /boot (/dev/sda1)? After
>> installation, the /boot partition had only about 57 MB of files.
> It should be at least 150 MB as you can easily run out of disk space
> there when multiple kernels are installed. You can also live with 100 MB
> or less, but then you always need to make sure to purge old kernels
> before installing a new one.
>
> I have often run into the situation that I ran out of disk space when
> /boot was small, so we eventually decided to raise the minimum size
> for automatic partitioning.
Thanks. I've also confirmed that the Boot partition doesn't have to be
mounted as /boot (see my reply to Hermann Lauer). But it can be, and in
that case, it would need to be large enough to hold all of the kernels
that may be needed.
>
>> After installation, at every boot, I see this:
>> -----
>> GRUB Loading kernel....
>> Welcome to GRUB!
>>
>> error: out of memory.
>> error: no suitable video mode found.
>> error: no video mode activated.
>> -----
> There are some limitations with GRUB on older machines, unfortunately.
So is the "out of memory" error above not a problem? The video errors
are probably related to the video mode needed by my monitor not being
recognized by GRUB -- not really a GRUB bug, but it would be nice to be
able to specify a video mode in GRUB (there probably is a way to do that).
>
>> Then the GRUB menu is displayed, and I am able to scroll through the
>> options using the "v" and "^" keys (but not the up and down arrow keys).
> I think that applies to all systems which basically use a (virtual) serial
> console where arrow keys aren't necessarily available.
>
>> After selecting the new Debian SID (or allowing it to be selected by
>> default), the X login eventually comes up, but it seems to be off the
>> screen. If I login anyway, the Xfce desktop comes up, but it seems to be
>> larger than the screen. This problem, which is similar to a problem I
>> had with Debian 7.8, can probably be fixed with an appropriate xorg.conf
>> file.
>> But UUID=052feb55-ef72-4a8a-8f6d-2d63390e76ff doesn't exist.
>>
>> So this line:
>>
>> linux /boot/vmlinux-5.14.0-1-sparc64
>> root=UUID=052feb55-ef72-4a8a-8f6d-2d63390e76ff ro quiet
>>
>> should be:
>>
>> linux /boot/vmlinux-5.14.0-1-sparc64
>> root=UUID=1ca6137b-dcb8-4e76-b3c5-794d453723ca ro quiet
>>
>> as shown by blkid:
>>
>> # blkid /dev/sdb1
>> /dev/sdb1: UUID="1ca6137b-dcb8-4e76-b3c5-794d453723ca" BLOCK_SIZE="4096"
>> TYPE="ext3" PTTYPE="sun"
>>
>> After making that change, I'm able to boot into my backup Debian SID
>> installation.
> Might be an issue with os-prober that is part of GRUB.
I don't have the expertise to know what needs to be fixed, but there
does appear to be a bug somewhere. And for me, that bug means GRUB is
not ready for use on Sparc systems with multiple operating systems. Of
course, YMMV and you should use whatever works for you.
>
>> So my choices at this point are to return to SILO or follow through with
>> a bug report for GRUB (I would need help submitting upstream bug reports
>> for GRUB).
> Bear in mind that SILO is basically dead upstream and might have issue with
> certain filesystems used for /boot.
I don't think I care. Old Sparc workstations are also dead, but they
continue to work, after manual intervention at every boot to account for
the bad design of having a now-dead battery embedded in the NVRAM chip.
SILO, once installed in the boot block of the Boot ext2 partition,
should continue working.
I would prefer to use GRUB, but GRUB doesn't appear to work well with
multiple operating systems. I don't want to have to edit grub.cfg every
time grub is updated just to fix the bogus UUID entries. That said, I'll
be happy to work with anytone to help debug the GRUB problems, now that
I know how to go back to using SILO at any time.
>
>> -> Question 3: If I return to SILO, is there anything special about
>> /dev/sda1 other than it needing to be ext2? For example, are there any
>> special flags or other attributes needed for that partition? Is
>> /dev/sda1 also ext2 when using GRUB or can it be ext3 or ext4?
> The point with /boot being small and using an older, simpler filesystem is
> because the bootloader accesses the kernel and initrd files using blocklists,
> i.e. by ignoring the actual filesystem.
>
> If you have a filesystem with a complicated on-disk format, both GRUB and
> SILO might have trouble finding the blocks of kernel and initrd and loading
> them.
>
> So, for the sake of compatibility, I recommend not using anything newer than
> ext3 for /boot.
>
> Adrian
>
Please explain. I don't see any evidence that SILO is using blocklists.
Are you referring to the SILO code itself that is installed in the
1024-byte boot block of the ext2 filesystem on the Boot partition? I've
confirmed that the Boot partition doesn't need to be mounted as /boot,
and it doesn't have to include any kernels or initrd files. And I'm able
to edit silo.conf without re-installing silo. Will SILO stop working if
the ext2 Boot partition becomes fragmented? Would SILO stop working if
I re-created the ext2 filesystem on the Boot partition and restored it
from a backup (asked another way, do I need to use something like dd to
back up the Boot partition to make sure I back up all of the blocks)?
I don't know enough about GRUB to know how it works, but the GRUB code
itself appears to also be installed in the boot block of the Boot partition.
-Stan
Reply to: