slackware 14 is out

Non release banter
markds
Legendary
Legendary
Posts: 43
Joined: 28 Dec 2012, 02:58
Distribution: Slackware
Location: Singapore

Re: slackware 14 is out

Post#16 by markds » 17 Jan 2013, 07:17

I checked out plymouth, nice indeed and doesn't require a kernel patch. The issue for me is with the liveOS specialised initramfs, where to put the calls for plymouth and plymouthd.

For bootsplash itself, placing the "/etc/bootsplash/..." into the initramfs tree and generating a "bootsplash" image file using "splash -s -f ... >> bootsplash" and placing the generate "bootsplash" file into the root of the initramfs tree, is sufficient to get the old bootsplash working. It will only work up to the point the KMS kicks in, after which it gets wiped out, no /proc/splash anymore either. If you put in the kernel parameter "nomodeset", then the old bootsplash behaviour prevails, /proc/splash is created but systems with funny graphics cards drop to vesa mode in X.

So plymouth covers all the boot messages and everything till X kicks in and works with KMS, but can't have a decorative screen for the virtual terminals. Bootsplash works like it is supposed to only until KMS kicks in or if the "nomodeset" kernel parameter is used.

*sigh* I miss the simplicity of the old ways :wall:

markds
Legendary
Legendary
Posts: 43
Joined: 28 Dec 2012, 02:58
Distribution: Slackware
Location: Singapore

Re: slackware 14 is out

Post#17 by markds » 22 Jan 2013, 18:19

@fanthom, just to check, how did you build your initrd.xz? Did you use:

find . -print | cpio -o -H newc 2>/dev/null | xz -f --extreme --check=crc32 > initrd.xz

I've been trying out bootsplash with nomodeset on Porteus (retains old bootsplash functionality) but I had to include the bootsplash into the initrd.xz, but when booting using that initrd, I get the error that it can't find the .sgn file.

I was wondering if I built the thing right (seems to be since I get the error in the first place).

Thanks.

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: slackware 14 is out

Post#18 by brokenman » 22 Jan 2013, 18:59

You can rebuild the initrd with:

Code: Select all

find | cpio -H newc -o | xz --check=crc32 --x86 --lzma2 > ../initrd.xz
How do i become super user?
Wear your underpants on the outside and put on a cape.

markds
Legendary
Legendary
Posts: 43
Joined: 28 Dec 2012, 02:58
Distribution: Slackware
Location: Singapore

Re: slackware 14 is out

Post#19 by markds » 22 Jan 2013, 20:02

Thanks brokenman. The system is definitely reading the initrd.xz I built, but its just not finding the sgn file.

Another thing, if you could let me know - is the kernel patched using the aufs-standalone patches:

aufs3-kbuild.patch
aufs3-base.patch
aufs3-proc_map.patch
aufs3-standalone.patch

Thanks.

beny
Full of knowledge
Full of knowledge
Posts: 2086
Joined: 02 Jan 2011, 11:33
Location: italy

Re: slackware 14 is out

Post#20 by beny » 22 Jan 2013, 20:11

if you check crippled source inside there is a folder with the whole aufs patch.

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: slackware 14 is out

Post#21 by brokenman » 22 Jan 2013, 20:13

Porteus v1.2 kernels were compiled by fanthom so best wait for his reply but i am pretty sure the following are used.

git://aufs.git.sourceforge.net/gitroot/aufs/aufs3-standalone.git

aufs3-standalone.git/aufs3-base.patch
aufs3-standalone.git/aufs3-standalone.patch
aufs3-standalone.git/aufs3-kbuild.patch
aufs3-standalone.git/aufs3-proc_map.patch
aufs3-standalone.git/aufs3-loopback.patch

Code: Select all

#!/bin/sh

dest=/tmp/aufs3-patch.patch
[ ! -d /tmp/wrk ] && mkdir /tmp/wrk

