puppylinux-woof-CE / woof-CE

woof - the Puppy builder
GNU General Public License v2.0
393 stars 283 forks source link

Woof-ce gives error at the end of 3builddistro-Z script #1138

Closed Randall-Glass closed 6 years ago

Randall-Glass commented 6 years ago

I am using xenialpup64-7.5 fugal install with a save folder. Trying to create xenialpup64 with standard options.

I get the following error.


INITRD: initrd.gz [x86_64] /DISTRO_SPECS: xenialpup64 7.5 x86_64

chroot: can't execute 'echo': No such file or directory ERROR: could not 'chroot' into sandbox3/rootfs-complete This means that something is incomplete, perhaps a library needed by bash. Check it out. Have to exit script now.


The only file I have modified is _00build.conf


#

persistent configuration options

#

see also DISTRO_SPECS DISTRO_PET_REPOS DISTRO_COMPAT_REPOS-*

#

NOTE: check the original file every once in a while

settings might be added or removed...

#

----------------

support/findpkgs (called by most scripts)

----------------

set to 'no' to speed up process..

CHECK_PKG_DEPENDENCIES=yes

----------

1download

----------

this will check all remote pkg repos and choose the working ones

CHECK_REMOTE_PKG_REPOS=yes

----------

2download

----------

binaries are usually already stripped. set to 'no' to speed up process

STRIP_BINARIES=yes

-------------

3builddistro

-------------

-- Live CD --

The default is to use the traditional Puppy Live CD (isolinux)

However there are 2 other options.

UEFI_ISO overrides GRUB4DOS_ISO if both are set to YES..

UEFI_ISO also supports legacy BIOS booting

On 32 bit systems this will still boot legacy BIOS however it

Will not boot 32 bit UEFI machines. These are rare anyway.

UFEI_ISO=yes G4DOS_ISO=no

UnionFS: aufs or overlay

the kernel must properly support your choice

UNIONFS=aufs

Kernel tarballs repo URL

for choosing/downloading kernel

KERNEL_REPO_URL=http://distro.ibiblio.org/puppylinux/huge_kernels

Kernel tarball URL

avoid being asked questions about downloading/choosing a kernel

KERNEL_TARBALL_URL=http://distro.ibiblio.org/puppylinux/huge_kernels/huge-3.14.55-slacko_noPAE.tar.bz2

an array of generically named programs to send to the ADRIVE, FDRIVE, YDRIVE

ADRV_INC="abiword gnumeric goffice"

ADRV_INC=""

YDRV_INC=""

YDRV_INC=""

FDRV_INC="" #this one is very experimental and it's recommended to be left unset

FDRV_INC=""

Include kernel-kit generated FDRIVE

set to yes or no or leave commented to be asked the question at build time

KFDRIVE=no

build devx? yes/no - any other value = ask

BUILD_DEVX=yes

include devx SFS in ISO?

DEVX_IN_ISO=no

Include the windows puppy installer LICK

by Luke Lorimer aka

LICK_IN_ISO=no

compression method to be used (SFS files)

SFSCOMP='-comp xz -Xbcj x86 -b 512K'

SFSCOMP='-comp xz'

SFSCOMP='-comp gzip'

SFSCOMP='-noI -noD -noF -noX'

if "$WOOF_HOSTARCH" = "$WOOF_TARGETARCH"

Would you like to strip all binary executables and shared library files?

These are usually already stripped, although some packages may have the shared

library files stripped with the '--strip-debug' option only, and extra stripping

should be okay. It won't do any harm answering yes here.

EXTRA_STRIPPING=yes

-- Dependency check --

if $WOOF_HOSTARCH" = "$WOOF_TARGETARCH"

The script can optionally do a thorough dependency check

This may take a long time.

CHECK_BINARY_DEPS=yes

PPM2 or the Classic gui for PPM?

UICHOICE=PPM2

Puppy is normally run as the 'administrator' (root) user, though there is

also 'fido' which is not currently very mature.

The structure of Puppy is such that we consider root to be safe (with a full

disclaimer of any responsibility if anything does go wrong), but there is a

compromise, to run as root but to run Internet apps as user 'spot'.

Note, in a running Puppy 'Menu->System->Login & Security Manager'

can be used to enable or disable running as spot.

RUN_INTERNET_APPS_AS_SPOT=no

Certain Xorg drivers require KMS (Kernel ModeSetting)

A value of '1' means on, '0' means off.

assume not using kms at all when boot from sd card (arm arch).

KMS_i915=1 KMS_radeon=1 KMS_nouveau=0

-- Xorg Auto --

- This overrides DISTRO_XORG_AUTO in DISTRO_SPECS..

- For ARM it's always set 'no' (may be changed)

Do you want Xorg to start automatically at first boot (or at 'pfix=ram'

kernel boot param) or run Xorg Wizard? The latter has been the case for

earlier puppies. Automatic startup of X usually works, though in some

cases may choose the wrong monitor resolution or driver -- which can be"

fixed by running Xorg Wizard afterward. (yes/no)

XORG_AUTO=yes

-- Xorg Text DPI (dots por inch) --

this is overriden by PTHEME - $DEFAULT_THEME_XORG_TEXT_DPI

see 'rootfs-complete/root/.Xresources' for the current value

You can specify a font dpi if you wish

...72 78 84 90 96 102 108 1114 120..

XORG_TEXT_DPI=114

-- pTheme -- applies only if ptheme pkg is being used

woof-code/rootfs-packages/ptheme/usr/share/ptheme/globals

You can choose a ptheme here if you wish

otherwise 3builddistro will ask you to choose one

PTHEME="Dark Touch"

PTHEME="Dark Mouse"

PTHEME="Bright Touch"

PTHEME="Bright Mouse"

-- ROX desktop text - black --

The ROX-Filer desktop text defaults to white with black shadow, but this is

not best for some light backgound images.

ROX_TEXT_BLACK=no

ROX-Filer defaults to 'DejaVu Sans 10' font for the desktop.

If you would prefer bold text 'DejaVu Sans Bold 10',

type in a full font specification (ex: Mono 12)

ROXFILER_FONT=DejaVu Sans 12

-- Xload in JWM --

By default xload is displayed in JWM. You can disable it here...

JWM_XLOAD=yes

-- Custom wallpapers -- if mkwallpaper is in $PATH

Do you want to build some custom wallpapers?

CUSTOM_WALLPAPERS=no

-- Locale --

Puppy is built with a default locale LANG=en_US and keyboard layout KMAP=us,

which may be changed after bootup.

However, if you are building a language-specific Puppy, you may change the

defaults. But, please do make sure that your Puppy has a 'langpack' PET

for your language installed -- if one does not exist, then you will have to

create one -- see MoManager in the Utility menu, also read the Menu -> Help

-> HOWTO Internationalization.

see valid locales in /usr/share/i18n/locales

(the default is en_US.UTF-8)

DEFAULTLANG=

-- Keyboard layout --

Default is english (en, us, "")

Choose another one if you wish..

azerty be-latin1 br-abnt2 br-abnt br-latin1-abnt2 br-latin1-us by cf

croat cz de de-latin1 dk dvorak dvorak-l dvorak-r es et fi fr

gr hu101 hu il it jp106 lt mk nl no pl pt-latin1 ro ru

se sg sk-qwerty sk-qwertz slovene sv-latin1 uk us wangbe

KEYMAP=

-- Default Apps --

Not all are implemented in the puppy scripts,

but you can specify a default app if you wish...

If you specify a value it will override anything that previously

set that value in the corresponding script...

These are the current default*apps (scripts) in /usr/local/bin

DEFAULTAPPS=" defaultarchiver= defaultaudioeditor= defaultaudiomixer= defaultaudioplayer=deadbeef defaultbrowser= defaultcalendar= defaultcdplayer=deadbeef defaultcdrecorder= defaultchat=hexchat defaultchmviewer= defaultconnect= defaultcontact= defaultdraw= defaultemail=claws-mail defaultfilemanager= defaulthandler= defaulthtmleditor= defaulthtmlviewer=defaultbrowser defaultimageeditor= defaultimageviewer= defaultmediaplayer= defaultpaint= defaultpdfviewer= defaultprocessmanager= defaultrun= defaultscreenshot= defaultspreadsheet= defaultterminal=urxvt defaulttexteditor= defaulttextviewer= defaultwordprocessor= "

