DebianDog64 - 64 bit DebianDog-Jessie
Thanks Fred. Quick response, perfect answer. Thanks again.
Just tried using rw-basemount kernel boot parameter (using one of DD's initrd.img (DD64)) ... and it didn't work, NTFS partition still mounted ro. Looks like the same for jd7654.
That initrd.img change was described as being 'experimental' so perhaps not that unsurprising. I did try editing initrd.img for myself, but extraction of the current Debian systemD version results in a .bin file (lockout)
Just tried using rw-basemount kernel boot parameter (using one of DD's initrd.img (DD64)) ... and it didn't work, NTFS partition still mounted ro. Looks like the same for jd7654.
That initrd.img change was described as being 'experimental' so perhaps not that unsurprising. I did try editing initrd.img for myself, but extraction of the current Debian systemD version results in a .bin file (lockout)
If you'd use "porteus-boot" style (savefile e.g. named changes.dat) persistence on NTFS should work on DD and also on XenialDog.jd7654 wrote:Just recently tried DD, and was wondering why persistence didn't work until I moved persistence file from NTFS to Ext4 partition.
I haven't tried Xenialdog yet. Is this fixed there or same problem with NTFS as in DD?
See here: https://github.com/DebianDog/Jessie/wiki/Porteus-boot
On XenialDog, the default (Ubuntu) save method is called casper-boot (savefile name is casper-rw)
Don't know about Xenialdog if casper-rw savefile works on NTFS
See for Xenialdog boot options here:
https://github.com/DebianDog/xenialdog/wiki
Fred
Yes, probably I didn't apply the NTFS fix on DD64, can't remember (I'm getting old )rufwoof wrote:Just tried using rw-basemount kernel boot parameter (using one of DD's initrd.img (DD64)) ... and it didn't work, NTFS partition still mounted ro. Looks like the same for jd7654.
Please explain, what does that mean exactly what you did? (.bin file (lockout) )That initrd.img change was described as being 'experimental' so perhaps not that unsurprising. I did try editing initrd.img for myself, but extraction of the current Debian systemD version results in a .bin file (lockout) Sad
You couldn't extract the initrd.img (in /boot)?
Fred
DD-Jessie 64 works on my NTFS as well when Porteus style booted (boot-1)
I created a changes.dat file (3GB) and formatted that as ext
dd if=/dev/zero of=changes.dat bs=1M count=3000
mkfs.ext3 -F changes.dat
As a test for someone who didn't want to install a bootloader onto their HDD i.e. a pure NTFS (Windows) user, I created a small bootable (grub4dos) USB with a menu.lst entry of
i.e. my NTFS is sda3 (hd0,2) and that menu.lst chains to the menu.lst in the NTFS partition i.e. the NTFS /DD-3/live folder contains
Where that menu.lst has a content of
Boots and saves fine.
I created a changes.dat file (3GB) and formatted that as ext
dd if=/dev/zero of=changes.dat bs=1M count=3000
mkfs.ext3 -F changes.dat
As a test for someone who didn't want to install a bootloader onto their HDD i.e. a pure NTFS (Windows) user, I created a small bootable (grub4dos) USB with a menu.lst entry of
Code: Select all
# menu.lst
color white/blue black/cyan white/black cyan/black
timeout 2
default 0
title DD-Jessie64 chain to NTFS boot on sda3 (hd0,2)
# root (hd0,2)
find --set-root /DD-3/live/jessie-x86_64.sgn
configfile /DD-3/live/menu.lst
commandline
Where that menu.lst has a content of
Code: Select all
# menu.lst
color white/blue black/cyan white/black cyan/black
timeout 2
default 0
title DDJessie64 (sda3)
# root (hd0,2)
find --set-root /DD-3/live/jessie-x86_64.sgn
kernel /DD-3/live/vmlinuz1 noauto from=/DD-3/ changes=EXIT:/DD-3/live/changes.dat
initrd /DD-3/live/initrd1.xz
Thanks. Yeah, moved DD back to NTFS drive and that worked with Porteus style changes.dat persistence.fredx181 wrote:If you'd use "porteus-boot" style (savefile e.g. named changes.dat) persistence on NTFS should work on DD and also on XenialDog.
See here: https://github.com/DebianDog/Jessie/wiki/Porteus-boot
Funny thing is, I already had Porteus installed on that drive along with Puppy and other stuff. But was trying to use this (more difficult) Debian persistence file, but failing to make it work. Then remembered that had the same problem with SliTaz savefile not working on NTFS. So moved it to ExtFS and it worked. So I guess I'll stick with the easier Porteus style persistence for the NTFS compatibility.
Reflected similar changes as per this link (manually as the files are different now to when that diff file was created) into my current Debian (/boot/initrd.img-3.16.0-4-amd64) file after having extracted it using zcat ../initrd.img | cpio -i -d (that failed last time I tried, must have missed typed something), including thefredx181 wrote:Hi rufwoof,
I'm not sure if it's the same issue as you describe, but long time ago we discussed in one of the DD threads persistence on NTFS, and if I remember well Toni found a fix (probably persistence file is not supported on NTFS by default, but can't remember exactly)
Have a look here: https://github.com/MintPup/DebianDog-Wheezy "Support for persistence file on NTFS partition"
Looks like that you need to replace "9990-misc-helpers.sh" with that patched script inside the initrd to make it work on NTFS.
EDIT: and probably more required, looking here:
https://github.com/MintPup/DebianDog-Wh ... e-ntfs.txt
I don't know enough about NTFS either, so can't help further, I'm afraid.
Fred
cd bin
rm mount umount
ln -sf busybox mount
ln -sf busybox umount
changes, and removing /lib/modules/3.2.0-4-486/kernel/fs/ntfs/ntfs.ko (not sure why the different version numbering there), alongside editing both /bin/boot/9990-misc-helpers.sh and copying that edited file also into /lib/live/boot/9990-misc-helpers.sh
... and it works. I created a large (8GB) persistence file
dd if=/dev/zero of=persistence bs=1M count=8000
mkfs.ext2 -b 4096 -F -L persistence persistence
(that persistence persistence is not a type error, as that also allocates a label of persistence that apparently worked for the Ubuntu/casper-rw mob)
I then copied my current HDD entire partition that also acts as a save partition to that file based filesystem by first creating a sfs of my current setup/save partition (that is a ext3 on sda1)
mksquashfs /mnt/sda1 p.sfs
and then mounted the persistence file filesystem
mkdir p
mount persistence p
and then unsquashed that sfs into that
unsquashfs -f -d p p.sfs
ensuring there was a persistence.conf containing
Code: Select all
/ union
Then unmount p and copied that 8GB "persistence" fs file to my sda3 NTFS partition, removed the persistence.conf from my sda1 and removed its persistence label (so no conflict/duplicate save areas) ... booted and flush2disk (similar to save2flash) worked fine, storing new files being created, existing files deleted ...etc not saving if no save performed, saving when a save was performed (previously saves couldn't be made because the NTFS partition filesystem was being mounted read only and couldn't be remounted rw due to being open (active).
Thanks for highlighting that fix and thanks to Toni (and others) for figuring out the fix.
If I understand correctly porteus boot (with changes.dat) method will be the only solution suitable for windows based PCs.fredx181 wrote:
If you'd use "porteus-boot" style (savefile e.g. named changes.dat) persistence on NTFS should work on DD and also on XenialDog.
See here: https://github.com/DebianDog/Jessie/wiki/Porteus-boot
On XenialDog, the default (Ubuntu) save method is called casper-boot (savefile name is casper-rw)
Don't know about Xenialdog if casper-rw savefile works on NTFS
See for Xenialdog boot options here:
https://github.com/DebianDog/xenialdog/wiki
Fred
Pure NTFS/Fat systems is a must for me since my target group won't have any ext* partitions.
So far I use grub4dos + DD64jessie + porteus boot method and this does almost exactly what I need/want .Also,the option fred gave me in the past with the script that can remote-load a squashfs file makes this system even more adaptable to my future needs.
It would be nice, thought, to know if DebianDog64 jessie could be ported to Debian 9 (for the future) -and keep it's puppy-like behaviour on pure windows systems.
This is exactly the way I boot DD64jessie for the past 6+months. The big advantage is that I just "copy" the dd64 folder in my other PCs and I have an instantly migrated Fully working & configured OS..rufwoof wrote:DD-Jessie 64 works on my NTFS as well when Porteus style booted (boot-1)
...
Boots and saves fine.Code: Select all
# menu.lst title DDJessie64 (sda3) # root (hd0,2) find --set-root /DD-3/live/jessie-x86_64.sgn kernel /DD-3/live/vmlinuz1 noauto from=/DD-3/ changes=EXIT:/DD-3/live/changes.dat initrd /DD-3/live/initrd1.xz
In 3 minutes I can "install" frugally install DD to a PC without doing ANY damage at all.
Boot USB image Download and dd it to a USB and you have a small (around 65MB) grub4dos bootable USB. Or just download and open it to see the menu.lst content to use in your own menu.lst (grub4dos).If I understand correctly porteus boot (with changes.dat) method will be the only solution suitable for windows based PCs
Single file containing a filesystem - well actually a compressed file of a 8GB file system (compressed down to around 1.3GB) ... download it to the root partition of either ext or ntfs and uncompress it ... and the boot usb above will find and load that.
Current system contained in that filesystem is Debian Jessie LXDE (64 bit). Runs as 'user' (password live). Root password is 'me' (use sudo passwd root to change that).
Two boot choices, read only (no changes saved) or read/write (changes saved). Generally you might boot mostly read only as you can still save things outside on other folders/partitions ... whilst keeping the factory fresh boot/core system. But periodically boot the read/write to apply updates before rebooting to read-only again.
To enable ntfs rw the initrd (as on the USB) was modified as per here and here. The core main filesystem was formed by first using Debian standard live (including non-free repositories, command line only debian live cd) as the initial base, on top of which xorg was installed, and then lxde ... etc.
Experimental, so make sure you backup everything first (works for me, your mileage may vary).
You can load additional sfs's at bootup by including them in the /live folder, but on the USB there isn't really enough space to do that. Any files with a .squashfs suffix in the /live folder get loaded in alphanumeric sorted order. If you create a filesystem.modules file in that folder you can specifically name each sfs that gets loaded, in the order of appearance in that file. filesystem.squashfs is the main sfs, but in this case its empty as everything is in effect being stored in the save file (the main/big 1.3GB file above).
When running the bottom (read/write) level is under the /lib/live/mount/persistence/... for instance you might see a sda3 folder in that directory. A handy tip is to select whichever ones you want one by one and bookmark each of those in pcmanfm (filemanager) as a quick means to access read/write layers even if running a read-only session (you'd need to be running a read/write boot for those changes to be preserved across reboots).
Debian is pretty stable and everything in its extensive repositories tends to work well individually and together. For stability the best time to be running a version is when its entering old-stable i.e. there is a new later version that has just been released as the current 'stable' version. Old stable will still receive security updates, and have been through development test, release test ... to 'end of life' when most bugs will have been fixed due to such widespread/extensive testing. By the time for instance Jessie as old-stable is reaching the end of LTS, Stretch will be near entering old stable, replaced by Buster, and most/all of the bugs have been ironed out of Stretch, which if you adopt/'upgrade' to Stretch at that time will see few updates and good stability. The downside is that's more for older hardware (not the most recent new hardware), and by the nature of having been extensively tested tends to be relatively older versions of programs. But if they work with your hardware and meet your needs Combined with frugal booting, where you can boot read-only, try things out and just reboot to undo all of those changes ... a great combination IMO. Some dislike not running as root, but with a 'root terminal' menu item, alongside a right-click file manager (pcManFM) 'open as root' choices, I personally got used to running as user pretty quickly.
EDIT : Print Screen doesn't work in that filesystem as it currently stands, to correct that open ~/.config/openbox/lxde-rc.xml and locate the Launch gnome-screenshot section and edit the command value to be scrot -cd5 ... which takes a snapshot 5 seconds after pressing the PrintScreen key.
<!-- Launch gnome-screenshot when PrintScreen is pressed -->
<keybind key="Print">
<action name="Execute">
<command>scrot -cd5</command>
</action>
</keybind>
- Attachments
-
- DEBIAN LIFE CYCLE.png
- (46.32 KiB) Downloaded 1487 times
Last edited by rufwoof on Tue 04 Apr 2017, 13:02, edited 1 time in total.
Preview of StretchDog64
Hi All,
Preview of StretchDog64 for testing.
Shortly after Debian Stretch will become stable (probably after July) I'll open separate thread for a new Dog64 version based on Stretch (don't know exact name yet).
For now, anyone interested, please test!
The base for this was already made, thanks to rufwoof, he did already dist-upgrade from Jessie to Stretch with working aufs.
http://murga-linux.com/puppy/viewtopic. ... 556#949556
So what I did was making it as small as possible, it's 271MB now, and put together new custom repository here (added e.g. latest Palemoon, which is included in ISO):
https://fredx181.github.io/StretchDog/amd64/Packages/
Download:
https://github.com/fredx181/StretchDog/ ... 4-TEST.iso
https://github.com/fredx181/StretchDog/ ... 4-TEST.md5
EDIT: On some hardware (includes mine) there can be a problem with newer kernels (from 4.8 on), see e.g. here:
https://bbs.archlinux.org/viewtopic.php?id=218581&p=3
Slow boot (specially starting X has 10 sec delay), or sometimes boot to a blank screen.
The workaround that works well for me is to add to the kernel boot line:
Fred
Preview of StretchDog64 for testing.
Shortly after Debian Stretch will become stable (probably after July) I'll open separate thread for a new Dog64 version based on Stretch (don't know exact name yet).
For now, anyone interested, please test!
The base for this was already made, thanks to rufwoof, he did already dist-upgrade from Jessie to Stretch with working aufs.
http://murga-linux.com/puppy/viewtopic. ... 556#949556
So what I did was making it as small as possible, it's 271MB now, and put together new custom repository here (added e.g. latest Palemoon, which is included in ISO):
https://fredx181.github.io/StretchDog/amd64/Packages/
Download:
https://github.com/fredx181/StretchDog/ ... 4-TEST.iso
https://github.com/fredx181/StretchDog/ ... 4-TEST.md5
EDIT: On some hardware (includes mine) there can be a problem with newer kernels (from 4.8 on), see e.g. here:
https://bbs.archlinux.org/viewtopic.php?id=218581&p=3
Slow boot (specially starting X has 10 sec delay), or sometimes boot to a blank screen.
The workaround that works well for me is to add to the kernel boot line:
Code: Select all
video=SVIDEO-1:d
Re: Preview of StretchDog64
Did a manual frugal install. All seems to work, even with my somewhat problematic Intel G30 graphics.fredx181 wrote:Hi All,
Preview of StretchDog64 for testing.
Shortly after Debian Stretch will become stable (probably after July) I'll open separate thread for a new Dog64 version based on Stretch (don't know exact name yet).
For now, anyone interested, please test!
The base for this was already made, thanks to rufwoof, he did already dist-upgrade from Jessie to Stretch with working aufs.
http://murga-linux.com/puppy/viewtopic. ... 556#949556
So what I did was making it as small as possible, it's 271MB now, and put together new custom repository here (added e.g. latest Palemoon, which is included in ISO):
https://fredx181.github.io/StretchDog/amd64/Packages/
Download:
https://github.com/fredx181/StretchDog/ ... 4-TEST.iso
https://github.com/fredx181/StretchDog/ ... 4-TEST.md5
EDIT: On some hardware (includes mine) there can be a problem with newer kernels (from 4.8 on), see e.g. here:
https://bbs.archlinux.org/viewtopic.php?id=218581&p=3
Slow boot (specially starting X has 10 sec delay), or sometimes boot to a blank screen.
The workaround that works well for me is to add to the kernel boot line:FredCode: Select all
video=SVIDEO-1:d
I'll play with it more later.
Great job again.
Dan
edit: strangely uninstalling conkyclock doesn't get rid of the clock, even after reboot.
edit again: Removing from startup folder does.
Re: Preview of StretchDog64
Worked fine for me Fred. Did have to auto-adjust the TV (my monitor) as it loaded off centre, but I've had to do that with Stretch in general so far.fredx181 wrote:EDIT: On some hardware (includes mine) there can be a problem with newer kernels (from 4.8 on), see e.g. here:
https://bbs.archlinux.org/viewtopic.php?id=218581&p=3
Slow boot (specially starting X has 10 sec delay), or sometimes boot to a blank screen.
The workaround that works well for me is to add to the kernel boot line:Code: Select all
video=SVIDEO-1:d
Installed it by extracting to / and .img booted that (boot3). Scanned and noticed that both mplayer and mpv were installed so I apt-get purge mpv which also prompted for autoremove to be run (which I did).
Did some other cleaning (logs ...etc that booting created) and mksquashfs using xz (-Xbj x86 -Xdict-size 100%) and a 240MB sfs (that I called 02-filesystem.squashfs). Booted that Porteus style OK (after removing 01-filesystem.squashfs) and played a movie fine, also loaded up the browser and that played a SneekyLinux youtube video OK.
Not sure but during my cleaning I removed the apt stuff ... maybe I went too far with that and perhaps should have left some ??? (so it knows whats installed ?? (beyond my area of knowledge)). Seems OK. After rebooting Porteus style I added gnome adwaita theme and switched over to that, along with a few other choices of fonts/settings, saved and rebooted and all seems OK
(clickable thumbnail)
EDIT : Tried Apt2SFS for kodi and it produced the kodi.sfs file fine. Dropped that into /live as 05-kodi.sfs and it loaded fine at reboot. But running kodi resulted in segmentation crash. Tried reinstalling xorg nouveau via synaptic .. no difference. Rebooted without the sfs and installed it and still crashed. Tried installing pulse-audio via synaptic, created /etc/asound.conf and added
Code: Select all
pcm.pulse {
type pulse
}
ctl.pulse {
type pulse
}
pcm.!default {
type pulse
}
ctl.!default {
type pulse
}
pulseaudio -D --system
and its running fine (I also apt-get pavucontrol as that's useful to run to adjust pulse). But kodi still doesn't want to play.
Found a link that said it needed libcec so installed libcec4. Still nothing. ... ongoing.
Last edited by rufwoof on Fri 07 Apr 2017, 14:38, edited 2 times in total.
Messed with Stretch64 a little bit more.
Set up mesa, installed Chrome and gksu to run Chrome, added my little wrapper scripts, and did a quick remaster as lz4. Posting from Chrome now. All seems good.
Filesystem01.squashfs is 549 meg, but that is without getting rid of Palemoon and as lz4, so I guess that is to be expected.
Seems good to go.
Dan
Set up mesa, installed Chrome and gksu to run Chrome, added my little wrapper scripts, and did a quick remaster as lz4. Posting from Chrome now. All seems good.
Filesystem01.squashfs is 549 meg, but that is without getting rid of Palemoon and as lz4, so I guess that is to be expected.
Seems good to go.
Dan
Thanks Fred. Installed that, added the 05-kodi.sfs I created earlier to /live, porteus booted and kodi's working fine. Different interface to what I use elsewhere, no longer the back-slash key to window it, now the hash key.fredx181 wrote:I had the same problem but installing the "libgl1-mesa-dri" package made it work for me (after restart X).rufwoof wrote:But kodi still doesn't want to play.
- Attachments
-
- s.jpg
- (60.43 KiB) Downloaded 1045 times
Found something I think.
When I use the copy2ram parameter, instead of mounting sda2 when I click on sda2, it mounts sda2//mnt/live/memory/images/changes-exit. However, it works correctly without the copy2ram parameter.
I remember something vaguely like this from before.
Here are the entries from my menu.1st.
If I go manually to /mnt/sda2, then it is correct.
When I use the copy2ram parameter, instead of mounting sda2 when I click on sda2, it mounts sda2//mnt/live/memory/images/changes-exit. However, it works correctly without the copy2ram parameter.
I remember something vaguely like this from before.
Here are the entries from my menu.1st.
Code: Select all
title stretch64 copy2ram (sda2) noauto from=/stretch64/ changes=EXIT:/stretch64/
root (hd0,1)
kernel (hd0,1)/stretch64/live/vmlinuz1 noauto copy2ram from=/stretch64/ changes=EXIT:/stretch64/
initrd (hd0,1)/stretch64/live/initrd1.xz
title stretch64 (sda2) noauto from=/stretch64/ changes=EXIT:/stretch64/
root (hd0,1)
kernel (hd0,1)/stretch64/live/vmlinuz1 noauto from=/stretch64/ changes=EXIT:/stretch64/
initrd (hd0,1)/stretch64/live/initrd1.xz
Yes, thanks, it's weird because this problem seems to appear only on 64 bit, I mean: on all 32 bit Jessie, Xenial, Stretch versions it's OK, AFAIK.dancytron wrote:When I use the copy2ram parameter, instead of mounting sda2 when I click on sda2, it mounts sda2//mnt/live/memory/images/changes-exit. However, it works correctly without the copy2ram parameter.
I remember something vaguely like this from before.
DD64-jessie and Xenialdog64 have the same problem.
Although I can't figure out why it's only on 64-bit, I've found a fix already (in linuxrc script inside initrd1.xz) but need to test more for possible other side-effects.
Fred