> I'd have to run through the stack of network cards in my closet (and > probably ask a few of the gPXE and iPXE guys to do the same to get an > exhaustive list). I would have to verify it, but I'm pretty sure some > of the 3com's I've got (older 10, 10/100 cards) have problems above 64M > I think. That said, I haven't seen a problem on anything I would > consider modern. > > Again though, if there's problems the older cards likely have good > [gi]PXE drivers and thus the problem can likely be gotten around that > way too. If it's not going to be a problem on something made in (say) the last five years, I don't know that I'd worry about it too much. I'm more concerned about the more unusual platforms like s390 and ppc64 than I am about boring old PC NICs. > > The test installs I've done here haven't seemed to take this long (they > > definitely don't take six minutes, they may take 43 seconds) across a > > wired network. There's also a sizeable delay when the kernel gets to > > unpacking the image. > > Well the 6 minute download looks like a worst case scenario, it is > something that should be noted that users are going to be waiting longer > at a point where there's no good way to explain why there's a big delay > going on though. Agreed - there's really no indication of what's going on besides an avalanche of dots flowing down the streen with no end in sight, and then later a big pause while the kernel does its unpacking. To me, this is the biggest problem with this new giant initrd approach. Actually, the kernel unpacking is slightly more concerning because it'll affect everyone, not just pxeboot users. > Probably, the boxes I know that have 512MB of ram in them are old [READ: > ~500mhz range old]. The big question here is do you want to raise the > minimum amount of ram for a system beyond what is defined already? > Modern machines are shipping with at least 1GB of ram these days, but > how many people are still running on old kit? If smolt is to be believed, about 1/3 of users are running with < 1GB of RAM (http://smolts.org/static/stats/stats.html). About 10% are running with < 512 MB. The first is considerable and is worth taking into account. I'm less concerned about < 512 MB cases. But you're right - that's a big question, and I do not know. I need a better sample size than two test machines and a VM here before I understand the impacts of this. > Anything that makes the maintainability and reliability better is > definitely a good thing, the big question is are the downsides, that may > be inherent with this, ok? I'm just trying to raise the yellow caution > flags where I see them, but that said I don't think this is a bad idea. > This would unify the install image type, and probably even make dealing > with the live isos easier (mainly that you've already got an initrd that > has everything in place to talk to any storage mechanism). Yeah, I do see your concerns and appreciate you raising them. I'm just trying to push my idea through if at all possible. > If you've got any images built up using a larger, more inclusive, initrd > I'd be more than happy to give them a go on anything I've got lying > around here for testing, particularly on the network cards I've got in > the drawer. I'll see what I can do and post a link. One problem is that because this is such an invasive patch set, it's a real pain to rebase when people make changes in scripts/. Therefore, whatever I post is likely to be a little old. Luckily, you won't yet be able to get past loader so it doesn't matter all that much. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
