[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SPARC Issues Open for Conjecture



On 2016-06-11 05:06, John Paul Adrian Glaubitz wrote:
On 06/10/2016 08:31 PM, alexmcwhirter@triadic.us wrote:
Something that might be worth doing it having the install check loaded modules on initialization, then compare that to the loaded modules before finalizing. If any new modules have shown up they should be added to /etc/initramfs-tools/modules before generating initrd. This way any modules the user had to manually load during install time will at least carry over to the actual installation.

This sounds like a rather crude hack. I do not think the DI team would
any of such patches.

Of course udev is the better option, but think of this as a type of fail safe in case udev doesn't work.

If udev doesn't work, you will have way more serious issues anyway.
There isn't really a normal
scenario where udev doesn't work. If it doesn't work, you won't be
able to do anything anyway.

As I have mentioned before, modules not being loaded automatically is
an issue with the
modules itself.


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.

Great, i've been looking for information about this. Are there any guides out there for cloning the entire source tree and building a repo from scratch? I have seen some references to buildd which appears to be an internal tool to do just this more or less, but with not a lot of documentation that i can find.

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.

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.

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...


Reply to: