alternative puppy build system

Message

wanderer · #361 Post by **wanderer** » Sun 26 May 2019, 13:29

hi s243a

yeah i dont want to distract you
very heavy work
i can follow along by your posts and the code

once again thanks
awesome work

wanderer

s243a · #362 Post by **s243a** » Mon 27 May 2019, 07:59

So previously, I was only syning the petspecs with the meta-data from dpkg. Now I'm also syncing the file lists:

Code: Select all

    pkg_file_list="$DPKG_ADMIN/$pet_specs_PKG_NAME".list
    if [ $(wc -c <"$pkg_file_list") -gt 4 ] || [ SYNC_DUMMY -eq 1 ]; then
      if [ "$(basename "$PUPPY_ADMIN_LIST")" = builtin_files ]; then
        ln $DPKG_ADMIN/"$pet_specs_PKG_NAME".list "$PUPPY_ADMIN_LIST/$pet_specs_PKG_NAME"
      else
        ln $DPKG_ADMIN/"$pet_specs_PKG_NAME".list \
           "$PUPPY_ADMIN_LIST/$pet_specs_PKG_NAME"_"$pet_specs_VERSION".files
fi

Code: Select all

install_from_dir() {
	...
	if [ -z "$4" ] || [ "$4" != "force" ]; then
	  is_already_installed $pkgname && return 1
	elif is_already_installed $pkgname; then
	  remove_pkg_status "${pkgname}"
	else
	  IS_INSTALLED=0
        fi
        ...

/builders/deb-build.sh#L405

Which required removing metadata about a package from the status file:

Code: Select all

remove_pkg_status() {
	pkg_name=$1
	status_new="$CHROOT_DIR$ADMIN_DIR/status.new.$$"
	echo "removing package status"
	while read line; do
	  case "$line" in
      'Package: '*)
          set -- "$line" 
          if [ "$pkg_name" = "$2" ]; then
            echo_line=0
          else
            echo_line=1
          fi
      ;;
      esac
     if [ $echo_line -eq 1 ]; then
       echo $line >> "$status_new"    
     fi
	done < $CHROOT_DIR$ADMIN_DIR/status
	rm "$CHROOT_DIR$ADMIN_DIR/status"
	mv "$status_new" "$CHROOT_DIR$ADMIN_DIR/status"
}

/builders/deb-build.sh#L349

The ability to re-install packages means I can install the core of a system (aka rootfs-skeleton) at the beginning to set up the environment then at the end of the configuration script to make sure nothing installed over-rode something important.

I did the over-riding by adding a --forced option:

Code: Select all

			%addpkg)
			    set -x
				shift # $1-pkgname, pkgname ...
				forced=0
				PKGSECTION="optional"
				while [ "$1" ]; do
					case "$1" in
					--forced)
					  forced=1
					  ;;
					--category=*)
					  PKGSECTION="${1#'--category='}";
					  ;;
					*)
					  ! [ -d $EXTRAPKG_PATH/$1 ] && shift && continue
					  echo Installing extra package "$1"  ...
					  if [ $forced -eq 1 ]; then
					    install_from_dir $EXTRAPKG_PATH/$1 $1 $PKGSECTION force
					  else
					    install_from_dir $EXTRAPKG_PATH/$1 $1 $PKGSECTION
					  fi
					  ;;
					esac
					shift
				done
				set +x
;;

/builders/deb-build.sh#L666

and the related lines on my configuration script look like:

Code: Select all

%addpkg --forced tinycore9_base_gz
%addpkg --forced puppycore_noarch

#%addpkg --forced tinycore9_base_gz_users #Can use instead of puppycore_users
%addpkg --forced puppycore_users

%addpkg --forced puppycore_i386_strech

#Can use tinycore9_base_gz_startup instead of puppycore: _sysinit _sysinit_net _Xstartup
#%addpkg tinycore9_base_gz_startup 

%addpkg --forced puppycore_sysinit
%addpkg --forced puppycore_sysinit_net
%addpkg --forced puppycore_Xstartup

%addpkg --forced debian-setup # specific debian setup, overriding puppy-base

#Dependencies for pkg (maybe create wrappers for these instead of installing them)
%reinstall findutils #Dependency of PKG
%reinstall sed       #Dependency of PKG
%reinstall grep      #Dependency of PKG
%reinstall wget #required for pkg

