> > (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? > 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. > > (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. > 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. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
