On 08/03/2010 01:37 PM, clumens@xxxxxxxxxx wrote: >>> (1) It's possible some PXE implementations will not like downloading a single >>> 100+ MB image. I'm hoping the number of machines affected is decreasing every >>> year and we can rapidly stop caring. >> >> This is actually of some concern, primarily that downloading within PXE >> (of any type) is quite slow. It's doable, but there are a few PXE >> stacks that will barf on something that big. Some of those can be >> "fixed" by chaining first to gPXE then to the install. > > Any ideas how common these implementations are, and on what kinds of > machines? 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. > >> http://boot.kernel.org/bko/pxeknife/linux_boot_disks/rip/tftpboot/rootfs.cgz >> >> is an initrd of roughly the size your proposing, and one I know works. >> >> Various download times: >> >> the above link with wget across the internet to my home: >> >> 69s - 1.37 MB/s >> >> With tftp from a server in my house to my laptop (with a wifi link involved) >> >> 6:15.60 - 262 KB/s >> >> Same tftp server only only wired (100mbps) >> >> 43.034s - 2.1 MB/s > > 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. > >>> (3) Memory requirements may be increased. >> >> It would effectively kill off anything with less than 256M of ram from >> doing an install. I wouldn't think this is common anymore, but I know >> machines with 512M of ram are still in production today, and running Fedora. > > These are basically dead anyway, and getting moreso all the time: > > #if defined(__powerpc64__) || defined(__sparc__) > #define MIN_RAM 1024*1024 // 1 GB > #define GUI_INSTALL_EXTRA_RAM 512*1024 // 512 MB > #else > #define MIN_RAM 256 * 1024 // 256 MB > #define GUI_INSTALL_EXTRA_RAM 128 * 1024 // 128 MB > #endif > #define URL_INSTALL_EXTRA_RAM 128 * 1024 // 128 MB > #define MIN_GUI_RAM MIN_RAM + GUI_INSTALL_EXTRA_RAM > #define EARLY_SWAP_RAM 512 * 1024 // 512 MB > > I kind of think MIN_RAM in the normal case is a lie anyway. 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? >> Just some thoughts, I'm not sure if this kind of change would ultimately >> be good or bad. The biggest problem I can see if the want for an ever >> increasing initrd. > > It's such a massive improvement in maintainability and reliability that > I think it's definitely for the best. Just removing the state machines > in loader alone would drastically cut down on the number of weird method > selection bugs we've got. This is the kind of stuff that end users > aren't directly going to notice, but they'll experience fewer bugs and > we'll have more time to work on other stuff. > > I understand the problem about the magic growing initrd. I'm not sure > how we can address that (especially given our desire to use system stuff > - see Martin's other thread on the list). We'll need to be careful. 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). 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. - John 'Warthog9' Hawley _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
