DebianDog64 - 64 bit DebianDog-Jessie

[rufwoof]

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)

[fredx181]

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?

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

[fredx181]

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.

Yes, probably I didn't apply the NTFS fix on DD64, can't remember (I'm getting old )

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

Please explain, what does that mean exactly what you did? (.bin file (lockout) )
You couldn't extract the initrd.img (in /boot)?

Fred

[rufwoof]

Please explain, what does that mean exactly what you did? (.bin file (lockout) )
You couldn't extract the initrd.img (in /boot)?

I could cpio -id extract the content ... but not the usual stuff in there ... a binary of some kind instead.

[fredx181]

I haven't tried Xenialdog yet. Is this fixed there or same problem with NTFS as in DD?

Just tested on XenialDog with savefile "casper-rw" located on a NTFS partition and it works fine.

Fred

[rufwoof]

Just noticed my NTFS partition has errors that are suggested best fixed using Windows ... except Windows isn't installed anymore. Message flashes by at 100 mph looking something like mounting read only due to such errors.

[rufwoof]

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

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

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

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

Boots and saves fine.

[jd7654]

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

Thanks. Yeah, moved DD back to NTFS drive and that worked with Porteus style changes.dat persistence.

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.

[rufwoof]

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

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 the

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

in root folder (blank line after the / union line) [it was already there in my case due to having copied it across from my sd1 ext HDD partition].

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.

[trister]

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

If I understand correctly porteus boot (with changes.dat) method will be the only solution suitable for windows based PCs.

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.

DD-Jessie 64 works on my NTFS as well when Porteus style booted (boot-1)
...

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

Boots and saves fine.

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..
In 3 minutes I can "install" frugally install DD to a PC without doing ANY damage at all.

[rufwoof]

If I understand correctly porteus boot (with changes.dat) method will be the only solution suitable for windows based PCs

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).

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>

[trister]

Thanks .
I will try this when I have time.

Also, thanks for tip of the .module file. It is very useful

As a file manager I mostly use DoubleCommander with bookmarked paths.If you're used to NortonCommander/MidnightCommander you'll find it very useful in conjuction with PcFileMan

[fredx181]

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:

Code: Select all

video=SVIDEO-1:d

Fred

[dancytron]

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:

Code: Select all

video=SVIDEO-1:d

Fred

Did a manual frugal install. All seems to work, even with my somewhat problematic Intel G30 graphics.

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.

[rufwoof]

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

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.

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
}

to that, then started pulse audio daemon
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.

[dancytron]

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

[fredx181]

Thanks Dan & rufwoof,

But kodi still doesn't want to play.

I had the same problem but installing the "libgl1-mesa-dri" package made it work for me (after restart X).
In fact a bit strange that it isn't a real dependency. (same goes for some 3D games)

Fred

[rufwoof]

But kodi still doesn't want to play.

I had the same problem but installing the "libgl1-mesa-dri" package made it work for me (after restart X).

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.

[dancytron]

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.

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

If I go manually to /mnt/sda2, then it is correct.

[fredx181]

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.

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.
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