Yes that would be the most proper? or logical way
to remaster the initrd.img if that is the one that
set permissions.

Now based on my experiences of Ubuntu. 18 out of 20
tested ubuntu derivatives and the official ubuntu and
LinuxMint 12 too. All these 18 work as the three I
gave example on.

so if one could find out what is different between the debian
and the ubuntu how it set up the permissions.

Maybe it has to do with how they treat sudo so Ubuntu had
to sift out that portion and place it in the .disk files?
or lacking diskfiles it skip the part of initrd that have to do
with setting permission for the live session user?

I have a vague notion or gut feeling that if one boot using
rescue or single on the boot code then maybe one are
allowed to set it up to have the ntfs drive set as read and
write allowed for the live session user too?

But maybe I am wrong but most likely Debian don't want
to share that knowledge or they would have already done
that somewhere?_________________I use Google Search on Puppy Forum
not an ideal solution though

But, if you feel uncomfortable with command Amigo offers, do the following and we will help.
Open a Terminal
type "fdisk -l"
post it back here.

We will tailor your mount command for you by changing the "name of partition" to match your configuration so that you can see whether you can mount your NTFS r/w. His command may work in your case. (In fact, we will provide you with 3 mount commands for each of your partitions so that you can see which work and if there's a problem with ANY of your partitions.

Hope this helps_________________Get ACTIVE Create Circles; Do those good things which benefit people's needs!
We are all related ... Its time to show that we know this!
3 Different Puppy Search Engineor use DogPile

This doesn't work. There are several Squash files and probably an ext2/ext3 savefile mounted on the ntfs partition to form the overlayed filesystem of debian live. If you try to remount then there is the "drive busy" error nooby mentions.

One thing I noticed was that in my case there was a message about "dirty NTFS" filesystem, so it couldn't get rw mounted. I tried to fix this from inside linux, but "ntsfix /dev/sda1" didn't help and I have no windows any more for a proper "chkdsk". But since nooby also has this problem I guess it is mounted ro in every case.

but was not man enough to find the mount command for the "root" partition (is is already mounted by the kernel?) - I think the mounting of the squashfs and the overlay happens in the "live" script inside initrd.img.
Maybe someone with more clue about the linux boot process can give a hint how and where in the this process a forced remount of the ntfs partition would be possible.

It supports my take on it that the Debian Developers are
true to Unix policy of not allowing "Live Session User" to
have the permissions of writing to that drive it boots from.

They would answer something like. "There is no need for
writing to that drive so do a proper install instead!"

But I can be wrong.

Now. Why do I talk about Ubuntu when the topic is Debian?

These two are close enough and have same policy of not
allowing the "Live Session User" what a full install allow.

But they have set it up differently. Ubuntu use casper dir
and Debian use live dir. Ubuntu also have a .disk dir with
three files in it?????? I don't remember exactly but ...

If one exclude that .disk and use my simplified boot
for grub4dos which I gave three examples on then
the script fails to set the permissions so the ntfs drive
one boot from frugally do allow read and write permission.

Which is surprising. The proper thing would be they
stalled the boot giving an error saying that due to
error we will not allow you to use the computer

But if one can mimic that failure or error then one
get insight in how they set the drive to be read only!_________________I use Google Search on Puppy Forum
not an ideal solution though

I think you are going to be out of luck. The switches you are using in Grub or whatever are not the magic key in Ubuntu or whatever. The magic key is actually in their equivalent to initrd.img and their vmlinuz

Without getting to high-tech, lost in detail or being 100% dead accurate, what happens at startup is that vmlinuz is loaded. This is a micro-kernel. It's sole job is to load and run initrd.img which in turn creates the initial filesystems in ram and all the "hidden" startup scripts. These scripts then create the real filesystems, load the real files (in our case .squashfs files) and then flip the whole lot over while running in the vmlinuz kernel so that the stuff you loaded then becomes the real kernel and filesystem.

It is sorta like starting a car drag-race in an old Volkswagen and while you're racing down the drag-strip you are also rebuilding the entire car so that when you get to the other end of the 1/4 mile (in under 10 seconds) you're driving a Brabus Mercedes 800E and you didn't notice the transformation.

Pussy is 100% debian-live which you know uses copy-on-write to track changes. Now while you can have caper-directories or special r/w partitions these still aren't really writing back to the boot volume (disk). They are using tricks to fool you into thinking they are writing back to the boot volume. There is a subtle yet very important distinction you need to take a moment to think about and hopefully you will understand. In all instances the operating system itself is actually in RAM and not on the disc (volume). Sure, your casper or whatever partition may be on the same physical drive, but not from the viewpoint of the operating system (and it's core file-system) which is still 100% in ram.