mkdir /tmp/aufs$$
cd /tmp/aufs$$
git clone git://aufs.git.sourceforge.net/gitroot/aufs/aufs3-standalone.git aufs3-standalone.git
cd aufs3-standalone.git
# uncomment line below to get aufs for kernel-3.0
git checkout origin/aufs3.2
# uncomment line below to get aufs for latest -rc kernel
#git checkout origin/aufs3.x-rcN
mkdir ../a ../b
cp -r {Documentation,fs,include} ../b
rm ../b/include/linux/Kbuild
cd ..
diff -rupN a/ b/ > $dest
cat aufs3-standalone.git/aufs3-base.patch >> $dest
cat aufs3-standalone.git/aufs3-standalone.patch >> $dest
cat aufs3-standalone.git/aufs3-kbuild.patch >> $dest
cat aufs3-standalone.git/aufs3-proc_map.patch >> $dest
cat aufs3-standalone.git/aufs3-loopback.patch >> $dest
rm -r /tmp/aufs$$
rm -rf a b

echo && echo "latest patch created as $dest"
How do i become super user?
Wear your underpants on the outside and put on a cape.

markds
Legendary
Legendary
Posts: 43
Joined: 28 Dec 2012, 02:58
Distribution: Slackware
Location: Singapore

Re: slackware 14 is out

Post#22 by markds » 22 Jan 2013, 20:16

Found the problem. The sgn file in the 64 bit is porteus-v2.0-x86_64.sgn, but linuxrc in the initrd.xz is looking for porteus-v2.0-i486.sgn.

markds
Legendary
Legendary
Posts: 43
Joined: 28 Dec 2012, 02:58
Distribution: Slackware
Location: Singapore

Re: slackware 14 is out

Post#23 by markds » 22 Jan 2013, 20:21

Thanks again brokenman. Yes those are the patches I used alright.

I patched and built kernel 3.7.3, I tested it with Slax 7 and it works fine.

I built kernel 3.7.3 for Porteus as well using the same patches, and included the lib/modules/3.7.3 into 000-kernel.xzm, then added a new syslinux menu item to boot my 3.7.3 vmlinuz and I keep getting "Cannot read <module>.xzm - corrupted module?" for all the base modules and all the other modules.

I did note that the lib/modules in the initrd.xz was empty, is this supposed to be right?

Thanks.

markds
Legendary
Legendary
Posts: 43
Joined: 28 Dec 2012, 02:58
Distribution: Slackware
Location: Singapore

Re: slackware 14 is out

Post#24 by markds » 22 Jan 2013, 20:25

One more thing I'd like to find out how you guys fixed.

When I boot up with the USB stick, the system says its reading the porteus data from /mnt/sda1/porteus - so the usb stick is being set as sda

When the system is booted up into porteus, this is no longer the case. The usb stick becomes /dev/sdb and the hard drive of the PC is now sda.

What did you guys do to get it to change from sda to sdb after bootup?

markds
Legendary
Legendary
Posts: 43
Joined: 28 Dec 2012, 02:58
Distribution: Slackware
Location: Singapore

Re: slackware 14 is out

Post#25 by markds » 22 Jan 2013, 21:06

Thanks Beny, I'll look at the crippled sources and see what I can find.

User avatar
brokenman
Site Admin
Site Admin
Posts: 6105
Joined: 27 Dec 2010, 03:50
Distribution: Porteus v4 all desktops
Location: Brazil

Re: slackware 14 is out

Post#26 by brokenman » 23 Jan 2013, 00:37

I did note that the lib/modules in the initrd.xz was empty, is this supposed to be right?
Yes this is right. Crippled kernel sources contains the files.

If this line in linuxrc fails (where x is a path to module) then you will get the message you described:

Code: Select all

NAME=`basename $x`; mkdir /memory/images/$NAME; mount -t squashfs -o loop $x /memory/images/$NAME 2>/dev/null
I imagine you havn't played with ALL the modules so bad modules couldn't account for all of them. That leaves loops and aufs and could be a patch. I'd wait for fanthom to chime in as i havn't delved into linuxrc since the change to initramfs.

Not sure why during boot the device is first detected as sda and then sdb. On my machine the USB stick is picked up as sdb during boot and remains that way. The change i can think of is that pivot_root takes place inside initramfs but i woudn't think this would cause a difference in device order.
How do i become super user?
Wear your underpants on the outside and put on a cape.

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5666
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

Re: slackware 14 is out

Post#27 by fanthom » 23 Jan 2013, 13:03

