Re: Updated Debian Ports installation images 2021-09-23
> Finally got a chance to test this more thoroughly. It turns out that > the install is failing because of my odd install method (dump the > install image on the disk, boot on it, overwrite the install media > with the install). > That is the only method I have seen work with older sparc netra gear. I just tested the SPARC64 install image and it works wonderfully. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Updated Debian Ports installation images 2021-09-23
> An update on this. > For interest sake I tried an install of Ubuntu 8.04 Sparc. > That gets far further than either of the Debian installs. This would be comparable to Debian etch or lenny. I remember having had a very stable experience with etch on my Ultra 10 back in the day, although this was still with the 32-bit userland. A lot of things have changes since then, and bit rot has taken hold in some places. There's still a lot to do bring things up to speed, but I think it's still remarkable how much is already working at this point. The port is by no means ready for General Consumption™️, though.
Re: Re: Debian Installation on Ultra 30 (was Re: Updated Debian Ports installation images 2021-09-23)
Hello Stan, On Mon, Sep 27, 2021 at 08:33:54AM -0600, Stan Johnson wrote: > Having the above partitioning scheme seems to work ok with GRUB; the > reason I asked about the "Whole disk" partition is that some > partitioning tools (specifically fdisk, as I recall), refuse to create > additional partitions once "Whole disk" has claimed all of the sectors. Oh ok, couldn't remember how that was - our Sparks are in Storage since a few years now. > In addition, there is an oddity (I think with parted, but I don't recall > now) where the "Whole disk" partition needed to exist, otherwise the > partitioner only recognized 1 GB. Perhaps this is related to parted > complaining during installation that the number of cylinders on the disk > exceeded the maximum of 65536 cylinders? Maybe parted is reading the > disk geometry from the third partition on the disk regardless of what's > there? No idea. > So I ended up using this partitioning scheme; note that parted complains > (but fdisk does not): > > # parted /dev/sda > GNU Parted 3.4 > Using /dev/sda > Welcome to GNU Parted! Type 'help' to view a list of commands. > (parted) print > Warning: The disk CHS geometry (562253,255,2) reported by the operating > system does not match the geometry stored on the disk label > (17849,255,63). > Ignore/Cancel? C > Model: SEAGATE ST3146807LC (scsi) > Disk /dev/sda: 147GB > Sector size (logical/physical): 512B/512B > Partition Table: unknown > Disk Flags: > (parted) quit Looks to me that parted did not recognize sun disklabel format. > # fdisk -l /dev/sda > Disk /dev/sda: 136.73 GiB, 146815737856 bytes, 286749488 sectors > Disk model: ST3146807LC > Geometry: 255 heads, 63 sectors/track, 17849 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 1048575 1048576 512M 1 Boot > /dev/sda2 1060290 17837505 16777216 8G 83 Linux native > /dev/sda3 17848215 34625430 16777216 8G 83 Linux native > /dev/sda4 34636140 68190571 33554432 16G 83 Linux native > /dev/sda5 68195925 70293076 2097152 1G 82 Linux swap u > /dev/sda6 70300440 286744184 216443745 103.2G 83 Linux native The speciality of sun disklabel format is that sda1 contains the boot block (block 0) of the HD. I somehow misused that in the past to mirror the boot block in raid1 configurations of sda1. YMMV. > It appears that SILO and GRUB do something similar -- they appear to be > installed in the 1024-byte "boot block" of an ext2 filesystem; for more > information, see this link for ext2 filesystem structure: > > http://www.science.smith.edu/~nhowe/teaching/csc262/oldlabs/ext2.html Yep, the filesystem needs to leave space for that boot block on (old) sparc machines on sda1 starting at sector 0. I wonder if there is an historic explanation for that somehow wicked setup on spark machines: Originally booting from a tape? Greetings Hermann
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/sda21000110 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
Re: Debian Installation on Ultra 30 (was Re: Updated Debian Ports installation images 2021-09-23)
Hi Hermann, On 9/27/21 1:56 AM, hermann.la...@uni-heidelberg.de wrote: > Hi Stan, > > On Sat, Sep 25, 2021 at 11:34:59PM -0600, 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/sda21000110 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 > this is a sun disk partitioning scheme - not shure, if this is well supported > with grub. Having the above partitioning scheme seems to work ok with GRUB; the reason I asked about the "Whole disk" partition is that some partitioning tools (specifically fdisk, as I recall), refuse to create additional partitions once "Whole disk" has claimed all of the sectors. In addition, there is an oddity (I think with parted, but I don't recall now) where the "Whole disk" partition needed to exist, otherwise the partitioner only recognized 1 GB. Perhaps this is related to parted complaining during installation that the number of cylinders on the disk exceeded the maximum of 65536 cylinders? Maybe parted is reading the disk geometry from the third partition on the disk regardless of what's there? So I ended up using this partitioning scheme; note that parted complains (but fdisk does not): # parted /dev/sda GNU Parted 3.4 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Warning: The disk CHS geometry (562253,255,2) reported by the operating system does not match the geometry stored on the disk label (17849,255,63). Ignore/Cancel? C Model: SEAGATE ST3146807LC (scsi) Disk /dev/sda: 147GB Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags: (parted) quit # fdisk -l /dev/sda Disk /dev/sda: 136.73 GiB, 146815737856 bytes, 286749488 sectors Disk model: ST3146807LC Geometry: 255 heads, 63 sectors/track, 17849 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 1048575 1048576 512M 1 Boot /dev/sda2 1060290 17837505 16777216 8G 83 Linux native /dev/sda3 17848215 34625430 16777216 8G 83 Linux native /dev/sda4 34636140 68190571 33554432 16G 83 Linux native /dev/sda5 68195925 70293076 2097152 1G 82 Linux swap u /dev/sda6 70300440 286744184 216443745 103.2G 83 Linux native > >> -> Question 1: If I don't plan to install Solaris, is it safe to remove >> the "Whole disk" partition (/dev/sda3)? > AFAIR sun disklabels allows up to 8 entries - so there is no advantage in > removing the solaris standard whole disk entry. > >> -> Question 2: What is the best size for /boot (/dev/sda1)? After >> installation, the /boot partition had only about 57 MB of files. > What's on this partition? Only Grub files or also the kernel stuff? > AFAIR I used around 100-200MB years ago, but this was with SILO. My experience is mostly with m68k and powerpc Macs, so please excuse my lack of Sun Sparc knowledge. I recall from many years ago that there is a "bootblk" on Sparc systems. I learned this after finally reading the manual when a full restore of Solaris on a new disk failed to boot because the bootblk was missing. It appears that SILO and GRUB do something similar -- they appear to be installed in the 1024-byte "boot block" of an ext2 filesystem; for more information, see this link for ext2 filesystem structure: http://www.science.smith.edu/~nhowe/teaching/csc262/oldlabs/ext2.html At appears that at least SILO wants the "Boot" partition to be ext2. These are the only files that I have in my "Boot" partition: # ls -l total 172 lrwxrwxrwx 1 root root 1 Oct 22 2020 boot -> . lrwxrwxrwx 1 root root 1 Oct 22 2020 etc -> . -rw-r--r-- 1 root root 1024 Aug 19 2012 fd.b -rw-r--r-- 1 root root 512 Aug 19 2012 first.b -rw-r--r-- 1 root root 1024 Aug 19
Re: Debian Installation on Ultra 30 (was Re: Updated Debian Ports installation images 2021-09-23)
On 9/27/21 03:56, hermann.la...@uni-heidelberg.de wrote: > Hi Stan, > > On Sat, Sep 25, 2021 at 11:34:59PM -0600, 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/sda21000110 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 > > this is a sun disk partitioning scheme - not shure, if this is well supported > with grub. > >> -> Question 1: If I don't plan to install Solaris, is it safe to remove >> the "Whole disk" partition (/dev/sda3)? > > AFAIR sun disklabels allows up to 8 entries - so there is no advantage in > removing the solaris standard whole disk entry. > I have had no issues with GRUB and Sun type disk labels and "vtoc" data. Also there are four bits used to count the disk "slices" but it depends on if one is on Sparc or x86 to get all four bits. So really one may have 16 separate entries in the disk vtoc but it won't be portable across architectures. I don't even know if that was ever documented. I have not even tried that for a few decades. I am quite sure that one may have eight disk regions without issue and they may overlap one another. That results in the old "backup" slice. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: Debian Installation on Ultra 30 (was Re: Updated Debian Ports installation images 2021-09-23)
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/sda21000110 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. > -> 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. > 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. > 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. > 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. > -> 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 -- .''`. 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: Debian Installation on Ultra 30 (was Re: Updated Debian Ports installation images 2021-09-23)
Hello Hermann! On 9/27/21 09:56, hermann.la...@uni-heidelberg.de wrote: >> 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/sda21000110 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 > > this is a sun disk partitioning scheme - not shure, if this is well supported > with grub. Yes, it's supported by both debian-installer and GRUB. However, you must use a separate /boot partition or make sure that the root partition isn't too big as GRUB uses blocklists on systems with Sun partition tables. >> -> Question 2: What is the best size for /boot (/dev/sda1)? After >> installation, the /boot partition had only about 57 MB of files. > > What's on this partition? Only Grub files or also the kernel stuff? > AFAIR I used around 100-200MB years ago, but this was with SILO. Since the kernel package installs into /boot, the partition should be at least 150-250 MB. I'm surprised that the installer would make it so small as partman-auto has a minimum size for /boot configured. 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: Debian Installation on Ultra 30 (was Re: Updated Debian Ports installation images 2021-09-23)
Hi Stan, On Sat, Sep 25, 2021 at 11:34:59PM -0600, 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/sda21000110 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 this is a sun disk partitioning scheme - not shure, if this is well supported with grub. > -> Question 1: If I don't plan to install Solaris, is it safe to remove > the "Whole disk" partition (/dev/sda3)? AFAIR sun disklabels allows up to 8 entries - so there is no advantage in removing the solaris standard whole disk entry. > -> Question 2: What is the best size for /boot (/dev/sda1)? After > installation, the /boot partition had only about 57 MB of files. What's on this partition? Only Grub files or also the kernel stuff? AFAIR I used around 100-200MB years ago, but this was with SILO. > > 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). > 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. Congrats, sounds good! Good luck, greetings Hermann
RE: Updated Debian Ports installation images 2021-09-23
An update on this. For interest sake I tried an install of Ubuntu 8.04 Sparc. That gets far further than either of the Debian installs. 1. No CPU lockup messages. 2. NIC's auto-negotiate fine which didn't happen for both Debian installs. The Ubuntu install still failed but failed with a SILO install error. So it really got most of the way there compared to the other two Debian attempts. Regards Brian -Original Message- From: Brian Noonan Sent: Saturday, 25 September 2021 12:23 PM To: debian-sparc@lists.debian.org Subject: RE: Updated Debian Ports installation images 2021-09-23 Good morning Adrian! (Well, it is morning here - lol!) I tried that earlier iso - thank you. Unfortunately, I get the same error. Just much later in the installation process. This time the CPU lockup appeared when trying to download from a mirror. It seems each incidence of the lockup happens when trying to use the NIC's. I'm going to see if there is a firmware update for the machine and go from there. Thank you for your efforts. I was using Aurora Linux on a Sparc 5/170 many years ago and then had a cross compile of the Linux Vax project setup on an Alphaserver 3305 running Red Hat (Whitebox AS800) so it is something I want to get going again for sure. Unfortunately, most of my Vax, Sparc's and Alpha's are still in storage on the other side of the world from my current location. Regards Brian -Original Message- From: John Paul Adrian Glaubitz Sent: Friday, 24 September 2021 10:12 PM To: Brian Noonan Cc: debian-sparc@lists.debian.org Subject: Re: Updated Debian Ports installation images 2021-09-23 Hello Brian! On 9/24/21 13:24, Brian Noonan wrote: > However, I get an error. > watchdog: BUG: soft lockup - CPU#0 stuck for 22s! > The error happens at different points in the install. First time was > when it tried to configure the NIC's by DHCP and the second was when > it tried to communicate to an NTP server. Some of the older SPARC machines have trouble with newer kernels, so I you can try using an older image which uses a 4.x kernel. See: https://cdimage.debian.org/cdimage/ports/snapshots/2019-07-16/ 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: Updated Debian Ports installation images 2021-09-23
Good morning Adrian! (Well, it is morning here - lol!) I tried that earlier iso - thank you. Unfortunately, I get the same error. Just much later in the installation process. This time the CPU lockup appeared when trying to download from a mirror. It seems each incidence of the lockup happens when trying to use the NIC's. I'm going to see if there is a firmware update for the machine and go from there. Thank you for your efforts. I was using Aurora Linux on a Sparc 5/170 many years ago and then had a cross compile of the Linux Vax project setup on an Alphaserver 3305 running Red Hat (Whitebox AS800) so it is something I want to get going again for sure. Unfortunately, most of my Vax, Sparc's and Alpha's are still in storage on the other side of the world from my current location. Regards Brian -Original Message- From: John Paul Adrian Glaubitz Sent: Friday, 24 September 2021 10:12 PM To: Brian Noonan Cc: debian-sparc@lists.debian.org Subject: Re: Updated Debian Ports installation images 2021-09-23 Hello Brian! On 9/24/21 13:24, Brian Noonan wrote: > However, I get an error. > watchdog: BUG: soft lockup - CPU#0 stuck for 22s! > The error happens at different points in the install. First time was > when it tried to configure the NIC's by DHCP and the second was when > it tried to communicate to an NTP server. Some of the older SPARC machines have trouble with newer kernels, so I you can try using an older image which uses a 4.x kernel. See: https://cdimage.debian.org/cdimage/ports/snapshots/2019-07-16/ 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: Updated Debian Ports installation images 2021-09-23
Hello Brian! On 9/24/21 13:24, Brian Noonan wrote: > However, I get an error. > watchdog: BUG: soft lockup - CPU#0 stuck for 22s! > The error happens at different points in the install. First time was > when it tried to configure the NIC's by DHCP and the second was when > it tried to communicate to an NTP server. Some of the older SPARC machines have trouble with newer kernels, so I you can try using an older image which uses a 4.x kernel. See: https://cdimage.debian.org/cdimage/ports/snapshots/2019-07-16/ 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: Updated Debian Ports installation images 2021-09-23
Hi Adrian, I booted the latest iso on a Sun V120 with 2.5GB RAM. However, I get an error. watchdog: BUG: soft lockup - CPU#0 stuck for 22s! The error happens at different points in the install. First time was when it tried to configure the NIC's by DHCP and the second was when it tried to communicate to an NTP server. This machine will run both Solaris 10 and OpenBSD perfectly fine. I ran a few test compiles under OpenBSD without issue. Regards Brian -Original Message- From: John Paul Adrian Glaubitz Sent: Thursday, 23 September 2021 7:26 PM To: debian-sparc Subject: Updated Debian Ports installation images 2021-09-23 Hi! I have just built and uploaded updated Debian Ports installation images. These images contain an updated apt-setup package which fixes the APT problem that occurred during installation with the 2021-09-21 images. I have performed a successful test installation on sparc64 and will perform a test on ia64 on my RX2660 later as well. I will provide more images updates in the following days which will contain more fixes such as for the hd-media installation as well as improvements on Apple PowerMac. The images can be obtained from [1]. Thanks, Adrian > [1] https://cdimage.debian.org/cdimage/ports/snapshots/2021-09-23/ -- .''`. 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: Updated Debian Ports installation images 2021-09-23
Hi! On 9/23/21 22:48, Connor McLaughlan wrote: > as for ia64 the news tell there is no kernel maintainer anymore and the > architecture is marked as orphaned, so removal might be coming soon. Architectures have been in the kernel without a maintainer before, so it's not really news. arch/sh was without a maintainer for some time but it eventually got new maintainers again. > But you would know first of course, as your name is mentioned in the same > news about it :) > > https://www.heise.de/news/Linux-5-11-Support-fuer-Intel-SGX-neue-Treiber-und-kleinere-Verbesserungen-5051869.html?seite=3 Funny, I didn't actually know that :D. Thanks for digging this up. > I was just thinking about trying to get one of those fancy ia64 > workstations for added fun... We have still a number of ia64 machines at SUSE that are being let go and which I am going to pick up. There are two SGI Prism, for example, very cool machines. 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: Updated Debian Ports installation images 2021-09-23
Hi Adrian, as for ia64 the news tell there is no kernel maintainer anymore and the architecture is marked as orphaned, so removal might be coming soon. But you would know first of course, as your name is mentioned in the same news about it :) https://www.heise.de/news/Linux-5-11-Support-fuer-Intel-SGX-neue-Treiber-und-kleinere-Verbesserungen-5051869.html?seite=3 I was just thinking about trying to get one of those fancy ia64 workstations for added fun... Regards, Connor On Thu, Sep 23, 2021 at 10:21 PM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hi Connor! > > On 9/23/21 22:16, Connor McLaughlan wrote: > > Unfortunately not all software in the repos and on snapshot are available > > or give a bus errors and won't work. > > For example all kde related stuff is not installable due to conflicts and > > missing packages. > > It is possible to fix these issues, but for that, we need bug reports. > > > I trained a whole year on NetBSD Sparc64 to get everything up and running > > and then transplanted this knowledge to use pkgsrc on debian sparc64. > > It also is by now way working out of the box and needs lots of manual > > intervention, but lets you compile a lot of software with the exception > of > > firefox52, thunderbird52, and an older seamonkey. These seem to be too > > optimised to run on NetBSD Sparc64. I'm stuck on bus errors for those > while > > they do run on NetBSD sparc64. > > Firefox on SPARC is actually maintained by Oracle. So, in principal we > should > be able to get it to work and I managed to get it to work in the past. > > > Debian sparc64 is an unofficial port and if i am not wrong, i think > Adrian > > is almost the only person maintaining it. > > Also sparc is heavy on the decline and no mainstream OS used for desktop > > work anymore. So a lot of the bugs are not reported and visible upstream. > > And debian is one of the last linux distributions even to have a port. > Once > > the kernel drops it (just happened to ia64), or Adrian stops supporting, > i > > gues it will all be gone and i am forced back to NetBSD. > > Not sure where you got the information that ia64 has been dropped from the > kernel sources, it hasn't. > > > For now I found my peace in combining debian and pkgsrc. This will lead > to > > a somehow complete desktop software collection. > > That's ok. But I think it would also help if people started reporting bugs > and help fix them. Bus errors in particular are not that difficult to fix. > > 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: Updated Debian Ports installation images 2021-09-23
Hi Connor! On 9/23/21 22:16, Connor McLaughlan wrote: > Unfortunately not all software in the repos and on snapshot are available > or give a bus errors and won't work. > For example all kde related stuff is not installable due to conflicts and > missing packages. It is possible to fix these issues, but for that, we need bug reports. > I trained a whole year on NetBSD Sparc64 to get everything up and running > and then transplanted this knowledge to use pkgsrc on debian sparc64. > It also is by now way working out of the box and needs lots of manual > intervention, but lets you compile a lot of software with the exception of > firefox52, thunderbird52, and an older seamonkey. These seem to be too > optimised to run on NetBSD Sparc64. I'm stuck on bus errors for those while > they do run on NetBSD sparc64. Firefox on SPARC is actually maintained by Oracle. So, in principal we should be able to get it to work and I managed to get it to work in the past. > Debian sparc64 is an unofficial port and if i am not wrong, i think Adrian > is almost the only person maintaining it. > Also sparc is heavy on the decline and no mainstream OS used for desktop > work anymore. So a lot of the bugs are not reported and visible upstream. > And debian is one of the last linux distributions even to have a port. Once > the kernel drops it (just happened to ia64), or Adrian stops supporting, i > gues it will all be gone and i am forced back to NetBSD. Not sure where you got the information that ia64 has been dropped from the kernel sources, it hasn't. > For now I found my peace in combining debian and pkgsrc. This will lead to > a somehow complete desktop software collection. That's ok. But I think it would also help if people started reporting bugs and help fix them. Bus errors in particular are not that difficult to fix. 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: Updated Debian Ports installation images 2021-09-23
@Iggi: You have several options which all require a lot of work. Do as Adrian tells and manually collect needed packages from snapshot.debian.org This way you can get for example an old firefox (50) and an old version of Libreoffice installed and working. Unfortunately not all software in the repos and on snapshot are available or give a bus errors and won't work. For example all kde related stuff is not installable due to conflicts and missing packages. If you go further and use for example the packaging system pkgsrc from NetBSD, you can get alot of stuff to compile, like almost the complete kde software and also a lot of stuff can be compiled that is then running without a bus error. But this is even more advanced, it will take a lot of time and there a lot of compile problems to track on the internet and work around as this is optimized for NetBSD. I trained a whole year on NetBSD Sparc64 to get everything up and running and then transplanted this knowledge to use pkgsrc on debian sparc64. It also is by now way working out of the box and needs lots of manual intervention, but lets you compile a lot of software with the exception of firefox52, thunderbird52, and an older seamonkey. These seem to be too optimised to run on NetBSD Sparc64. I'm stuck on bus errors for those while they do run on NetBSD sparc64. The reason why i want to use debian sparc64 instead of NetBSD is that on NetBSD there is a recent java, libreoffice, xrdp and more not available. Debian sparc64 is an unofficial port and if i am not wrong, i think Adrian is almost the only person maintaining it. Also sparc is heavy on the decline and no mainstream OS used for desktop work anymore. So a lot of the bugs are not reported and visible upstream. And debian is one of the last linux distributions even to have a port. Once the kernel drops it (just happened to ia64), or Adrian stops supporting, i gues it will all be gone and i am forced back to NetBSD. For now I found my peace in combining debian and pkgsrc. This will lead to a somehow complete desktop software collection. Regards, Connor On Thu, Sep 23, 2021 at 4:17 PM John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > Hello Iggi! > > On 9/23/21 15:46, James Bond wrote: > > ok, works till you select a "non default" option in "Select and Install > > software". I selected "Debian desktop environment" it fails. Well after > > finishing the installation manually I also tried mplayer etc and it looks > > like the binary files are not available to apt-get. > > It is not possible to provide any help if you're not providing any > feedback. > > You have most likely run into this issue: > > > https://lists.debian.org/debian-sparc/2017/12/msg00060.html > > > Debian could be such a nice and actual OS for our retro hardware if we > would > > just have a "decent" X driver for the most common graphics cards ffb and > > mach64/radeon. And it looks like not even someone getting paid wants to > do it > > (I would love to it but due to a lack of skills I can just be a sponsor). > > Paying a professional developer to work on such a driver would probably be > much > more expensive than some people throwing in some money. Software > development is > expensive and unless you find a hobbyist willing to work on the code, it > won't > be easy. > > But the Debian package for the sunffb driver will most likely be worked on > by Adrian > Bunk as he said he would be looking into it. However, that probably won't > happen > before the Debian SPARC porterbox has found a new home. > > You know, complaining about these issues is very easy but helping to get > them fixed > is much more difficult and just giving someone 50 Euros doesn't magically > fix all > these problems. > > If you want these issues to be fixed, please consider helping with the > work. The first > step to this will be providing useful feedback messages with detailed > error messages. > This way, I have a chance to see where the problems are and start working > on them. > > 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: Updated Debian Ports installation images 2021-09-23
Hello Iggi! On 9/23/21 15:46, James Bond wrote: > ok, works till you select a "non default" option in "Select and Install > software". I selected "Debian desktop environment" it fails. Well after > finishing the installation manually I also tried mplayer etc and it looks > like the binary files are not available to apt-get. It is not possible to provide any help if you're not providing any feedback. You have most likely run into this issue: > https://lists.debian.org/debian-sparc/2017/12/msg00060.html > Debian could be such a nice and actual OS for our retro hardware if we would > just have a "decent" X driver for the most common graphics cards ffb and > mach64/radeon. And it looks like not even someone getting paid wants to do it > (I would love to it but due to a lack of skills I can just be a sponsor). Paying a professional developer to work on such a driver would probably be much more expensive than some people throwing in some money. Software development is expensive and unless you find a hobbyist willing to work on the code, it won't be easy. But the Debian package for the sunffb driver will most likely be worked on by Adrian Bunk as he said he would be looking into it. However, that probably won't happen before the Debian SPARC porterbox has found a new home. You know, complaining about these issues is very easy but helping to get them fixed is much more difficult and just giving someone 50 Euros doesn't magically fix all these problems. If you want these issues to be fixed, please consider helping with the work. The first step to this will be providing useful feedback messages with detailed error messages. This way, I have a chance to see where the problems are and start working on them. 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: Updated Debian Ports installation images 2021-09-23
Hi Adrian, ok, works till you select a "non default" option in "Select and Install software". I selected "Debian desktop environment" it fails. Well after finishing the installation manually I also tried mplayer etc and it looks like the binary files are not available to apt-get. Debian could be such a nice and actual OS for our retro hardware if we would just have a "decent" X driver for the most common graphics cards ffb and mach64/radeon. And it looks like not even someone getting paid wants to do it (I would love to it but due to a lack of skills I can just be a sponsor). Cheers Iggi Am 23.09.21, 11:25 schrieb "John Paul Adrian Glaubitz" : Hi! I have just built and uploaded updated Debian Ports installation images. These images contain an updated apt-setup package which fixes the APT problem that occurred during installation with the 2021-09-21 images. I have performed a successful test installation on sparc64 and will perform a test on ia64 on my RX2660 later as well. I will provide more images updates in the following days which will contain more fixes such as for the hd-media installation as well as improvements on Apple PowerMac. The images can be obtained from [1]. Thanks, Adrian > [1] https://cdimage.debian.org/cdimage/ports/snapshots/2021-09-23/ -- .''`. 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: Updated Debian Ports installation images 2021-09-23
Hi Adrian, thanks a lot will instantly give it a try on the Ultra 10. Cheers Iggi Am 23.09.21, 11:25 schrieb "John Paul Adrian Glaubitz" : Hi! I have just built and uploaded updated Debian Ports installation images. These images contain an updated apt-setup package which fixes the APT problem that occurred during installation with the 2021-09-21 images. I have performed a successful test installation on sparc64 and will perform a test on ia64 on my RX2660 later as well. I will provide more images updates in the following days which will contain more fixes such as for the hd-media installation as well as improvements on Apple PowerMac. The images can be obtained from [1]. Thanks, Adrian > [1] https://cdimage.debian.org/cdimage/ports/snapshots/2021-09-23/ -- .''`. 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