Now, Ubuntu may have weaved some magic such that the physical files are in an uncompressed format and can be seen from WinXP as normal files, although I could _almost_ assure you that when debian or Ubunto see them, they think they are in ram and they probably are. Doing anything otherwise would break the entire copy-on-write mechanism.

Now, I think I've got an idea that may work, that may simulate what Ubuntu do, but it may require you to make some changes. To start with, I would need the output of an "fdisk -l" and then you may need to do some thinking.

If I have got some of the exact details above it is because I am trying to help you understand the debian-live concept, rather than get bogged down in specific detail. If you already understand this fully, then I'm sorry if this comes across as condescending.

PS. with work commitments and my desire to sort some of my own issues at the moment, please do not think I'm ignoring you if I don't reply the same or next day.

Oh ... gcmartin - I don't think that sickgut would mind me saying that there are a lot of other people playing with pussy that know more about linux and debian-live than he does. For the record, I am NOT one of them, but I don't think sickgut would consider himself to be the supreme holder of all knowledge on pussy (which is really just debian-live) with some stuff chucked on top.

Sickgut should answer himself but that is how I remember
is his view of himself too. That he learn from the feedback
and test out things so I trust this is true.

Quote:

I don't think that sickgut would mind me saying
that there are a lot of other people playing with pussy
that know more about linux and debian-live than he does.

Nothing wrong with that at all. Developers should learn from
each other so just go for it.

Thanks jbv, let it take the time you need and like Barry
say on his blog. He is in it for the fun of testing out things
and to solve coding problems because one learn and that
can be very fun doing.

Even I who almost never learn or remember what I learn
find it very fun when I manage to boot something and
use google and find I am among the few that could do it.

Just kidding

copy-on-write Ooops new term to me.

To be fair I should read up on it but my experience is
that I almost never get what such texts say. But sure
I can give it a try.

My extreme wild guess is that Ubuntu has placed part
of the scripts in the .disk hidden directory.

I trust that Debian have all their scripts in the proper place.

So when I "cheat" boot ubuntu in iso frugal style and
make .disk unavailable them I find a loop hole to the
protection that Ubuntu want to set up.

Most likely part of that protection is placed in the files
in the .disk directory so when these are not there physically then the script is set up to give priority
to let the human at least have a booted system.

The Dev was not aware of that that allowed us noobs
to boot using grub4dos and using the iso and that way
get permissions to write to the ntfs we boot from

something they most likely try to protect to not be
possible using these hidden files in the .disk directory.

Why else make them hidden? I try to list them.
I use the LinuxMint 12 as example files are:
base_installable
casper-uuid-generic
cd_type
info
release_notes_url

None of these names gives me any clue that they
would include codes that perform some "Live Session User" setting permissions for the ntfs drive to be "busy"
by the boot process and impossible to change from
within the system.

So I may be totally wrong about these scripts.
Someone savvy would need to go through exactly what
the lack of these files trigger the scripts to not care about
setting the ntfs drive to be forever busy and not giving
permission to unmount it and then remount it.

I just know that if one include the directory then
the boot fails.

I could rename all of them and then change the names
back one at a step to test exactly where the code is.
Maybe even test to have the dir there renamed and see
if the script find the right file inside despite having wrong
name I am too lazy to open the files and read them
in case they have many many lines of code.

Sometimes I wonder if the .disk is so magic that it can
even be empty and that would allow the script to set
the ntfs as read only. One never know.

The cool or scary thing is that I have written about this
on Ubuntu and Linux Mint forum and on LinuxQuestion
and none of the Devs or anybody else care about it.

These people are extremely at it to protect the newbie
from being able to write to teh ntfs hd so their total
silence must indicate they are working 24/7 behind
the scenes to rebuild the loop hole and do a upgrade
that force the hd to be only read and not write and read.

That it takes this long time could indicate I 've found
something they never anticipated or it just means they
hate to give a total noob any response so they rather
ignore that I found this breach of security.

The good thing about it is that it points out that
Debian should be able to easily change to being able
to do easy "cheat" iso booting too if one know how
to patch that script._________________I use Google Search on Puppy Forum
not an ideal solution though

You cannot just copy a directory or files from Ubuntu into Debian and expect them to work. Ubuntu may be based on Debian, but it is so different that it is not the same.

I don't know what is in the .disc directory although that won't make any difference. Whatever is there will not do anything in Debian, although most importantly whatever Ubuntu are doing happens while the kernel is loading.

This means there will not be anywhere that you can just replace a file or whatever. This is what I was trying to explain above. Obviously not well enough though.

Puppy tells me that /dev/sda1 1 1567 12586896 27 Unknown is not unknown but ntfs too.
It is the Acer OEM where they have registration of
the Acer computer at their site and most likely script
for doing back up copies to an external CD or something

Sda2 is the recovery partition. and sda3 is the one
used for both Ms Win 7 and puppy etc._________________I use Google Search on Puppy Forum
not an ideal solution though