Re: SPARC Issues Open for Conjecture
On 06/11/2016 03:58 PM, alexmcwhirter@triadic.us wrote:
> Something else i've noticed with this is that full systemd has no issues initialing this hardware automatically. Take for example the sun hme nic driver. The
> installation cd doesn't load it automatically, but when you boot into the finished installation it will initialize fine. Granted you still have to manually add
> at least the scsi controller into initramfs in order to get to systemd. But, if i only add the qlogicpti driver in /etc/initramfs-tools/modules (which is where
> my hard disks are), after initramfs has finished up and switches root to the hard disk systemd will load snu_esp and sun_hme without issue.
>
> Im just assuming at this point, but i would guess that udev is being compiled separately from systemd for the initramfs of both the installer and the generic
> initramfs? I can't see any reason as to why full systemd would be in the initramfs.
systemd isn't doing any module loading, that's solely done by udevd. However, there might be different udev rules defined when comparing a full system
installation with debian-installer. udevd itself should behave the same way in debian-installer it behaves in a full installation.
>> You want to build 11,000 packages from source? Why? There isn't
>> anything to gain from, really.
>>
>> Also, buildd is not an internal tool, it's part of the sbuild package
>> and you can just install
>> it yourself. You just need a wanna-build server to interact with.
>>
>
> The primary motivation behind me working on sparc is for work. We run internal forks of distributions as we apply a lot of custom tweaks and customizations that
> debian (or any distro for that matter) would not want to adopt. So in that case it's easier for us to have an on site source tree, build server, and package
> repo so we can easily distribute it to our machines.
>
> Granted i don't need all 11,000 packages. We would dial it down considerably based on the software we need.
That is actually common practice. You set up a mini-dinstall server which will maintain all the Debian packages and
build any packages manually with sbuild for the distribution of choice (stable, testing, unstable etc). If you just
need to build for one machine, you can also just use apt-build.
>>> ZFS actually works great on most sparc boxes, but i don't know where debian stands on it with the CDDL debate. That's an issue for another time i suppose.
>>> Regardless the installer in fact doesn't have the ZFS modules included (probably because they fail to build on SPARC without some minor patching). The
>>> partitioner attempts to load them, but they are missing so it just keep chugging along without them, which is fine for now.
>>
>> Debian ships with zfslinux now, although the module itself is
>> source-only. We use DKMS for installation.
>>
>
> Good to know, I'll dig through some of my gentoo patches and get them to the list. I haven't had time to try to install ZFS yet here, but i know if isa_defs.h
> isn't patched for sparc64 it wont build. I need to submit them to upstream as well, there's some logic in there that really doesn't make any sense.
If you find that zfs-linux doesn't build on sparc64, you can file a bug report here, attach your patch if you have one:
> https://packages.qa.debian.org/z/zfs-linux.html
>>> Will do, i have a feeling that we should avoid patching the installer and just make sure the CD has everything in place to work with it if possible.
>>
>> Debian Installer has lots of architecture-specific code and that code
>> sometimes needs some
>> patching, there is nothing wrong with that.
>>
>> Adrian
>
> Also good to know, i haven't had time to look at it yet. reprepro is still going to town...
Yeah, the first sync takes quite some time.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: