Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy
I cooked up this kernel and modules.squashfs, compiled with clock freq @ 300mhz (options also 250mh and 100mhz available for more stability less responsive performance), no smp and no pae but has 4G highmem (no highmem is also available option good for 1 GB ram) and xz compression (which I think causes the no working init found problem on the initrd you sent).
If you are willing to test on your old hardware, as I don't have any such old hardware, I can further hone my skills to compile kernels for any specification.
https://drive.google.com/file/d/0B4GhZV ... edit?usp=1
If you are willing to test on your old hardware, as I don't have any such old hardware, I can further hone my skills to compile kernels for any specification.
https://drive.google.com/file/d/0B4GhZV ... edit?usp=1
Only if it is important for you, Stemsee, otherwise I'm not interested of testing or use non-debian official kernels for DebianDog. I'm happy with the default 3.2.0.4-486 that works fine on my hardware.stemsee wrote:If you are willing to test on your old hardware, as I don't have any such old hardware, I can further hone my skills to compile kernels for any specification.
Any suggestion how to test your 028-kernel-3.15.2-DebianDog-nopae-nosmp.squashfs without initrd file for it? I thought I can rename it to kernel-modules.sfs and use puppy initrd.gz file but boot freezes in the beginning while uncompressing kernel message appears.
How did you test it?
oh....no just leave it! Not important at all!
I have narrowed down the problem I exerienced with the boot process at least on original woof-ng initrd.gz .... it is the ydrv: system complains of pup_z duplicated. I removed ydrv entry from initrd distro specs leaving only DISTRO_PUPSAVE=debiandogsave.2fs and DISTRO_ZDRVSFS=kernel-modules.sfs and DISTRO_ADRVSFS=06-DEVX-DebDog-2.squashfs and now it is perfect for me! And anyone who doesn't need extra modules, which in any case can be loaded post boot!
If zdrv is specified or not it causes problems for my pc. Maybe I should start a new thread as there is little interest here! If no one objects?
For anyone interested (it does Involve downloading files you may already have, but ensures integrity!)
Here is live.tar.gz with 01-filesystem.squashfs 06-DEVX-DebDog-2.squashfs debiandogsave.2fs (1GB) and vmlinuz (3.15.0 non pae (really)) and woof-ng initrd.gz (no ydrv entry, no save to folder) Running amazingly well! Much faster boot time! Fully functioning save. I didn't try with xfce version yet!
pending approval!
I have narrowed down the problem I exerienced with the boot process at least on original woof-ng initrd.gz .... it is the ydrv: system complains of pup_z duplicated. I removed ydrv entry from initrd distro specs leaving only DISTRO_PUPSAVE=debiandogsave.2fs and DISTRO_ZDRVSFS=kernel-modules.sfs and DISTRO_ADRVSFS=06-DEVX-DebDog-2.squashfs and now it is perfect for me! And anyone who doesn't need extra modules, which in any case can be loaded post boot!
If zdrv is specified or not it causes problems for my pc. Maybe I should start a new thread as there is little interest here! If no one objects?
For anyone interested (it does Involve downloading files you may already have, but ensures integrity!)
Here is live.tar.gz with 01-filesystem.squashfs 06-DEVX-DebDog-2.squashfs debiandogsave.2fs (1GB) and vmlinuz (3.15.0 non pae (really)) and woof-ng initrd.gz (no ydrv entry, no save to folder) Running amazingly well! Much faster boot time! Fully functioning save. I didn't try with xfce version yet!
pending approval!
Last edited by stemsee on Tue 01 Jul 2014, 07:09, edited 3 times in total.
No objections at all, Stemsee. Do it as it works best for you.stemsee wrote:Maybe I should start a new thread as there is little interest here! If no one objects?
If specifying ydrv and adrv files creates problems for some hardware maybe you should point this in woof-ce project. The only way to solve this problem is unpack, edit and repack initrd.gz and this is not new puppy user friendly method.
Hi Toni,
Btw,as I said earlier, if you want to gain some space by removing the old Porteus-Wheezy iso's it's fine by me as they are very outdated.
Using older kernel should be possible for now but not a good idea in the future.
Transmission works ok also on openbox version when linking the libraries you suggested.
Fred
No problem!Unfortunately we have around 150Mb free space for DebianDog files on the site. I can't upload them there.
Btw,as I said earlier, if you want to gain some space by removing the old Porteus-Wheezy iso's it's fine by me as they are very outdated.
Well, if it only goes wrong with distro upgrade it's not a big problem I think.Distro upgrading does many update-menus and something goes wrong for mk-jwm.menu. I think it is because of the way it creates the desktop name and split the content from menu file with several programs to separate desktop files.
That's bad news if this means you (and others with older hardware) will never be able to upgrade to newer Debian version. I really hope this can be solved somehow.Quick test confirms what I expected. I can boot 3.14 kernel only on my laptop. No more old hardware support with kernel above 3.12. Xorg fails on my old machines:
Using older kernel should be possible for now but not a good idea in the future.
Transmission works ok also on openbox version when linking the libraries you suggested.
Fred
Hi, Fred.
BTW I have puppy separate kernel and initrd working fine for DebianDog with new created empty save file (.2fs, .3fs, .4fs) and save folder with option to choose which one to load if more than one present. If I can make saving on CD/DVD work we will have one more boot method as separate puppy kernel module/modules for download.
Toni
There is no need yet. If you prefer to delete them and upload DebianDog-Jessie instead I will do it, but I plan to update only Wheezy iso version till Jessie become stable.fredx181 wrote:... if you want to gain some space by removing the old Porteus-Wheezy iso's it's fine by me as they are very outdated.
At least from my tests mk-jwm.menu works well for installing-uninstalling applications if no distro-upgrade is executed.Well, if it only goes wrong with distro upgrade it's not a big problem I think.
I can boot with separate older kernels uploaded on the site and this option will be available in the future for old hardware. It is also possible to make distro upgrade without upgrading the kernel.Using older kernel should be possible for now but not a good idea in the future.
Great, I will add this to next version changes post.Transmission works ok also on openbox version when linking the libraries you suggested.
BTW I have puppy separate kernel and initrd working fine for DebianDog with new created empty save file (.2fs, .3fs, .4fs) and save folder with option to choose which one to load if more than one present. If I can make saving on CD/DVD work we will have one more boot method as separate puppy kernel module/modules for download.
Toni
You are breaking /var/lib/dpkg/status while using the same debdogsave.2fs save file from your uploaded live.tar.gz, Stemsee. You have inside status for wheeze and it overlays status for jessie.stemsee wrote:Really enjoying and posting from DebianDog Jessie XFCE! on woof-ng kernel of course! Same .2fs savefile = immediate internet!
Also inside the save file you keep all your hardware network settings and audio card settings. Internet works only on your computer whith the settings included in debdogsave.2fs
Ah yes, I should have done a bit more housekeeping before uploading! Just trying to get to he bottom of the issue with the ydrv before making an iso with updated kernel and adjustments! No excuses though!
Tested: mksave-gtkdlg > added debiandogsave.2fs as default ... works fine.
Tested: mksave-gtkdlg > added debiandogsave.2fs as default ... works fine.
Last edited by stemsee on Tue 01 Jul 2014, 08:54, edited 2 times in total.
Hi Toni, Fred and everyone,
I have a crazy idea about remasterdog and need your help in implementing it. Basically, the idea is to run remasterdog either as separate commands, or to re-arrange the commands so, that YAD is excluded from the job. The work directory will be predefined in /tmp, no need to calculate space, remount and such.
Thank you in advance.
I have a crazy idea about remasterdog and need your help in implementing it. Basically, the idea is to run remasterdog either as separate commands, or to re-arrange the commands so, that YAD is excluded from the job. The work directory will be predefined in /tmp, no need to calculate space, remount and such.
Thank you in advance.
Hi, Anikin.
This script does copy the system in working folder, cleaning, creating new 01-filesystem.squashfs, deleting working folder.
No Yad needed, no questions, no choice, no confirmation, no options to clean manually the working folder before creating 01-filesystem.squashfs.
Replace all /live/image with /tmp and it should give you what you need:
Fred, I might ask you later to include /initrd in exclude folders for RemasterDog. This is in case we add Puppy initrd.gz boot option. All drives are mounted inside /initrd for Puppy.
I have positive tests making puppy initrd.gz to create proper links for /live/cow and /live/image on boot without any changes outside initrd.gz.
This script does copy the system in working folder, cleaning, creating new 01-filesystem.squashfs, deleting working folder.
No Yad needed, no questions, no choice, no confirmation, no options to clean manually the working folder before creating 01-filesystem.squashfs.
Replace all /live/image with /tmp and it should give you what you need:
Code: Select all
#!/bin/bash
# Edited for command line only tool from original RemasterDog, remaster script for DebianDog by Fred (fredx181)
[ "`whoami`" != "root" ] && exec gsu ${0}
mkdir /live/image/work-dir
echo "Copying files in /live/image/work-dir... Please, wait..."
rsync -a / /live/image/work-dir/ --exclude=/{dev,live,lib/live/mount,cdrom,mnt,proc,sys,media,run,tmp}
mkdir -p /live/image/work-dir/{dev,live,lib/live/mount,proc,run,mnt,media,sys,tmp}
cp -a /dev/console /live/image/work-dir/dev
chmod a=rwx,o+t /live/image/work-dir/tmp
echo "Cleaning..."
rm -f /live/image/work-dir/var/lib/alsa/asound.state
rm -f /live/image/work-dir/root/.bash_history
rm -f /live/image/work-dir/root/.xsession-errors
rm -rf /live/image/work-dir/root/.cache
rm -rf /live/image/work-dir/root/.thumbnails
rm -f /live/image/work-dir/etc/blkid-cache
rm -f /live/image/work-dir/etc/resolv.conf
rm -rf /live/image/work-dir/etc/udev/rules.d/70-persistent*
rm -f /live/image/work-dir/var/lib/dhcp/dhclient.eth0.leases
rm -f /live/image/work-dir/var/lib/dhcpcd/*.lease
ls /live/image/work-dir/var/lib/apt/lists | grep -v "lock" | grep -v "partial" | xargs -i rm /live/image/work-dir/var/lib/apt/lists/{} ;
ls /live/image/work-dir/var/cache/apt/archives | grep -v "lock" | grep -v "partial" | xargs -i rm /live/image/work-dir/var/cache/apt/archives/{} ;
ls /live/image/work-dir/var/cache/apt | grep -v "archives" | xargs -i rm /live/image/work-dir/var/cache/apt/{} ;
cd /live/image/work-dir
zerosize() {
find $* | while read file; do
echo -n "."
rm -f $file
touch $file
done
}
zerosize usr/share/doc -type f -size +1c
zerosize usr/share/doc -type l
zerosize usr/share/man -type f -size +1c
zerosize usr/share/man -type l
zerosize usr/share/info -type f -size +1c
zerosize usr/share/info -type l
zerosize usr/share/gnome/help -type f -size +1c
zerosize usr/share/gnome/help -type l
zerosize usr/share/gtk-doc -type f -size +1c
zerosize usr/share/gtk-doc -type l
chown -R man:root usr/share/man
cd /live/image
mksquashfs /live/image/work-dir /live/image/01-filesystem.squashfs -comp xz -b 1024k -Xbcj x86
rm -rf /live/image/work-dir
I have positive tests making puppy initrd.gz to create proper links for /live/cow and /live/image on boot without any changes outside initrd.gz.
Thank you, Toni.
I will test it soon. As a matter of fact, I have nothing against remasterdog in its current implementation. It works absolutely fine here. I need this CLI variant for my experimenting. That being said, the original remasterdog has this line near the bottom:
Fred, can you make it to be terminal agnostic, just in case a user will want to have urxvt, or lxterminal instead of xterm in his DD?
I will test it soon. As a matter of fact, I have nothing against remasterdog in its current implementation. It works absolutely fine here. I need this CLI variant for my experimenting. That being said, the original remasterdog has this line near the bottom:
Code: Select all
echo "Creating module..."
xterm -T "RemasterDog" -si -sb -fg white -bg SkyBlue4 -geometry 65x14 -e "mksquashfs "$WORK" "$SQFS" -comp xz -b 512k -Xbcj x86"
Maybe the safe way is to make it just:
Then it will not open separate terminal window and will not depend on xterm.
In Jwm version you can replace xterm in the command line with default_virtual-terminal similar to puppy. I don't see this link in OpenBox /usr/local/bin but you can create it and change the link to lxterm or other terminal.
I think this will give you progress bar instead new xterm window:
Code: Select all
echo "Creating module..."
mksquashfs "$WORK" "$SQFS" -comp xz -b 512k -Xbcj x86
In Jwm version you can replace xterm in the command line with default_virtual-terminal similar to puppy. I don't see this link in OpenBox /usr/local/bin but you can create it and change the link to lxterm or other terminal.
I think this will give you progress bar instead new xterm window:
Code: Select all
echo "Creating module..."
mksquashfs "$WORK" "$SQFS" -comp xz -b 512k -Xbcj x86 | yad --title="RemasterDog" --center --height="100" --width="400" --progress --no-buttons --auto-close --text=" Creating module..."
Anikin, make sure you have enough space in /tmp Check right click properties. I guess it has to be at least 1Gb available. I do not have enough Ram to work in /tmp
Also make sure the last 3 lines in the script are correct. From your picture it stops there just after the cleaning.
Here is the output from Jwm version booted with live-boot-2x (initrd1.img) and /live/image instead /tmp
Just to be sure I did copy/paste from my post in empty remasterdog.sh so there is no error in the posted content:
Also make sure the last 3 lines in the script are correct. From your picture it stops there just after the cleaning.
Here is the output from Jwm version booted with live-boot-2x (initrd1.img) and /live/image instead /tmp
Just to be sure I did copy/paste from my post in empty remasterdog.sh so there is no error in the posted content:
Code: Select all
root@debian:~# remasterdog.sh
Copying files in /live/image/work-dir... Please, wait.
Cleaning...
find: `usr/share/gtk-doc': No such file or directory
find: `usr/share/gtk-doc': No such file or directory
Parallel mksquashfs: Using 1 processor
Creating 4.0 filesystem on /live/image/01-filesystem.squashfs, block size 131072
[=====================================================================|] 19005/19005 100%
Exportable Squashfs 4.0 filesystem, gzip compressed, data block size 131072
compressed data, compressed metadata, compressed fragments, compressed xattrs
duplicates are removed
Filesystem size 124910.82 Kbytes (121.98 Mbytes)
37.77% of uncompressed filesystem size (330737.03 Kbytes)
Inode table size 260561 bytes (254.45 Kbytes)
24.90% of uncompressed inode table size (1046343 bytes)
Directory table size 281893 bytes (275.29 Kbytes)
44.77% of uncompressed directory table size (629648 bytes)
Number of duplicate files found 5712
Number of inodes 30449
Number of files 22289
Number of fragments 1204
Number of symbolic links 5000
Number of device nodes 1
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 3159
Number of ids (unique uids + gids) 16
Number of uids 5
root (0)
puppy (1000)
libuuid (100)
ntp (101)
man (6)
Number of gids 14
root (0)
fuse (111)
shadow (42)
puppy (1000)
tty (5)
mlocate (110)
messagebus (105)
utmp (43)
utempter (103)
staff (50)
libuuid (101)
ntp (112)
adm (4)
mail (8)
root@debian:~#
Plenty of space in /tmp - 1010 M free.
On Tuesdays, I'm a bit more dense than usual. I have commented the last two lines, to have a break to make manual changes and was expecting to see "cd /tmp". It might have cd'ed, most probably. Anyway, I need it to stop at "cd /tmp" and will be using a separate mksquashfs command as the last step. The goal has been achieved as planned, I think.Also make sure the last 3 lines in the script are correct
Code: Select all
zerosize usr/share/gtk-doc -type f -size +1c
zerosize usr/share/gtk-doc -type l
chown -R man:root usr/share/man
cd /tmp
# mksquashfs /tmp/work-dir /tmp/01-filesystem.squashfs -comp xz -b 1024k -Xbcj x86
# rm -rf /tmp/work-dir
Haven't tested this yet but it should give you the options you need:
Replace the end from cd /tmp with this:
Replace the end from cd /tmp with this:
Code: Select all
cd /tmp
echo ###
echo "Now you can clean manually /tmp/work-dir if you like."
echo "After that type 1 and press Enter to continue."
echo ###
echo "1)Type 1 and press Enter to continue."
echo ###
read n
case $n in
1) xterm -e mksquashfs /tmp/work-dir /tmp/01-filesystem.squashfs -comp xz -b 512k -Xbcj x86;;
esac
echo ###
echo "Do you want to delete /tmp/work-dir?"
echo ###
echo "1)Type 1 YES - delete /tmp/work-dir."
echo "2)Type 2 NO and exit."
echo ###
echo "Type the number and press Enter."
echo ###
read n
case $n in
1) rm -rf /tmp/work-dir;;
2) exit;;
esac
Excellent! Many thanks to you, Toni.
In the meantime, I tried this half-assed solution to make sure I'm on the safe side:
got this:
In the meantime, I tried this half-assed solution to make sure I'm on the safe side:
Code: Select all
cd /tmp
ls work-dir
# mksquashfs /tmp/work-dir /tmp/01-filesystem.squashfs -comp xz -b 1024k -Xbcj x86
# rm -rf /tmp/work-dir
got this:
Code: Select all
root@debian:~# remasterdog.sh
Copying files in /tmp/work-dir... Please, wait...
Cleaning...
find: `usr/share/gtk-doc': No such file or directory
find: `usr/share/gtk-doc': No such file or directory
0_ 0_sdc1 boot home live-rw-backing opt run srv usr
0_sda1 0_shm dev lib media proc sbin sys var
0_sdb1 bin etc live mnt root selinux tmp
root@debian:~#
- Attachments
-
- remaster01.jpeg
- (41.74 KiB) Downloaded 332 times
re-mastered using remaster-debiandog on puppy initrd (added initrd to exclude list) added debiandogsave.2fs to create-savefile, removed firmware and modules from 01-filesystem.squashfs and made separate 09-modules-3.2.0-4.squashfs with modules and firmware from original 01-filesystem.squashfs for anyone who needs the 3.2 kernel. I used maximum xz compression throughout.
Uploading new live-pup.tar.gz as I type. Includes remastered 01-filesystem.squashfs, devx and initrd.gz and vmlinuz (uname -a 3.16.0-rc2-EmSee-DebianDog) verbose.
Uploading new live-pup.tar.gz as I type. Includes remastered 01-filesystem.squashfs, devx and initrd.gz and vmlinuz (uname -a 3.16.0-rc2-EmSee-DebianDog) verbose.
Last edited by stemsee on Wed 02 Jul 2014, 06:58, edited 1 time in total.
Stemsee, I hope you also will answer if some problems and questions come up about EmSee-DebianDog versions?
For example Devx will not work proper since linux-headers included inside is for kernel 3.2.0-4-486. Creating new kernel module is involved also with providing proper linux-headers for it. While remastering you have Devx included in 01-filesystem.squashfs Check out /usr/source There is no need to include Devx as separate module then.
What you upload is a system with many lost functions and save file options from DebianDog. Maybe you see this as improvement but I don't.
For example Devx will not work proper since linux-headers included inside is for kernel 3.2.0-4-486. Creating new kernel module is involved also with providing proper linux-headers for it. While remastering you have Devx included in 01-filesystem.squashfs Check out /usr/source There is no need to include Devx as separate module then.
What you upload is a system with many lost functions and save file options from DebianDog. Maybe you see this as improvement but I don't.