@markds
I've been trying out bootsplash with nomodeset on Porteus
this is a dead end.
intel, nouveau (and soon radeon) DDX drivers requires kernel modesetting to work in GUI.
i would give up with bootsplash unless your distro is intended to work in text mode only.
The sgn file in the 64 bit is porteus-v2.0-x86_64.sgn, but linuxrc in the initrd.xz is looking for porteus-v2.0-i486.sgn.
our initrd is slightly different between 32/64 bit archs so you can't mix them
I built kernel 3.7.3 for Porteus as well using the same patches, and included the lib/modules/3.7.3 into 000-kernel.xzm, then added a new syslinux menu item to boot my 3.7.3 vmlinuz and I keep getting "Cannot read <module>.xzm - corrupted module?" for all the base modules and all the other modules.
i have just pushed 3.7.4 kernel update and all is fine so my guess is that your kernel was compiled incorrectly.
there was a change in kernel 3.7.x line which introduced 'uapi' directory and probably this is the reason.
here is updated script for getting aufs patch:

Code: Select all

#!/bin/sh

dest=/home/ftp/storage/kernel/aufs3.patch

mkdir /tmp/aufs$$
cd /tmp/aufs$$
git clone git://aufs.git.sourceforge.net/gitroot/aufs/aufs3-standalone.git aufs3-standalone.git
cd aufs3-standalone.git
# uncomment line below to get aufs for stable kernel
git checkout origin/aufs3.7
# uncomment line below to get aufs for latest -rc kernel
#git checkout origin/aufs3.x-rcN
mkdir ../a ../b
cp -r {Documentation,fs,include} ../b
rm ../b/include/uapi/linux/Kbuild 2>/dev/null || rm ../b/include/linux/Kbuild
cd ..
diff -rupN a/ b/ > $dest