/woof-distro/x86/tiny_devuan/ascii/basesfs#L208

wiak · #363 Post by **wiak** » Mon 27 May 2019, 09:21

I'm just curious if the package manager (sc0ttman's?) has knowledge (keeps track of) any programs included in root-fs skeleton or does it just come into play after that (in your build system)? It would be good, especially for upgrade purposes, if it keeps track of 'every' script and package involved in the build, but maybe it does or maybe that isn't possible the way Puppy is traditionally put together (though I guess anything could be arranged?).

No doubt, a commandline, dependency resolving package manager is the way ahead to improve Puppy, though I realise, and can see from your efforts s243a, that there is a lot of complex work involved even with that now available.

Good to see your determined effort! End result will surely be much better than current woof-CE mechanism.

wiak

s243a · #364 Post by **s243a** » Mon 27 May 2019, 16:34

wiak wrote:I'm just curious if the package manager (sc0ttman's?) has knowledge (keeps track of) any programs included in root-fs skeleton or does it just come into play after that (in your build system)? It would be good, especially for upgrade purposes, if it keeps track of 'every' script and package involved in the build, but maybe it does or maybe that isn't possible the way Puppy is traditionally put together (though I guess anything could be arranged?).

When you use the command (for the first time):

Code: Select all

pkg --repo-update

pkg, will look for files in the /root/.pkgages folder to see what is installed.

This includes the petspecs that are stored in files of the form:

Code: Select all

