On Monday 06 June 2011 11:13, Cody Jackson wrote: > Tomorrow if there's time in town I'll see about fetching the rhel6 > kernel and playing with it. It'd be nice to know ahead of time if it > compiles cleanly for i586. RHEL6 makes less sence than RHEL5 due to memory requirements again, doesn't it? > I'll also play with build scripts in the upcoming week. I'm really sorry I can't find a buildscript. It should be somewhere on a machine. > In addition, it's kick-starting > alt-arch support for things like ALPHA, SPARC, I64, etc. (Maybe.) A lot harder to test, hardware is rare/expensive, what kernel options to use... Lots of questions. > > Even less if a script does a: > > 1)fdisk on a target drive > > 2)mkfs.ext3 > > 3)mount > > 4)cp -aR /installed/and/ready/filesystem/converted/to/i586/already > > /on/a/formatted/hdd/mount > > 5)grub-install > > This looks like it might save some time; I'll give it a whirl when I > get my USB hard drive adapter tomorrow. Had problems with grub-install. You'd better chroot before grub-install, don't forget to bind-mount /dev, /proc and /sys. And if the target machine uses a disk controller not compiled in kernel or other than new machine you're doing it at, you'd need to rebuild initrd. No problems with VIA, Intel. But certainly problems with old SCSI cards are guaranteed. > > I was doing 'rpm -e' until I got something like 730MB. Was hard to go > > further. > > Minimal install gives you various crap like irda-tools for example. Kudzu > > depends on a haldaemon. The haldaemon depends on dbus. The latter two > > bring about 50MB of unneeded libs with them AFAIR. But I like kudzu. > > There's a lvm2-monitor from lvm2 package. I don't need one, but mkinitrd > > depends on it and we need mkinitrd to update kernels. You could rip > > sendmail, but you'd lose LSB compliance. And remember, it's a wrong way. > > > > This way we'd end up building our own, another Linux distro for > > firewalls. But > > we're here because of upstream compliance and upgradeability to a more > > decent > > box if need arises WITHOUT ANY MIGRATION/REINSTALL. > > I dunno; when I get this thing to boot natively into an installer I'll > let you know how much it takes to do a minimal install. I think the > way I have it now it's about 500MB (?) of packages, which is still > excessive to me but works. (Of course, keeping in mind this machine > came with a 480MB hard drive before I swapped it for a 30GB drive...) You could use rpm to force-remove certain components like the aforementioned lvm2 but you're calling for problems with yum later. And if you use yum, it'll bring dependencies back. I wasn't able to cleanly push the root dir below 700M. Add 300MB free space just in case, 100MB for /boot and 100MB (at least) for swap and you get a 1200MB HDD needed @ absolute minimum. I preferred 1700MB. BTW, removing rpm/yum metadata saves about 100mb, removing YUM itself with dependencies saves about 50+MB, but it's just like back to the stone age. I won't recomment anyone dealing with RPM hell by hand. > > 1)wget a_new_kernel_src.rpm > > 2)rpm -i > > 3)patch -pX /on/a/rpm/SPEC/file </to/include/our/patch > > 4)rpmbuild > > wait until a gazillion of individual patches are applied > > (offtopic - this time I won't be against RHEL6 prepared-and-intergrated > > kernel > > source tree) > > 5)copy a built RPMs where needed > > 6)rebuild repo metadata > > Exactly! That's what I hope to have set up soon. As it is, I already > have the .patch for the spec, so wrapping it in a script shouldn't be > too bad. The only thing I add is running it through Mock--I like > things being separated into little compartments. The end result is the > same. Is it silly to ask 'what the Mock is?' Don't lmgtfy.com me, Ok? > > On a lightly loaded server (4-core Q6600, SCSI disk subsystem) it doesn't > > take > > enormous time. > > Remember, I'm the guy with the i586s. No quad-cores for me. :P But > you're right, it doesn't take too long, and updates--and hence > rebuilds--are few and far between. I'm willing to provide a diskspace, bandwith and CPU time on my server for the project and it's repo if needed. I hope the traffic wouldn't be enormous because I'm paying $0.1 per gigabyte of traffic. The full bandwidth is 100mbit but I'm cautious to provide more that 10mbit to single instance/VPS. > my new LAPTOP has more memory than any desktop I've owned to > date, and it's fairly low-end--so here come the programs > *COUGH*WINDOWS*COUGH* that eats up ridiculous amounts of memory just > because we have it. Ahh, progress. I don't like KDE4 either ;-) I was quite happy with Fedora on my 1.5GHz single-core Centrino laptop before KDE4 arrived. Then I switched to CentOS. > > It would take ages to install anyway. So no one would use it anyway. Then > > why > > fixing? > > I'm the person that believes an operating system should allow a person > to shoot themselves in the foot if they try something dumb (like > installing on 64MB of RAM). If someone thinks they're smarter than the > OS--which, usually, they're not--let them try it. If they're the > learning type, they'll learn not to do it again, unless they're like > me, in which case they're utterly hopeless and will continue to do > dumb things just for the heck of it. Does it really worth the precious minutes of developer's time?