Feature Requests item #682696, was opened at 2003-02-07 19:56 Message generated for change (Comment added) made by jenos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350259&aid=682696&group_id=259
Category: None Group: None Status: Open Priority: 5 Submitted By: Jeremy Enos (jenos) Assigned to: Nobody/Anonymous (nobody) Summary: build boot image from server system Initial Comment: If possible, provide the option to build the boot image (kernel, modules, ramdisk, and tools) completely from the server system. This idea only works if the server's kernel supports the critical items which are required of course... maybe test for that? But having this option would help reduce the lag that SI has with hardware support- allowing for the end user to shoulder the load potentially without feeling it. ---------------------------------------------------------------------- >Comment By: Jeremy Enos (jenos) Date: 2004-04-16 16:45 Message: Logged In: YES user_id=270124 Another option to consider adding would be: --enable-serial-console [TTY] [BAUDRATE] This configuration doesn't actually go into the boot image of course, but rather pxelinux.cfg/default or elilo.conf (on ia64). However, these files specify the kernel and initrd that are getting generated by mkbootimage anyway, so maybe this is an appropriate command to have this option? I don't know... just a suggestion. ---------------------------------------------------------------------- Comment By: Jeremy Enos (jenos) Date: 2004-04-01 13:32 Message: Logged In: YES user_id=270124 Per my mail on the oscar/sis-devel lists... Some other features that would fit perfectly into the mkbootimage tool... --with-sshd [pub_key] (runs an sshd and injects a pub_key into auth_keys for root) --redirect-syslog [host] (obvious) Having options like these would GREATLY increase our ability to monitor and troubleshoot the build process. ---------------------------------------------------------------------- Comment By: dann frazier (dannf) Date: 2003-02-16 02:51 Message: Logged In: YES user_id=146718 also keep in mind that we currently depend on devfs, which will limit the number of distros this can work with - debian & mandrake will be ok in this respect, dunno about RH/SuSE/others. ---------------------------------------------------------------------- Comment By: dann frazier (dannf) Date: 2003-02-15 17:37 Message: Logged In: YES user_id=146718 > Initrds are just as important as kernels. Without them we > cannot load modules. the initrd only needs to be regenerated if you need to add a module driver for the network device you plan to install over. otherwise, you can just use the vanilla initrd, and add needed modules to boel_binaries. > If you need specific examples of why I need to create an > initrd on demand, and not just a kernel, let me know. did you miss some of this discussion? search for mkcramfsing on the page. regenerating a cramfs initrd is cake - it just won't work with most distributor kernels. as i've already mentioned, supporting multiple types of filesystems for initrds is a way around this. ---------------------------------------------------------------------- Comment By: Jason Brechin (brechin) Date: 2003-02-15 16:25 Message: Logged In: YES user_id=274641 dannf wrote: >then you just don't understand the argument. >this feature request is for kernels on demand, not initrds. > the initrds in the binary packages is cramfs. Initrds are just as important as kernels. Without them we cannot load modules. In case you haven't been paying attention, the argument consists of "provid[ing] the option to build the boot image (kernel, modules, ramdisk, and tools) completely from the server system." If you were confused, check the FR summary at the top... If you need specific examples of why I need to create an initrd on demand, and not just a kernel, let me know. ---------------------------------------------------------------------- Comment By: Jeremy Enos (jenos) Date: 2003-02-14 17:08 Message: Logged In: YES user_id=270124 Ok... some irresistible noise... I feel very comfortable questioning support of minorities when attempts to do that are plainly holding back support for the most widely used architectures. All I'm trying to reach is a point where SIS can meet the status quo, where it supports the same kind of things a distro does. (driver disks, install on newer hardware, etc.) We need special kernels, yes. But only for SIS. Distros install fine, because they have an easy means of supporting newer hardware. SIS does not. Newer hardware is one thing that I can guarantee will be around forever. Support is needed. I don't have to be brave to question that. > considering our discussion has spawned 2 additional > possibilities, you must be pretty pessimistic. Are you saying it's LIKELY that all distros will spontaneously decide to build cramfs into themselves? Or that someone will rewrite genext2fs?? I'm not pessimistic. > you have as much access to the source as i do. WOW. That's the very attitude that keeps me using MS products. I'm not an SIS developer. >> If this could happen, why hasn't it already? SI has been >> around for awhile... you guys haven't already pushed for >> inclusion into distro kernels? Why not? > troll. what reason was there to care before? What? See feature request above. I'd be surprised if this feature's capability wasn't on your minds during the initial design phase. Let's face it. Distro makers aren't exactly easy to push around and tell them what to include. There's no reason to believe genext2fs is going to be changed. This isn't going to get fixed by anything I've seen suggested or hoped for here. ---------------------------------------------------------------------- Comment By: Neil Gorsuch (ngorsuch) Date: 2003-02-14 17:06 Message: Logged In: YES user_id=215662 If systemimager is going to be used for very new hardware, it is going to have support letting the user plug in a kernel/modules of his choice and build the ramdisk from his system utilities, and use vendor supplied driver disks. It's as simple as that. Until that happens, when someone asks if systemimager supports IA64, I will have to continue to answer "only the old hardware, don't even bother trying with new hardware". It's great that systemimager caters to the masses and even the people that still need to use floppies to network install, that's very liberal of systemimager. Quite admirable. But that kind of thinking will lead to systemimager's being replaced more and more by other means that do move ahead with new hardware. ---------------------------------------------------------------------- Comment By: dann frazier (dannf) Date: 2003-02-14 00:14 Message: Logged In: YES user_id=146718 > I'm still surprised now that I know more though. It looks > as though you're shorting support for the most widely used > architecture to support some minorities. Kind of > academic, no? questioning our support of the minorities is pretty brave of you - considering most people don't need special kernels for their hardware. we try to care about all our users - even those who don't. > It seems unreasonable to expect SI to support > architectures w/o ever having root access to them, and > it's fortunate you've > been able to do it at all. troll. for debian to include it, a debian developer must upload it. i don't do any development for the ppc/s390 arches. those who do aren't debian developers. if you want more information about debian, i'm always happy to discuss it, but find me on irc somewhere, or e-mail me, its no longer relevant here. >> our mutual goals *can* be achieved. >I'd be all for it, if it seemed at all likely. considering our discussion has spawned 2 additional possibilities, you must be pretty pessimistic. >> the two quickest ways for this to happen would be: >> 1) improvement in the gene2fs code base >I know of no reason to expect this to happen. You yourself >have already hinted that you have no interest in doing this. you have as much access to the source as i do. >> 2) getting cramfs initrds supported in the 2.4 linux >> series. >If this could happen, why hasn't it already? SI has been >around for awhile... you guys haven't already pushed for >inclusion into distro kernels? Why not? troll. what reason was there to care before? > btw, just to be clear- we're banging pretty hard on this > issue. We're motivated because we want to be able to use > SIS... not just to heckle you. ;-)e well, some of this has been productive, and will hopefully give brian some good ideas - but a lot of this is just unhelpful trolling (for example, everything in your last post) - but i suppose i'm just as guilty for increasing the noise/signal ratio for responding. ---------------------------------------------------------------------- Comment By: Jeremy Enos (jenos) Date: 2003-02-13 12:04 Message: Logged In: YES user_id=270124 This is good- parts of this discussion are really beneficial to the ignorant (me). I didn't understand much of the reasoning before. I'm still surprised now that I know more though. It looks as though you're shorting support for the most widely used architecture to support some minorities. Kind of academic, no? It seems unreasonable to expect SI to support architectures w/o ever having root access to them, and it's fortunate you've been able to do it at all. > our mutual goals *can* be achieved. I'd be all for it, if it seemed at all likely. > the two quickest ways for this to happen would be: > 1) improvement in the gene2fs code base I know of no reason to expect this to happen. You yourself have already hinted that you have no interest in doing this. > 2) getting cramfs initrds supported in the 2.4 linux series. If this could happen, why hasn't it already? SI has been around for awhile... you guys haven't already pushed for inclusion into distro kernels? Why not? In any case, this isn't any kind of future to be counting on, and certainly doesn't help today's situation. btw, just to be clear- we're banging pretty hard on this issue. We're motivated because we want to be able to use SIS... not just to heckle you. ;-) ---------------------------------------------------------------------- Comment By: dann frazier (dannf) Date: 2003-02-13 11:10 Message: Logged In: YES user_id=146718 although, if you can detect the kind of initrds the kernel *does* support, you could dump the contents of teh cramfs initrd into the appropriate kind, and expect the user to have root privs - a lot more complicated then re-mkcramfsing, but also possible. dunno if that's what you were getting at... ---------------------------------------------------------------------- Comment By: dann frazier (dannf) Date: 2003-02-13 10:03 Message: Logged In: YES user_id=146718 > I don't think that much of this argument matters, since we're > only talking about making something an image at run time > (on demand), not something that's part of the binary package > (which has its limitations as you point out). then you just don't understand the argument. this feature request is for kernels on demand, not initrds. the initrds in the binary packages is cramfs. > Also, are you saying that cramfs support is the only thing > that needs to be added to the kernel for the SI initrd to work? no. i'm saying that adding cramfs *initrd* support will increase the number of cases in which this will work. ---------------------------------------------------------------------- Comment By: Jason Brechin (brechin) Date: 2003-02-13 05:39 Message: Logged In: YES user_id=274641 I don't think that much of this argument matters, since we're only talking about making something an image at run time (on demand), not something that's part of the binary package (which has its limitations as you point out). Also, are you saying that cramfs support is the only thing that needs to be added to the kernel for the SI initrd to work? ---------------------------------------------------------------------- Comment By: dann frazier (dannf) Date: 2003-02-13 01:48 Message: Logged In: YES user_id=146718 fyi, if you have the kernel source tree for the kernel you're running, you can easily patch in cramfs initrd support. this could even be automated, since the patch is very low touch. Checking to see if your kernel has all the right bits.... No. Would you like me to try to build a kernel for you [Y/n]? where is your kernel source tree [(/usr/src/linux)]? Copying tree to /tmp/linux.... Applying required patches.... Building.... Copying kernel to some dir... done! if you need to use a binary module, you'll wanna build the kernel w/ the same name as the one the binary module was built for, of course. ---------------------------------------------------------------------- Comment By: dann frazier (dannf) Date: 2003-02-13 01:20 Message: Logged In: YES user_id=146718 > First, why not use mke2fs or mkfs? I've not heard of any > problems with them, and they are used in other distributions' > initrd creation tools. mke2fs can't populate a filesystem in a file in place. > It seems silly to pick cramfs only > because debian uses them. that's not why it was chosen. there's a whole thread on this from late last year if you're interested, where we looked at various options to come to this decision (on si-devel), and the thread is not called "debian uses them, so we must too." our goals at the time were 1) small size 2) no root access required to create. mkcramfs lets you create a filesystem in place - as does gene2fs, but gene2fs doesn't support hard links, and has a hard size limitation, iirc. > cramfs has been around for a > couple years, and support for it still isn't included > in "mainstream" linux distros. yes it is. nearly every distro supports cramfs these days. they just don't support cramfs initrds - but there is a standard patch for this. the only reason i can guess that it isn't in mainline kernels is that noone has really put in an effort to get it accepted. > There's probably a reason for that. jfs, xfs, & devfs aren't included in many popular distributors kernels.. maybe we should drop those too? (sorry - had to throw some sarcasm in there). > Second, I don't know where you're getting genext2fs (since it > isn't part of e2fsprogs), but root permissions are not required > to use mke2fs as it is used to create an initrd. I just made a > 1M file, and ran mke2fs as a regular user... it works... sure. but try putting files in it. > Third, though I must admit I'm inexperienced with Debian > autobuilding, I see no mention in Debian's various policies or > from a google search that say anything about problems with > root permission. I may be missing something, but in any > case, due to my second point above, it's not an issue. ok, let me explain in more detail: for each package i upload to debian, i must have a corresponding binary package for one arch. because of the funky nature of si boot packages, i have to build, by hand, each boot package. this means i must have access to build on a box of the proper debian arch & release for each upload. in most cases this isn't a problem, because i happen to have root on some i386/ia64 boxes, running various versions of debian, or a chroot thereof. however, for example, i don't have root access to any ppc boxes - but the debian project does provide user level access to various boxes, including some ppc's . once debian has ppc64 compilers for ppc, i plan to upload a boot package for it. i can do this if i don't need root. i can't do this if i need root. as systemimager goes along, we can only hope to support more architectures - s390 is in the works, so is hppa. i happen to have access to hppa as root, i don't for s390 - but i'm a lot more likely to be able to get a mortal account for building. so i somewhat misspoke - the autobuilders themselves can do things as root on arches i can't - but i can't take advantage of them. our mutual goals *can* be achieved. the two quickest ways for this to happen would be: 1) improvement in the gene2fs code base 2) getting cramfs initrds supported in the 2.4 linux series. ---------------------------------------------------------------------- Comment By: Jason Brechin (brechin) Date: 2003-02-12 23:34 Message: Logged In: YES user_id=274641 First, why not use mke2fs or mkfs? I've not heard of any problems with them, and they are used in other distributions' initrd creation tools. It seems silly to pick cramfs only because debian uses them. cramfs has been around for a couple years, and support for it still isn't included in "mainstream" linux distros. There's probably a reason for that. Second, I don't know where you're getting genext2fs (since it isn't part of e2fsprogs), but root permissions are not required to use mke2fs as it is used to create an initrd. I just made a 1M file, and ran mke2fs as a regular user... it works... Third, though I must admit I'm inexperienced with Debian autobuilding, I see no mention in Debian's various policies or from a google search that say anything about problems with root permission. I may be missing something, but in any case, due to my second point above, it's not an issue. ---------------------------------------------------------------------- Comment By: dann frazier (dannf) Date: 2003-02-12 21:28 Message: Logged In: YES user_id=146718 > I too am surprised that you'd limit a feature so that people > can install as non-root? I must not be understanding this > right. This has nothing to do with installing - its building that is a concern. You can assume that users that are building it for their own use will have root on their build box, but the same doesn't go for myself or other distributors (for example, the debian autobuilders). > I'm also confused about genext2fs vs cramfs issues. If > genext2fs won't work, and cramfs isn't built in anywhere, then > how is bef going to make a mkbootpackage tool? cramfs initrds are in debian kernels, and people can patch it into their own, but i don't believe it will be generally useful until other distributors start supporting cramfs initrds (which would instantly happen, if someone could persuade marcello to add it to the 2.4 series) - or someone fixes genext2fs. I think the best solution is to have genext2fs capable of doing what we need, so's we can support ext2 initrds, but I'm not voluteering for that job. If you want to see this happen, adding that support (or funding someone else to do it) would be the way to go - i'd be glad to see us switch at that point. > Another question: are any of these limitations imposed by > supporting floppy based installation and PXE based > installation in the same solution? Not at all. ---------------------------------------------------------------------- Comment By: Jeremy Enos (jenos) Date: 2003-02-12 15:44 Message: Logged In: YES user_id=270124 I too am surprised that you'd limit a feature so that people can install as non-root? I must not be understanding this right. I'm also confused about genext2fs vs cramfs issues. If genext2fs won't work, and cramfs isn't built in anywhere, then how is bef going to make a mkbootpackage tool? Another question: are any of these limitations imposed by supporting floppy based installation and PXE based installation in the same solution? e.g. Keeping sizes down, using busybox, etc? If so, would it be time for the two solutions to fork? ---------------------------------------------------------------------- Comment By: dann frazier (dannf) Date: 2003-02-10 23:56 Message: Logged In: YES user_id=146718 > So why does it matter that only root can do this? I can't > imagine why a non-root person would need to mess > around with building kernels, etc. a goal is to get into more distributions, which is more difficult to do if root perms are required to build (i believe sdague got some pushback about this), and it is definitely a plus for the debian autobuilders. also, using mkcramfs is a lot cleaner way to make an appropriate size ext2 ramdisk (gene2fs has too many limitations to be useful). > Please tell me why this isn't a good thing, i never said it wasn't. > or a reasonable possibility. it is definitely a goal to make it easier for people to add support for their hardware - hopefully mkbootpackage can do just that at some point. i'm just pointing out what is difficult about it, not attacking the idea - the idea is quite valid. ways to make this happen would be to make genext2fs capable of dealing w/ hardlinks & large ramdisk sizes, or push distributors to add cramfs initrd support. ---------------------------------------------------------------------- Comment By: Neil Gorsuch (ngorsuch) Date: 2003-02-10 15:06 Message: Logged In: YES user_id=215662 So why does it matter that only root can do this? I can't imagine why a non-root person would need to mess around with building kernels, etc. The problem, as I have found in the last couple of weeks while trying to get some very new hardware to work with oscar/sis/systemimager, is that there is no practical, easy way to use your own kernel build and modules with systemimager. Until this is easy to do, people will be looking for alternatives to systemimager. This is the third time that I have had to use oscar/systemimager on very new hardware. This time we lucked out and the latest linux kernel had the required driver, and you systemimager folks were nice enough to release a new version of systemimager quickly. The previous two times I ended up munging in a kickstart replacement for systemimager inside oscar. It will be a requirement for a subset of future oscar systems, that systemimager supports having a knowledgable user supply his own kernel and modules (with features such as cramfs or whatever that systemimager specifies and needs) that can be used with systemimager. This will also require the ability for systemimager to build a new boot image from the running system's binaries such as insmod, and a kernel and modules from user specified locations on the system. We tried various ways of updating the kernel/ramdisk with our own kernel and/or modules, but always ran into incompatibility problems (we don't use a debian environment, the busybox insmod command can't handle various module constructs, the ramdisk was too small, etc). Please tell me why this isn't a good thing, or a reasonable possibility. ---------------------------------------------------------------------- Comment By: dann frazier (dannf) Date: 2003-02-08 03:34 Message: Logged In: YES user_id=146718 as things are, such a tool would work in *very* few cases. systemimager uses cramfs initrds, which aren't supported in any baseline 2.4 kernel. as far as i know, debian/i386 is the only distribution that provides a kernel that could concievably work in this case - i know redhat kernels will not. and if you're using a debian standard kernel, there's few corner cases in which the standard si kernel will not work for you. cramfs initrds are used because it eliminates the need for root priveleges to build, and by the same token, loop device support. if you know enough to build your own kernel w/ the necessary patches, then you should also know enough to tweak your kernel source & run 'make binaries' and resolve (with help from the list) any build issues you run into. flavor support exists as of 3.0.0, which enables us (or you) to create updated flavors quickly, reducing the lag of waiting for a new systemimager release. instructions for doing so are in the systemimager manual. all that aside, it looks like brian has started work on a tool for this: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/systemimager/systemimager/sbin/mkbootpackage ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350259&aid=682696&group_id=259 ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Sisuite-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/sisuite-devel
