Re: Kernel Panics / Re: GRUB testers on SPARC needed
thanks for the information. I'm still battling a few issues, but the most prominent problem on my way to netboot-install is that I can't seem to get the apt/sources.list right for fetching sources (?): You just have to build the debian-installer package on sparc64 using sbuild and as a result, you will get the tarball containing the netboot and cdrom images. ...trying to get the build-deps for debian-installer complains, that I should at least specify one deb-src line in my sources.list... I have the settings the installer configured ("deb-src http://deb.debian.org/debian-ports/ sid main"), but sid doesn't have a /main/source on debian-ports... "unreleased" does have a source folder, but apt seems to ignore the "unreleased" distribution for sources (maybe that's what the comment "unreleased does not support sources yet" means?) Well... long story short: Can you point me in the right direction to get the sources the debian-ports use? Or is the normal way to pull sources from "normal" debian repositories? Thanks, Robin
Re: Kernel Panics / Re: GRUB testers on SPARC needed
Hi Robin, On 17.05.21 12:36, Robin Cremer wrote: [...] On a not entirely unrelated note: Are there any news on functioning netboot images? The last post I could find points to images from April '17 on your webspace, which were, according to the ML, not bootable because of the size. At least I can't boot them either. Can't help you with any netboot images, though I assume the existing ones in the archives ([1], images are in `./installer-sparc64/20210415/images/netboot/netboot.tar.gz`) could actually work if they are loaded from GRUB and not from the OBP. [1]: http://ftp.ports.debian.org/debian-ports/pool-sparc64/main/d/debian-installer/ If there is no more recent version, I'll try to build something myself - are there any pointers on how to go about this? Minimal OS or the netinstaller in an .img would be preferred. I described a possible setup to netboot with GRUB on [2]. My used version of GRUB is old (`sparc64-ieee1275-2.02+dfsg1-18`) but works. This setup works similarly to identically for most of my machinery (ia64, amd64, powerpc, ppc64, sparc64) and for me GRUB is able to load "large" images (> 100 MiB, tested during my investigation on [3]) over network w/o an issue. With a working sparc64 Debian installation it's even easier to setup. You can host everything needed (I recommend: dnsmasq (only for DNS), tftpd-hpa, isc-dhcp-server and possibly rarpd) on a Raspberry Pi for example. I assume you're already familiar with these services but just ask if you need some help in configuration. [2]: https://wiki.debian.org/Sparc64#Netbooting_with_GRUB2 [3]: https://lists.debian.org/debian-sparc/2021/03/msg00045.html I think that would help in quick testing, as I have multiple other systems with Cheetah (UltraSPARC III, III CU and IIIi) I'd like to try provoking the panics on. Also, some older (UltraSPARC IIi and IIe+) systems are waiting for recent Debian :-) For testing multiple systems for anomalies I'd recommend to netboot with a Debian root FS provided by NFS which saves you the time to install Debian on every machine. There were two posts on the debian-sparc list recently ([4]) by Anatoly that mentioned the `stress-ng` tool, which might be helpful in provoking panics and possibly identifying the source of a panic. [4]: https://lists.debian.org/cgi-bin/search?P=stress-ng&DEFAULTOP=or&B=Gdebian-sparc&SORT=&HITSPERPAGE=10 Cheers, Frank
Re: Kernel Panics / Re: GRUB testers on SPARC needed
On 5/17/21 12:36 PM, Robin Cremer wrote: >>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/sparc?id=e5e8b80d352ec999d2bba3ea584f541c83f4ca3f > I'm using the latest version from the repositories: >> 5.10.0-6-sparc64-smp #1 SMP Debian 5.10.28-1 (2021-04-09) sparc64 GNU/Linux > The commit you mention seems to be in 5.12 and 5.13-rc2? > Is there a pre-built SMP-image for this or do I have to set up building > myself? The commit has been backported to the 5.10.x series which is an LTS kernel: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/sparc?h=linux-5.10.y&id=f2b38f03a3f71c30c77a4516b26c8bea13cc08ce > Running on the v215 was a real nightmare yesterday. They will be stable for > hours, but > certain actions (in one occurence executing dmesg (!), apt-get installing > nfs-common, > some mounts systemd tries) crashed both of the boxes with various errors, > most of them the > dreaded line with "p Try to use a 4.19 kernel from snapshot.debian.org, these are known to run more stable on the older machines. Any machine older than T2 seem to have some issues with the more recent kernels. If you have the possibility to bisect the issue, that would be great. I do have such older machines myself but currently no possibility to set them up for bisecting. On the newer CPUs (>= SPARC T2), the kernel runs stable. Dave Miller (the Linux SPARC maintainer) uses a T5 himself for testing. > Retrying the dpkg-reconfigure as well. After the systemd-unit for - I think - > rpcbind was activated > during package configuration, both boxes crashed about 4-6 times, I had to > reset from OBP. > After a few tries, installation went through, then. Now I can mount nfs... > The hours I spent in the rescue mode of the current installation CD without > any trouble made me suspect > that non-SMP-kernels are "more stable". I'm currently running the SMP variant > with "maxcpus=1", that > seems stable so far... But as with any other sporadic issue, that's hard to > tell with a way to reliably > trigger the errors... I think these issues have started to show up sometime after 4.19 but only on the older machines. So, chances are you can bisect the issue. > On a not entirely unrelated note: > Are there any news on functioning netboot images? The last post I could find > points to images from April '17 > on your webspace, which were, according to the ML, not bootable because of > the size. I don't have the time and resources at the moment to work on netboot. I'm not just maintaining the sparc64 port in Debian but also many of the other unofficial ports such as 32-bit PowerPC. So far, netboot has not been a top priority so I haven't worked on it yet. Additional support is always welcome. > At least I can't boot them either. > If there is no more recent version, I'll try to build something myself - are > there any pointers on how to go > about this? Minimal OS or the netinstaller in an .img would be preferred. You just have to build the debian-installer package on sparc64 using sbuild and as a result, you will get the tarball containing the netboot and cdrom images. > I think that would help in quick testing, as I have multiple other systems > with Cheetah (UltraSPARC III, III CU > and IIIi) I'd like to try provoking the panics on. Also, some older > (UltraSPARC IIi and IIe+) systems are waiting > for recent Debian :-) For these machines, I would recommend installing a regular release, then downgrading the kernel to 4.19, then bi-sect using a cross-compiled kernel if you have a working reproducer. 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
Kernel Panics / Re: GRUB testers on SPARC needed
Hi Adrian, for the sake of visibility, here the response to the kernel-trouble: Am 17.05.2021 um 10:23 schrieb John Paul Adrian Glaubitz: Installing on two SunFire v215 went reasonably well /- (apart from recurring Kernel Panics with "Unable to handle kernel paging request in mna handler", most often triggered on boot immediately after the systemd binfmt service tries to start. This seems to have been mentioned in /2020/04/msg00020.html but never pinpointed and fixed?) -/ What kernel version are you running. There have actually been some fixes in this regard, in particular this fix: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/sparc?id=e5e8b80d352ec999d2bba3ea584f541c83f4ca3f I'm using the latest version from the repositories: 5.10.0-6-sparc64-smp #1 SMP Debian 5.10.28-1 (2021-04-09) sparc64 GNU/Linux The commit you mention seems to be in 5.12 and 5.13-rc2? Is there a pre-built SMP-image for this or do I have to set up building myself? Running on the v215 was a real nightmare yesterday. They will be stable for hours, but certain actions (in one occurence executing dmesg (!), apt-get installing nfs-common, some mounts systemd tries) crashed both of the boxes with various errors, most of them the dreaded line with "p Retrying the dpkg-reconfigure as well. After the systemd-unit for - I think - rpcbind was activated during package configuration, both boxes crashed about 4-6 times, I had to reset from OBP. After a few tries, installation went through, then. Now I can mount nfs... The hours I spent in the rescue mode of the current installation CD without any trouble made me suspect that non-SMP-kernels are "more stable". I'm currently running the SMP variant with "maxcpus=1", that seems stable so far... But as with any other sporadic issue, that's hard to tell with a way to reliably trigger the errors... The worst offender so far seems to be xfs, though... I initially installed both v215 with ext3 /boot and xfs for /. I'm not sure if the problem is related, but xfs seems to frequently encounter [ 35.325122] XFS (md1): Metadata corruption detected at xfs_dinode_verify.part.0+0x358/0x6c0 [xfs], inode 0x402c4d0 dinode [ 35.469639] XFS (md1): Unmount and run xfs_repair on both machines. xfs_repair doesn't do anything, though. Either, these inodes were the last ones written during kernel panics, or the underlying issue of the panics leads to checksum-mismatches in-memory? The latter seems more likely, because during dpkg-installs the following popped up a few times as well: [ 195.360257] XFS (md1): Corruption of in-memory data detected. Shutting down filesystem (after that, obviously, the system is unusable despite not panicking, as root is missing entirely...) Some faults: [ 281.304119] WARNING: CPU: 1 PID: 11 at kernel/smp.c:633 smp_call_function_many_cond+0x3bc/0x3e0 [ 281.418696] Modules linked in: ext4(E) crc16(E) mbcache(E) jbd2(E) sr_mod(E) cdrom(E) ata_generic(E) tg3(E) libphy(E) ptp(E) ohci_pci(E) sg(E) pata_ali(E) ehci_pci(E) ohci_hcd(E) ehci_hcd(E) libata(E) pps_core(E) usbcore(E) usb_common(E) flash(E) drm(E) drm_panel_orientation_quirks(E) i2c_core(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) xfs(E) raid10(E) raid456(E) async_raid6_recov(E) async_memcpy(E) async_pq(E) raid6_pq(E) async_xor(E) xor(E) async_tx(E) libcrc32c(E) crc32c_generic(E) raid0(E) multipath(E) linear(E) raid1(E) md_mod(E) sd_mod(E) t10_pi(E) crc_t10dif(E) crct10dif_generic(E) crct10dif_common(E) mptsas(E) scsi_transport_sas(E) mptscsih(E) mptbase(E) scsi_mod(E) [ 282.224447] CPU: 1 PID: 11 Comm: ksoftirqd/1 Tainted: G D E 5.10.0-6-sparc64-smp #1 Debian 5.10.28-1 [ 282.359710] Call Trace: [ 282.391788] [<0046c67c>] __warn+0xbc/0x120 [ 282.454810] [<00c450f8>] warn_slowpath_fmt+0x34/0x74 [ 282.529285] [<00517b5c>] smp_call_function_many_cond+0x3bc/0x3e0 [ 282.617512] [<00517be4>] smp_call_function+0x24/0x40 [ 282.691989] [<00441828>] smp_send_stop+0x28/0x120 [ 282.763028] [<00c44e84>] panic+0x110/0x350 [ 282.826047] [<00472ad0>] do_exit+0xad0/0xb20 [ 282.891357] [<00c43ab0>] die_if_kernel+0x1f4/0x260 [ 282.963543] [<00c5501c>] unhandled_fault+0x88/0xac [ 283.035728] [<00c553c8>] do_sparc64_fault+0x388/0xa80 [ 283.111354] [<00407714>] sparc64_realfault_common+0x10/0x20 [ 283.193850] [<005a1e64>] __bpf_prog_put_rcu+0x24/0x60 [ 283.269470] [<004f5c20>] rcu_core+0x240/0x620 [ 283.335926] [<004f600c>] rcu_core_si+0xc/0x20 [ 283.402383] [<00c5602c>] __do_softirq+0x10c/0x3a0 [ 283.473423] [<00473b14>] run_ksoftirqd+0x34/0x60 [ 283.543315] ---[ end trace 9f0a29fcdf85be47 ]--- [ 124.914048] CPU[1]: Cheetah+ D-cache parity error at TPC[005bc2b0] [ 125.004638] TPC nfs-utils.service is a disabled or a static unit, not starting it. [ 125.528183] Kernel unaligned access at
Re: GRUB testers on SPARC needed
Hi Adrian, thanks for the response! First things first: I got GRUB to work yesterday :-) The last bit of magic missing in the picture was what you expected: The blocklist was "shifted" because GRUB-install didn't correctly determine the relation of physical disk vs. MDraid-Volume block positions. Not sure if it does when installing on x86 with blocklists? I found it hard to find usable documentation about the actual physical on-disk-layout of MDraid RAID-1. SuperBlocks are well documented, the "complex" RAID-levels reasonably well also, but I found no mention that building the volume with metadata-version 1.2 (metadata 4k from beginning of disk, which shouldn't be a problem, as only the first 2 512-Byte sectors (->~1k) are in use for label & GRUB boot.img) actually shifts the start of Data in the mdraid to the end of the first 1MB block - so blocklist numbers are off by 1MB. I noticed that by trial & error: I opened a "normally installed" disk and the RAID member disk I tried to build in a hexeditor ;-) metadata=0.9 does not do this. I thought the metadata-settings only affected the position and "type" of the mdraid metadata blocks, not the actual on-disk-layout of the mirror. So, long story short: My old setup with SILO was exactly like this: metadata=0.9 for the /boot partition. With this, the ext3 blocks are on the same position on the physical disk AND on the md-volume. I might have set it up like this for the same reason back then, but forgot... It's been quite a while. The second (although minor) trouble was, that grub-mkconfig generates an unusable grub.cfg for this setup. It refuses to set the "root=" variable to (mduuid/UUID), which was in turn necessary to install the bootblocks, instead using settings that lead to GRUB being unable to open the partition label and failing back to OBP. The best solution I found was to edit the /usr/lib/grub/grub-mkconfig_lib shellscript to not set root at all. In my case, that works flawlessly, as GRUB actually starts with "root=" already set to the disk that loaded it, so it even works with one disk pulled from the server, simulating failure - which was exactly what I wanted. So, long story short: - Patching util/setup.c to correctly handle (virtual) block devices without partition tables. - Use metadata=0.9 to build the mirror (!) - Add device.map entry for MDraid-Device to work around the "diskfilter writes not supported"-issue (from grub-probe -t ieee1275_hints -d /dev/md0): (mduuid/66bf8873932144cf2d6a74e4a05e67d3) /dev/md0 - Strip the lines in /usr/lib/grub/grub-mkconfig_lib between # otherwise set root as per value in device.map. and IFS="$old_ifs" to make boot entries that do not try to re-set "root" After this fight, I achieved my boot mirror setup on GRUB/SPARC :-) I'll respond to the kernel-stuff separately. Thanks! - Robin Am 17.05.2021 um 10:23 schrieb John Paul Adrian Glaubitz: Hi Robin! On 5/15/21 7:25 PM, Robin Cremer wrote: 7. Report back to the list and include your hardware and partition setup A bit late to the party, as SILO already appears to be gone (including the repos) and all install images use GRUB now, but I'm having trouble and wanted to report this - and maybe get some ideas, in case this is the best address to do so: You can still install SILO from snapshot.debian.org. However, I would recommend building the latest version from source as there have been some bugfixes in the meantime. I'm in the process of migrating most of our SPARC servers running Solaris 10 & the old Debian with 32bit SPARC userland to the SPARC64 debport. Some servers running Solaris 11 will follow. Good to hear. Installing on two SunFire v215 went reasonably well /- (apart from recurring Kernel Panics with "Unable to handle kernel paging request in mna handler", most often triggered on boot immediately after the systemd binfmt service tries to start. This seems to have been mentioned in /2020/04/msg00020.html but never pinpointed and fixed?) -/ What kernel version are you running. There have actually been some fixes in this regard, in particular this fix: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/sparc?id=e5e8b80d352ec999d2bba3ea584f541c83f4ca3f but I can't seem to be able to configure GRUB on these servers as I did in the past with SILO (a 2-disk mdraid with mirrored /boot, / and swap). I'm currently stuck with /boot on only one disk and the rest of the system mirrored as I can't figure out how to install grub for a mirrored /boot partition: Please keep in mind that GRUB is installed using blocklists on these older machines which means it's not aware of the filesystem being used. The bootloader will just remember the location of the data blocks and the physical disk. So it has no means to deal with something sophisticated as a software RAID. Not sure how it worked with SILO which didn't use anything else than blocklists either (which is why
Re: GRUB testers on SPARC needed
On 5/16/21 2:03 AM, Robin Cremer wrote: > Responding to myself: > > Some progress: > I put additional informational output between all commands in the suspect > area in GRUBs util/setup.c and pinpointed the bug: > >> #ifdef GRUB_SETUP_SPARC64 >> { >> grub_partition_t container = root_dev->disk->partition; >> >> if (grub_strstr (container->partmap->name, "gpt")) >> bl.gpt_offset = grub_partition_get_start (container); >> } >> #endif > > When installing on an md-device - or other special devices - it will never > have a partition table, thus "container" is null. It might be trying to read the partition table from a fixed position where it wouldn't be when using a software RAID, not sure. In any case, this definitely needs to be moved upstream and you should put Eric Snowberg from Oracle in the loop as he is the expert on GRUB for SPARC. > After that, access to struct members is tried without checking if it even > exists, leading to the segfault. >> if (container && grub_strstr (container->partmap->name, "gpt")) > actually works & installs on LVM if I put a hint for GRUB into the device.map > pointing to the UUID of the MDRAID. > > I'll try to get a patch for that submitted or discussed (I'm new to this and > not exactly sure if the change has other implications). > > > It still won't boot, though. The first "stage" in the 2nd partition block is > executed by OBP and something along the lines > of "GRUB FAIL - trap: Illegal Instruction" and on a second attempt "Unaligned > Memory Access" was encountered... Most likely because the block numbers reported back by the software RAID don't map to the block numbers on the physical device which is why the first stage is just loading random garbage and executing it which leads to SIGILL. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: GRUB testers on SPARC needed
Hi Robin! On 5/15/21 7:25 PM, Robin Cremer wrote: >> 7. Report back to the list and include your hardware and partition setup > > A bit late to the party, as SILO already appears to be gone (including the > repos) and > all install images use GRUB now, but I'm having trouble and wanted to report > this - and > maybe get some ideas, in case this is the best address to do so: You can still install SILO from snapshot.debian.org. However, I would recommend building the latest version from source as there have been some bugfixes in the meantime. > I'm in the process of migrating most of our SPARC servers running Solaris 10 > & the old Debian > with 32bit SPARC userland to the SPARC64 debport. Some servers running > Solaris 11 will follow. Good to hear. > Installing on two SunFire v215 went reasonably well > > /- (apart from recurring Kernel Panics with "Unable to handle kernel paging > request in mna handler", > most often triggered on boot immediately after the systemd binfmt service > tries to start. This seems > to have been mentioned in /2020/04/msg00020.html but never pinpointed and > fixed?) -/ What kernel version are you running. There have actually been some fixes in this regard, in particular this fix: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/sparc?id=e5e8b80d352ec999d2bba3ea584f541c83f4ca3f > but I can't seem to be able to configure GRUB on these servers as I did in > the past with SILO (a 2-disk > mdraid with mirrored /boot, / and swap). I'm currently stuck with /boot on > only one disk and the rest of > the system mirrored as I can't figure out how to install grub for a mirrored > /boot partition: Please keep in mind that GRUB is installed using blocklists on these older machines which means it's not aware of the filesystem being used. The bootloader will just remember the location of the data blocks and the physical disk. So it has no means to deal with something sophisticated as a software RAID. Not sure how it worked with SILO which didn't use anything else than blocklists either (which is why the /boot partition couldn't be too large and the filesystem used couldn't be too fancy). > 1) Installing to the mirror device always yields a Segmentation Fault. I was > unable to get any clue with > my limited gdb experience as to why - (with loaded debug symbols etc.: > "Backtrace stopped: previous frame > identical to this frame (corrupt stack?)"): >> # grub-install --skip-fs-probe --force --debug /dev/md0 >> [...] >> grub-install: info: setting the root device to >> `mduuid/1ae243c1e2445aef777f4d32b671f41c'. >> grub-install: warning: File system `ext2' doesn't support embedding. >> grub-install: warning: Embedding is not possible. GRUB can only be >> installed in this setup by using blocklists. However, blocklists are >> UNRELIABLE and their use is discouraged.. >> grub-install: info: will leave the core image on the filesystem. >> Segmentation fault As I said above, I don't expect this to work, really. That doesn't mean that grub-install should crash here. I will try to reproduce the issue when I find some time. Ideally, grub-install should just abort the installation in this case. But we could also find out how SILO worked in this case. > 2) Trying to install to the individual disk partitions or the raw disk itself: >> grub-install: warning: File system `ext2' doesn't support embedding. >> grub-install: error: embedding is not possible, but this is required for >> RAID and LVM install. > [...] >> grub-install: warning: Partition style `sun' doesn't support embedding. >> grub-install: error: embedding is not possible, but this is required for >> RAID and LVM install. > > Neither different filesystems (ext2, xfs, ...) nor different mdraid metadata > formats made any difference. > I can't test other disk labels, as the old OBP doesn't handle GPT AFAIR. > Also, GRUB built from the most recent official sources from their git > segfaults as well. Thanks for testing the git version, I was about to ask that. > Any pointers how to achieve this setup? What can I test or does someone else > have a similar setup > working? Am I doing something horribly wrong? I don't think mdraid-mirrored > bootdisks should be too > uncommon on this hardware. >From my statements above, I wouldn't expect GRUB with blocklists to work on a >software RAID, so I think you probably have no choice but to use a single disk for booting. In any case, I think the the GRUB-specific discussion should be moved to the GRUB mailing list as this really concerns the low-level functionality of GRUB. > Thanks and cheers to the community keeping SPARC alive :-) Sure. Glad it's being useful. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: GRUB testers on SPARC needed
Responding to myself: Some progress: I put additional informational output between all commands in the suspect area in GRUBs util/setup.c and pinpointed the bug: #ifdef GRUB_SETUP_SPARC64 { grub_partition_t container = root_dev->disk->partition; if (grub_strstr (container->partmap->name, "gpt")) bl.gpt_offset = grub_partition_get_start (container); } #endif When installing on an md-device - or other special devices - it will never have a partition table, thus "container" is null. After that, access to struct members is tried without checking if it even exists, leading to the segfault. if (container && grub_strstr (container->partmap->name, "gpt")) actually works & installs on LVM if I put a hint for GRUB into the device.map pointing to the UUID of the MDRAID. I'll try to get a patch for that submitted or discussed (I'm new to this and not exactly sure if the change has other implications). It still won't boot, though. The first "stage" in the 2nd partition block is executed by OBP and something along the lines of "GRUB FAIL - trap: Illegal Instruction" and on a second attempt "Unaligned Memory Access" was encountered... I'll post back, Greetings, Robin
Re: GRUB testers on SPARC needed
Hi, We're in the process of migrating Debian for sparc64 from SILO to GRUB as GRUB upstream is adding support for modern SPARC machines thanks to the work of Eric Snowberg from Oracle. In order to make sure GRUB works on all machines supported by the sparc64 port, we need your help to test GRUB on your particular hardware, the older your machine, the better. [...] 7. Report back to the list and include your hardware and partition setup A bit late to the party, as SILO already appears to be gone (including the repos) and all install images use GRUB now, but I'm having trouble and wanted to report this - and maybe get some ideas, in case this is the best address to do so: I'm in the process of migrating most of our SPARC servers running Solaris 10 & the old Debian with 32bit SPARC userland to the SPARC64 debport. Some servers running Solaris 11 will follow. Installing on two SunFire v215 went reasonably well /- (apart from recurring Kernel Panics with "Unable to handle kernel paging request in mna handler", most often triggered on boot immediately after the systemd binfmt service tries to start. This seems to have been mentioned in /2020/04/msg00020.html but never pinpointed and fixed?) -/ but I can't seem to be able to configure GRUB on these servers as I did in the past with SILO (a 2-disk mdraid with mirrored /boot, / and swap). I'm currently stuck with /boot on only one disk and the rest of the system mirrored as I can't figure out how to install grub for a mirrored /boot partition: 1) Installing to the mirror device always yields a Segmentation Fault. I was unable to get any clue with my limited gdb experience as to why - (with loaded debug symbols etc.: "Backtrace stopped: previous frame identical to this frame (corrupt stack?)"): # grub-install --skip-fs-probe --force --debug /dev/md0 [...] grub-install: info: setting the root device to `mduuid/1ae243c1e2445aef777f4d32b671f41c'. grub-install: warning: File system `ext2' doesn't support embedding. grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. grub-install: info: will leave the core image on the filesystem. Segmentation fault 2) Trying to install to the individual disk partitions or the raw disk itself: grub-install: warning: File system `ext2' doesn't support embedding. grub-install: error: embedding is not possible, but this is required for RAID and LVM install. [...] grub-install: warning: Partition style `sun' doesn't support embedding. grub-install: error: embedding is not possible, but this is required for RAID and LVM install. Neither different filesystems (ext2, xfs, ...) nor different mdraid metadata formats made any difference. I can't test other disk labels, as the old OBP doesn't handle GPT AFAIR. Also, GRUB built from the most recent official sources from their git segfaults as well. Any pointers how to achieve this setup? What can I test or does someone else have a similar setup working? Am I doing something horribly wrong? I don't think mdraid-mirrored bootdisks should be too uncommon on this hardware. Thanks and cheers to the community keeping SPARC alive :-) Robin
Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed
Hello! On 1/11/21 2:53 PM, Dennis Clarke wrote: > I am doing a re-install with the "default" installer and I choose the > most trivial config options. Which is to say the partition options were > whatever seems most trivial. Full disk. New partition table. Everything > in one partition. The default seems to be 512MB ext2 bootable /boot and > then a large slice and 1G of swap. > > Eventually I see a big red box : > > [!!] Configure the package manager > apt configuration problem > An attempt to configure apt to install additional packages from the > media failed. > > Here I select "continue" and things seem to move along. You should have checked what's in the log in the other terminal so you know the actual problem was. > I guess there is something oddball in the expert level menu option but > we don't really test for that. OKay, this works in the easy mode option. I alone simply don't have the capacity to test (and fix!) all possible paths in the installer. If you run into such problem, try to reproduce it with a daily snapshot of the installer on one of the officially supported architectures and then file a bug against debian-installer. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed
On 1/9/21 1:12 AM, John Paul Adrian Glaubitz wrote: > On 1/9/21 1:53 AM, Dennis Clarke wrote: >> >> I think this is pretty much well known but I will report it here >> regardless. From the latest sparc64 installer images I eventually >> see grub-ieee1275 fails. >> (...) >> Jan 4 19:00:02 in-target: Get:1 http://deb.debian.org/debian-ports >> sid/main sparc64 grub2-common sparc64 2.04-11 [719 kB] >> Jan 4 19:00:04 in-target: Err:2 http://deb.debian.org/debian-ports >> sid/main sparc64 grub-ieee1275-bin sparc64 2.04-11 >> Jan 4 19:00:04 in-target: 503 Backend unavailable, connection >> timeout [IP: 2a04:4e42:58::644 80] >> Jan 4 19:00:04 in-target: Get:3 http://deb.debian.org/debian-ports >> sid/main sparc64 grub-ieee1275 sparc64 2.04-11 [542 kB] >> Jan 4 19:00:05 in-target: Fetched 1261 kB in 4s (316 kB/s) >> Jan 4 19:00:05 in-target: E >> Jan 4 19:00:05 in-target: : >> Jan 4 19:00:05 in-target: Failed to fetch >> http://deb.debian.org/debian-ports/pool-sparc64/main/g/grub2/grub-ieee1275-bin_2.04-11_sparc64.deb >> 503 Backend unavailable, connection timeout [IP: 2a04:4e42:58::644 80] >> Jan 4 19:00:05 in-target: >> Jan 4 19:00:05 in-target: E >> Jan 4 19:00:05 in-target: : >> Jan 4 19:00:05 in-target: Unable to fetch some archives, maybe run >> apt-get update or try with --fix-missing? >> Jan 4 19:00:05 in-target: >> Jan 4 19:00:05 grub-installer: info: Calling 'apt-install >> grub-ieee1275' failed > > I have no clue which image you used and I'm not sure what you did to end up > in a situation > where the installer would try to download the grub2 packages over the net > which are actually > on the installation ISO, so they don't have to be downloaded. > > I also just verified that by installing the latest sparc64 ISO inside an LDOM > in offline mode > and grub2 was installed without any issues with no package mirror being set > up. I am doing a re-install with the "default" installer and I choose the most trivial config options. Which is to say the partition options were whatever seems most trivial. Full disk. New partition table. Everything in one partition. The default seems to be 512MB ext2 bootable /boot and then a large slice and 1G of swap. Eventually I see a big red box : [!!] Configure the package manager apt configuration problem An attempt to configure apt to install additional packages from the media failed. Here I select "continue" and things seem to move along. Then, after a little while everything seems to just work neatly. I guess there is something oddball in the expert level menu option but we don't really test for that. OKay, this works in the easy mode option. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional
Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed
On 1/9/21 2:33 PM, Dennis Clarke wrote: > May be possibly because I always use the "expert mode" option in the > installer. That allows me to setup the network without DHCP. Manual networking setup also works in normal mode. It will try DHCP first, then fail and then offer manual configuration. > I will try again with the default trivial installer. Yes, please try to avoid the expert installer. It's an untested code path. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed
On 1/9/21 1:12 AM, John Paul Adrian Glaubitz wrote: > On 1/9/21 1:53 AM, Dennis Clarke wrote: >> >> I think this is pretty much well known but I will report it here >> regardless. From the latest sparc64 installer images I eventually >> see grub-ieee1275 fails. >> (...) >> Jan 4 19:00:02 in-target: Get:1 http://deb.debian.org/debian-ports >> sid/main sparc64 grub2-common sparc64 2.04-11 [719 kB] >> Jan 4 19:00:04 in-target: Err:2 http://deb.debian.org/debian-ports >> sid/main sparc64 grub-ieee1275-bin sparc64 2.04-11 >> Jan 4 19:00:04 in-target: 503 Backend unavailable, connection >> timeout [IP: 2a04:4e42:58::644 80] >> Jan 4 19:00:04 in-target: Get:3 http://deb.debian.org/debian-ports >> sid/main sparc64 grub-ieee1275 sparc64 2.04-11 [542 kB] >> Jan 4 19:00:05 in-target: Fetched 1261 kB in 4s (316 kB/s) >> Jan 4 19:00:05 in-target: E >> Jan 4 19:00:05 in-target: : >> Jan 4 19:00:05 in-target: Failed to fetch >> http://deb.debian.org/debian-ports/pool-sparc64/main/g/grub2/grub-ieee1275-bin_2.04-11_sparc64.deb >> 503 Backend unavailable, connection timeout [IP: 2a04:4e42:58::644 80] >> Jan 4 19:00:05 in-target: >> Jan 4 19:00:05 in-target: E >> Jan 4 19:00:05 in-target: : >> Jan 4 19:00:05 in-target: Unable to fetch some archives, maybe run >> apt-get update or try with --fix-missing? >> Jan 4 19:00:05 in-target: >> Jan 4 19:00:05 grub-installer: info: Calling 'apt-install >> grub-ieee1275' failed > > I have no clue which image you used and I'm not sure what you did to end up > in a situation > where the installer would try to download the grub2 packages over the net > which are actually > on the installation ISO, so they don't have to be downloaded. > I used the sparc64 netinst from https://cdimage.debian.org/cdimage/ports/snapshots/2021-01-03/ and did veridy the SHA512 hash. > I also just verified that by installing the latest sparc64 ISO inside an LDOM > in offline mode > and grub2 was installed without any issues with no package mirror being set > up. > May be possibly because I always use the "expert mode" option in the installer. That allows me to setup the network without DHCP. I will try again with the default trivial installer. Dennis
Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed
On 1/9/21 2:03 PM, Gregor Riepl wrote: > The only situation where I can imagine this would happen is when the > repositories have a newer version of the package than the installer > image, and update to the latest version during installation is enabled > (probably the default). I have never run into this situation but I know that a lot of users choose the weirdest configuration settings in debian-installer without understanding the ramifications and then wonder why it doesn't work. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed
> I have no clue which image you used and I'm not sure what you did to end up > in a situation > where the installer would try to download the grub2 packages over the net > which are actually > on the installation ISO, so they don't have to be downloaded. The only situation where I can imagine this would happen is when the repositories have a newer version of the package than the installer image, and update to the latest version during installation is enabled (probably the default). Maybe try again, or with a different mirror? This sounds very much like a temporary issue with the repo, not the installer: Jan 4 19:00:04 in-target: 503 Backend unavailable, connection timeout [IP: 2a04:4e42:58::644 80]
Re: grub-installer: info: Calling 'apt-install grub-ieee1275' failed
On 1/9/21 1:53 AM, Dennis Clarke wrote: > > I think this is pretty much well known but I will report it here > regardless. From the latest sparc64 installer images I eventually > see grub-ieee1275 fails. > (...) > Jan 4 19:00:02 in-target: Get:1 http://deb.debian.org/debian-ports > sid/main sparc64 grub2-common sparc64 2.04-11 [719 kB] > Jan 4 19:00:04 in-target: Err:2 http://deb.debian.org/debian-ports > sid/main sparc64 grub-ieee1275-bin sparc64 2.04-11 > Jan 4 19:00:04 in-target: 503 Backend unavailable, connection > timeout [IP: 2a04:4e42:58::644 80] > Jan 4 19:00:04 in-target: Get:3 http://deb.debian.org/debian-ports > sid/main sparc64 grub-ieee1275 sparc64 2.04-11 [542 kB] > Jan 4 19:00:05 in-target: Fetched 1261 kB in 4s (316 kB/s) > Jan 4 19:00:05 in-target: E > Jan 4 19:00:05 in-target: : > Jan 4 19:00:05 in-target: Failed to fetch > http://deb.debian.org/debian-ports/pool-sparc64/main/g/grub2/grub-ieee1275-bin_2.04-11_sparc64.deb > 503 Backend unavailable, connection timeout [IP: 2a04:4e42:58::644 80] > Jan 4 19:00:05 in-target: > Jan 4 19:00:05 in-target: E > Jan 4 19:00:05 in-target: : > Jan 4 19:00:05 in-target: Unable to fetch some archives, maybe run > apt-get update or try with --fix-missing? > Jan 4 19:00:05 in-target: > Jan 4 19:00:05 grub-installer: info: Calling 'apt-install > grub-ieee1275' failed I have no clue which image you used and I'm not sure what you did to end up in a situation where the installer would try to download the grub2 packages over the net which are actually on the installation ISO, so they don't have to be downloaded. I also just verified that by installing the latest sparc64 ISO inside an LDOM in offline mode and grub2 was installed without any issues with no package mirror being set up. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: grub-ieee1275 fails to install bootblock
Hi Alexander! Could you please retest with the latest ISO image for sparc64 [1] and check whether this issue has been resolved for you now? We have fixed a lot of issues around GRUB on sparc64, both upstream and in Debian and I'm confident that GRUB should work now out of the box on your UltraSPARC 45. FWIW, there are currently some issues with 5.x on older UltraSPARC machines but these should not affect this bug report. If GRUB works for you on sparc64 after testing the image, please consider closing this bug report. Adrian > [1] > https://cdimage.debian.org/cdimage/ports/2020-04-19/debian-10.0-sparc64-NETINST-1.iso -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Grub, sparc64, and compressed kernels
On Tue, Jul 03, 2018 at 04:43:32PM -0400, Chris Ross wrote: > [- tried to grub-install onto /dev/sda1 and /dev/sda2, won't boot, Illegal >Instruction. -] > So, I fear some of this is based on the fact that I'm running grub-install > into raid filesystems that are mounted as a RAID1, but I'm sticking things > into them at the same time. Or maybe it's more complicated, but the fact > that I'm writing into the raw partitions under an md RAID certainly seems > of concern. :-/ So I'm even more confused now. I was unable to boot disk0 or disk1, but also got errors booting off of disk3, which had been working. So I booted into rescue cd, re-ran the grub-install onto /dev/sdd1, then rebooted. Came up fine, as before. When it did, I did nothing but log in, then re-run "grub-install --force --skip-fs-probe" onto each of /dev/sda1 and /dev/sda2, while /dev/md0 wasn't mounted. Nothing on the first three disks had been accessed since boot. Sadly, this did not make those disks bootable either. But, surprisingly, I now can't boot off of disk3 again. Even after a "reset-all", I see: Boot device: disk3 File and args: GRUB ERROR: Last Trap: Illegal Instruction So, I've no idea how merely running grub-install onto /dev/sda1 and /dev/sdb1 could possibly have messed up the grub on /dev/sdd1? I am booting into rescue cd again now to repair that, but I'm starting to feel that grub is acting for some evil spirit and I am failing to meet whatever it's needs are - Chris ps, re-grub-install'ing to /dev/sdd1 allowed the system to boot again. I rebooted a few times, seems to have remained functional. I also after a few successful boots to sdd (aka disk3), tried booting from PROM to disk0 again, got the Illegal Instruction, but was then still able to boot disk3.
Re: Grub, sparc64, and compressed kernels
Sorry for the chatter on the list, all... On Tue, Jul 03, 2018 at 04:14:18PM -0400, Chris Ross wrote: > Adrian answered some of this before I asked the above questions: > > t5120# grub-install /dev/sda1 > Installing for sparc64-ieee1275 platform. > grub-install: warning: File system `ext2' doesn't support embedding. > grub-install: error: embedding is not possible, but this is required for RAID > and LVM install. > t5120# grub-install --force --skip-fs-probe /dev/sda1 > Installing for sparc64-ieee1275 platform. > grub-install: warning: File system `ext2' doesn't support embedding. > grub-install: error: embedding is not possible, but this is required for RAID > and LVM install. > t5120# Okay. So, I see the above error from grub-install, when running in the chroot, for both /dev/sda1, _and_ for /dev/sdd1 which worked fine for the real disks I'm running on, and booted from. From the full machine, I can also successfully grub-install onto /dev/sda1 (and /dev/sdb1). I don't know why that is different when running in the chroot onto the target area. Rebooting now, to see if I can load a working grub from disk0, and what it can load. Hmm. Okay, clearly some problems there... Boot device: disk3 File and args: [halt sent] {0} ok boot disk0 Boot device: /pci@0/pci@0/pci@2/scsi@0/disk@0 File and args: GRUB Loading kernel... ERROR: /pci@0/pci@0/pci@2/scsi@0: Last Trap: Illegal Instruction {0} ok boot disk1 Boot device: /pci@0/pci@0/pci@2/scsi@0/disk@1 File and args: GRUB Loading kernel error: unable to open /pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@4/device@ 4/st. error: unable to open /pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@4/device@ 4/st. error: unable to open /pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@4/device@ 4/st. error: unable to open /pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@4/device@ 4/st. UNKNOWN DEVICE: ieee1275//pci@0/pci@0/pci@2/scsi@0/disk@3\,0:a error: unable to open /pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@4/device@ 4/st. error: unable to open /pci@0/pci@0/pci@1/pci@0/pci@1/pci@0/usb@0,2/hub@4/device@ 4/st. ERROR: /pci@0: Last Trap: Fast Data Access MMU Miss {0} ok boot disk0 Boot device: /pci@0/pci@0/pci@2/scsi@0/disk@0 File and args: GRUB Loading kernel... ERROR: Last Trap: Illegal Instruction {0} ok So, I fear some of this is based on the fact that I'm running grub-install into raid filesystems that are mounted as a RAID1, but I'm sticking things into them at the same time. Or maybe it's more complicated, but the fact that I'm writing into the raw partitions under an md RAID certainly seems of concern. :-/ Again, let me know any thoughts. Thanks. - Chris
Re: Grub, sparc64, and compressed kernels
On Tue, Jul 03, 2018 at 03:37:24PM -0400, Chris Ross wrote: > Sorry, stupid user trick. I had mdadm and friends in the disk I was running > on, but had _not_ installed those packages into the environment in md/ZFS > that I chrooted into. After installing mdadm (and the collection it brought), > I am able to update-grub. And grub-probe gives me the answer I'd expect: > > But, I'm seeing the following if I try to grub-install: > > (chroot) root@t5120# grub-install --force --skip-fs-probe /dev/md0 > Installing for sparc64-ieee1275 platform. > grub-install: warning: File system `ext2' doesn't support embedding. > grub-install: warning: Embedding is not possible. GRUB can only be installed > in this setup by using blocklists. However, blocklists are UNRELIABLE and > their use is discouraged.. > zsh: segmentation fault grub-install --force --skip-fs-probe /dev/md0 > > (1) Is this supposed to work? > (2) Assuming it's not actually installed correctly yet, booting will fail. > Should I grub-install onto /dev/sda1 or /dev/sda2? Whether one or both, > won't that mess up the RAID of those devices? Adrian answered some of this before I asked the above questions: On Tue, Jul 03, 2018 at 09:39:56PM +0200, John Paul Adrian Glaubitz wrote: > Well, you need to tell GRUB to install on the individual disks > and not on the RAID (md0), this won't work - with any boot loader. > [...] > Don't use /dev/md0, use /dev/sd* and install on any of the disks that > are part of the RAID. You cannot boot from /dev/md0 as the kernel needs > to be running to be able to access the software RAID device. Okay. That all makes sense, thank you. Two problems at this point (1) The segv above. I'm doing something wrong, but it shouldn't SEGV (2) Installing onto /dev/sda1 doesn't work. t5120# grub-install /dev/sda1 Installing for sparc64-ieee1275 platform. grub-install: warning: File system `ext2' doesn't support embedding. grub-install: error: embedding is not possible, but this is required for RAID and LVM install. t5120# grub-install --force --skip-fs-probe /dev/sda1 Installing for sparc64-ieee1275 platform. grub-install: warning: File system `ext2' doesn't support embedding. grub-install: error: embedding is not possible, but this is required for RAID and LVM install. t5120# Is there some other options for grub-install I'm missing? Embedding (grub-install /dev/sda) isn't possible with sun partition labels, but the above message suggests that embedding is required for RAID install. Thanks... - Chris
Re: Grub, sparc64, and compressed kernels
On 07/03/2018 09:24 PM, Chris Ross wrote: > Okay. So, in prepping a chroot'd md/zfs environemnt on this machine, while > updating the kernel packages, I see: > > /etc/kernel/postinst.d/zz-update-grub: > Generating grub configuration file ... > Found linux image: /boot/vmlinuz-4.16.0-2-sparc64-smp > Found initrd image: /boot/initrd.img-4.16.0-2-sparc64-smp > /usr/sbin/grub-probe: error: disk `md0' not found. > /usr/sbin/grub-probe: error: disk `md0' not found. > /usr/sbin/grub-probe: error: disk `md0' not found. > Found linux image: /boot/vmlinuz-4.16.0-1-sparc64-smp > Found initrd image: /boot/initrd.img-4.16.0-1-sparc64-smp > /usr/sbin/grub-probe: error: disk `md0' not found. > /usr/sbin/grub-probe: error: disk `md0' not found. > Found Debian GNU/Linux buster/sid on /dev/sdd2 > done > > This leads me to the same problem I had earlier, grub (grub-probe or > grub-install) saying "error: disk `md0' not found." I think this is why > I started down a path of looking for an alternative grub2. Well, you need to tell GRUB to install on the individual disks and not on the RAID (md0), this won't work - with any boot loader. > Googling for this error leads me to many people that had had this error, > sometimes an old double-free problem that isn't hitting me, > and problems with one-disk md RAID arrays, which isn't my issue. But I > don't see anyone with a solution to my problem without the others. I > fear I just don't know what I'm looking for. What double-free problem? That would indicate a software bug, but this isn't a bug. You just need to tell GRUB not to use md0 as the target block device as GRUB won't be able to map this to actual physical disks. > If anyone else is more familiar with using grub, and has any idea > how to work around this current situation, I'd appreciate a pointer. > > (chroot) root@t5120# grub-install --force --skip-fs-probe /dev/md0 > Installing for sparc64-ieee1275 platform. > grub-install: error: disk `md0' not found. > (chroot) root@t5120# ls -l /dev/md* > brw-rw 1 root disk 9, 0 Jul 3 14:26 /dev/md0 > crw--- 1 root root 10, 62 Jul 3 12:19 /dev/mdesc > (chroot) root@t5120# df /boot > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/md0 458396 63776366432 15% /boot > (chroot) root@t5120# Don't use /dev/md0, use /dev/sd* and install on any of the disks that are part of the RAID. You cannot boot from /dev/md0 as the kernel needs to be running to be able to access the software RAID device. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Grub, sparc64, and compressed kernels
On Tue, Jul 03, 2018 at 03:24:12PM -0400, Chris Ross wrote: > Okay. So, in prepping a chroot'd md/zfs environemnt on this machine, while > updating the kernel packages, I see: > > /etc/kernel/postinst.d/zz-update-grub: > Generating grub configuration file ... > Found linux image: /boot/vmlinuz-4.16.0-2-sparc64-smp > Found initrd image: /boot/initrd.img-4.16.0-2-sparc64-smp > /usr/sbin/grub-probe: error: disk `md0' not found. > /usr/sbin/grub-probe: error: disk `md0' not found. > /usr/sbin/grub-probe: error: disk `md0' not found. > Found linux image: /boot/vmlinuz-4.16.0-1-sparc64-smp > Found initrd image: /boot/initrd.img-4.16.0-1-sparc64-smp > /usr/sbin/grub-probe: error: disk `md0' not found. > /usr/sbin/grub-probe: error: disk `md0' not found. > Found Debian GNU/Linux buster/sid on /dev/sdd2 > done > > This leads me to the same problem I had earlier, grub (grub-probe or > grub-install) saying "error: disk `md0' not found." I think this is why > I started down a path of looking for an alternative grub2. Sorry, stupid user trick. I had mdadm and friends in the disk I was running on, but had _not_ installed those packages into the environment in md/ZFS that I chrooted into. After installing mdadm (and the collection it brought), I am able to update-grub. And grub-probe gives me the answer I'd expect: (chroot) root@t5120# grub-probe -d /dev/md0 ext2 But, I'm seeing the following if I try to grub-install: (chroot) root@t5120# grub-install --force --skip-fs-probe /dev/md0 Installing for sparc64-ieee1275 platform. grub-install: warning: File system `ext2' doesn't support embedding. grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. zsh: segmentation fault grub-install --force --skip-fs-probe /dev/md0 (1) Is this supposed to work? (2) Assuming it's not actually installed correctly yet, booting will fail. Should I grub-install onto /dev/sda1 or /dev/sda2? Whether one or both, won't that mess up the RAID of those devices? - Chris
Re: Grub, sparc64, and compressed kernels
On Tue, Jul 03, 2018 at 12:22:34PM -0400, Chris Ross wrote: > I'll run with this for a bit, and respond back with questions about getting > it installed onto software-raid partitions later. Thanks again. Okay. So, in prepping a chroot'd md/zfs environemnt on this machine, while updating the kernel packages, I see: /etc/kernel/postinst.d/zz-update-grub: Generating grub configuration file ... Found linux image: /boot/vmlinuz-4.16.0-2-sparc64-smp Found initrd image: /boot/initrd.img-4.16.0-2-sparc64-smp /usr/sbin/grub-probe: error: disk `md0' not found. /usr/sbin/grub-probe: error: disk `md0' not found. /usr/sbin/grub-probe: error: disk `md0' not found. Found linux image: /boot/vmlinuz-4.16.0-1-sparc64-smp Found initrd image: /boot/initrd.img-4.16.0-1-sparc64-smp /usr/sbin/grub-probe: error: disk `md0' not found. /usr/sbin/grub-probe: error: disk `md0' not found. Found Debian GNU/Linux buster/sid on /dev/sdd2 done This leads me to the same problem I had earlier, grub (grub-probe or grub-install) saying "error: disk `md0' not found." I think this is why I started down a path of looking for an alternative grub2. Googling for this error leads me to many people that had had this error, sometimes an old double-free problem that isn't hitting me, and problems with one-disk md RAID arrays, which isn't my issue. But I don't see anyone with a solution to my problem without the others. I fear I just don't know what I'm looking for. If anyone else is more familiar with using grub, and has any idea how to work around this current situation, I'd appreciate a pointer. (chroot) root@t5120# grub-install --force --skip-fs-probe /dev/md0 Installing for sparc64-ieee1275 platform. grub-install: error: disk `md0' not found. (chroot) root@t5120# ls -l /dev/md* brw-rw 1 root disk 9, 0 Jul 3 14:26 /dev/md0 crw--- 1 root root 10, 62 Jul 3 12:19 /dev/mdesc (chroot) root@t5120# df /boot Filesystem 1K-blocks Used Available Use% Mounted on /dev/md0 458396 63776366432 15% /boot (chroot) root@t5120# Thanks. - Chris
Re: Grub, sparc64, and compressed kernels
On Tue, Jul 03, 2018 at 12:04:09PM -0400, Chris Ross wrote: > It sounds from Eric like the grub I built from him doesn't want to deal with > gzip. But the one shipping (2.02+dfsg1-4) does? Well, easy enough to try > that on the same disk to see. But, I presume I will face the same problem > with it not being willing to install onto md0. I'll face that later. > > Back shortly with data on Debian's grub 2.02+dfsg1-4 results. Okay. Took me a couple attempts, and the grub 2.02+ is a lot more alarming in what it says: % sudo grub-install --force --skip-fs-probe /dev/sdd1 Installing for sparc64-ieee1275 platform. grub-install: warning: Discarding improperly nested partition (hostdisk//dev/sdd,sun1,sun2). grub-install: warning: Discarding improperly nested partition (hostdisk//dev/sdd,sun1,sun4). grub-install: warning: Discarding improperly nested partition (hostdisk//dev/sdd,sun1,sun5). grub-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet.. grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. Installation finished. No error reported. % But, after getting that installed, the machine rebooted with the default (vmlinuz, gzip'd) kernel. Thought i do notice before it puts up the initial boot menu: Boot device: disk3 File and args: GRUB Loading kernel error: out of memory. error: no suitable video mode found. ...then the screen clears and shows the boot menu, and when left alone to boot the default kernel, it succeeds. So, I'm curious to read the conversation spawned by your comment back on the bug I'd opened in grub2-sparc in github. I'll run with this for a bit, and respond back with questions about getting it installed onto software-raid partitions later. Thanks again. - Chris
Re: Grub, sparc64, and compressed kernels
On Tue, Jul 03, 2018 at 05:46:18PM +0200, John Paul Adrian Glaubitz wrote: > Hi Chris! > > Any reason why you aren't just using the normal Debian procedure to setup > and install GRUB? Well, IIRC, because it wasn't working for me. But, I must admit, I'm not 100% sure I tried that on the simple disk. I know I was having no luck getting it installed on md0 when I tried, and eventually punted back to trying on sdd just to get something working. I am no longer 100% sure I hadn't already switched to trying https://github.com/esnowberg/grub2-sparc/ before that. > Debian stores its kernel compressed by default and I don't see how this is > supposed to be a problem. All SPARCs that we have installed with Debian > for sparc64 are using the grub2 package from Debian with a compressed > kernel. It sounds from Eric like the grub I built from him doesn't want to deal with gzip. But the one shipping (2.02+dfsg1-4) does? Well, easy enough to try that on the same disk to see. But, I presume I will face the same problem with it not being willing to install onto md0. I'll face that later. Back shortly with data on Debian's grub 2.02+dfsg1-4 results. - Chris
Re: Grub, sparc64, and compressed kernels
Hi Chris! On 07/03/2018 05:38 PM, Chris Ross wrote: > As I was mentioning in other threads, I was getting grub installed onto the > "normal" sun-labeled ext2/4 partitioned disk in my T5120. Working with > Eric (https://github.com/esnowberg/grub2-sparc/issues/14) he helped me > figure out that grub wasn't working because the kernel in /boot was gzip'd. Any reason why you aren't just using the normal Debian procedure to setup and install GRUB? > Is there something that's told Debian that I want my kernels in /boot to be > gzip'd? Is there a way to make it _not_ do that, since grub apparently > needs them not to be gzip'd on this machine? Debian stores its kernel compressed by default and I don't see how this is supposed to be a problem. All SPARCs that we have installed with Debian for sparc64 are using the grub2 package from Debian with a compressed kernel. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: GRUB is now the default bootloader on sparc64
On Fri, May 18, 2018 at 01:44:45PM +0200, John Paul Adrian Glaubitz wrote: > Hi! > > I have now disabled SILO support in debian-installer meaning that > it's no longer possible to install the SILO bootloader when installing > Debian on sparc64. > > [...] > > GRUB is fully supported on sparc64 and, from the various feedback we got > on the mailing list, should be compatible with even the oldest UltraSPARC > machines. So it will work on any machine that run Debian's sparc64 port. Hello Adrian, all. I have been working on getting grub2 running as a step in getting my t5120 running, as the list has been hearing from me. I was/am building from https://github.com/esnowberg/grub2-sparc, using the guide https://github.com/esnowberg/grub2-sparc/wiki. But, this makes me wonder, what is it you've included in the installer if the core grub2 code is not yet inclusive of these changes? (I did try to use the grub2 2.02++ that was on the host, but wasn't able to get it to install, and shifted to the above.) Thanks. I have enough balls in the air on this machine that I'm starting to think I might be better starting from scratch with grub2 now the default. I don't know where to find built ISO's since approximately the date of this email, so I want to ensure the above is effective in an ISO before trying to reinstall from such. - Chris
Re: GRUB is now the default bootloader on sparc64
On 07/02/2018 05:17 AM, Chris Ross wrote: > Hello Adrian, all. I have been working on getting grub2 running as a step > in getting my t5120 running, as the list has been hearing from me. I was/am > building from https://github.com/esnowberg/grub2-sparc, using the guide > https://github.com/esnowberg/grub2-sparc/wiki. But, this makes me wonder, > what is it you've included in the installer if the core grub2 code is not > yet inclusive of these changes? (I did try to use the grub2 2.02++ that > was on the host, but wasn't able to get it to install, and shifted to the > above.) All the sparc64-related changes in GRUB that Debian is carrying in a local patch have already been upstreamed, they are part of the master git repository of GRUB: > http://git.savannah.gnu.org/cgit/grub.git However, the current released version of GRUB - 2.02 - does not contain the changes yet, they will be part of GRUB 2.04. That's why Debian's grub2 package is still carrying an additional sparc64 patch. This patch will be dropped once 2.04 has been released and uploaded to Debian. > Thanks. I have enough balls in the air on this machine that I'm starting to > think I might be better starting from scratch with grub2 now the default. > I don't know where to find built ISO's since approximately the date of this > email, so I want to ensure the above is effective in an ISO before trying > to reinstall from such. The image found here should be fine and should install GRUB as the default bootloader on sparc64: > https://cdimage.debian.org/cdimage/ports/10.0/sparc64/iso-cd/ It might be though that both the grub-installer and partman-auto debian-installer packages are not up-to-date in this ISO yet which might lead to smaller issues. I will build updated images soonish. 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: Re: GRUB testers on SPARC needed
On Mon, Mar 05, 2018 at 11:45:16AM +0100, John Paul Adrian Glaubitz wrote: > > At least with the stretch installer there is no problem with using a MBR > > partitioning > > on the am64 arch. You maybe can't select it, but if you generate a MBR > > partitioning using > > the shell inside the installer this will work. > > Ok, after a quick look it seems that this particular configuration is actually > supported by the grub-installer: > > > https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n338 > > On EFI systems, it will test whether /var/lib/partman/ignore_uefi exists > which I > assume is written by partman if it finds an MBR partition table on an EFI > system. Thanks for this information. > > Also IMHO this (EFI partition on MBR) is usefull to work, as the server > > BIOSses here are all able > > to boot from an USB stick which usually have MBR partitioning. > > This is for installed systems, not for installer images. Yes, exactly: Booting the installed system via UEFI from usb stick. The netboot installer has no partitioning - so no issue with installer images, at least not in my case. > > As the servers used here all have an internal USB slot thats my favorite > > setup at the moments. > > Why not use a remote KVM? ;) Because netbooting rocks - or what are I'm missing ? ;-) Probably we are getting to OT now... Greetings Hermann -- Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg IWR; INF 205; 69120 Heidelberg; Tel: (06221)54-14405 Fax: -14427 Email: hermann.la...@iwr.uni-heidelberg.de
Re: Re: GRUB testers on SPARC needed
On Sat, Mar 03, 2018 at 01:09:40AM +0100, John Paul Adrian Glaubitz wrote: > On 03/02/2018 10:27 PM, Frank Scheiner wrote: > >> On x86, it will automatically use GPT if the machine is booted in EFI > >> mode. ... ... > >> I know you try to make the most compatible design to fit all use cases, > >> but I don’t think we should support such edge cases when debian-installer > >> doesn’t > >> support it on other platforms. ... > Maybe it's a good idea to perform some tests with such setups on x86 (e.g. > having MBR partitioning and then booting the machine in EFI mode and keeping > the MBR setup) and observe what debian-installer does. At least with the stretch installer there is no problem with using a MBR partitioning on the am64 arch. You maybe can't select it, but if you generate a MBR partitioning using the shell inside the installer this will work. Also IMHO this (EFI partition on MBR) is usefull to work, as the server BIOSses here are all able to boot from an USB stick which usually have MBR partitioning. As the servers used here all have an internal USB slot thats my favorite setup at the moments. Just 2cents and thank for all your work, greetings Hermann -- Netzwerkadministration/Zentrale Dienste, Interdiziplinaeres Zentrum fuer wissenschaftliches Rechnen der Universitaet Heidelberg IWR; INF 205; 69120 Heidelberg; Tel: (06221)54-14405 Fax: -14427 Email: hermann.la...@iwr.uni-heidelberg.de
Re: GRUB testers on SPARC needed
On 03/05/2018 11:32 AM, Hermann Lauer wrote: At least with the stretch installer there is no problem with using a MBR partitioning on the am64 arch. You maybe can't select it, but if you generate a MBR partitioning using the shell inside the installer this will work. Ok, after a quick look it seems that this particular configuration is actually supported by the grub-installer: https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n338 On EFI systems, it will test whether /var/lib/partman/ignore_uefi exists which I assume is written by partman if it finds an MBR partition table on an EFI system. We can most certainly add support for that later on sparc*. I just want to get a simple GRUB installation on a clean system working and we're almost there regarding that. Also IMHO this (EFI partition on MBR) is usefull to work, as the server BIOSses here are all able to boot from an USB stick which usually have MBR partitioning. This is for installed systems, not for installer images. As the servers used here all have an internal USB slot thats my favorite setup at the moments. Why not use a remote KVM? ;) Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: GRUB testers on SPARC needed
On 03/02/2018 10:27 PM, Frank Scheiner wrote: >> On x86, it will automatically use GPT if the machine is booted in EFI mode. >> On sparc64, we would normally just switch to GPT if the machine supports GPT. > > I understand. Then it's safe to just use the subarch to select how GRUB2 > should be installed, although it's really not less complex than using the > variable. The thing is - I don't want to deviate the code too much from what's doing on the other architectures. I don't necessarily disagree with you, but I just want to go along with the other architectures for the time being. However, if you're really concerned about the issue, I think we should discuss this in a separate thread and also involve the debian-boot mailing list so that we can find a common solution for all architectures. >> I know you try to make the most compatible design to fit all use cases, but >> I don’t think we should support such edge cases when debian-installer doesn’t >> support it on other platforms. > > Ok, makes sense. We can still address this once the other stuff works. You definitely have a point though that there can be cases where the current code will most likely fail. Maybe it's a good idea to perform some tests with such setups on x86 (e.g. having MBR partitioning and then booting the machine in EFI mode and keeping the MBR setup) and observe what debian-installer does. PS: I wrote "MFT" in my previous mail. I meant MBR, of course. MFT is part of NTFS. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: GRUB testers on SPARC needed
On 03/02/2018 10:10 PM, John Paul Adrian Glaubitz wrote: Well, debian-installer normally does not allow you to choose the partition table type. I remember I had a problem - which must be due to that behaviour in hindsight - when I used a GPT partitioned disk from an rx2620 in a rp3440. Although the installer created a different partition layout it continued to use the GPT partitioning scheme and whan palo should be installed it failed miserably. On x86, it will automatically use GPT if the machine is booted in EFI mode. On sparc64, we would normally just switch to GPT if the machine supports GPT. I understand. Then it's safe to just use the subarch to select how GRUB2 should be installed, although it's really not less complex than using the variable. I don’t know how debian-installer behaves if you boot an x86 machine in EFI mode which has an MFT partition table, but I think that’s not supported by debian-installer. For now it should be reasonable to assume GPT partioning on a machine that supports it and defaulting to Sun otherwise. Please don’t let‘s us over-engineer this just to be able the rare case that someone used Sun partition tables from a previous installation on a machine that supports GPT. I know you try to make the most compatible design to fit all use cases, but I don’t think we should support such edge cases when debian-installer doesn’t support it on other platforms. Ok, makes sense.
Re: GRUB testers on SPARC needed
> On Mar 2, 2018, at 9:53 PM, Frank Scheiner wrote: > > I don't think we can rely on the subarch value in this case, but have to > determine the actual partitioning scheme (available in `bootfslabel` when > running `grub-installer` or via `partmap `) to select the correct > installation method. This because at least for sun4v with GPT support users > could also manually select to use a Sun disklabel. I used the `bootfslabel` > variable in my modifcations. Well, debian-installer normally does not allow you to choose the partition table type. On x86, it will automatically use GPT if the machine is booted in EFI mode. On sparc64, we would normally just switch to GPT if the machine supports GPT. I don’t know how debian-installer behaves if you boot an x86 machine in EFI mode which has an MFT partition table, but I think that’s not supported by debian-installer. For now it should be reasonable to assume GPT partioning on a machine that supports it and defaulting to Sun otherwise. Please don’t let‘s us over-engineer this just to be able the rare case that someone used Sun partition tables from a previous installation on a machine that supports GPT. I know you try to make the most compatible design to fit all use cases, but I don’t think we should support such edge cases when debian-installer doesn’t support it on other platforms. Adrian
Re: GRUB testers on SPARC needed
Hi Adrian, On 02/27/2018 11:42 AM, John Paul Adrian Glaubitz wrote: On 02/26/2018 05:55 PM, Frank Scheiner wrote: Thanks for the upload. The new version works like version 2.02-2+sparc64.3 for me. Frank, if you like, you can help improving grub-installer for sparc64. Sure! :-) I had a first look and also did some testing. I did use the image from 2018-02-16 for my testing though, as the newer one from 2018-02-27 didn't work for me. When selecting the menu option to load additional installer components I get a red screen ("Installation step failed") and looking into the log I see the following: ``` [...] Mar 2 20:34:21 cdrom-retriever: warning: File /cdrom/dists/sid/main/debian-installer/binary-sparc64/Packages does not exist. Mar 2 20:34:21 main-menu[220]: (process:836): Segmentation fault Mar 2 20:34:21 kernel: [ 151.303940] anna[838]: segfault at 0 ip 800100497648 (rpc 800100308f74) sp 07feff91a961 error 1 in libc.so.6[80010041+15e000] Mar 2 20:34:21 main-menu[220]: WARNING **: Configuring 'load-cdrom' failed with error code 139 Mar 2 20:34:21 main-menu[220]: WARNING **: Menu item 'load-cdrom' failed. ``` As I don't have a T4 (=minimum requirement for GPT support according to Eric's wiki page) I cannot test booting from a GPT partitioned disk. But I assume I can still test GRUB installations to GPT partitioned disks. So I rewrote `/lib/partman/lib/disk-label.sh` to propose a default partitioning scheme depending on the existence of a properly named file in `/tmp`: ``` [...] sparc|sparc64) if [ -e /tmp/gpt ]; then echo gpt elif [ -e /tmp/sun ]; then echo sun else echo UNKNOWN fi;; [...] ``` ...which also works around the missing new subarch hardware detection on the older image I had to use. ## Results ## Up until now I got GRUB2 installations working automatically for disks with Sun disklabel and GPT partitioned disks. For GPT I had to manually partition the disk to get that required BIOS_GRUB partition. In the end it worked with the following layout: ``` # parted /dev/sda print Model: ATA Samsung SSD 850 (scsi) Disk /dev/sda: 250GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End SizeFile system Name Flags 1 1049kB 7340kB 6291kBbios_grub 2 7340kB 263MB 256MB ext2 3 263MB 240GB 240GB ext4 4 240GB 250GB 9796MB linux-swap(v1) ``` So we should also have a look into the recipe for GPT partitioning on sparc(64). The modifications I made autoselect (1) the partition for `/boot` as target if a Sun disklabel is used and (2) the whole disk containing the partition for `/boot` as target if the disk is GPT partitioned. A user is never asked to select a target device. Is that what we want? We have extended the hardware detection in debian-installer on sparc and sparc64 now, so that the installer can detect whether the hardware supports GPT partition tables or not. Nice. I have to say I never noticed that the subarch was always "generic" for sparc(64) up until your changes ([1]). [1]: https://anonscm.debian.org/cgit/d-i/libdebian-installer.git/commit/src/system/subarch-sparc-linux.c?id=aa1ce486176b0cb24f5783d67eb28f80128aafb3 This information should be used here: https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n628 and here: https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n853 and here: https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n867 I don't think we can rely on the subarch value in this case, but have to determine the actual partitioning scheme (available in `bootfslabel` when running `grub-installer` or via `partmap `) to select the correct installation method. This because at least for sun4v with GPT support users could also manually select to use a Sun disklabel. I used the `bootfslabel` variable in my modifcations. Up until now I tested with a single disk installed, but I'll also test with multiple disks installed in my T5220 to see if this will make any difference. I can come up with a patch the next days perhaps. This should be much smaller than the patchset for NewWorld Power Macs. Cheers, Frank
Re: GRUB testers on SPARC needed
On 02/27/2018 11:42 AM, John Paul Adrian Glaubitz wrote: I am building a new installer image necessary to work on this. Image here: https://people.debian.org/~glaubitz/debian-cd/debian-9.0-sparc64-NETINST-1.iso Note: This image might have issues, it's solely intended for working on grub-installer in case anyone else wants to use it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: GRUB testers on SPARC needed
On 02/26/2018 05:55 PM, Frank Scheiner wrote: Thanks for the upload. The new version works like version 2.02-2+sparc64.3 for me. Frank, if you like, you can help improving grub-installer for sparc64. We have extended the hardware detection in debian-installer on sparc and sparc64 now, so that the installer can detect whether the hardware supports GPT partition tables or not. On a sparc64 with GPT support, you get something like: sparc64/sun4v_gpt as the hardware type. A sparc with GPT gives: sparc/sun4v_gpt And a sparc64 which is a sun4u without GPT, gives: sparc64/sun4u_sun This information should be used here: https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n628 and here: https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n853 and here: https://anonscm.debian.org/git/d-i/grub-installer.git/tree/grub-installer#n867 For the different invocations of grub-install on Sun and GPT partition tables, see: https://github.com/esnowberg/grub2-sparc/wiki I am building a new installer image necessary to work on this. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: GRUB testers on SPARC needed
On 02/23/2018 11:38 PM, John Paul Adrian Glaubitz wrote: On 02/23/2018 11:37 PM, John Paul Adrian Glaubitz wrote: I just uploaded "2.02+dfsg1-1+sparc64.1" which fixes the problem. Just wait some hours until it shows up on the regular FTP servers or fetch it from https://incoming.debian.org/debian-buildd/pool/main/g/. Wrong link. Should be: http://incoming.ports.debian.org/ Thanks for the upload. The new version works like version 2.02-2+sparc64.3 for me. Although not that useful currently: I just tested this also with a PRIMEPOWER 250 with two SPARC64 V+ (sun4us) CPUs and guess what, GRUB(2) also works on this machine: ``` Fujitsu Siemens PRIMEPOWER250 2x SPARC64 V, No Keyboard OpenBoot 3.18.1-1, 16384 MB memory installed Ethernet address 0:b:5d:12:34:56, Host ID: 80123456. XSCF Version: 4.12.1 {0} ok boot net:dhcp Boot device: /pci@83,4000/network@1,1:dhcp File and args: 44800 screen:r1024x768x75 not found. Will use config file "(tftp)/etc/01-00-0b-5d-12-34-56" Network status of pp250-3: ofnet_gnet 00:0b:5d:12:34:56 ofnet_net0 00:0b:5d:12:34:56 ofnet_net0 00:0b:5d:12:34:56 172.16.2.109 ofnet_net0:local 172.16.0.0/16 ofnet_net0 ofnet_net0:default 0.0.0.0/0 gw 172.16.0.1 Loading Linux kernel ... Loading initial ramdisk ... [0.58] PROMLIB: Sun IEEE Boot Prom 'OBP 3.18.1 2006/01/23 17:06' [0.67] PROMLIB: Root node compatible: sun4us [0.000259] Linux version 4.15.0-1-sparc64-smp (debian-ker...@lists.debian.org) (gcc version 7.3.0 (Debian 7.3.0-3)) #1 SMP Debian 4.15.4-1 (2018-02-18) [0.295767] bootconsole [earlyprom0] enabled [0.346696] ARCH: SUN4U [0.375829] Ethernet address: 00:0b:5d:12:34:56 [0.429880] MM: PAGE_OFFSET is 0xf800 (max_phys_bits == 40) [0.508875] MM: VMALLOC [0x0001 --> 0x0600] [0.583726] MM: VMEMMAP [0x0600 --> 0x0c00] [0.659608] Kernel: Using 3 locked TLB entries for main kernel image. [0.735624] Remapping the kernel... [0.735682] done. RED State Exception ( CPU#0 ) {0} ok ``` Though downloading kernel and initramfs via TFTP is slow on this machine and the kernel crashes the machine, GRUB already works well. Nice! Cheers, Frank
Re: GRUB testers on SPARC needed
On 02/23/2018 11:37 PM, John Paul Adrian Glaubitz wrote: > I just uploaded "2.02+dfsg1-1+sparc64.1" which fixes the problem. > Just wait some hours until it shows up on the regular FTP servers or > fetch it from https://incoming.debian.org/debian-buildd/pool/main/g/. Wrong link. Should be: http://incoming.ports.debian.org/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: GRUB testers on SPARC needed
On 02/19/2018 10:26 AM, Frank Scheiner wrote: > There's a new package version (2.02+dfsg1-1) available since a few days ([1]). > > [1]: > http://metadata.ftp-master.debian.org/changelogs/main/g/grub2/grub2_2.02+dfsg1-1_changelog > > Installing it **and** using the mentioned `grub-install` command to install > it on the `/boot` partition over the previous version (2.02-2+sparc64.3) > breaks > booting with GRUB2: I just uploaded "2.02+dfsg1-1+sparc64.1" which fixes the problem. Just wait some hours until it shows up on the regular FTP servers or fetch it from https://incoming.debian.org/debian-buildd/pool/main/g/. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: GRUB testers on SPARC needed
I finally found time to test GRUB on my Netra T1. But then I saw this message and am demotivated. Please add a grub build with Erics patches to experimental. kind regards txt.file John Paul Adrian Glaubitz: > Hello! > > On 02/19/2018 10:26 AM, Frank Scheiner wrote: >> There's a new package version (2.02+dfsg1-1) available since a few >> days ([1]). >> >> [1]: >> http://metadata.ftp-master.debian.org/changelogs/main/g/grub2/grub2_2.02+dfsg1-1_changelog >> >> >> Installing it **and** using the mentioned `grub-install` command to >> install it on the `/boot` partition over the previous version >> (2.02-2+sparc64.3) breaks booting with GRUB2: > > Yes, this is something I don't have any control over. The grub2 package > will > break every time on sparc64 until GRUB 2.04 has been released with > hopefully > all of Eric's patches merged. > > Alternatively, you can try to convince Debian's GRUB maintainers (CC'ed) > that > they will merge my patch from #854568 [1]. > > Additionally, you will have to add the following in debian/rules for > sparc/sparc64: > > ifneq (,$(filter sparc sparc64,$(DEB_HOST_ARCH_CPU))) > export TARGET_LDFLAGS := -no-pie > endif > >> @Adrian: >> Could or will you provide a new package with Eric's patches included - >> assuming those are missing in 2.02+dfsg1-1? > Well, this will break over and over again, so I rather prefer getting the > patch merged into the Debian package officially. > > Adrian > >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854568 > signature.asc Description: OpenPGP digital signature
Re: GRUB testers on SPARC needed
Hi, On 02/19/2018 02:37 PM, John Paul Adrian Glaubitz wrote: Installing it **and** using the mentioned `grub-install` command to install it on the `/boot` partition over the previous version (2.02-2+sparc64.3) breaks booting with GRUB2: Yes, this is something I don't have any control over. The grub2 package will break every time on sparc64 until GRUB 2.04 has been released with hopefully all of Eric's patches merged. I see. Alternatively, you can try to convince Debian's GRUB maintainers (CC'ed) that they will merge my patch from #854568 [1]. If they couldn't be convinced by you despite all your hard work on Debian Ports, not even for the experimental suite, why should they bother about me? :-) But if someone cares: GRUB2 (w/those patches) allows network booting for sparc64 w/modern (aka huge) kernels and initram file systems - something that wasn't working properly (if at all) for a long time on sparc64. Though the selection of per MAC/IP address configuration files during startup as of now is in fact not on par with other network capable boot loaders like pxelinux or yaboot, one can still script together a somewhat similar method (see [1]). [1]: https://bugzilla.redhat.com/show_bug.cgi?id=873406#c1 In addition it works on every sparc64 (Sun-4u, Sun-4v) machine I've tested so far. Hence I consider it a must have for sparc64. And my machines see things the same way. :-) Cheers, Frank
Re: GRUB testers on SPARC needed
Hello! On 02/19/2018 10:26 AM, Frank Scheiner wrote: There's a new package version (2.02+dfsg1-1) available since a few days ([1]). [1]: http://metadata.ftp-master.debian.org/changelogs/main/g/grub2/grub2_2.02+dfsg1-1_changelog Installing it **and** using the mentioned `grub-install` command to install it on the `/boot` partition over the previous version (2.02-2+sparc64.3) breaks booting with GRUB2: Yes, this is something I don't have any control over. The grub2 package will break every time on sparc64 until GRUB 2.04 has been released with hopefully all of Eric's patches merged. Alternatively, you can try to convince Debian's GRUB maintainers (CC'ed) that they will merge my patch from #854568 [1]. Additionally, you will have to add the following in debian/rules for sparc/sparc64: ifneq (,$(filter sparc sparc64,$(DEB_HOST_ARCH_CPU))) export TARGET_LDFLAGS := -no-pie endif @Adrian: Could or will you provide a new package with Eric's patches included - assuming those are missing in 2.02+dfsg1-1? Well, this will break over and over again, so I rather prefer getting the patch merged into the Debian package officially. Adrian [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854568 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: GRUB testers on SPARC needed
On 12/08/2017 01:24 PM, John Paul Adrian Glaubitz wrote: We're in the process of migrating Debian for sparc64 from SILO to GRUB as GRUB upstream is adding support for modern SPARC machines thanks to the work of Eric Snowberg from Oracle. In order to make sure GRUB works on all machines supported by the sparc64 port, we need your help to test GRUB on your particular hardware, the older your machine, the better. So, in order to help us, please follow the guide below to install GRUB to replace SILO as your boot loader. [...] 2. Make sure you have version 2.02-2+sparc64.3 root@andi:~# apt-cache show grub2 |grep Version Version: 2.02-2+sparc64.3 root@andi:~# There's a new package version (2.02+dfsg1-1) available since a few days ([1]). [1]: http://metadata.ftp-master.debian.org/changelogs/main/g/grub2/grub2_2.02+dfsg1-1_changelog Installing it **and** using the mentioned `grub-install` command to install it on the `/boot` partition over the previous version (2.02-2+sparc64.3) breaks booting with GRUB2: ``` Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 440MHz), No Keyboard OpenBoot 3.31, 512 MB (60 ns) memory installed, Serial #12345678. Ethernet address 8:0:20:12:34:56, Host ID: 80c6bc6f. Rebooting with command: boot Boot device: disk File and args: GRUB Loading kernel.. Fast Data Access MMU Miss ok ``` @Adrian: Could or will you provide a new package with Eric's patches included - assuming those are missing in 2.02+dfsg1-1? Cheers, Frank
Re: GRUB testers on SPARC needed
Tested on a Sparc Ultra 10 workstation and it boots fine using your instructions. Had to use an image from 2016 as the newer ones from september and december 2017 did not work at all(both fail during installation). Lshw ultra description: Computer product: SUNW,375-0066 width: 64 bits *-core description: Motherboard physical id: 0 clock: 110MHz *-firmware product: SUNW,3.31 physical id: 0 logical name: /proc/device-tree *-memory description: System memory physical id: 2 size: 740MiB *-cpu physical id: 3 bus info: cpu@0 *-pci:0 description: PCI bridge product: Simba Advanced PCI Bridge vendor: Oracle/SUN physical id: 1 bus info: pci@:00:01.0 version: 13 width: 32 bits clock: 66MHz capabilities: pci normal_decode bus_master resources: ioport:0(size=12582912) memory:1ff-1ffbfff *-usb:0 description: USB controller product: VT82xx/62xx UHCI USB 1.1 Controller vendor: VIA Technologies, Inc. physical id: 1 bus info: pci@:02:01.0 version: 61 width: 32 bits clock: 33MHz capabilities: pm uhci bus_master cap_list configuration: driver=uhci_hcd latency=22 resources: irq:15 ioport:400(size=32) *-usbhost product: UHCI Host Controller vendor: Linux 4.14.0-3-sparc64 uhci_hcd physical id: 1 bus info: usb@2 logical name: usb2 version: 4.14 capabilities: usb-1.10 configuration: driver=hub slots=2 speed=12Mbit/s *-usb:1 description: USB controller product: VT82xx/62xx UHCI USB 1.1 Controller vendor: VIA Technologies, Inc. physical id: 1.1 bus info: pci@:02:01.1 version: 61 width: 32 bits clock: 33MHz capabilities: pm uhci bus_master cap_list configuration: driver=uhci_hcd latency=22 resources: irq:16 ioport:420(size=32) *-usbhost product: UHCI Host Controller vendor: Linux 4.14.0-3-sparc64 uhci_hcd physical id: 1 bus info: usb@3 logical name: usb3 version: 4.14 capabilities: usb-1.10 configuration: driver=hub slots=2 speed=12Mbit/s *-usb:2 description: USB controller product: USB 2.0 vendor: VIA Technologies, Inc. physical id: 1.2 bus info: pci@:02:01.2 version: 63 width: 32 bits clock: 33MHz capabilities: pm ehci bus_master cap_list configuration: driver=ehci-pci latency=22 resources: irq:17 memory:1ff2000-1ff20ff *-usbhost product: EHCI Host Controller vendor: Linux 4.14.0-3-sparc64 ehci_hcd physical id: 1 bus info: usb@1 logical name: usb1 version: 4.14 capabilities: usb-2.00 configuration: driver=hub slots=4 speed=480Mbit/s *-firewire description: FireWire (IEEE 1394) product: VT6306/7/8 [Fire II(M)] IEEE 1394 OHCI Controller vendor: VIA Technologies, Inc. physical id: 1.3 bus info: pci@:02:01.3 version: 46 width: 32 bits clock: 33MHz capabilities: pm ohci bus_master cap_list configuration: driver=firewire_ohci latency=0 maxlatency=32 resources: irq:15 memory:1ff4000-1ff47ff ioport:480(size=128) *-multimedia UNCLAIMED description: Multimedia audio controller product: EMU10k1 [Sound Blaster Live! Series] vendor: Creative Labs physical id: 2 bus info: pci@:02:02.0 version: 07 width: 32 bits clock: 33MHz capabilities: pm cap_list configuration: latency=0 maxlatency=20 mingnt=2 resources: ioport:800(size=32) *-input UNCLAIMED description: Input device controller product: SB Live! Game Port vendor: Creative Labs physical id: 2.1 bus info: pci@:02:02.1 version: 07 width: 32 bits clock: 33MHz capabilities: pm cap_list configurati
Re: GRUB testers on SPARC needed
Hi Adrian, hi Eric, thanks for getting GRUB2 with support for sparc64 into Debian Ports. Looks very good so far. :-D On 12/08/2017 01:24 PM, John Paul Adrian Glaubitz wrote: root@andi:~# 7. Report back to the list and include your hardware and partition setup I had some spare time these days and tested on the following machines: ## Machines tested ## * Sun Enterprise 250 * Sun Ultra 80 * Sun Enterprise 4500 * Sun Fire V240 * Sun Fire V445 * Sun SPARC Enterprise T1000 ## General information ## I started with my Ultra 80 but wasn't able to successfully install Debian Sid (from the sparc64 ISO from 2017-12-04 created by Adrian) - the installation process always blocks during partman startup (always at 33%) but sadly for no obvious reason (nothing specific in syslog). Later I sucessfully installed Debian Sid with the mentioned ISO on a V240 and moved its disk to the other machines with parallel SCSI SCA ports (Ultra 80, E250). When running `update-grub` GRUB2 configures the "root" device by using a "search hint" with the OF path for the partition containing `/boot` on the currently used machine: e.g. from `/boot/grub/grub.cfg` on E250: ``` [...] set root='hd0,sun1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-ieee1275='ieee1275//pci@1f\,4000/scsi@3/disk@0\,0,sun1' --hint-bios=hd0,sun1 --hint-efi=hd0,sun1 --hint-baremetal=ahci0,sun1 df9a392d-2dc5-4981-b6f9-57476351d51b else search --no-floppy --fs-uuid --set=root df9a392d-2dc5-4981-b6f9-57476351d51b fi [...] ``` ...but when moving the disk to a different machine with different bus structure and different devices this OF path usually does not exist there, so GRUB2 won't be able to find the correct "root" device. Fortunately it's possible to use available OF device aliases in GRUB2 by e.g. `set root='ieee1275/disk,1'`, where "disk" is a device alias which usually translates to the very first disk and ",1" selects the partition which contains `/boot`. So to boot successfully the easiest way for me was to modify the device setting for the "root" device of GRUB2 (`set root=[...]`) and remove the whole if clause below it. This can be done directly from the GRUB2 menu on startup (select the desired entry and hit the "e" key). When booted, a call to `update-grub` should configure the correct search hint and this change won't be needed any longer (works on E250, V240 and V445, not tested on Ultra 80 and not working on E4500). ## Specific information ## UPDATE: V445 and V240 tested with Linux kernel v4.14.2. E250, E4500, Ultra 80 and T1000 tested with both v4.14.2 and v4.14.7. ### Enterprise 250 ### * 2 x UltraSPARC II @ 400 MHz * partition layout => same as on the V240 * booting via GRUB2 works * installation from ISO not tested, used SCSI SCA disk from V240 ### Ultra 80 ### * 4 x UltraSPARC II @ 450 MHz * partition layout => same as on the V240 * booting via GRUB2 works * installation does not succeed (see above), used SCSI SCA disk from V240 ### Enterprise 4500 ### * 14 x UltraSPARC II @ 400 MHz * partition layout => similar to the one on the V240 * booting via GRUB2 works, but problems with console (handover - I assume) during kernel boot (at least with the MP kernel, the SP kernel from the installer and the Debian Sid repo work without issues but leave me with 13 unused CPUs, which is a pity :-/) * installation from ISO worked somehow: the GRUB2 installer suggests to install into MBR although the disk has a Sun disk label on it. I selected /dev/sda1 manually (assuming an installation in the MBR would overwrite the Sun disk label) and it looks like it worked. On reboot though I noticed, that there was no ieee1275 search hint in the grub.cfg entry (see above for an entry for E250), hence booting didn't work without manual intervention (i.e. setting "root" to "ieee1275/disk,1"). ### Fire V240 ### * 2 x UltraSPARC IIIi @ 1 GHz * partition layout: ``` # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT [...] sda 8:00 33.9G 0 disk ├─sda1 8:10 94.1M 0 part /boot ├─sda2 8:20 22.3G 0 part / ├─sda3 8:30 33.9G 0 part └─sda4 8:40 11.6G 0 part [SWAP] [...] ``` * booting via GRUB2 works * installation from ISO worked, but I only installed SILO from ISO first, GRUB2 was installed manually later (as per Adrian's howto). ### Fire V445 ### * 4 x UltraSPARC IIIi @ 1.59 GHz * partition layout similar to layout on V240, but as the machine since the latest package upgrades no longer successfully boots I cannot get the lsblk output :-( * booting via GRUB2 works * initially used an updated SATA disk from a V245 with Debian Sid and installed GRUB2 manually but a later installation from ISO and a SAS disk also worked (but similar situation as for E4500, i.e. GRUB2 proposed installation to MBR although the disk has a Sun disk label on it, but at least a correct ieee1275 se
Re: GRUB testers on SPARC needed
I tested it on a SunFire V440 and it is booting. I plan to test it also on a Sun Netra T1. root@txt-sunfire-v440:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:00 67.9G 0 disk ├─sda1 8:10 94.1M 0 part /boot ├─sda2 8:20 67.8G 0 part │ ├─txt--sunfire--v440--vg-root 254:00 11.7G 0 lvm / │ ├─txt--sunfire--v440--vg-swap_1 254:10 7.7G 0 lvm [SWAP] │ ├─txt--sunfire--v440--vg-var254:20 4.2G 0 lvm /var │ ├─txt--sunfire--v440--vg-tmp254:30 800M 0 lvm /tmp │ └─txt--sunfire--v440--vg-home 254:40 43.5G 0 lvm /home └─sda3 8:30 67.9G 0 part sr011:01 1024M 0 rom root@txt-sunfire-v440:~# kind regards txt.file John Paul Adrian Glaubitz: > Hi! > > We're in the process of migrating Debian for sparc64 from SILO to GRUB > as GRUB upstream is adding support for modern SPARC machines thanks to > the work of Eric Snowberg from Oracle. > > In order to make sure GRUB works on all machines supported by the sparc64 > port, we need your help to test GRUB on your particular hardware, the older > your machine, the better. > > So, in order to help us, please follow the guide below to install GRUB to > replace SILO as your boot loader. > > NOTE: If your system doesn't boot after installing GRUB, don't panic. Use > the current Debian sparc64 installation image and boot into rescue > mode by typing "rescue". Then chroot into your installed system and > just run "silo -t -f" to restore SILO on your machine. > > 1. Install the grub2 package: > > root@andi:~# apt install grub2 > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following additional packages will be installed: > grub-common grub-ieee1275 grub-ieee1275-bin grub2-common libfreetype6 > libfuse2 libpng16-16 os-prober > Suggested packages: > multiboot-doc xorriso desktop-base console-setup fuse > The following NEW packages will be installed: > grub-common grub-ieee1275 grub-ieee1275-bin grub2 grub2-common libfreetype6 > libfuse2 libpng16-16 os-prober > 0 upgraded, 9 newly installed, 0 to remove and 0 not upgraded. > Need to get 4,556 kB of archives. > After this operation, 23.6 MB of additional disk space will be used. > Do you want to continue? [Y/n] y > Get:1 http://ftp.ports.debian.org/debian-ports unstable/main sparc64 > libpng16-16 sparc64 1.6.34-1 [271 kB] > (...) > > Creating config file /etc/default/grub with new version > Setting up grub2 (2.02-2+sparc64.3) ... > root@andi:~# > > 2. Make sure you have version 2.02-2+sparc64.3 > > root@andi:~# apt-cache show grub2 |grep Version > Version: 2.02-2+sparc64.3 > root@andi:~# > > 3. Find your boot partition: > > root@andi:~# mount |grep /boot > /dev/sda1 on /boot type ext3 (rw,relatime,data=ordered) > root@andi:~# > > If you don't have one but just one root file system, grep for " / " instead > > 4. Install grub into your boot partition: > > root@andi:~# grub-install --force --skip-fs-probe /dev/sda1 > Installing for sparc64-ieee1275 platform. > grub-install: warning: Discarding improperly nested partition > (hostdisk//dev/sda,sun1,sun2). > grub-install: warning: Discarding improperly nested partition > (hostdisk//dev/sda,sun1,sun4). > grub-install: warning: Attempting to install GRUB to a disk with multiple > partition labels. This is not supported yet.. > grub-install: warning: Embedding is not possible. GRUB can only be installed > in this setup by using blocklists. However, blocklists are UNRELIABLE and > their use is discouraged.. > Installation finished. No error reported. > root@andi:~# > > Note: If you are using GPT partition tables instead of Sun partition > tables, you need to install GRUB into /dev/sda > (see: https://github.com/esnowberg/grub2-sparc/wiki) > > 5. Run update-grub: > > root@andi:~# update-grub > Generating grub configuration file ... > Found linux image: /boot/vmlinuz-4.14.0-1-sparc64-smp > Found initrd image: /boot/initrd.img-4.14.0-1-sparc64-smp > Found linux image: /boot/vmlinuz-4.14.0-trunk-sparc64-smp > Found initrd image: /boot/initrd.img-4.14.0-trunk-sparc64-smp > Found linux image: /boot/vmlinuz-4.14.0-rc7-sparc64-smp > Found initrd image: /boot/initrd.img-4.14.0-rc7-sparc64-smp > Found linux image: /boot/vmlinuz-4.14.0-rc5-sparc64-smp > Found initrd image: /boot/initrd.img-4.14.0-rc5-sparc64-smp > Found linux image: /boot/vmlinuz-4.12.0-rc1-sparc64-smp > Found initrd image: /boot/initrd.img-4.12.0-rc1-sparc64-smp > Found linux image: /boot/vmlinuz-4.11.0-trunk-sparc64-smp > Found initrd image: /boot/initrd.img-4.11.0-trunk-sparc64-smp > Found linux image: /boot/vmlinuz-4.10.0-trunk-sparc64-smp > Found initrd image: /boot/initrd.img-4.10.0-trunk-sparc64-smp > Found Debian GNU/Linux buster/sid on /dev/md0p1 > done > root@andi:~# >
Re: GRUB testers on SPARC needed
Hi Tony! On 12/16/2017 09:45 AM, Tony Rodriguez wrote: > FYI, as requested, successfully installed Debian 9 using grub2 on my sun > T5120 and T4-2. Thanks! I'm starting to get confident now that we will be able to completely replace SILO with GRUB on sparc and sparc64 :). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: GRUB testers on SPARC needed
FYI, as requested, successfully installed Debian 9 using grub2 on my sun T5120 and T4-2. Tony Rodriguez On 12/08/2017 04:24 AM, John Paul Adrian Glaubitz wrote: Hi! We're in the process of migrating Debian for sparc64 from SILO to GRUB as GRUB upstream is adding support for modern SPARC machines thanks to the work of Eric Snowberg from Oracle. In order to make sure GRUB works on all machines supported by the sparc64 port, we need your help to test GRUB on your particular hardware, the older your machine, the better. So, in order to help us, please follow the guide below to install GRUB to replace SILO as your boot loader. NOTE: If your system doesn't boot after installing GRUB, don't panic. Use the current Debian sparc64 installation image and boot into rescue mode by typing "rescue". Then chroot into your installed system and just run "silo -t -f" to restore SILO on your machine. 1. Install the grub2 package: root@andi:~# apt install grub2 Reading package lists... Done Building dependency tree Reading state information... Done The following additional packages will be installed: grub-common grub-ieee1275 grub-ieee1275-bin grub2-common libfreetype6 libfuse2 libpng16-16 os-prober Suggested packages: multiboot-doc xorriso desktop-base console-setup fuse The following NEW packages will be installed: grub-common grub-ieee1275 grub-ieee1275-bin grub2 grub2-common libfreetype6 libfuse2 libpng16-16 os-prober 0 upgraded, 9 newly installed, 0 to remove and 0 not upgraded. Need to get 4,556 kB of archives. After this operation, 23.6 MB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 http://ftp.ports.debian.org/debian-ports unstable/main sparc64 libpng16-16 sparc64 1.6.34-1 [271 kB] (...) Creating config file /etc/default/grub with new version Setting up grub2 (2.02-2+sparc64.3) ... root@andi:~# 2. Make sure you have version 2.02-2+sparc64.3 root@andi:~# apt-cache show grub2 |grep Version Version: 2.02-2+sparc64.3 root@andi:~# 3. Find your boot partition: root@andi:~# mount |grep /boot /dev/sda1 on /boot type ext3 (rw,relatime,data=ordered) root@andi:~# If you don't have one but just one root file system, grep for " / " instead 4. Install grub into your boot partition: root@andi:~# grub-install --force --skip-fs-probe /dev/sda1 Installing for sparc64-ieee1275 platform. grub-install: warning: Discarding improperly nested partition (hostdisk//dev/sda,sun1,sun2). grub-install: warning: Discarding improperly nested partition (hostdisk//dev/sda,sun1,sun4). grub-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet.. grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.. Installation finished. No error reported. root@andi:~# Note: If you are using GPT partition tables instead of Sun partition tables, you need to install GRUB into /dev/sda (see: https://github.com/esnowberg/grub2-sparc/wiki) 5. Run update-grub: root@andi:~# update-grub Generating grub configuration file ... Found linux image: /boot/vmlinuz-4.14.0-1-sparc64-smp Found initrd image: /boot/initrd.img-4.14.0-1-sparc64-smp Found linux image: /boot/vmlinuz-4.14.0-trunk-sparc64-smp Found initrd image: /boot/initrd.img-4.14.0-trunk-sparc64-smp Found linux image: /boot/vmlinuz-4.14.0-rc7-sparc64-smp Found initrd image: /boot/initrd.img-4.14.0-rc7-sparc64-smp Found linux image: /boot/vmlinuz-4.14.0-rc5-sparc64-smp Found initrd image: /boot/initrd.img-4.14.0-rc5-sparc64-smp Found linux image: /boot/vmlinuz-4.12.0-rc1-sparc64-smp Found initrd image: /boot/initrd.img-4.12.0-rc1-sparc64-smp Found linux image: /boot/vmlinuz-4.11.0-trunk-sparc64-smp Found initrd image: /boot/initrd.img-4.11.0-trunk-sparc64-smp Found linux image: /boot/vmlinuz-4.10.0-trunk-sparc64-smp Found initrd image: /boot/initrd.img-4.10.0-trunk-sparc64-smp Found Debian GNU/Linux buster/sid on /dev/md0p1 done root@andi:~# 6. Reboot: root@andi:~# 7. Report back to the list and include your hardware and partition setup Thanks, Adrian
Re: GRUB testers on SPARC needed
On 11/12/17 22:00, Frans van Berckel wrote: Hi Mark, On Mon, 2017-12-11 at 21:23 +, Mark Morgan Lloyd wrote: On 08/12/17 12:30, John Paul Adrian Glaubitz wrote: So, in order to help us, please follow the guide below to install GRUB to replace SILO as your boot loader. NOTE: If your system doesn't boot after installing GRUB, don't panic. Use the current Debian sparc64 installation image From where? The "Regularly updated" link on https://wiki.debian.org/Sparc64 doesn't have any SPARC stuff. You're right. Please checkout, where all ports are saved now. https://cdimage.debian.org/cdimage/ports/ Thanks Frans, using it to test a new router and will try installing over the next day or so. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: GRUB testers on SPARC needed
Hi Mark, On Mon, 2017-12-11 at 21:23 +, Mark Morgan Lloyd wrote: > On 08/12/17 12:30, John Paul Adrian Glaubitz wrote: > > > So, in order to help us, please follow the guide below to install > > GRUB to > > replace SILO as your boot loader. > > > > NOTE: If your system doesn't boot after installing GRUB, don't > > panic. Use > >the current Debian sparc64 installation image > > From where? The "Regularly updated" link on > https://wiki.debian.org/Sparc64 doesn't have any SPARC stuff. You're right. Please checkout, where all ports are saved now. https://cdimage.debian.org/cdimage/ports/ Thanks, Frans van Berckel
Re: GRUB testers on SPARC needed
On 08/12/17 12:30, John Paul Adrian Glaubitz wrote: So, in order to help us, please follow the guide below to install GRUB to replace SILO as your boot loader. NOTE: If your system doesn't boot after installing GRUB, don't panic. Use the current Debian sparc64 installation image From where? The "Regularly updated" link on https://wiki.debian.org/Sparc64 doesn't have any SPARC stuff. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]
Re: GRUB testers on SPARC needed
On Fri, 2017-12-08 at 14:37 +0100, Frans van Berckel wrote: > On Fri, 2017-12-08 at 14:28 +0100, John Paul Adrian Glaubitz wrote: > > > > So, I assume this means GRUB works as expected? > > > > Do you get the normal boot menu? Does everything work? > > Yes, yes and yes. About grub.conf the header section ... ### BEGIN /etc/grub.d/00_header ### at if [ x$feature_default_font_path = xy ] ; then font=unicode else insmod part_sun insmod part_sun insmod diskfilter insmod mdraid1x insmod ext2 The part_sun module is called twice. Thanks, Frans van Berckel
Re: GRUB testers on SPARC needed
There is no separate ISO. You can just choose to install GRUB instead of SILO when you install your machine with the current ISO. Just go back to the main menu instead of finishing the installation at the last installation step. Then choose „Install GRUB boot loader“, ignore the two errors about missing packages and install into /dev/BOOTDISK1 where BOOTDISK is your boot disk (e.g. sda or vdiska). Adrian > On Dec 8, 2017, at 4:27 PM, Tony Rodriguez wrote: > > Please provide a link to the latest ISO with grub support for sparc64. I will > happy to test if it works on my t5120, t5140, and T4-2 systems. > > Tony > >> On 12/08/2017 05:27 AM, Frans van Berckel wrote: >> Hi Adrian, >> >>> On Fri, 2017-12-08 at 13:24 +0100, John Paul Adrian Glaubitz wrote: >>> Hi! >>> >>> We're in the process of migrating Debian for sparc64 from SILO to >>> GRUB as GRUB upstream is adding support for modern SPARC machines >>> thanks to the work of Eric Snowberg from Oracle. >>> >>> In order to make sure GRUB works on all machines supported by the >>> sparc64 port, we need your help to test GRUB on your particular >>> hardware, the older your machine, the better. >>> 7. Report back to the list and include your hardware and partition >>> setup >> Probing system devices >> Probing memory >> Probing I/O buses >> screen not found. >> keyboard not found. >> Keyboard not present. Using ttya for input and output. >> Probing system devices >> Probing memory >> Probing I/O buses >> >> Sun Fire V440, No Keyboard >> Copyright 2010 Sun Microsystems, Inc. All rights reserved. >> OpenBoot 4.30.4.a, 20480 MB memory installed, Serial #57654521. >> Ethernet address 0:3:ba:6f:bc:f9, Host ID: 836fbcf9. >> >> booting with command: boot >> Boot device: disk File and args: >> >> GRUB Loading kernel... >> screen not found. >> error: out of memory. >> error: no suitable video mode found. >> >> GNU GRUB version 2.02-2+sparc64.3 >> >> Loading Linux 4.13.0-1-sparc64-smp ... >> >> # lsblk >> >> NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT >> sda 8:00 136.7G 0 disk >> ├─sda18:10 902.1M 0 part /boot >> ├─sda28:20 135.9G 0 part >> │ └─md0 9:00 135.7G 0 raid1 / >> └─sda38:30 136.7G 0 part >> sdb 8:16 0 136.7G 0 disk >> ├─sdb18:17 0 902.1M 0 part >> ├─sdb28:18 0 135.9G 0 part >> │ └─md0 9:00 135.7G 0 raid1 / >> └─sdb38:19 0 136.7G 0 part >> sdc 8:32 0 33.9G 0 disk >> ├─sdc18:33 030G 0 part >> │ └─md1 9:1030G 0 raid1 /home >> └─sdc28:34 0 3.9G 0 part [SWAP] >> sdd 8:48 0 33.9G 0 disk >> ├─sdd18:49 030G 0 part >> │ └─md1 9:1030G 0 raid1 /home >> └─sdd28:50 0 3.9G 0 part [SWAP] >> sr0 11:01 197.2M 0 rom >> >> The sda and sdb are Sun, sdc and sdd are GTP. >> >> # uname -a >> >> Linux deblnxsrv211 4.13.0-1-sparc64-smp #1 SMP Debian 4.13.4-2 (2017- >> 10-15) sparc64 GNU/Linux >> >> Thanks, >> >> >> Frans van Berckel >>
Re: GRUB testers on SPARC needed
Please provide a link to the latest ISO with grub support for sparc64. I will happy to test if it works on my t5120, t5140, and T4-2 systems. Tony On 12/08/2017 05:27 AM, Frans van Berckel wrote: Hi Adrian, On Fri, 2017-12-08 at 13:24 +0100, John Paul Adrian Glaubitz wrote: Hi! We're in the process of migrating Debian for sparc64 from SILO to GRUB as GRUB upstream is adding support for modern SPARC machines thanks to the work of Eric Snowberg from Oracle. In order to make sure GRUB works on all machines supported by the sparc64 port, we need your help to test GRUB on your particular hardware, the older your machine, the better. 7. Report back to the list and include your hardware and partition setup Probing system devices Probing memory Probing I/O buses screen not found. keyboard not found. Keyboard not present. Using ttya for input and output. Probing system devices Probing memory Probing I/O buses Sun Fire V440, No Keyboard Copyright 2010 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.30.4.a, 20480 MB memory installed, Serial #57654521. Ethernet address 0:3:ba:6f:bc:f9, Host ID: 836fbcf9. booting with command: boot Boot device: disk File and args: GRUB Loading kernel... screen not found. error: out of memory. error: no suitable video mode found. GNU GRUB version 2.02-2+sparc64.3 Loading Linux 4.13.0-1-sparc64-smp ... # lsblk NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:00 136.7G 0 disk ├─sda18:10 902.1M 0 part /boot ├─sda28:20 135.9G 0 part │ └─md0 9:00 135.7G 0 raid1 / └─sda38:30 136.7G 0 part sdb 8:16 0 136.7G 0 disk ├─sdb18:17 0 902.1M 0 part ├─sdb28:18 0 135.9G 0 part │ └─md0 9:00 135.7G 0 raid1 / └─sdb38:19 0 136.7G 0 part sdc 8:32 0 33.9G 0 disk ├─sdc18:33 030G 0 part │ └─md1 9:1030G 0 raid1 /home └─sdc28:34 0 3.9G 0 part [SWAP] sdd 8:48 0 33.9G 0 disk ├─sdd18:49 030G 0 part │ └─md1 9:1030G 0 raid1 /home └─sdd28:50 0 3.9G 0 part [SWAP] sr0 11:01 197.2M 0 rom The sda and sdb are Sun, sdc and sdd are GTP. # uname -a Linux deblnxsrv211 4.13.0-1-sparc64-smp #1 SMP Debian 4.13.4-2 (2017- 10-15) sparc64 GNU/Linux Thanks, Frans van Berckel
Re: GRUB testers on SPARC needed
On Fri, 2017-12-08 at 14:28 +0100, John Paul Adrian Glaubitz wrote: > On 12/08/2017 02:27 PM, Frans van Berckel wrote: > > Sun Fire V440, No Keyboard > > Copyright 2010 Sun Microsystems, Inc. All rights reserved. > > OpenBoot 4.30.4.a, 20480 MB memory installed, Serial #57654521. > > Ethernet address 0:3:ba:6f:bc:f9, Host ID: 836fbcf9. > > > > booting with command: boot > > Boot device: disk File and args: > > > > GRUB Loading kernel... > > screen not found. > > error: out of memory. > > error: no suitable video mode found. > > > > GNU GRUB version 2.02-2+sparc64.3 > > > > Loading Linux 4.13.0-1-sparc64-smp ... > > So, I assume this means GRUB works as expected? > > Do you get the normal boot menu? Does everything work? Yes, yes and yes. Thanks, Frans van Berckel
Re: GRUB testers on SPARC needed
On 12/08/2017 02:27 PM, Frans van Berckel wrote: Sun Fire V440, No Keyboard Copyright 2010 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.30.4.a, 20480 MB memory installed, Serial #57654521. Ethernet address 0:3:ba:6f:bc:f9, Host ID: 836fbcf9. booting with command: boot Boot device: disk File and args: GRUB Loading kernel... screen not found. error: out of memory. error: no suitable video mode found. GNU GRUB version 2.02-2+sparc64.3 Loading Linux 4.13.0-1-sparc64-smp ... So, I assume this means GRUB works as expected? Do you get the normal boot menu? Does everything work? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: GRUB testers on SPARC needed
Hi Adrian, On Fri, 2017-12-08 at 13:24 +0100, John Paul Adrian Glaubitz wrote: > Hi! > > We're in the process of migrating Debian for sparc64 from SILO to > GRUB as GRUB upstream is adding support for modern SPARC machines > thanks to the work of Eric Snowberg from Oracle. > > In order to make sure GRUB works on all machines supported by the > sparc64 port, we need your help to test GRUB on your particular > hardware, the older your machine, the better. > 7. Report back to the list and include your hardware and partition > setup Probing system devices Probing memory Probing I/O buses screen not found. keyboard not found. Keyboard not present. Using ttya for input and output. Probing system devices Probing memory Probing I/O buses Sun Fire V440, No Keyboard Copyright 2010 Sun Microsystems, Inc. All rights reserved. OpenBoot 4.30.4.a, 20480 MB memory installed, Serial #57654521. Ethernet address 0:3:ba:6f:bc:f9, Host ID: 836fbcf9. booting with command: boot Boot device: disk File and args: GRUB Loading kernel... screen not found. error: out of memory. error: no suitable video mode found. GNU GRUB version 2.02-2+sparc64.3 Loading Linux 4.13.0-1-sparc64-smp ... # lsblk NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:00 136.7G 0 disk ├─sda18:10 902.1M 0 part /boot ├─sda28:20 135.9G 0 part │ └─md0 9:00 135.7G 0 raid1 / └─sda38:30 136.7G 0 part sdb 8:16 0 136.7G 0 disk ├─sdb18:17 0 902.1M 0 part ├─sdb28:18 0 135.9G 0 part │ └─md0 9:00 135.7G 0 raid1 / └─sdb38:19 0 136.7G 0 part sdc 8:32 0 33.9G 0 disk ├─sdc18:33 030G 0 part │ └─md1 9:1030G 0 raid1 /home └─sdc28:34 0 3.9G 0 part [SWAP] sdd 8:48 0 33.9G 0 disk ├─sdd18:49 030G 0 part │ └─md1 9:1030G 0 raid1 /home └─sdd28:50 0 3.9G 0 part [SWAP] sr0 11:01 197.2M 0 rom The sda and sdb are Sun, sdc and sdd are GTP. # uname -a Linux deblnxsrv211 4.13.0-1-sparc64-smp #1 SMP Debian 4.13.4-2 (2017- 10-15) sparc64 GNU/Linux Thanks, Frans van Berckel
Re: grub
On Fri, 03 Jun 2005 08:17:29 +0200 Andreas Schindler <[EMAIL PROTECTED]> wrote: > Martín Marqués wrote: > > Why isn't there a version of grub for Linux SPARC? > > > Because SILO is much better ;-) Heh heh :) Which reminds me, is thhe Sparc version of 3.0r6 out already? I am running 3.0r5 on an Ultra 5 right now and I THINK I have all the updates since I run both apt-get update and apt-get upgrade on almost a daily basis.
Re: grub
Martín Marqués wrote: Why isn't there a version of grub for Linux SPARC? Because SILO is much better ;-) Andreas -- Dr.-Ing. Andreas Schindler Alpha Zero One Computersysteme GmbH Frankfurter Str. 141 63303 Dreieich Telefon 06103-57187-21 Telefax 06103-373245 [EMAIL PROTECTED] www.az1.de
Re: grub
On Thu, 2 Jun 2005, Vincent Pelletier wrote: I added support for SUN disklabel in grub2 (still in development) and I have been working on making it boot on my usparc IIi, but with little success. All I've been able to was getting the OF vector from registers, but I haven't been able to call any function that need args or return value, so all I was able to was to call "exit", which falls back to the OF prompt (everyone : wow, useful). I haven't worked on it for a few months because I wasn't able to find a doc that was correct & complete : the few I found were either explaining how to use OF prompt, or telling me the function vector was in a register that contained 0 on my box... If anyone knows how to make that work, with as few ASM as possible, I would be happy to again put my hands inside that code. Vincent Pelletier Hi Vincent, I don't have any direct advice for you, but I know that Jeff Bailey ([EMAIL PROTECTED]) is working on sparc support for grub2 as a summer project. You might want to coordinate with him, if you are interested in this. Best regards, Jurij Smakov[EMAIL PROTECTED] Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: grub
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frans Pop wrote: > Because Sparc uses the SUN disklabel for boot disks and not the msdos > disklabel and grub does not support the SUN disklabel. Not only... I added support for SUN disklabel in grub2 (still in development) and I have been working on making it boot on my usparc IIi, but with little success. All I've been able to was getting the OF vector from registers, but I haven't been able to call any function that need args or return value, so all I was able to was to call "exit", which falls back to the OF prompt (everyone : wow, useful). I haven't worked on it for a few months because I wasn't able to find a doc that was correct & complete : the few I found were either explaining how to use OF prompt, or telling me the function vector was in a register that contained 0 on my box... If anyone knows how to make that work, with as few ASM as possible, I would be happy to again put my hands inside that code. Vincent Pelletier -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCnww3FEQoKRQyjtURAhQIAJ9JMQMpDVObGW+64MrZnibBoweRQACeL+qi B/oRM+Yz5GzmPeJA1NtSKIg= =WtrW -END PGP SIGNATURE- _ Découvrez le nouveau Yahoo! Mail : 1 Go d'espace de stockage pour vos mails, photos et vidéos ! Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: grub
On Thursday 02 June 2005 14:03, Martín Marqués wrote: > Why isn't there a version of grub for Linux SPARC? Because Sparc uses the SUN disklabel for boot disks and not the msdos disklabel and grub does not support the SUN disklabel. Cheers, FJP pgpAp9WdshQCk.pgp Description: PGP signature