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