/root/.packages/*--installed-packages

e.g. "woof-installed-packages"
and it will look for file lists in one of the following forms:

Code: Select all

/root/.packages/"$pkgname_$pkgversion".files
/root/.packages/builtin_files/"$pkgname"

Since the deb-build.sh component of woof-next uses dpkg to build the rootfs, I covert the dpkg meta data into the "puppy package manager" (i.e. petget) equivalent using the function:
sync_pet_specs_fm_dpkg.sh

As for keeping tracking of packages in "root-fs skeleton", woof-next will treat "root-fs skeleton" (aka puppybase) as a complete package. As I noted in my previous post I started breaking up puppies "rootfs skeleton" into seperate packages. The reason to do this is that if we start mixing the core parts of different versions of "linux", then files in the core/base/skeleton (for each version of "linux") might conflict.

No doubt, a commandline, dependency resolving package manager is the way ahead to improve Puppy, though I realise, and can see from your efforts s243a, that there is a lot of complex work involved even with that now available.

Good to see your determined effort! End result will surely be much better than current woof-CE mechanism.

wiak

The biggest issue that I have with "pkg" is that it doesn't fail gracefully, if you are missing dependencies: sed, tar, findutils, grep. I think that pkg should detect if you have the full versions and try to use the best busybox equivalent of the command if you are missing the full version.

For instance the devaun repo doesn't like the --spider option if it is both the case that:
1. you are referring to a specific file and,
2. you are using using the busybox version of wget.

Therefore, if you are using the busybox version of wget you should try to download the file rather than testing if it exists with the --spider option. Also if pkg, can't work without a given dependency then it should throw an error rather than going into an infinite loop.

The other thing that might be challenging for some people is to configure a given repo for pkg. Fortunately, there was a puppy version of devaun that I could copy these files from. If these files don't exist then pkg should try to supply fallbacks for these files.

As a final issue with pkg, pkg should match the shortest matching name of a pkg. It doesn't always behave this way.

P.S. package also seems to use the cut command in places where either grep or awk would be faster.

Edit: pkg seems to also require "sort" from coreutils.

Code: Select all

sort: unrecognized option '--field-separator=-'

s243a · #365 Post by **s243a** » Tue 28 May 2019, 08:12

s243a wrote:
Edit: pkg seems to also require "sort" from coreutils.
Code: Select all
sort: unrecognized option '--field-separator=-'

I think that installing coreutils overwrites /bin/df which is a puppy specific version of df that might be required for startup. The full version (non puppy spedific) has the name df-FULL in puppy linux. There are a few utilities like this on puppylinux. I created a script a post insall script that will rename these files. Here is part of that script:

Code: Select all

       #TODO maybe do a more in depth check before removing this. 
       if [ -e "$full_util_dir/$a_util-FULL" ]; then
         rm "$full_util_dir/$a_util-FULL"
       fi
       mv "$full_util_dir/$a_util" "$full_util_dir/$a_util-FULL"
mv "$puppy_util_dir/$a_util.new" "$puppy_util_dir/$a_util"

/woof-code/rootfs-packages/puppycore_utils/pinstall.sh#L48

This postinstall script is for the package puppycore_utils. It contains the following files:

Code: Select all

/bin/df.new
/bin/mount.new
/bin/bs.new
/bin/umount.new
/sbin/losetup.new

The post install script removes the .new suffix after the full version has the "-FULL" fufix added to it. Since the files in the final system differ than in the package, I created a file list for the packge called "files" and I modified the function install_from_dir() in deb-build.sh so that it will use the supplied file list when it exists.

Code: Select all

rm "$CHROOT_DIR$ADMIN_DIR/info/${pkgname}.list"
cp "${1}"/files "$CHROOT_DIR$ADMIN_DIR/info/${pkgname}.list"

/builders/deb-build.sh#L418

This code isn't completly tested yet.

sc0ttman · #366 Post by **sc0ttman** » Tue 28 May 2019, 22:31

I'm happy to look at any pull requests or diffs (etc) that help remove dependencies in Pkg or make it's installation easier, or whatever other changes/improvements you can think of/need..

wanderer · #367 Post by **wanderer** » Wed 29 May 2019, 00:58

hi s243a

you might check out dcores import-sce (and related scripts)
if you have not already
it downloads debs and makes sces
which are combined sfs files
with the app and its dependencies
in the same sfs file

it resolves a lot of dependency issues
and may be interesting to you
and apply to the work you are doing with woof-next

by the way thanks for doing all this
i have been following your posts and reading your code
its awesome

wanderer

jamesbond · #368 Post by **jamesbond** » Wed 29 May 2019, 05:38

@s243a: Before you get too engrossed with "fixing" puppy-base code in woof-next, please remember that code is five (5) years old. A lot has changed since then. I think it would be better if you grab the latest/current puppy-base from Woof-CE proper and work from there.

s243a · #369 Post by **s243a** » Wed 29 May 2019, 06:22

wanderer wrote:hi s243a

you might check out dcores import-sce (and related scripts)
if you have not already
it downloads debs and makes sces
which are combined sfs files
with the app and its dependencies
in the same sfs file

it resolves a lot of dependency issues
and may be interesting to you
and apply to the work you are doing with woof-next

These scripts could be a pacakge that one could install.

Related to tinycore though, I would like to use some more tinycore libraries as base libraries (e.g. the tc equivalent of libglib2.0-0 ). Maybe I could do this with tinycores package manager.

by the way thanks for doing all this
i have been following your posts and reading your code
its awesome

wanderer

Thankyou

s243a · #370 Post by **s243a** » Wed 29 May 2019, 06:25

jamesbond wrote:@s243a: Before you get too engrossed with "fixing" puppy-base code in woof-next, please remember that code is five (5) years old. A lot has changed since then. I think it would be better if you grab the latest/current puppy-base from Woof-CE proper and work from there.

I already did that a while ago. The puppy base I copied was the rootfs-skeleton of the master branch.
/woof-CE/tree/master/woof-code/rootfs-skeleton

Today, I also copied into my woof-next branch the following folder:

https://github.com/puppylinux-woof-CE/w ... itrd-progs

I did this because I thought that the lastest woof-CE boot code might be easier to troubleshoot. I made some modifications to get this working which I'll describe shortly.

s243a · #371 Post by **s243a** » Wed 29 May 2019, 07:11

As I noted above, I copied the more recent boot code from woof-CE
/puppylinux-woof-CE/woof-CE/.../initrd-progs/0initrd/init
/s243a/woof-CE/.../initrd-progs/0initrd/init

To use this newer initrd boot code one must make the following change in build.conf

Code: Select all

#INITRD_CODE="$WOOFCE/woof-code/boot/initrd-tree0"
INITRD_CODE="$WOOFCE/initrd-progs/0initrd"

Also since I'm using the following kernal:
https://distro.ibiblio.org/puppylinux/huge_kernels/
https://distro.ibiblio.org/puppylinux/h ... up.tar.bz2
https://distro.ibiblio.org/puppylinux/h ... z2.md5.txt
https://distro.ibiblio.org/puppylinux/h ... readme.txt
***See Previous post.

I also need an fdrv. To get the fdrv to work you must modify the DISTRO_SPEC file that goes into the ISO. On jamesbond's repo this is defined at:
builders/build-iso.sh#L81

I modified it to look like:

Code: Select all

	> $initrdtmp/DISTRO_SPECS cat << EOF
DISTRO_NAME='$SOURCE Puppy'
DISTRO_VERSION='$DISTRO_VERSION'
DISTRO_BINARY_COMPAT='$SOURCE'
DISTRO_FILE_PREFIX='$SOURCE'
DISTRO_COMPAT_VERSION='$SOURCE'
DISTRO_XORG_AUTO='yes'
DISTRO_TARGETARCH='$TARGET_ARCH'
DISTRO_DB_SUBNAME='$SOURCE'
DISTRO_PUPPYSFS=$PUPPY_SFS
$(echo_sfs_drvs)
EOF

/builders/build-iso.sh#L105
Where the "$(echo_sfs_drvs)" at the end of the heardoc inserts info about other sfs files of the type (adrv ydrv zdrv fdrv) into /initrd/DISTRO_SPECS.

The function that inserts this additional info is defined as follows:

Code: Select all

_(){
  eval "echo \"$1\""
}

echo_sfs_drvs(){
  #DISTRO_ZDRVSFS=kernel-modules.sfs
 for A_DRV in F Z Y A; do 
  a_drv=$(echo $A_DRV | tr '[:upper:]' '[:lower:]')
  if [ ! -z "$(_ "\$${A_DRV}DRV_SFS")" ]; then 
    echo DISTRO_${A_DRV}DRVSFS="$(_ "\$${A_DRV}DRV_SFS")";   
  elif [ -f $ISO_ROOT/"$a_drv"drv_sfs.sfs ]; then 
    echo DISTRO_${A_DRV}DRVSFS="$a_drv"drv_sfs.sfs; 
  elif [ -f $ISO_ROOT/"$a_drv"drv_"$SFS_SUFIX".sfs ]; then 
    echo DISTRO_${A_DRV}DRVSFS="$a_drv"drv_"$SFS_SUFIX".sfs; 
  elif [ -f $ISO_ROOT/"$a_drv"drv.sfs ]; then 
    echo DISTRO_${A_DRV}DRVSFS="$a_drv"drv.sfs    
  fi
 done
}

/builders/build-iso.sh#L73

Now this code is a bit cryptic. So In words (taking the adrv as an example), first we look to see if the variable ADRV_SFS is defined and if it is that gives the name of the adrv. If not we look to see if there is something in the iso-root folder that looks like the adrv and if there is then we base the petspec on this name.

The final thing that I did here was to copy bb-create-symlinks into the initrd if it doesn't exist.

Code: Select all

[ ! -e "$initrdtmp/bin/bb-create-symlinks" ] && \
  cp -f "$WOOFCE/initrd-progs/pkg/busybox_static/bb-create-symlinks" \
  "$initrdtmp/bin/bb-create-symlinks"

/builders/build-iso.sh#L100

This wasn't an issue with the initrd that woof next original linked to but the latest puppycode doesn't include this file directly in the initrd code and without it the kernal will not be able to find the interpreter for the init script and as a consequence will tell you that init is not found.

s243a · #372 Post by **s243a** » Wed 29 May 2019, 08:09

On a debugging note, I tried the newer boot code because I started getting stuck on 'switch root'

I have the same problem with the newer boot code. I dumped the debugging output to the screen as follows:

Code: Select all

#[ ! "$LOGLEVEL" ] && exec 1>/tmp/bootinit.log 2>&1 #remove o/p from console. v2.22 loglevel added.
exec 1>/dev/console 2>&1 #s243a

I had to do this because supplying loglevel=3 as a boot paramater didn't work.

and I'm getting lots of errors of the form

Code: Select all

can't open /dev/tty1: No such file or director

I think that I need to copy the device files into initrd. Now to hunt for them.

Edit 1: hmmmmm....I wonder if these are the device files that I was looking for:
/woof-next/woof-arch/woof-code_rootfs-skeleton_DEVDIR.tar.gz

I found these in a previous post.

Edit 2: On another note, there are a lot of packages in:
/woof-CE/tree/testing/initrd-progs/pkg

that I think are for the initrd. I wonder which ones might be needed, which aren't in:

/woof-next/woof-arch/x86/target/boot/initrd-tree0/bin

s243a · #373 Post by **s243a** » Wed 29 May 2019, 18:42

So after adding debugging code to /initrd/init I was able to get more troubleshooting info from the console.

I got the errors:

Code: Select all

/etc/rc.d/rc.sysinit: line 101: can't open 'etc/DISTRO_SPECS

and then a bunch of

Code: Select all

can't open /dev/tty1: No such file or directory

The first error tells me that we probably suceeded in the switch root. I'm wondering if DISTRO_SPECS was included in one of the puppy base files and I removed it. I think though it would be better if we had a distribution specific version of DISTRO_SPECS rather than using a generic one from "puppycore".

Also if this file is missing then I think (in rc.sysinit) we could copy it from /etc/initrd/DISTRO_SPECS but I need to first verify that the intent of these two files is the same.

I also see that I'm missing device files in the new root (i.e. after the switch root). I think these files can be created by either edev or udev (or did jamesbond include them in puppycore?) but I also think that if neither of these packages are installed then we could copy them from:
/woof-next/woof-arch/woof-code_rootfs-skeleton_DEVDIR.tar.gz

We might be able to extract these into the basesfs and if that doesn't work we could copy the .tar.gz file into intird and then in the init script extract these into the new root if either edev or udev isn't installed.

I most cases we will probably have eudev or udev installed (tinycore being a probable excretion), so we might want to add some functional control structures (e.g. a functional if) to the base sfs configuration file. I'm thinking it might look like this

Code: Select all

%if( %isInstalled eudev %, %devSekeleton %)

and I don't think that simple control strctures like this will be that hard to implement. The advantage here is that we can add and remove things like edev and udev without worrying about breaking the configuration file.

P.S. I'm assuming that we will need only lazy functional logic. If there is a reason for a "non function if", then we could call the functional iff %iff.

Edit: I just checked and I had eudev installed in my base sfs. I'm wondering if I could have avoided this error by starting this service prior to rc.sysinit looking for ttyl1 or alternatively if we need some minimum amount of device files regardless of whether or not we have eudev or udev installed.

wiak · #374 Post by **wiak** » Wed 29 May 2019, 22:03

With great respect s243a, I can't help but wonder from your many posts about your attempted woof-next developments if you have placed yourself in some very deep water? Clearly from what your write there are some great issues/complexities involved, including pkg issues and device files missing and so on. That is the trouble with taking over someone elses complex system many years after it was originally written too I feel. Personally I wouldn't myself try.

My main point is that, you are clearly trying your very best to get a good outcome here and it certainly would be great if you manage, but please don't be afraid to ever throw in the towel if the issues you come across proves to be insurmountable (which can sometimes be the case). It's not worth the stress and effort sometimes and you were doing very well with your 64-bit TazPup dev work and I miss seeing you completing that.

I didn't want to say anything because of course it would be great if woof-next could be resurrected as an alternative Puppy build system, and maybe you are close (I don't know) - just hoping you take stock and make sure you don't tire yourself out on anything that proves impossible.

I am particularly concerned if it is the case that pkg has any issues that prevent your success - any package manager, as you know, is a complex beast and despite pkg being a much-needed kind of commandline driven package manager for Puppy, I don't think it has been given a great deal of community testing as yet (of course you are helping with that). That could prove to be a road-block, for now, that you cannot reasonably pass?

So if you do hit any such roadblock, which it is unreasonable for you to shift yourself, please do not be afraid to freeze your woof-next project if you have to. 64-bit TazPup also beckons and results there were looking very positive.

wiak

s243a · #375 Post by **s243a** » Wed 29 May 2019, 22:39

wiak wrote:With great respect s243a, I can't help but wonder from your many posts about your attempted woof-next developments if you have placed yourself in some very deep water? Clearly from what your write there are some great issues/complexities involved, including pkg issues and device files missing and so on.

Yes but at the same time you can learn a lot by reviewing someone else's code. I also think that woof-next can evolve beyond a distribution builder. I think that it can become a full fledged interpreter that can also be used as a package manager.

That is the trouble with taking over someone elses complex system many years after it was originally written too I feel. Personally I wouldn't myself try.

I understand this but I was looking at woof-next because it has fewer lines of code than woof-CE. It also lets me learn about woof-CE because there are components of woof-CE incorporated into woof-Next.

My main point is that, you are clearly trying your very best to get a good outcome here and it certainly would be great if you manage, but please don't be afraid to ever throw in the towel if the issues you come across proves to be insurmountable (which can sometimes be the case).

This is a fair comment but I know that woof-next can successfully build a debian or slackware distribution. Therefore, if the goal is only to build slackware and debian based distributions than it isn't that far behind woof-CE...albiet with older code.

Jamesbond claims it can also build fatdog like distributions but i need to see more info on this.

I do question though whether or not woof-next can "as is" build a devaun based distro. It appears from some peoples report that it has but due to some issues that I've encounter, I am somewhat skeptical...the device file issue being the top issue on my the list of why I'm skeptical about whether or not the official woof-next can produce a devaun distro.

P.S. I was actually able to boot into a tinycore like system using woof-next but it wasn't really tinycore. It was puppy calling tinycore's init scripts. I also (regarding devaun builds) got past rc.sysinit to where qemu was looking for plogin...so it is possible that I broke some things along the way but hopefully in the end this will create a better system.

It's not worth the stress and effort sometimes and you were doing very well with your 64-bit TazPup dev work and I miss seeing you completing that.

Thanks for the compliment

I wasn't aware there was much interest in TazPup64 but I have been using it daily. I do think that TazPup64 is a good project because most newer 64bit puppies (in my opinion) don't preform well on older machines. I do know that this is somewhat of a hardware specific issue because I know that some people do have old hardware that runs newer 64 bit pupps well.

I didn't want to say anything because of course it would be great if woof-next could be resurrected as an alternative Puppy build system, and maybe you are close (I don't know) - just hoping you take stock and make sure you don't tire yourself out on anything that proves impossible.

I don't think it's impossible and I do think that I'll learn a lot.

I am particularly concerned if it is the case that pkg has any issues that prevent your success - any package manager, as you know, is a complex beast and despite pkg being a much-needed kind of commandline driven package manager for Puppy, I don't think it has been given a great deal of community testing as yet (of course you are helping with that). That could prove to be a road-block, for now, that you cannot reasonably pass?

Woof-Next does have the option of using the native package manager (or even the official puppy package manager). To me this is unsatisfying because in my opinion dpkg/apt complains too much if things aren't perfect and petget doesn't support the command line.

I think that if I create a distro (/derivative distro) that is functional and uses Sc0tmann's pkg as the package manager then this will create interest in the distro and help Sc0tmann's package manger progress.

I don't think that pkg has to work perfectly in the first release of the distro and having something that works well enough will be enough to help spur further development/testing of pkg.

So if you do hit any such roadblock, which it is unreasonable for you to shift yourself, please do not be afraid to freeze your woof-next project if you have to. 64-bit TazPup also beckons and results there were looking very positive.

wiak

I'm glad you think so. My intent wasn't to completely freeze TazPup64 but I did want to get woof-next far enough a long so that I could better split my time. On my upstairs floor I have a 64bit computer running TazPup64, on the lower floor I have a 32bit computer running dpup strech. So in theory being able to develop woof-next on the 32 bit computer gives me more development time.

The problem of course is the amount of mental energy that it takes to be able to balance two complex projects becasue some times troubleshooting requires a large mental roadmap of where in the code various things are done and not everyone can do this kind of multitasking.

p.s. 1 I hope that my error reports of either pkg or woof-next don't misrepresent these two systems. As with any system, user error is always a possibility.

That said, sometimes it is essential to use system in the way that the author didn't intend in order for the system to progress.

p.s. 2 Development on woof-next may help me with TazPup64 because both systems use components of woof-CE, so the resulting knowledge gained is likely helpful. Also sometimes scripts developed on one system can be reused on another. Also I may create a config file to build a TazPup64 like system on woof-next. If I do so then there will be more cross-fertilization between what I do on woof-next vs TazPup64.

ps. 3: Some issues that I'm experience might be due to me using a different puppycore (aka rootfs-skeleton) than provided by jamesbond. I'm doing this so that I'm using newer woof-CE code and also because greater modularity is required to make woof-next more flexible in the type of systems that it can build.

s243a · #376 Post by **s243a** » Thu 30 May 2019, 00:53

s243a wrote:
wiak wrote:With great respect s243a, I can't help but wonder from your many posts about your attempted woof-next developments if you have placed yourself in some very deep water? Clearly from what your write there are some great issues/complexities involved, including pkg issues and device files missing and so on.
...

I do question though whether or not woof-next can "as is" build a devaun based distro. It appears from some peoples report that it has but due to some issues that I've encounter, I am somewhat skeptical...the device file issue being the top issue on my the list of why I'm skeptical about whether or not the official woof-next can produce a devaun distro.

P.S. I was actually able to boot into a tinycore like system using woof-next but it wasn't really tinycore. It was puppy calling tinycore's init scripts. I also (regarding devaun builds) got past rc.sysinit to where qemu was looking for plogin...so it is possible that I broke some things along the way but hopefully in the end this will create a better system.

...

p.s. 1 I hope that my error reports of either pkg or woof-next don't misrepresent these two systems. As with any system, user error is always a possibility.

That said, sometimes it is essential to use system in the way that the author didn't intend in order for the system to progress.

I think the missing device files might be created by the kernal and accessed by mounting devtmpfs

Devtmpfs lets the kernel create a tmpfs very early at kernel initialization, before any driver core device is registered. Every device with a major/minor will have a device node created in this tmpfs instance. After the rootfs is mounted by the kernel, the populated tmpfs is mounted at /dev. In initramfs, it can be moved to the manually mounted root filesystem before /sbin/init is executed.

https://blog.csdn.net/longwang155069/ar ... s/52757592

The following occurs before the boot scripts look for tty1

Code: Select all

#================================================================
#                         MAIN
#================================================================
# mount devtmpfs early
mount -t devtmpfs devtmpfs /dev 2>/dev/null

/etc/rc.d/rc.sysinit#L94

It's possible that I could be missing a dependency for mount (or maybe a kernal module isn't loaded that is needed for tmpfs?).

I also noticed some differences in /etc/fstab. Here is what I have in dpup stretch:

Code: Select all

none          /proc        proc     defaults               0 0
none          /sys         sysfs    defaults               0 0
none          /dev/pts     devpts   gid=2,mode=620         0 0
/dev/fd0      /mnt/floppy  auto     noauto,rw              0 0

vs what I have in the rootfs that I built:

Code: Select all

# /etc/fstab
proc            /proc        proc    defaults          0       0
sysfs           /sys         sysfs   defaults          0       0
devpts          /dev/pts     devpts  defaults          0       0
tmpfs           /dev/shm     tmpfs   defaults          0       0

I'm not sure whether or not these differences in fstab are relevant at this point in the boot process.

s243a · #377 Post by **s243a** » Thu 30 May 2019, 01:19

Regarding the device files I see that there was a change about a year ago in woof-CE on how they were created in the initrd boot scripts.

** This was done in commit 54ef39153265bc8e032179f188c172d15b5f02f0

Previously these files were created by extracting a tar.gz archive and now it looks like they are created by mounting devtmpfs.

Anyway here are some code exerpts:

Code: Select all

/sbin/usablefs # mount: /proc /sys /dev / (proc sysfs devtmpfs rootfs)

/initrd-progs/0initrd/init#L60]

Code: Select all

mount -t devtmpfs devtmpfs /dev 2>/dev/null

/initrd-progs/0initrd/sbin/usablefs#L7

Code: Select all

cp -a bin sbin etc dev lib locale usr var /pup_new${TMPFS} 2>/dev/null

/0initrd/init#L1417

Code: Select all

umount /sys
umount /dev
umount /proc

/0initrd/init#L1426

wanderer · #378 Post by **wanderer** » Thu 30 May 2019, 01:27

hi s243a

like wiak has posted

i also am worried about you working too hard

can you just make a simple system
that builds to completion

and then add to it when you get the time

i have been following your posts and code
and i do think that you are breaking new ground
and will accomplish your very ambitious goals

but i am afraid that you will exhaust yourself

remember we just want to have fun

i intend to continue to learn and use the system you are creating
ad infinitum
and i could just build isos
and solicit your opinion as things go along
and develop the system step by step

regards

wanderer

s243a · #379 Post by **s243a** » Thu 30 May 2019, 02:56

wanderer · #380 Post by **wanderer** » Thu 30 May 2019, 03:22

hi s243a

i agree (with at least what i think is your opinion)

i think that you doing all this work on woof-next
actually spurs interest and understanding of woof-ce

but i am hoping for something that a non guru can use

once again thanks for all your work
but take it easy we all worry about you

regards

wanderer

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

alternative puppy build system