Re: SMP kernel on sparc64 working
Hi Gregor, On 8/12/23 3:33 AM, Gregor Riepl wrote: > ... The V215 is very picky about RAM > (requires buffered DDR-333 modules with ECC). > I've attached logs from two kernel panics for reference. One happened at > boot time, the other after some heavy compilation and debugging. Both > aren't reproducible reliably, but they did happen a few times. > ... I've seen similar errors on other systems (mostly x86 and powerpc) that did turn out to be intermittent memory errors. Have you tried memtester? Even though it won't test all the memory, running memtester in single-user mode should test most of it. -Stan Johnson
Re: Debian SID kernel results in "Fast Data Access MMU Miss" on Sun Ultra 30
Update: Well, I was wrong about the size of the initrd.img file causing the "Fast Data Access MMU Miss" (it only happens with some kernels). This combination (the default Debian SID vmlinux and initrd.img) fails: # ls -l *6.4.0* -rw-r--r-- 1 root root 186222 Jul 29 22:50 config-6.4.0-1-sparc64 -rw-r--r-- 1 root root 23023550 Jul 31 07:05 initrd.img-6.4.0-1-sparc64 -rwxr-xr-x 1 root root 19082504 Jul 29 22:50 vmlinux-6.4.0-1-sparc64 This combination (based on Debian's config file) also fails: # ls -l config*6.4.7 initrd*6.4.7 vmlinux*6.4.7 -rw-r--r-- 1 root root 185601 Aug 3 09:13 config-6.4.7 -rw-r--r-- 1 root root 23139317 Aug 3 10:15 initrd.img-6.4.7 -rwxr-xr-x 1 root root 19114368 Aug 3 09:54 vmlinux-6.4.7 And this combination (built with gzipped modules) also fails: # ls -l config*6.4.7 initrd*6.4.7 vmlinux*6.4.7 -rw-r--r-- 1 root root 185639 Aug 3 10:21 config-6.4.7 -rw-r--r-- 1 root root 5804190 Aug 3 12:13 initrd.img-6.4.7 -rwxr-xr-x 1 root root 19114368 Aug 3 11:00 vmlinux-6.4.7 So I guess I'll need to try a bisect after all. -Stan - On 8/2/23 8:33 AM, Stan Johnson wrote: > Hello, > > On 7/31/23 1:06 PM, Stan Johnson wrote: >> ... "Fast Data Access MMU Miss" while loading the initrd > > After doing some more testing (and accidentally erasing my system disk > -- sda is the lower drive, not the upper one!), it's looking like the > "Fast Data Access MMU Miss" error is not caused by a kernel issue. I > think the default initrd has blown past some hard-coded memory limit in > SILO for loading the initrd (that's a guess). I'm able to get any kernel > to boot as long as I keep the initrd to less than around 20 MB. > > Note: Debian's vmlinux-6.4.0-1-sparc64 kernel can't be created using > Debian's config file config-6.4.0-1-sparc64. The config file has debug > options enabled that result in a 300 MB kernel and over 3 GB of modules. > > After re-installing SILO 1.4.14 by installing Debian 7.11 from CD, I > re-learned some interesting things about SILO. Like GRUB, it lives in an > ext2 filesystem (the Sun Boot partition), and it wants to be mounted as > /boot. So by default, SILO is very similar to GRUB. Both silo.conf and > grub.conf can be configured to be static, with no kernels in the Sun > Boot partition, and the Boot partition likely doesn't have to remain > mounted as /boot for GRUB to still work (though I'd probably have to > delete or disable grub-install to manage GRUB manually). > > To test the latest GRUB, I downloaded what I thought was the latest > Debian sparc64 snapshot from here: > https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-18/debian-12.0.0-sparc64-NETINST-1.iso > > The installation failed with an error regarding Perl -- I didn't save > anything yet because I wanted to make sure I'm using the correct image. > If it's the right image, I'll capture the log file and post it under a > different thread. > > One last question regarding Sun partitions: Is the following warning > while using parted important? > "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)." > Using fdisk, I don't see a similar error: > # fdisk -l > 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 > DeviceStart End Sectors Size Id Type Flags > /dev/sda1 0257039257040 125.5M 1 Boot > /dev/sda2257040 4257224 4000185 1.9G 82 Linux swap > /dev/sda3 0 286744184 286744185 136.7G 5 Whole disk > /dev/sda4 4257225 20257964 16000740 7.6G 83 Linux native > /dev/sda5 20257965 52259444 32001480 15.3G 83 Linux native > /dev/sda6 52259445 84260924 32001480 15.3G 83 Linux native > /dev/sda7 84260925 286744184 202483260 96.6G 83 Linux native > > -Stan >
Re: Debian SID kernel results in "Fast Data Access MMU Miss" on Sun Ultra 30
Hello, On 7/31/23 1:06 PM, Stan Johnson wrote: > ... "Fast Data Access MMU Miss" while loading the initrd After doing some more testing (and accidentally erasing my system disk -- sda is the lower drive, not the upper one!), it's looking like the "Fast Data Access MMU Miss" error is not caused by a kernel issue. I think the default initrd has blown past some hard-coded memory limit in SILO for loading the initrd (that's a guess). I'm able to get any kernel to boot as long as I keep the initrd to less than around 20 MB. Note: Debian's vmlinux-6.4.0-1-sparc64 kernel can't be created using Debian's config file config-6.4.0-1-sparc64. The config file has debug options enabled that result in a 300 MB kernel and over 3 GB of modules. After re-installing SILO 1.4.14 by installing Debian 7.11 from CD, I re-learned some interesting things about SILO. Like GRUB, it lives in an ext2 filesystem (the Sun Boot partition), and it wants to be mounted as /boot. So by default, SILO is very similar to GRUB. Both silo.conf and grub.conf can be configured to be static, with no kernels in the Sun Boot partition, and the Boot partition likely doesn't have to remain mounted as /boot for GRUB to still work (though I'd probably have to delete or disable grub-install to manage GRUB manually). To test the latest GRUB, I downloaded what I thought was the latest Debian sparc64 snapshot from here: https://cdimage.debian.org/cdimage/ports/snapshots/2023-06-18/debian-12.0.0-sparc64-NETINST-1.iso The installation failed with an error regarding Perl -- I didn't save anything yet because I wanted to make sure I'm using the correct image. If it's the right image, I'll capture the log file and post it under a different thread. One last question regarding Sun partitions: Is the following warning while using parted important? "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)." Using fdisk, I don't see a similar error: # fdisk -l 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 DeviceStart End Sectors Size Id Type Flags /dev/sda1 0257039257040 125.5M 1 Boot /dev/sda2257040 4257224 4000185 1.9G 82 Linux swap /dev/sda3 0 286744184 286744185 136.7G 5 Whole disk /dev/sda4 4257225 20257964 16000740 7.6G 83 Linux native /dev/sda5 20257965 52259444 32001480 15.3G 83 Linux native /dev/sda6 52259445 84260924 32001480 15.3G 83 Linux native /dev/sda7 84260925 286744184 202483260 96.6G 83 Linux native -Stan
Re: Debian SID kernel results in "Fast Data Access MMU Miss" on Sun Ultra 30
Hi Adrian, On 7/31/23 9:15 AM, John Paul Adrian Glaubitz wrote: > > >> On Jul 31, 2023, at 4:33 PM, Stan Johnson wrote: >> >> I don't think a kernel bisect will identify the issue, since the kernel >> boots ok. This has something to do with the initrd, and I don't know how >> to troubleshoot that. Any recommendations? > > It can still be a bug in the kernel, especially since we’re not seeing this > issue on the T5220 and the SPARC-T4. > > I bet if you rebuild the initrd for the older kernels, these will still boot > fine which would prove my theory. > ... Booting an older working kernel (vmlinux-5.16.0-6-sparc64), I rebuilt these initrd files: # mkinitramfs -o initrd.img-5.16.0-6-sparc64 5.16.0-6-sparc64 # mkinitramfs -o initrd.img-6.1.0-7-sparc64 6.1.0-7-sparc64 # mkinitramfs -o initrd.img-6.4.0-1-sparc64 6.4.0-1-sparc64 Then I tried booting the following combinations of kernels and initrd files, 1) vmlinux-5.16.0-6-sparc64, initrd.img-5.16.0-6-sparc64 -- pass 2) vmlinux-6.1.0-7-sparc64, initrd.img-6.1.0-7-sparc64 -- fail 3) vmlinux-6.4.0-1-sparc64, initrd.img-6.4.0-1-sparc64 -- fail Note: For these tests: fail -> "Fast Data Access MMU Miss" while loading the initrd pass -> normal boot to multiuser I rebuilt the above initrd files again while booted into my custom 6.2 kernel and tried booting the following combinations: 4) vmlinux-5.16.0-6-sparc64, initrd.img-5.16.0-6-sparc64 -- pass 5) vmlinux-6.1.0-7-sparc64, initrd.img-6.1.0-7-sparc64 -- fail 6) vmlinux-6.4.0-1-sparc64, initrd.img-6.4.0-1-sparc64 -- fail So that suggests the problem is not with mkinitramfs, since each initrd behaves the same regardless of the kernel that was booted while each initrd was built. Next, I tried this: 7) vmlinux-6.4.0-1-sparc64, initrd.img-5.16.0-6-sparc64 -- fail So I could try a kernel bisect next, but it would be a long process: a) Cross-compile stock kernels and modules using the latest Debian SID config file. b) Copy new kernels and modules to the Ultra 30; boot a known working kernel to build each corresponding initrd file. c) Try booting the new kernel/initrd; a "Fast Data Access MMU Miss" while loading the initrd is a failure; otherwise it passes. Alternately, I could use a spare disk and install a default Debian SID installation that includes GRUB. Perhaps there's a memory or some other issue with SILO (I'm using SILO 1.4.14). I won't be using GRUB on my Ultra-30 as long as the GRUB partition must remain mounted, since there's a risk of data corruption if the system crashes. SILO works more like yaboot in that it doesn't require its filesystem to remain mounted, so it will not be affected by a crash, and once configured, there's no need to update silo.conf, just the symbolic links to the kernel and initrd. But I'll be happy to do a clean-install test if anyone thinks that the "Fast Data Access MMU Miss" error might be related to SILO; otherwise, I'll try a kernel bisect. Let me know if there's a preference. -Stan
Re: Debian SID kernel results in "Fast Data Access MMU Miss" on Sun Ultra 30
Update:
Sorry it's taken me a while to start looking at this issue; my Ultra-30
was unavailable for about 5 days while it was updating Gentoo (I need to
configure a QEMU host for Sparc 64 to build and update my Debian and
Gentoo root filesystems).
Anyway, this morning I upgraded Debian SID again ("apt-get upgrade") and
noticed that it had updated the kernel and initrd. I made a mistake with
my symbolic link for the initrd, so it ended up booting without an
initrd, and the kernel boots fine (as expected, it fails to see the SCSI
disks). So the "Fast Data Access MMU Miss" error seems to be related
only to the initrd, which is consistent with my original message.
I don't think a kernel bisect will identify the issue, since the kernel
boots ok. This has something to do with the initrd, and I don't know how
to troubleshoot that. Any recommendations?
# ls -l vmlinuz initrd.img
lrwxrwxrwx 1 root root 26 Jul 31 08:07 initrd.img ->
initrd.img-6.4.0-1-sparc64
lrwxrwxrwx 1 root root 23 Jul 31 07:51 vmlinuz -> vmlinux-6.4.0-1-sparc64
# ls -l *6.4.0-1*
-rw-r--r-- 1 root root 83 Jul 29 22:50 System.map-6.4.0-1-sparc64
-rw-r--r-- 1 root root 186222 Jul 29 22:50 config-6.4.0-1-sparc64
-rw-r--r-- 1 root root 23023550 Jul 31 07:05 initrd.img-6.4.0-1-sparc64
-rwxr-xr-x 1 root root 19082504 Jul 29 22:50 vmlinux-6.4.0-1-sparc64
thanks
-Stan
-
On 7/24/23 11:28 PM, John Paul Adrian Glaubitz wrote:
> Hi Stan!
>
> On Mon, 2023-07-24 at 15:46 -0600, Stan Johnson wrote:
>> The latest Debian SID kernel (vmlinux-6.4.0-1-sparc64) fails on a Sun
>> Ultra 30 with the following error at the PROM:
>>
>> -
>> ...
>> Loaded kernel version 6.4.4
>> Loading initial ramdisk (23022746 bytes at 0x6400 phys, 0x40C0
>> virt)...
>> Fast Data Access MMU Miss
>> ok
>> -
>>
>> I have been running a custom 6.2.10 kernel, and that continues to work.
>> I'm not sure whether this is related to Joacim Nilsson's cgroup fail
>> error on his Sun Ultra 5, but the failure message is different. I'll
>> have to investigate whether this could be a kernel regression.
>
> Thanks for the report.
>
> If you could bisect this issue and report the commit to the original author
> who introduced it while CC'ing the SPARC LKML, that would be extremely
> helpful.
>
> I have some older SPARCs myself, but currently no space to set them up for
> testing.
>
> Adrian
>
Debian SID kernel results in "Fast Data Access MMU Miss" on Sun Ultra 30
Hello, The latest Debian SID kernel (vmlinux-6.4.0-1-sparc64) fails on a Sun Ultra 30 with the following error at the PROM: - ... Loaded kernel version 6.4.4 Loading initial ramdisk (23022746 bytes at 0x6400 phys, 0x40C0 virt)... Fast Data Access MMU Miss ok - I have been running a custom 6.2.10 kernel, and that continues to work. I'm not sure whether this is related to Joacim Nilsson's cgroup fail error on his Sun Ultra 5, but the failure message is different. I'll have to investigate whether this could be a kernel regression. The previous Debian SID kernel that I have is vmlinux-6.1.0-7-sparc64, and it also results in the "Fast Data Access MMU Miss" error. An earlier kernel (vmlinux-5.16.0-6-sparc64) works as expected: # uname -a Linux ultra-30 5.16.0-6-sparc64 #1 Debian 5.16.18-1 (2022-03-29) sparc64 GNU/Linux # cat /proc/cpuinfo cpu : TI UltraSparc II (BlackBird) fpu : UltraSparc II integrated FPU pmu : ultra12 prom: OBP 3.9.5 1997/04/11 10:03 type: sun4u ncpus probed: 1 ncpus active: 1 D$ parity tl1 : 0 I$ parity tl1 : 0 Cpu0ClkTck : 11a4783f cpucaps : flush,stbar,swap,muldiv,v9,mul32,div32,v8plus,vis MMU Type: Spitfire MMU PGSZs : 8K,64K,512K,4MB root@ultra-30:~# cat /proc/swaps FilenameTypeSize Used Priority /dev/sda2 partition 10522480-2 # fdisk -l 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 1060289 1060290 517.7M 1 Boot /dev/sda21060290 3164804 2104515 1G 82 Linux swap /dev/sda3 0 286744184 286744185 136.7G 5 Whole disk /dev/sda43164805 19936664 16771860 8G 83 Linux native /dev/sda5 19936665 53496449 3355978516G 83 Linux native /dev/sda6 53496450 87056234 3355978516G 83 Linux native /dev/sda7 87056235 103828094 16771860 8G 83 Linux native /dev/sda8 103828095 286744184 182916090 87.2G 83 Linux native -Stan
Re: Sun Ultra 5 cgroup fail after clean install
Hello, On 7/23/23 3:27 AM, Joacim Nilsson wrote: > ... >>> >>> Loading Linux 6.3.0-2-sparc64 ... >>> Loading initial ramdisk ... >>> >>> Failed to get cgroup, ignoring: No medium found >>> /dev/sda2: recovering journal >>> /dev/sda2: clean, 32037/15204352 files, 1785366/60804430 blocks >>> [ 49.359252] /dev/sda: Can't open blockdev >>> [FAILED] Failed to mount boot.mount - /boot. >>> [DEPEND] Dependency failed for local-fs.target - Local File Systems. >>> You are in emergency mode. After logging in, type "journalctl -xb" to view >>> system logs, "systemctl reboot" to reboot, or "exit"Give root password for >>> maintenance >>> (or press Control-D to continue): >>> >>> ... > > I used the installer suggested > > To get more information i booted the 6.1.0-9 kernel > That one works! > > 6.3.0-2 does not for me > > output from lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS > fd0 2:01 4K 0 disk > sda 8:00 232.9G 0 disk > ├─sda1 8:10 488.3M 0 part /boot > ├─sda2 8:20 232G 0 part / > ├─sda3 8:30 232.9G 0 part > └─sda4 8:40 469.4M 0 part [SWAP] > sr0 11:01 1024M 0 rom > > FWIW, I think the "Failed to get cgroup, ignoring: No medium found" isn't related to the error (I'm also seeing that, for the first time, with the latest Debian SID kernel on 686 systems but the systems boots normally; I haven't checked other systems). If this problem is also likely to happen on a Sun Ultra 30, let me know and I'll try a default installation and (if necessary) a kernel bisect sometime during the next week. It might be an issue with grub. The kernel boots and fsck of the root partition works, but "/dev/sda: Can't open blockdev" might indicate a missing module or incorrect kernel CONFIG option. That's just a guess. -Stan Johnson
Re: Debian SID on Ultra 30
Hi Dennis, On 3/29/23 11:12 AM, Dennis Clarke wrote: > On 3/28/23 18:50, Stan Johnson wrote: >> "Fast Data Access MMU Miss" Thanks for your message. > > Power down the machine to the firmware ok prompt. You should be able to > do that with : > > shutdown -Hh 'now' > > The capital " H " should just halt the linux os and leave you as the > prompt. > > Then do this : > > setenv diag-switch? true > setenv auto-boot? false > setenv verbosity max > > Then do printenv and check if the diagnostics verbosity is actually set > to maximum. On the old Ultra 30 it may be named something else. "diag-level" is set to "max" > > Then issue the golden "power-off". Unplug it from the AC power. This system has a failed battery (the battery that's embedded in the ID chip). So a hardware power-on always fails, but after entering a few initializing lines at the Forth "ok" prompt, followed by "set-defaults" and "reset-all", it boots normally. This Ultra 30 also has 1,536 MiB memory, but apparently the hardware power-on process only initializes 1,280 MiB, before reporting that the NVRAM contents are invalid. > Then power on the unit and watch all the diagnostics happen. > > I do not recall the specifics of the Ultra 30 but if you issue this to > the forth ok prompt : > > sifting post > > You will get a list of commands related to POST status. One of tham may > actually be post-results or post-status. Issue that command. > > If the result looks sane then "setenv diag-switch? false" and boot the > system as per normal. > ... Looking at the post results after a "reset-all", the only complaint is that a power-on self-test didn't run since "reset-all" (and that's probably the test we want). Do you know whether there's a separate memory test (similar to the scsi-probe test)? I don't think there's a memory issue with this system (I've run Linux memtest in the past with no errors, though the Linux test probably isn't as thorough as Sun's test). Other kernels boot without any problems, including Debian's vmlinux-5.16.0-6-sparc64 as well as a custom 6.2.8 that I'm using now. I haven't seen the "Fast Data Access MMU Miss" with any kernel other than Debian's vmlinux-6.1.0-7-sparc64. But since my system doesn't have a working battery, perhaps this would need to be duplicated by someone who has an Ultra 30 that still has a working battery. -Stan
Debian SID on Ultra 30
Hello, I updated an existing Debian SID installation today on a Sparcstation Ultra 30. Everything went as expected except for two issues: 1) During "apt-get dist-upgrade", the kernel was updated to vmlinux-6.1.0-7-sparc64, and the initramfs was created as expected. However, booting the new kernel failed. After the kernel and ramdisk are loaded, there is an error message: "Fast Data Access MMU Miss" and the Boot PROM returns to the "ok" prompt. I tried it a few times to confirm the error. So for now I'm back to using vmlinux-5.16.0-6-sparc64. I'm currently using SILO to load the initrd and kernel. 2) While running "apt autoremove" after the upgrade, I noticed that telnet, telnetd and git were going to be deleted. After rebooting, I was able to re-install telnet and telnetd but the installation of git failed: * # apt-get install git Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: git : Depends: git-man (< 1:2.39.1-.) but 1:2.40.0-1 is to be installed E: Unable to correct problems, you have held broken packages. * I could probably go back to an older version of git and git-man from Debian snapshots, but for now it's ok, since I don't use git very often on the Ultra 30, anyway. It's actually pretty amazing that everything works as well as it does. Thanks to everyone who works to keep Debian and Linux running on the old Sparcstations! -Stan Johnson
Re: Install debian sparc64 with a hdd/ssd as source
On 7/5/22 9:15 AM, Connor McLaughlan wrote: > Hello, > > is there a sparc64 debian installer image available somewhere that i > could write with dd to a hdd/ssd and boot from it? > > > Regards, > Connor > Hi Connor, As I recall, the last time I tried to install Debian SID from the Debian installer CD, it did not recognize my CD drive (despite having just booted the CD from that drive). So I copied the entire installation CD to a spare 1 GB disk (something like "dd if=/dev/cdrom of=/dev/sdb bs=64k"). I was then able to boot from that disk and proceeded to a full installation. My existing installation was Debian 7.8, which was able to recognize the CD drive. -Stan
Re: nasty bug in /usr/sbin/grub-probe
Hello Adrian and Dennis, 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. -Stan - On 4/3/22 5:57 AM, John Paul Adrian Glaubitz wrote: > Hello! > > On 4/3/22 13:42, Dennis Clarke wrote: >>> But since you seem to have a reliable reproducer, you can start trying to >>> bisect >>> the kernel to find the commit that introduced this regression. >> >> That will be nearly impossible. I can not even recall when the bug first >> appeared or when was the last time that I could run update-grub without >> the machine locking up. At least two years now. Maybe three. > > What do you mean is impossible? Bisecting the bug or the fact that it is > a kernel bug? I know very well it's a kernel bug because it does not occur > when using the 4.19 kernel on any of the affected SPARCs and it does not > occur on any of the newer SPARCs with a current kernel. > > The SPARC T2 and T5 we are using don't have the problem at all, for example. > >> Also this is an even older UltraSparc IIi type machine. Really I should >> have tossed it out long ago but the next machine I have handy is a >> Fujitsu M3000 unit and I thought I had heard it was impossible to get >> Linux on such a beast for unknown reasons. Could be myth or rumour but I >> thought the M3000 was somehow "special". The larger M4000 seems to be >> fine but those are just nasty large beasts to run in a home lab. >> >> Dragging the deep waters looking for that kernel bug will take a lot of >> time. Possibly even some luck. > > Not really. You cross-build the kernel, transfer it to the machine and see if > update-grub works. If it doesn't, you mark the commit as bad. If it does, you > mark the commit as good. You start from a good known working kernel such as > 4.19. > > But I can do it myself if I find the time, I have an Ultra 45 that can be used > for that. Thought it would just be nice if I can get a helping hand, > especially > since cross-compiling and bisecting the kernel isn't really hard, it just > takes > time. > > Adrian >
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 w
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 &
Re: 5.10.0-4-sparc64-smp #1 Debian 5.10.19-1 crashes on T2000
Hi Riccardo, On 3/26/21 6:21 PM, Riccardo Mottola wrote: > Hi, > ... > > I cloned linux stable. It took 60 minutes... > > I took the config out of /boot/config of a good kernel, updated it with > "make oldconfig" > > During compilation I see: > > CC init/init_task.o > make[1]: *** No rule to make target > 'debian/certs/debian-uefi-certs.pem', needed by > 'certs/x509_certificate_list'. Stop. > make[1]: *** Waiting for unfinished jobs > ... I think you need to remove all references to debian certs to compile a custom kernel. -Stan Johnson