# extra patches:
cat aufs3-standalone.git/*.patch >> $dest

# fix broken Kbuild:
cat >> $dest << EOF
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -66,6 +66,7 @@ header-y += atmppp.h
 header-y += atmsap.h
 header-y += atmsvc.h
 header-y += audit.h
+header-y += aufs_type.h
 header-y += auto_fs.h
 header-y += auto_fs4.h
 header-y += auxvec.h
EOF

# cleanup:
rm -r /tmp/aufs$$

echo && echo "latest patch created as $dest"
please tweak 'dest=' variable.
I did note that the lib/modules in the initrd.xz was empty, is this supposed to be right?
yes. everything we need is compiled directly into porteus kernel: aufs, squashfs, fuse, filesystems, usb drivers, etc (i see no point loading them at every boot while i know i will need them)
this dir is filled in with modules only when doing PXE boot as compiling all ethernet drivers into kernel would make it too much bloated.
When I boot up with the USB stick, the system says its reading the porteus data from /mnt/sda1/porteus - so the usb stick is being set as sda
When the system is booted up into porteus, this is no longer the case. The usb stick becomes /dev/sdb and the hard drive of the PC is now sda.
afaik this is not possible as devices never gets renamed no matter what you do.
vmlinuz and initrd could be loaded from usb stick but your system booted from hard drive (first matching *.sgn file is ok for linuxrc)
to confirm please view /var/log/porteus-livedbg and check 'Booting device:'

to make sure you are booting from usb please use 'from=/dev/sdb1' cheatcode.
Please add [Solved] to your thread title if the solution was found.

markds
Legendary
Legendary
Posts: 43
Joined: 28 Dec 2012, 02:58
Distribution: Slackware
Location: Singapore

Re: slackware 14 is out

Post#28 by markds » 23 Jan 2013, 14:15

Hi Fanthom,
fanthom wrote: this is a dead end.
intel, nouveau (and soon radeon) DDX drivers requires kernel modesetting to work in GUI.
i would give up with bootsplash unless your distro is intended to work in text mode only.
Interesting, because all my Intel's (4 notebooks, 1 desktop) and my Radeon (desktop) all work with 'nomodeset' as a kernel boot parameter and they all get the correct max resolutions for the monitor. I've been testing this against a whole load of different machines for over 2 weeks. The only Intel I have a problem with is the GM945. Thats so far the _only_ one that doesn't give me the right resolution for X with 'nomodeset'. Have to use modesetting to get the right resolution for that one.
our initrd is slightly different between 32/64 bit archs so you can't mix them
Yes this was actually my mistake. I had extracted the 32bit initrd.xz from Brokenman's Gnome version and when I started building for the 64bit, I forgot to re-extract from the 64bit version, but used the 32bit version to build.
i have just pushed 3.7.4 kernel update and all is fine so my guess is that your kernel was compiled incorrectly.
there was a change in kernel 3.7.x line which introduced 'uapi' directory and probably this is the reason.
----------------
yes. everything we need is compiled directly into porteus kernel: aufs, squashfs, fuse, filesystems, usb drivers, etc (i see no point loading them at every boot while i know i will need them)
this dir is filled in with modules only when doing PXE boot as compiling all ethernet drivers into kernel would make it too much bloated.
Its not the uapi directory, I noted that when I compiled the 3.7.3. I mentioned I had the 3.7.3 working fine on Slax7.

Anyway your 2nd statement gave me the clue to the issue. For Slax7 the above you mentioned are compiled as modules and loaded into the initramfs, so what I compiled for Slax was fine, but using the same .config wouldn't work for Porteus. I unfortunately used the same .config file for my porteus kernel compilation. The patches I used for aufs3-standalone are the same as porteus, so I gather not having the aufs, squashfs, etc in the kernel itself instead of just modules is the actual problem.

I'll be redoing the kernel (likely 3.7.4) later tonight and will put in the necessary options.
afaik this is not possible as devices never gets renamed no matter what you do.
vmlinuz and initrd could be loaded from usb stick but your system booted from hard drive (first matching *.sgn file is ok for linuxrc)
to confirm please view /var/log/porteus-livedbg and check 'Booting device:'
Ok, will check this. I'll post some pictures later too. Btw, I have to note that this "usb-id-as-sda" only occurs on my Core2 Duo machine. The newer machines (i3,5,7) work the way you'd expect them to, ie: hdd=sda, usb=sdb.
to make sure you are booting from usb please use 'from=/dev/sdb1' cheatcode.
I'll do that to ensure.

Thanks for all the help!

User avatar
fanthom
Moderator Team
Moderator Team
Posts: 5666
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland
Contact:

Re: slackware 14 is out

Post#29 by fanthom » 23 Jan 2013, 15:30

Interesting, because all my Intel's (4 notebooks, 1 desktop) and my Radeon (desktop) all work with 'nomodeset' as a kernel boot parameter and they all get the correct max resolutions for the monitor.
there is a chance that drm kernel module is loaded by Xorg just before start (it was the case for nouveau till 1.04 release which falls back to VESA now) and destroys bootsplash then (no splash on reboot/shutdown), or you are running 'modesetting' driver instead of 'intel'.

anyway - KMS is the future. please read this article for more info (mind references to intel and nouveau):
link
Please add [Solved] to your thread title if the solution was found.

markds
Legendary
Legendary
Posts: 43
Joined: 28 Dec 2012, 02:58
Distribution: Slackware
Location: Singapore

Re: slackware 14 is out

Post#30 by markds » 23 Jan 2013, 15:58

Having the squashfs, fuse, etc as modules was indeed the issue. Instead of recompiling the kernel all over again, I add the modules to the initrd and edited the linuxrc to modprobe the modules before the actual porteus live script started. Added the new initrd.xz to the USB, booted it up and it worked immediately. All modules loaded perfectly and the system came up.

This way I can compile the kernel, create kernel and header packages once (I can just rename sb to xzm or vice versa - they work on either distro) and use it on both Slax and Porteus - a total time saver!
there is a chance that drm kernel module is loaded by Xorg just before start (it was the case for nouveau till 1.04 release which falls back to VESA now) and destroys bootsplash then (no splash on reboot/shutdown), or you are running 'modesetting' driver instead of 'intel'.

anyway - KMS is the future --snip--
I booted with "nomodeset" so likely the nomodesetting driver was running, but the thing is it was running with every machine I booted on with the exception of the GM945. The '"nomodeset" is the only way to prevent the splash getting destroyed. I know KMS is the future, and looking forward I'll probably work on plymouth for the splash portion (important in my case for rebranding), but for now, with this coming release of my distro at least, bootsplash will give me some breathing room to work on other more important features.

Thanks!

Post Reply