- extra commands --

Here add custom commands to be executed inside sandbox3/rootfs-complete

EXTRA_COMMANDS="rm usr/share/X11/xorg.conf.d/10-amdgpu.conf sed -i 's/rox/defaultfilemanager/g' root/Choices/ROX-Filer/PuppyPin sed -i 's/Height>22/Height>28/g' root/.jwm/jwmrc-personal sed -i 's/"24"/"MENHEIGHT"/g' etc/xdg/templates/root.jwmrc sed -i 's/"24"/"16"/g' /root/.jwmrc rm -r root/.config/rox.sourceforge.net/MIME-types/application_x-sharedlib rm -r usr/share/themes/Raleigh rm -r usr/share/themes/stark-blueish rm -r usr/share/themes/FlatBlueContrast rm -r usr/bin/xcalc rm -r root/.config/autostart/pmcputemp.desktop rm -r usr/share/applications/Xcalc-scientific-calculator.desktop rm -r usr/share/applications/jcontrol.desktop cp -r root/firstrun/yassm usr/local cp -r root/firstrun/yassm-search.desktop usr/share/applications rm -r root/firstrun/yassm rm -r root/firstrun/yassm-search.desktop cp -r root/firstrun/jwmrc-personal root/.jwm cp -r root/firstrun/.jwmrc-tray root cp -r root/firstrun/globicons root/.config/rox.sourceforge.net/ROX-Filer cp -r root/firstrun/jwmrc-theme root/.jwm rm -r lib64 ln -s lib lib64 "

wdlkmpx commented 6 years ago

Thanks for reporting that bug. I think i've read about it before.. it has a long history. I usually only build and use a pup.. and not very often.. dpup stretch. So that may be the reason it hasn't been fixed.

I know it's outrageous that bugs are not fixed, but here in the git repo where solutions must be applied there's little manpower, almost none, and in fact the upups maintainer is AWOL 99.99% of the time since forever probably.

That's the current state of affairs, and it will get worse, at least according to Murphy's Law. https://en.wikipedia.org/wiki/Murphy%27s_law

What you can do now is try to build a xenialpup64 with a slacko64 and see what happens.

Hmm @peabee might want to fix the 0.3K md5.txt files from: http://distro.ibiblio.org/puppylinux/huge_kernels/ (make them look like the 0.1K files)

And if that fails, you can always resort to a 32bit puppy and do a cross-build. Cross-builds are not that well tested, and i think ptheme is not designed for cross-builds. This is another really bad bug. Anything that doesn't play well with cross-builds should be removed or fixed ASAP.

I have many changes ready to be added, i just need to split them into commits, that includes a few more lines for cross-builds.

peabee commented 6 years ago

Done:

Hmm @peabee might want to fix the 0.3K md5.txt files from: http://distro.ibiblio.org/puppylinux/huge_kernels/ (make them look like the 0.1K files)

woodenshoe-wi commented 6 years ago

@peabee

The checksum for huge-4.9.58-xenialpup64.tar.bz2 doesn't match the download, have downloaded several times.

Is huge-4.9.58-xenialpup64.tar.bz2 corrupted?

woodenshoe-wi commented 6 years ago

Sorry for the late reply, but our Internet connection got accidentally disconnected last Friday. Just got back on today.

The problem with

chroot: can't execute 'echo': No such file or directory
ERROR: could not 'chroot' into sandbox3/rootfs-complete
This means that something is incomplete, perhaps a library
needed by bash. Check it out. Have to exit script now.

is caused by the way the binaries in Xenial are compiled. They are expecting the linker to be /lib64/ld-linux-x86-64.so.2 but there is no /lib64 directory and EXTRA_COMMANDS is not run until after the chroot test.

Going into sandbox3 and running LD_TRACE_LOADED_OBJECTS=1 chroot rootfs-complete/ echo gives

    linux-vdso.so.1 =>  (0x00007ffca08d9000)
    libc.so.6 => /lib/libc.so.6 (0x00007f587e009000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f587e3d3000)

Try going into sandbox3/rootfs-complete and making a link to the lib directory named lib64

