bike/gbootroot
1
0
Fork 0
mirror of https://github.com/fspc/gbootroot.git synced 2025-02-23 09:03:23 -05:00
Code Issues Projects Releases Wiki Activity

1.3.5 release.

Browse Source
This commit is contained in:
freesource 2002-02-13 19:43:15 +00:00
parent 033c61d043
commit 504e8545a2
1 changed files with 12 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
Changes
View File

@ -1,14 +1,20 @@
1.3.5 - 02/13/2002
------------------
** not yet Now the template called Helper.yard used to create the root_fs_helper is
Now the templated called Helper.yard used to create the root_fs_helper is
included with root_fs_helper. included with root_fs_helper.
1.3.4 was awarded Editor's pick by SoftLandMark, but I recommend upgrading
to 1.3.5 because of my oversight with the root_fs_helper issue, as well as
the improved initrd testing capability of the specially patched
2.4.17-10um kernel. I also recommend running gbootroot as a normal user, at
least that's what I usually do. :)
Root_fs_helper was working fine, but because I hadn't committed, let alone Root_fs_helper was working fine, but because I hadn't committed, let alone
copied the new changes to CVS I didn't notice any aberrations until I copied the new changes to CVS I didn't notice any aberrations until I
installed the new released version of gbootroot. This is related to the new installed the new released version of gbootroot. This is related to the new
securretty requirements of uml. Problem fixed. securretty requirements of uml. Problem fixed.
*** Better check on this below
Initrd was not working with any fs other than ext2. After Initrd was not working with any fs other than ext2. After
contacting the trinux-uml project, Matthew Franz <mfranz@cisco.com> confirmed contacting the trinux-uml project, Matthew Franz <mfranz@cisco.com> confirmed
that he was having problems creating a working uml for the initrd created that he was having problems creating a working uml for the initrd created
@ -18,11 +24,10 @@ known bugs as documented in the kernel sources. Because cramfs was placed
before just about every fs in the VFS check order, and trinux-uml's initrd before just about every fs in the VFS check order, and trinux-uml's initrd
was minix, the kernel failed, but an ext2 initrd didn't. Changing the order was minix, the kernel failed, but an ext2 initrd didn't. Changing the order
in which filesystems are checked during the VFS stage by editing fs/Makefile in which filesystems are checked during the VFS stage by editing fs/Makefile
solves the problem. Thanks for Henrik Nordstrom <hno@marasystems.com> for solves the problem. Thanks to Henrik Nordstrom <hno@marasystems.com> for
pointing out how to do this at user-mode-linux-devel. I am hoping the patch pointing out how to do this at user-mode-linux-devel. I am hoping the patch
I posted at -devel becomes part of uml. This should have been corrected found in user-mode-linux/usr/lib/uml/cramfs-vfs-oder.patch becomes part of
ages ago in the standard Linux kernel. uml. This should have been corrected ages ago in the standard Linux kernel.
** not yet
Removed unecessary warning which warned that left-hand side replacements Removed unecessary warning which warned that left-hand side replacements
couldn't be a directory if it happened to find that directory on the hostfs. couldn't be a directory if it happened to find that directory on the hostfs.