gbootroot-devel Mailing List for gBootRoot
Brought to you by:
freesource
Menu
▾
▴
gbootroot-devel — Development of gBootRoot
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(12) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jonathan R. <fre...@ul...> - 2003-03-02 19:12:44
|
This is to announce the release of gBootRoot 1.5.0. gBootRoot provides an integrated development environment to easily create root_fs for use by User-Mode Linux. The UML box allows easy testing/running of root_fs including support for jffs/jffs2 root_fs with the help of a pre-made Initrd. Gbootroot creates itself via User-Mode Linux from a source package that provides a convenient method to keep up with jdike's latest patches. The gBootRoot home page is at http://gbootroot.sf.net Changes: * New if/elsif control structure for Yard template * Binary packages compiled for >= glibc 2.2.5 * Many fixes to source packages * Several bug fixes and improvements * uml-patch 2.4.20-1 and uml_utilities 20030202 Notes and observations: Tested on Debian stable/unstable and rpm based distros RedHat 7.3/8.0, Mandrake 9.0, and Suse 7.3 thanks to umlbuilder. Overall, this is by far the most heavily tested release to date. Suse users may need to edit /usr/include/asm/ptrace.h adding "#define FRAME_SIZE 17" after the "#define SS 16" line or else uml won't compile. This was observed in Suse 7.3. Observed that kernel stack overflows are occurring from time to time in the nested environment. Enjoy. Jonathan |
|
From: Jonathan R. <fre...@ul...> - 2003-03-01 05:11:13
|
This is to announce the release of gBootRoot 1.5.0. gBootRoot provides an integrated development environment to easily create root_fs for use by User-Mode Linux. The UML box allows easy testing/running of root_fs including support for jffs/jffs2 root_fs with the help of a pre-made Initrd. Gbootroot creates itself via User-Mode Linux from a source package that provides a convenient method to keep up with jdike's latest patches. The gBootRoot home page is at http://gbootroot.sf.net Changes: * New if/elsif control structure for Yard template * Binary packages compiled for >= glibc 2.2.5 * Many fixes to source packages * Several bug fixes and improvements * uml-patch 2.4.20-1 and uml_utilities 20030202 Notes and observations: Tested on Debian stable/unstable and rpm based distros RedHat 7.3/8.0, Mandrake 9.0, and Suse 7.3 thanks to umlbuilder. Overall, this is by far the most heavily tested release to date. Suse users may need to edit /usr/include/asm/ptrace.h adding "#define FRAME_SIZE 17" after the "#define SS 16" line or else uml won't compile. This was observed in Suse 7.3. Observed that kernel stack overflows are occurring from time to time in the nested environment. Enjoy. Jonathan |
|
From: Jonathan R. <fre...@ul...> - 2003-01-15 19:45:26
|
This is to announce the release of gBootRoot 1.4.0. gBootRoot provides an integrated development environment to easily create root_fs for use by User-Mode Linux. The UML box allows easy testing/running of root_fs including support for jffs/jffs2 root_fs with the help of a pre-made Initrd. Gbootroot creates itself via User-Mode Linux from a source package that provides a convenient method to keep up with jdike's latest patches. The gBootRoot home page is at http://gbootroot.sf.net Changes: * Added Command-Line interface to Yard Method * Completely automated the source package * Fixed lock-up bugs related to newer Perl Modules and a problem locating NSS libraries for newer glibc versions * Added automatic recognition to determine the mode=(skas|tt) UML option * Configured NEST=1 to allow uml to run both on the host kernel and within itself on most machines * uml-patch 2.4.19-46 and uml_utilities 20021103 Enjoy. Jonathan |
|
From: Jonathan R. <mma...@ya...> - 2002-03-12 04:35:30
|
gbootroot 1.3.6 "The application which allows you to create distributions from scratch." Available in tgz, rpm, and deb formats: http://sourceforge.net/project/showfiles.php?group_id=9513&release_id=79150 Updated to 2.4.18-2um and the latest uml tools 20020212. A MTD "Memory Technology Device" Emulator has been added to the UML Box with can run either from ram (mtdram) or from a ubd "block device" (blkmtd). This is most useful for running and testing distributions built on the jffs2 filesystem, though other types of filesystems may be tested. There are two jffs2 images you may try out which were made from templates created by make_debian* from a Debian unstable/testing host system: http://prdownloads.sourceforge.net/gbootroot/root_fs_debian_x11_jffs2 http://prdownloads.sourceforge.net/gbootroot/root_fs_debian_jffs2 Notes: http://sourceforge.net/project/shownotes.php?release_id=79088 I've also added a reiserfs image with the manpages and documentation included: http://prdownloads.sourceforge.net/gbootroot/root_fs_debian_x11_reiserfs.bz2 When creating a fs with genext2fs or UML Exclusively it is no longer necessary to run the copy stage again if you want to change the fs type. This requirement now only applies when using a loopback device as the root user. This means if you want to change the fs type of your root_fs just enter a different command in the Filesystem Box, select the Create stage, and press the Continue button. Other changes: http://sourceforge.net/project/shownotes.php?release_id=79150 Documentation: gbootroot.sourceforge.net Have fun, Jonathan |
|
From: Jonathan R. <mma...@ya...> - 2002-02-14 02:15:01
|
gbootroot 1.3.5 http://sourceforge.net/project/showfiles.php?group_id=9513&release_id=75030 "The application which allows you to create distributions from scratch." Due to an oversight I neglected to update the root_fs_helper even though I had done this on my own system. This caused the program to lock-up. This has been fixed. The uml kernel included with gbootroot is now much better at initrd testing. Before it was limited to the ext2 filesystem, because cramfs corrupted the filesystem detection phase. In this kernel the order has been changed so that cramfs is the last filesystem to be detected by the kernel so initrds made with other types of filesystems like minix will not fail. However, if your filesystem fails with "bad magic" then you know that is most likely the case. :) Finally, I do recommend that you run this program as a normal user even though it is not a requirement. In case you are wondering I almost always run gbootroot not as root. For all the gory details you can visit the changelog: http://sourceforge.net/project/shownotes.php?release_id=75030 Have fun, Jonathan |
|
From: Jonathan R. <mma...@ya...> - 2002-02-09 06:16:49
|
On Sat, 9 Feb 2002, Jonathan Rosenbaum wrote: > One interesting note, the rpms were created and tested on Linux virtual > uml because this feature doesn't exist; however, the fs created worked > nicely. This sentence was meant to read: One interesting note, the rpms were created and tested on Linux virtual machines. That was very convenient, but I couldn't test uml within uml because this feature doesn't exist; however, the fs created worked nicely. > Jonathan |
|
From: Jonathan R. <mma...@ya...> - 2002-02-09 06:11:51
|
Hi, Version 1.3.4 of gbootroot has been released. Added a button in the ARS to access the filesystem box. Updated to the 2.4.17-10um uml kernel, updated to the newest uml tools. Now RPM packages are included for Mandrake and Red Hat type distributions. Please note that there are two types of rpms packaged for gbootroot. Distributions which require perl-GTK and require perl-base for perl such as Mandrake or PDL should use the mdk rpm. Distributions which require Gtk-Perl and only require perl for perl such as Red Hat should use the rpm not marked as mdk. The rpmized gbootroot package requires perl-Expect which in turn requires perl-IO-Tty and perl-IO-Stty. A search on the Net revealed that the existing rpms out there are either outdated, don't have their dependencies set-up properly, or require a particular version of the perl5 series. I made these rpms so they work on any i386 architecture which is using the perl5 series. This includes 5.6.0 and 5.6.1 which are in common use on most major distributions as of the year 2002. If you have a problem with the automated Linux virtual machine which appears related to these modules, please don't hesitate to contact me. They are available at prdownloads.sourceforge.net/gbootroot. One interesting note, the rpms were created and tested on Linux virtual uml because this feature doesn't exist; however, the fs created worked nicely. Regards, Jonathan |
|
From: Jonathan R. <mtt...@ac...> - 2000-09-29 01:55:29
|
On Thu, 28 Sep 2000 pu...@ly... wrote: > > I think it would be nice if gbootroot could make a bootable cdrom with a > whole linux system. (just mount /tmp and /var or what's needed as a > ramdisk) Hi Magnus, I remember you from bootroot. I don't have a cdrw right now to test something like this out, but getting a cdrw is a definite TODO .. but that's what I told the project leader several months ago on another project I was involved with. gBootRoot is being developed on www.sourceforge.net/projects/gbootroot, so if you get an account at sourceforge and send me your login, I can register you as a tester, I'd really appreciate having a tester for this project. Here some plans I have for gBootRoot, once the Olympics are over, and I use my free time in a different way. :) There will be a new section to help in creating Linux systems. It will incorporate code from Yard to make accessing configuration options in Yard much easier. This will allow people to make customized Linux systems from stuff laying around in their hard drives. I have plans which go beyond this, but that is in the future. The new section will allow a different root device to be specifed then the one being used by the boot device. But things can get really creative here. Maybe somebody wants to use one of those new boot loaders, or maybe they want to create a bootable cdrom in the traditional way. There will be methods added to allow this to happen. When the method is choosen gBootRoot will change its appearance to take the parameters of that method into consideration. One method which really interests me is the ability to test a live Linux system by running another kernel as a process over your normal kernel. The ability to do this already exists in user-mode-linux.sourceforge.net, but it's still experimental, but very cool, I've tried it. So a person could create a whole Linux system in a file, and test it with UML. Afterwards, they could choose another method to setup the system on whatever media they want to. I am looking forward to having you test out your ideas as they are added to gBootRoot. I really appreciated your help on bootroot. Best regards, Jonathan |
|
From: Jonathan R. <mtt...@ac...> - 2000-09-14 14:32:57
|
> > O.k., CVS 1.26 is the frozen version of 1.2.2. I've updated CHANGES. I > > will release the file to our project. Unless a major bug is found before > > tomorrow morning (US EST), the new gBootRoot goes public on Freshmeat, > > and icewalkers (1-2 days later). Well, everybody has seen the new version, and there were no bugs reported. I did get questions like "Where can I find mkrboot" from someone who wanted to make a single disk, and "How do I get ppp working" on a set made with Yard. People definitely notice gBootRoot. Remember Part II will involve incorporating Yard, I forsee many ways of doing this. Templates could be used to allow people to choose from different styes .. Yard, rtbt, bare min. working system + customized, etc. Part I probably still can use some features, which will be easy to add to the AI. I've been day dreaming about Part III. I will start another project called AVD "Aquired Virtual Distribution." The client model to accomplish this already exists, and to a large degree so does the server model. I've developed a database with Berkeley DB. I want to convert this database to run with SQL databases using DBI. This will all be integrated with the UML "http://user-mode-linux.sourceforge.net/" approach, making testing the creation of a new distribution a lot of fun. Then this will be added as a method to gBootRoot. Keep adding any features you feel are necessary to Part I, and any improvements. |
|
From: Jonathan R. <mtt...@ac...> - 2000-09-03 19:19:22
|
On Sun, 3 Sep 2000, Cristian Ionescu-Idbohrn wrote:
> On Sat, 2 Sep 2000, Jonathan Rosenbaum wrote:
>
> > On Sun, 3 Sep 2000, Cristian Ionescu-Idbohrn wrote:
> >
> > >
> > > Did a quick test with 1.20; found 2 bugs which I reported to the bug
> > > list.
> >
> > O.k., these two bugs are fixed. Thanks for observing them. For personal
> > use, I think filling in append options in both bootdisk and normalboot is
> > acceptable. For other people's computers, they will have to know the
> > append options for their own system configurations anyways.
>
> OK.
>
> > > It looks good, otherwise.
> > >
> > > Do you think it may be possible to make the text fields in the advanced
> > > section a bit wider?
> >
> > I added this as an "program enhancement" bug. Close the bug if you like
> > the changes I made. Do you want all the fields wider?
>
> Changes OK. I want to close the bug but I don't seem to find any
> appropriate command for that. I might not have the permition to do that.
Just choose "Fixed" or "Works For Me" from "Resolution:" and "Closed" from
"Status:", and than press the "Submit Changes" button at the bottom of the
page. This is bug 113466.
> > Realize you can use emac commands in these
> > fields, pretty cool, eh?
>
> No, I don't. Can you be more specific.
With Gtk you can do all this stuff. Maybe I should add this to the FAQ?
Motion Shortcuts
Ctrl-A Beginning of line
Ctrl-E End of line
Ctrl-N Next Line
Ctrl-P Previous Line
Ctrl-B Backward one character
Ctrl-F Forward one character
Alt-B Backward one word
Alt-F Forward one word
Editing Shortcuts
Ctrl-H Delete Backward Character (Backspace)
Ctrl-D Delete Forward Character (Delete)
Ctrl-W Delete Backward Word
Alt-D Delete Forward Word
Ctrl-K Delete to end of line
Ctrl-U Delete line
Selection Shortcuts
Ctrl-X Cut to clipboard
Ctrl-C Copy to clipboard
Ctrl-V Paste from clipboard
> Made a hash out of @entry_advanced. Documents cleanly what is what.
> Much easier to maintain too. I also seemed to have hit a bug in sub
> entry_advanced. It was because I was trying to use $_[index] directly.
> Kept getting "Use of uninitialized value at ... line ...". I thought the
> reason was the fact I don't grok PerlTk, or I made some stupid
> mistake elsewhere.
> Using local variables for the in-params put me back on the right track
> (see more below).
Add this as a program enhancement, too. At this point, with the stable
release coming very soon it may introduce bugs, but it is an interesting
approach.
> @container is probably a good candidate for a hash too.
I wouldn't fool with this array at this point, it's a major part of
submit(), see previous statement.
> Would be much easier to follow what the subs are doing if they
> documented the in-params (check out my comment in sub entry_advanced).
Submit this as a program enhancement bug - it's low priority right now. I
was just using programming shorthand. But, you are right, it would
definitely help people understand what is going on.
> When I have both scalar, array and subroutine with the same name,
> the thing I do is try to make it obvious which is which by
> prepending the sub with a &. But that's, again, that sort of religion
> I'm suffering of ;-)
Yes, this is programming style. When Perl4 was used that was pretty
standard, but sub() seems to be more popular now. That's interesting ..
&sub(). :)
> The HELP needs some header update (date, version and the like).
> Should also describe the advanced options.
I just did this before you wrote, but I'll apply your cleaned-up look
approach. I'll submit a proposed version number for the next Stable
Release in the next CVS, too.
Check out the changes on the web page at the.netpedia.net/gBootRoot.html.
I will probably be moving everying to gbootroot.sourceforge.net before the
next release.
>I think the default floppy density should be set to 1440. Advanced
>users may want to fiddle with it.
>I always used the /dev/fd0u1722 floppy device when dealing with the
>1722 desity. But I now realized the generic /dev/fd0 can probably be
>used for most things, except formatting. By the way, shouldn't there
>be some words mentioned abou formatting the floppies?
Let's try out the present tomsrtbt optimized default approach in the
stable release and see what happens. Advanced users can make the changes
anyways. Ext2fs takes care of the formatting issues, basically anything
that's on the floppy is history. That's why I have lots of checks for
this.
|
|
From: Jonathan R. <mtt...@ac...> - 2000-08-28 17:10:20
|
On Sun, 27 Aug 2000, Cristian Ionescu-Idbohrn wrote: > On Sun, 27 Aug 2000, Jonathan Rosenbaum wrote: > > > Yes, I mean guess_default_kernel_image_and_root_device. Test it out > > really well, first. If you just want to set-up a demo cvs version so the > > variable results go to STDIN, that will be o.k., too. > > I attach that sub as a test case to this message. This is fine. It's actually a better way to test your functions. Gdkbirdaao is nice, I'll be linking it to the GUI. Append options will be put in the Advanced Section. > > I just got the new stripping section working, and I was able to test it in > > Debian because ld-2.1.2.so is not stripped. This means I can close bug > > 112073. I am wondering what will happen if I do a --strip-all rather than > > --strip-debug with libraries? If this works I may add this as an option, > > too. Yes, --strip-all works for initrd, so I'll add an option for libraries for people who like to live on the edge. > There's some more. I was playing around with gBootRoot and noticed some > inconsistances: > 1. if you role the floppy density counter down to 0 and then try go back > up twards 1440 and 1722, you get very funny figures This is because of the way Gtk works. This is something to put in the FAQ. There are two adjustments, step and page increments. When you press your first mouse button the step has been set to 282 so that a person can easily switch between 1440 & 1722. When you use your second mouse button the page is set at 360. You can go down to zero by pressing your third mouse button on the down arrow. Now page up with the second button to 1440 and step with the first button to 1722. Pretty cool, eh? > 2. the floppy device name _must_ be syncronized with the counter; > modifying one of then, should change the other This is an interesting function for you to write. I will be looking forward to it. 1722 has been set to fd0 by default, and I think it is a cool default value. (My own blurb about devices). Some problems I see with the present set-up of gBootRoot relate to the reopening of bug 11215. Most people will probably make disks on the same floppy used to boot, but if they use /dev/fd1, the disks won't work, so I'll add another field to the advanced section to avoid this problem. This leads to an interesting issue. Do you know if there are any ways to figure out all boot devices supported by a systems's BIOS? If we know this we could just list those devices in the beginners section, which would be a really cool thing to do. I hope you can figure out how to do this. Even is we can't read the BIOS, lots of the devices you list in 3 are unecessary. We could also just generalize and create a list of know boot devices. > 3. I know there are 2 different name schemes; Debian, the distro I use, > has support for these floppy devices: > > brw-rw---- 1 root floppy 2, 0 Apr 4 23:21 /dev/fd0 > brw-rw---- 1 root floppy 2, 84 Apr 4 23:21 /dev/fd0u1040 > brw-rw---- 1 root floppy 2, 88 Apr 4 23:21 /dev/fd0u1120 > brw-rw---- 1 root floppy 2, 28 Apr 4 23:21 /dev/fd0u1440 > brw-rw---- 1 root floppy 2, 124 Apr 4 23:21 /dev/fd0u1600 > brw-rw---- 1 root floppy 2, 44 Apr 4 23:21 /dev/fd0u1680 > brw-rw---- 1 root floppy 2, 60 Apr 4 23:21 /dev/fd0u1722 > brw-rw---- 1 root floppy 2, 76 Apr 4 23:21 /dev/fd0u1743 > brw-rw---- 1 root floppy 2, 96 Apr 4 23:21 /dev/fd0u1760 > brw-rw---- 1 root floppy 2, 116 Apr 4 23:21 /dev/fd0u1840 > brw-rw---- 1 root floppy 2, 100 Apr 4 23:21 /dev/fd0u1920 > brw-rw---- 1 root floppy 2, 12 Apr 4 23:21 /dev/fd0u360 > brw-rw---- 1 root floppy 2, 16 Apr 4 23:21 /dev/fd0u720 > brw-rw---- 1 root floppy 2, 120 Apr 4 23:21 /dev/fd0u800 > brw-rw---- 1 root floppy 2, 52 Apr 4 23:21 /dev/fd0u820 > brw-rw---- 1 root floppy 2, 68 Apr 4 23:21 /dev/fd0u830 > brw-rw---- 1 root floppy 2, 1 Oct 20 1999 /dev/fd1 > brw-rw---- 1 root floppy 2, 37 Oct 20 1999 /dev/fd1CompaQ > brw-rw---- 1 root floppy 2, 5 Oct 20 1999 /dev/fd1d360 > brw-rw---- 1 root floppy 2, 9 Oct 20 1999 /dev/fd1h1200 > brw-rw---- 1 root floppy 2, 41 Oct 20 1999 /dev/fd1h1440 > brw-rw---- 1 root floppy 2, 57 Oct 20 1999 /dev/fd1h1476 > brw-rw---- 1 root floppy 2, 73 Oct 20 1999 /dev/fd1h1494 > brw-rw---- 1 root floppy 2, 93 Oct 20 1999 /dev/fd1h1600 > brw-rw---- 1 root floppy 2, 21 Oct 20 1999 /dev/fd1h360 > brw-rw---- 1 root floppy 2, 49 Oct 20 1999 /dev/fd1h410 > brw-rw---- 1 root floppy 2, 65 Oct 20 1999 /dev/fd1h420 > brw-rw---- 1 root floppy 2, 25 Oct 20 1999 /dev/fd1h720 > brw-rw---- 1 root floppy 2, 81 Oct 20 1999 /dev/fd1h880 > brw-rw---- 1 root floppy 2, 85 Oct 20 1999 /dev/fd1u1040 > brw-rw---- 1 root floppy 2, 89 Oct 20 1999 /dev/fd1u1120 > brw-rw---- 1 root floppy 2, 29 Oct 20 1999 /dev/fd1u1440 > brw-rw---- 1 root floppy 2, 125 Oct 20 1999 /dev/fd1u1600 > brw-rw---- 1 root floppy 2, 45 Oct 20 1999 /dev/fd1u1680 > brw-rw---- 1 root floppy 2, 61 Oct 20 1999 /dev/fd1u1722 > brw-rw---- 1 root floppy 2, 77 Oct 20 1999 /dev/fd1u1743 > brw-rw---- 1 root floppy 2, 97 Oct 20 1999 /dev/fd1u1760 > brw-rw---- 1 root floppy 2, 117 Oct 20 1999 /dev/fd1u1840 > brw-rw---- 1 root floppy 2, 101 Oct 20 1999 /dev/fd1u1920 > brw-rw---- 1 root floppy 2, 33 Oct 20 1999 /dev/fd1u2880 > brw-rw---- 1 root floppy 2, 105 Oct 20 1999 /dev/fd1u3200 > brw-rw---- 1 root floppy 2, 109 Oct 20 1999 /dev/fd1u3520 > brw-rw---- 1 root floppy 2, 13 Oct 20 1999 /dev/fd1u360 > brw-rw---- 1 root floppy 2, 113 Oct 20 1999 /dev/fd1u3840 > brw-rw---- 1 root floppy 2, 17 Oct 20 1999 /dev/fd1u720 > brw-rw---- 1 root floppy 2, 121 Oct 20 1999 /dev/fd1u800 > brw-rw---- 1 root floppy 2, 53 Oct 20 1999 /dev/fd1u820 > brw-rw---- 1 root floppy 2, 69 Oct 20 1999 /dev/fd1u830 > > I think the redhatish distros have anothe scheme. Don't know anything > about the others. > > Do you want me to add this stuff to the bug list? Always feel free to add Bug Reports. The stuff in this letter would be Category: program Group: enhancement Prioritize based on how important you feel these features will be to the next public release. If it can be put on hold it is less important, if it keeps the program from working properly it is very important. Mention 'cretzu' as the reporter. Email goes out to whoever is the reporter and whoever the bug is assigned to. Keep up the great work, Lead Developer! |
|
From: Jonathan R. <mtt...@ac...> - 2000-08-24 17:12:50
|
>> I'll be adding stripping soon to make gBootRoot useable on 1440 devices >> in distributions which don't strip libraries. This situation created a >> very large initrd. You wouldn't happen to be running a distribution >> with unstripped libraries or binaries would you? > I use Debian, sorry: I knew that all along. :) > /lib/libc-2.1.3.so: ELF 32-bit LSB shared object, > Intel 80386, > version 1, > stripped > > > One cool thing, you can use the 1722 setting on most 1440 floppy devices > > without any problems. This is a trick of Tom's rtbt. This creates a lot > > of extra room for both the Boot and Root disk. :) This is something I > > will put in the FAQ. > > I actually use tomsrtbt now an then. Never got Yard working on my distro > (dispite the fact that it's packaged by Debian). Yard has some great and interesting coding, it would be a shame to let all that work go to waste. I just think the author stopped maintaining the code, not to mention his HOWTO. Hopefully, we will incorporate lots of Yard into gBootRoot; so always take a look there first to check whether the code we need already exists. |
|
From: Jonathan R. <mtt...@ac...> - 2000-08-24 16:17:56
|
On Thu, 24 Aug 2000, Cristian Ionescu-Idbohrn wrote: > > First off: my toes are to big for this keyboard :-) > What I thought was WARN showed up as WARM :-( Well the next time, just say: perl -e '$trans = "WARM", $trans =~ tr/M/N/, print $trans;' :) > > [snip] > > > Let me explain what I thought of when I suggested WARN as a separate error > level. > > We know what we're be going to do (at the beginning of the script). We > have a plan. We also know we can't do things with our bare hands. We need > some system tools. We know what system tools we need. Let's make sure we > have access to those tools (sanity checks in an init phase right from the > beginning, like: the program is there and is executable). Any problems > that arise, report them as WARN (warnings) to the user. I see what you are talking about, Yard does this. This is generally a good thing to do, I was hoping people who make packages for distributions would fill in the blanks, for instance, by making gBootRoot dependent on binutils, but that is assuming too much. Sanity checks for some things will be optional. For instance, if it isn't necessary for stripping to be done by objcopy (which belongs to binutils), there is no sense in requiring it. I'll be adding stripping soon to make gBootRoot useable on 1440 devices in distributions which don't strip libraries. This situation created a very large initrd. You wouldn't happen to be running a distribution with unstripped libraries or binaries would you? One cool thing, you can use the 1722 setting on most 1440 floppy devices without any problems. This is a trick of Tom's rtbt. This creates a lot of extra room for both the Boot and Root disk. :) This is something I will put in the FAQ. |
|
From: Cristian Ionescu-I. <ci...@ax...> - 2000-08-24 15:51:32
|
First off: my toes are to big for this keyboard :-) What I thought was WARN showed up as WARM :-( On Thu, 24 Aug 2000, Jonathan Rosenbaum wrote: [snip] > I think it would be better to just log the FATAL error, then the user can > make corrections, and resubmit. FATAL errors are caused by things like > running out of disk space. I've been avoiding dies or croaks for most > cases deliberately, on the other hand, if the system doesn't have init, > the person is really in trouble. The majority of things which stop > execution can be corrected by the user without killing the program. > > > b. ERROR stops the execution cleans up and brings you back to some safe, > > previous stage; keeps as much as possible of the entered data and gives > > some indication on what the problem is > > This is already built into the program at least for the present > capabilities. > > > These two cover the verbosity level 0, above. > > Sounds right, basically in most cases this would be the error output from > system calls .. the 2> thing. > > > 3. WARM indicates that something didn't work out but the program can > > continue > > Distinguishing between WARM and FATAL will be difficult and impressive > thing to do. I leave this to you for figuring out. :) Let me explain what I thought of when I suggested WARN as a separate error level. We know what we're be going to do (at the beginning of the script). We have a plan. We also know we can't do things with our bare hands. We need some system tools. We know what system tools we need. Let's make sure we have access to those tools (sanity checks in an init phase right from the beginning, like: the program is there and is executable). Any problems that arise, report them as WARN (warnings) to the user. > > This would be verbositi level 1, above. > > > > 4. INFO would give something like a trace (debug level) > > I am kind of turning your approach of INFO inside out, but here is my > idea, though it isn't necessary right: > > FATAL is -v .. WARM & FATAL is -vv , INFO can be -vvv and -vvvv > > INFO can be STDOUT -> -vvv > INFO can be written description -> -vvvv Throughout the program I have > commented out written descriptions I used in BootRoot with #V# Sounds ok. > We may ditch a -v because WARM & FATAL may be difficult to establish. See above. > > Not everything executed is a shell command, so there's need for a function > > to do that too. > > > > Maybe '--verbosity <level>' may be a command line option? > > No, I've written too many command line programs. :) And there is really > no advantage doing this with gBootRoot because it is designed to be a > button pushing program. ok. > > Another way to specify it could be some button(s) on the main window? > > I think a spin button like what is being used for device size will be > used. This will have different levels of verbosity .. nothing .. 1 .. 4 > > I think setting up a collapsable/expandable advanced section may be kind > of cool, then verbosity, initrd setting and the like can be included > there. Alternatively, maybe a popup menu .. there many ways of doing > this. > > > The results can stay in a log file (like it's done now) or showed 'live' > > in another window. > > There will be a SAVE button on the visible log. I'll create some > functions to do this, and then you do the fine tuning. We will be > converting to sys(), too. > > What do you think? Go for it! Cheers, Cristian -- I respect faith, but doubt is what gets you an education. -- Wilson Mizner |
|
From: Jonathan R. <mtt...@ac...> - 2000-08-24 13:25:08
|
> > I am glad you brought this up. First I think we should consider using the
> > sys function found in Yard:
> >
> > sub sys {
> > open(SYS, "@_ 2>&1 |") or die "open on sys(@_) failed: $!";
> > while (<SYS>) {
> > print LOGFILE;
> > print if $CFG::verbosity > 0;
> > }
> > close(SYS) or die "Command failed: @_\nSee logfile for error
> > message.\n";
> > 0; # like system()
> > }
> >
> > package CFG;
> >
> > # $verbosity: 1 or 0
> > #
> > # This controls only what is printed to the screen.
> > # 0 --> only the important messages.
> > # 1 --> all messages.
> > # All messages will be written to the log file regardless of the setting.
> > #
> > $verbosity = 0;
> >
> > The error parts would be modified to feed the users chosen level of
> > verbosity to a viewable widget. This would be a good way to handle system
> > calls. We may also consider getting rid of as many sys() as possible and
> > use Perl functions whenever we can. But one way or the other there should
> > be a verbosity option which brings up a text widget to show things as they
> > happen. And perhaps another option which allows the user to log stuff to
> > a file, ofcourse things could be cut and pasted, too.
> >
> > Tell me what you think?
>
> This is good. Clean and proper.
>
> Error handling is probably one of the more difficult things. That said,
> this idea is what I think:
>
> a. FATAL stops the execution (perl: die) and throws you out
I think it would be better to just log the FATAL error, then the user can
make corrections, and resubmit. FATAL errors are caused by things like
running out of disk space. I've been avoiding dies or croaks for most
cases deliberately, on the other hand, if the system doesn't have init,
the person is really in trouble. The majority of things which stop
execution can be corrected by the user without killing the program.
> b. ERROR stops the execution cleans up and brings you back to some safe,
> previous stage; keeps as much as possible of the entered data and gives
> some indication on what the problem is
This is already built into the program at least for the present
capabilities.
> These two cover the verbosity level 0, above.
Sounds right, basically in most cases this would be the error output from
system calls .. the 2> thing.
> 3. WARM indicates that something didn't work out but the program can
> continue
Distinguishing between WARM and FATAL will be difficult and impressive
thing to do. I leave this to you for figuring out. :)
> This would be verbositi level 1, above.
>
> 4. INFO would give something like a trace (debug level)
I am kind of turning your approach of INFO inside out, but here is my
idea, though it isn't necessary right:
FATAL is -v .. WARM & FATAL is -vv , INFO can be -vvv and -vvvv
INFO can be STDOUT -> -vvv
INFO can be written description -> -vvvv Throughout the program I have
commented out written descriptions I used in BootRoot with #V#
We may ditch a -v because WARM & FATAL may be difficult to establish.
> Not everything executed is a shell command, so there's need for a function
> to do that too.
>
> Maybe '--verbosity <level>' may be a command line option?
No, I've written too many command line programs. :) And there is really
no advantage doing this with gBootRoot because it is designed to be a
button pushing program.
> Another way to specify it could be some button(s) on the main window?
I think a spin button like what is being used for device size will be
used. This will have different levels of verbosity .. nothing .. 1 .. 4
I think setting up a collapsable/expandable advanced section may be kind
of cool, then verbosity, initrd setting and the like can be included
there. Alternatively, maybe a popup menu .. there many ways of doing
this.
> The results can stay in a log file (like it's done now) or showed 'live'
> in another window.
There will be a SAVE button on the visible log. I'll create some
functions to do this, and then you do the fine tuning. We will be
converting to sys(), too.
What do you think?
|
|
From: Cristian Ionescu-I. <ci...@ax...> - 2000-08-22 21:34:05
|
On Tue, 22 Aug 2000, Jonathan Rosenbaum wrote: [snip] > > On the other hand, maybe the person wants to enter a lot of different > things in brlilo, so it may not be a good idea to limit him to one > editable field. We could provide both an editable field for simple needs > and the ability to edit brlilo() for complex needs. Reparsing the user input (paranoia) would make it more complicated. |
|
From: Cristian Ionescu-I. <ci...@ax...> - 2000-08-22 21:04:03
|
On Tue, 22 Aug 2000, Jonathan Rosenbaum wrote:
> On Sun, 20 Aug 2000, Cristian Ionescu-Idbohrn wrote:
>
> > Another thing I'm thinking of is a verbose option which would put more
> > progress info into the log file, tell the user where it's placed and leave
> > it there on exit. That would help both bug tracebility and also help
> > curious guys, like me, underdtand what's going out behind the scens.
>
> I am glad you brought this up. First I think we should consider using the
> sys function found in Yard:
>
> sub sys {
> open(SYS, "@_ 2>&1 |") or die "open on sys(@_) failed: $!";
> while (<SYS>) {
> print LOGFILE;
> print if $CFG::verbosity > 0;
> }
> close(SYS) or die "Command failed: @_\nSee logfile for error
> message.\n";
> 0; # like system()
> }
>
> package CFG;
>
> # $verbosity: 1 or 0
> #
> # This controls only what is printed to the screen.
> # 0 --> only the important messages.
> # 1 --> all messages.
> # All messages will be written to the log file regardless of the setting.
> #
> $verbosity = 0;
>
> The error parts would be modified to feed the users chosen level of
> verbosity to a viewable widget. This would be a good way to handle system
> calls. We may also consider getting rid of as many sys() as possible and
> use Perl functions whenever we can. But one way or the other there should
> be a verbosity option which brings up a text widget to show things as they
> happen. And perhaps another option which allows the user to log stuff to
> a file, ofcourse things could be cut and pasted, too.
>
> Tell me what you think?
This is good. Clean and proper.
Error handling is probably one of the more difficult things. That said,
this idea is what I think:
a. FATAL stops the execution (perl: die) and throws you out
b. ERROR stops the execution cleans up and brings you back to some safe,
previous stage; keeps as much as possible of the entered data and gives
some indication on what the problem is
These two cover the verbosity level 0, above.
3. WARM indicates that something didn't work out but the program can
continue
This would be verbositi level 1, above.
4. INFO would give something like a trace (debug level)
Not everything executed is a shell command, so there's need for a function
to do that too.
Maybe '--verbosity <level>' may be a command line option?
Another way to specify it could be some button(s) on the main window?
The results can stay in a log file (like it's done now) or showed 'live'
in another window.
|
|
From: Jonathan R. <mtt...@ac...> - 2000-08-22 20:39:34
|
On Tue, 22 Aug 2000, Cristian Ionescu-Idbohrn wrote: > On Tue, 22 Aug 2000, Jonathan Rosenbaum wrote: > > True. Let's put them devices in a list and test and (maybe) create them > one by one. This sounds like a good idea. /dev/MAKEDEV could be used. We should give the user the benefit of the doubt, maybe he wants to use a device for the program which doesn't yet exist, but we should ask him first. We don't need all devices on the Boot disk. We may consider asking him in one or both of the ways mentioned below. > > You mentioned: > > > > > To make it work on my system, the way I want to, I had to add > > > > > > "video=matrox:vesa:402,depth:16 aic7xxx=verbose:0x39" > > > > > > to the "append" option. > > > > What I think needs to be done is to have gBootRoot bring up an interactive > > text selection. After a person makes the changes, gBootRoot will sense > > the changes in the text and add the new devices as needed. I think > > advanced users will like this feature, otherwise gBootRoot will become an > > installation program where the gBootRoot developers have to do all the > > guessing about other people's systems. gBootRoot should remain a tool. > > > > There may be better ways of doing this. Tell me what you think? > > "Another way of doing it" might be to show a new editable field with a > default value for the append parameter. On the other hand, maybe the person wants to enter a lot of different things in brlilo, so it may not be a good idea to limit him to one editable field. We could provide both an editable field for simple needs and the ability to edit brlilo() for complex needs. |
|
From: Cristian Ionescu-I. <ci...@ax...> - 2000-08-22 20:16:02
|
On Tue, 22 Aug 2000, Jonathan Rosenbaum wrote:
> Cristian,
>
> I hope you have your changes submitted to CVS,
No, I didn't. I agreed it's better to do easy traceble changes, so I'll
have to cool down and reorganize myself a bit.
> but here's the problem I
> found with your /dev/fb0 solution:
>
> # it is possible other folks use some othe partition to boot
> # we're more generous now :-)
> return if err(system "mkdir $mnt/{boot,dev} >> $verbosefn 2>&1; cp -a
> /dev/{null,fd?,hda*,sda*,fb0*} $mnt/dev >> $verbosefn 2>&1") == 2;
>
> Simplicity can be a nice thing. Not all distributions include all these
> devices by default. This change didn't work on my system because there
> isn't any /dev/fb0. I imagine there are some systems which don't have
> hda* or sda* either. I had:
>
> return if err(system "mkdir $mnt/{boot,dev} >> $tmp/verbose 2>&1; cp -a
> /dev/{null,fd?,hda1} $mnt/dev >> $tmp/verbose 2>&1") == 2;
>
> Come to think of it, I was presumptuous in assuming the existence of
> /dev/hda1. :)
>
> In your case /dev/fb0 is important for the kernel to function properly
> with your video card, the boot issue is already taken care of by this
> code:
>
> # Hopefully, this works, but have never tested it
> if ($device !~ m#/dev/fd\d{1}$#) {
> return if err( system "cp -a $device $mnt/dev >> $verbosefn 2>&1")
> == 2;
> }
>
> I'd be weired out if someone used gBootRoot on two /dev/sda1's at this
> point. But, anyways, a solution has to be provided for situations like
> yours.
True. Let's put them devices in a list and test and (maybe) create them
one by one.
> You mentioned:
>
> > To make it work on my system, the way I want to, I had to add
> >
> > "video=matrox:vesa:402,depth:16 aic7xxx=verbose:0x39"
> >
> > to the "append" option.
>
> What I think needs to be done is to have gBootRoot bring up an interactive
> text selection. After a person makes the changes, gBootRoot will sense
> the changes in the text and add the new devices as needed. I think
> advanced users will like this feature, otherwise gBootRoot will become an
> installation program where the gBootRoot developers have to do all the
> guessing about other people's systems. gBootRoot should remain a tool.
>
> There may be better ways of doing this. Tell me what you think?
"Another way of doing it" might be to show a new editable field with a
default value for the append parameter.
|
|
From: Jonathan R. <mtt...@ac...> - 2000-08-22 20:08:25
|
On Sun, 20 Aug 2000, Cristian Ionescu-Idbohrn wrote:
> Another thing I'm thinking of is a verbose option which would put more
> progress info into the log file, tell the user where it's placed and leave
> it there on exit. That would help both bug tracebility and also help
> curious guys, like me, underdtand what's going out behind the scens.
I am glad you brought this up. First I think we should consider using the
sys function found in Yard:
sub sys {
open(SYS, "@_ 2>&1 |") or die "open on sys(@_) failed: $!";
while (<SYS>) {
print LOGFILE;
print if $CFG::verbosity > 0;
}
close(SYS) or die "Command failed: @_\nSee logfile for error
message.\n";
0; # like system()
}
package CFG;
# $verbosity: 1 or 0
#
# This controls only what is printed to the screen.
# 0 --> only the important messages.
# 1 --> all messages.
# All messages will be written to the log file regardless of the setting.
#
$verbosity = 0;
The error parts would be modified to feed the users chosen level of
verbosity to a viewable widget. This would be a good way to handle system
calls. We may also consider getting rid of as many sys() as possible and
use Perl functions whenever we can. But one way or the other there should
be a verbosity option which brings up a text widget to show things as they
happen. And perhaps another option which allows the user to log stuff to
a file, ofcourse things could be cut and pasted, too.
Tell me what you think?
|
|
From: Jonathan R. <mtt...@ac...> - 2000-08-22 19:58:05
|
On Sun, 20 Aug 2000, Cristian Ionescu-Idbohrn wrote: > Another thing I've been thinking of is the following: > > Do you know of any way to find out if a kernel image has support for > > CONFIG_BLK_DEV_RAM=y > CONFIG_BLK_DEV_RAM_SIZE=4096 > CONFIG_BLK_DEV_INITRD=y > > by just analyzing the image. One could probably not expect a newbie to > know how that correlates with the ability to use such a tool like > gBootRoot. Nevertheless, a tool like this might help a newbie to get out > of a troublesom situation. If you look at /usr/src/linux/README there is a section which explains how you can use nm to look at linux/vmlinux, but the existence of this file and it's correlation to the chosen kernel can't be assumed. It would be easier just to look at .config, but again this is speculative. I suppose there is a way of finding this out, and I am open to suggestions. Good question. |
|
From: Jonathan R. <mtt...@ac...> - 2000-08-22 19:37:28
|
Cristian,
I hope you have your changes submitted to CVS, but here's the problem I
found with your /dev/fb0 solution:
# it is possible other folks use some othe partition to boot
# we're more generous now :-)
return if err(system "mkdir $mnt/{boot,dev} >> $verbosefn 2>&1; cp -a
/dev/{null,fd?,hda*,sda*,fb0*} $mnt/dev >> $verbosefn 2>&1") == 2;
Simplicity can be a nice thing. Not all distributions include all these
devices by default. This change didn't work on my system because there
isn't any /dev/fb0. I imagine there are some systems which don't have
hda* or sda* either. I had:
return if err(system "mkdir $mnt/{boot,dev} >> $tmp/verbose 2>&1; cp -a
/dev/{null,fd?,hda1} $mnt/dev >> $tmp/verbose 2>&1") == 2;
Come to think of it, I was presumptuous in assuming the existence of
/dev/hda1. :)
In your case /dev/fb0 is important for the kernel to function properly
with your video card, the boot issue is already taken care of by this
code:
# Hopefully, this works, but have never tested it
if ($device !~ m#/dev/fd\d{1}$#) {
return if err( system "cp -a $device $mnt/dev >> $verbosefn 2>&1")
== 2;
}
I'd be weired out if someone used gBootRoot on two /dev/sda1's at this
point. But, anyways, a solution has to be provided for situations like
yours.
You mentioned:
> To make it work on my system, the way I want to, I had to add
>
> "video=matrox:vesa:402,depth:16 aic7xxx=verbose:0x39"
>
> to the "append" option.
What I think needs to be done is to have gBootRoot bring up an interactive
text selection. After a person makes the changes, gBootRoot will sense
the changes in the text and add the new devices as needed. I think
advanced users will like this feature, otherwise gBootRoot will become an
installation program where the gBootRoot developers have to do all the
guessing about other people's systems. gBootRoot should remain a tool.
There may be better ways of doing this. Tell me what you think?
|