woodenshoe-wi commented 6 years ago

On the subject of how to fix this in woof-CE, the Xenial libc6 deb has a lib64 directory with a ld-linux-x86-64.so.2 symlink that points to /lib/x86_64-linux-gnu/ld-2.23.so but this is removed by the glibc template.

One option is to change the glibc template so it will not remove the symlink in the deb.

Another option is to add a lib64 directory and a ld-linux-x86-64.so.2 symlink by adding a rootfs-skeleton directory to woof-distro/x86_64/ubuntu/xenial64/ the same way I did for https://github.com/woodenshoe-wi/xenial64-valgrind

A third option is to add a rootfs-skeleton directory to woof-distro/x86_64/ubuntu/xenial64/ with a lib64 symlink pointing to lib.

peabee commented 6 years ago

The checksum for huge-4.9.58-xenialpup64.tar.bz2 doesn't match the download

I've updated the md5 file

wdlkmpx commented 6 years ago

For slacko64 there is a massive lib -> lib64 rename. Maybe that also makes sense for the 64-bit upups

There is lib64 in the slacko64 glibc pkg template.

There was a massive cleanup in the pkgs templates that removed thousand of files, and added a lot of FIXUPHACKS to remove specific stuff so that iso remains relatively small.

Maybe the same logic must be applied to all the remaning pkg templates where there is a /lib directory. That way there won't be surprises.

The stuff requires another massive cleanup. A neverending story.

woodenshoe-wi commented 6 years ago

Looking in the libc6 deb, the libs are all in lib/x86_64-linux-gnu. 2createpackages moves them back into lib.

At this point there is nothing in lib64 except the ld-linux-x86-64.so.2 symlink. I don't know if they are planning to move the libs into lib64 in the future, but it hasn't happened yet.

Adding a lib64 directory to the glibc template would also add it to 32bit builds, but would adding a PLUSEXTRADIRS file work?

wdlkmpx commented 6 years ago

There is no support for debian control files, post install stuff, whatever it is called.

So, the pkg templates fill in the gaps in some cases. And some .deb packages may be missing some required post-processing that only control files or whatever they are called can provide. Sigh..

To edit a pkg template, you have to see what it produces for .deb and .txz pkgs, is the result consistent? That's what i did some time ago, and it can be time consuming. And i introduced a few bugs that took months to fix haha.. but the overall result was a much better OS

wdlkmpx commented 6 years ago

The massive rename happens in merge2out, and only for slacko64. That includes all 'lib' dirs and the 'lib' string in the FIXUPHACKS and files in the pkg templates.

I used a 64 bit puppy only to compile static stuff for the initrd. Slacko64.

2createpackages certainly moves stuff to lib but creates a circurlar x86_64-linux-gnu symlink that points to the same dir, so in a complete system there should be no issuess.. in theory. It does that same for the 32bit .deb builds, the multi arch stuff.

But this whole stuff requires attention and experimentation, and it's probably woodenshoe-wi the chosen one..

I'll perform some quick tests to see if i can fix it quickly, otherwise someone else must do it.

woodenshoe-wi commented 6 years ago

Although I do agree that the template system is very useful for adding / modifying files in compat packages that otherwise we would have no control over, the problem of making them work consistently with the various compat distros and versions that can be used to build a Puppy make me uncomfortable modifying them except in woof-distro/.../packages-templates.

If I am supposed to fix this, to avoid unintended consequences I would choose either option two,

or option three

wdlkmpx commented 6 years ago

I fixed it locally, it's been simplified.. exported a new variable in 2createpackages and add some more lines to the FIXUPHACK.

Now i'll see what happens in tahrpup64

wdlkmpx commented 6 years ago

Ok this should fix the issue: https://github.com/puppylinux-woof-CE/woof-CE/commit/ab035dfa9afaf4424ed159ba7e18f702bfd5e08f

but someone else must build a xenialpup64 iso and test it..

woodenshoe-wi commented 6 years ago

I think that fixed it 😃

./3builddistro-Z got as far as making the main sfs before I stopped it. (It is after midnight here)

wdlkmpx commented 6 years ago

Hmm ok i think the issue is fixed