Prev: freenas-like solution for aoe?
Next: Small snort/oinkmaster problem
From: brandlk on 23 Mar 2010 05:20
>> I really wonder in which context this example (and also the other one
>> given
>> in the manpage) could work? Have you sucessfully tried it on your
>> system?
>
> No, I've never had occasion to.
> But where exactly is the failure occuring?
> Does the mount command fail?
> Does the pivot_root command fail? Does exec chroot fail?

The umount command fails with "device is busy". privot root and chroot
work fine.

> Kill should be able to kill any process *except* init itself.
> And "telinit -u" should be able to refresh init.

I did a telinit u after the chroot and killed the remaining processes.
After that lsof doesn't show any open files under old-root but umount
still fails with "device is busy".

> Something like this occurs during boot with the transition from the
> initial
> RAM filesystem to the permanent root filesystem. Perhaps you should
> study the scripts in /etc/rcS.d to find how the root file system is
> changed there. Maybe that will give you some clues.

No, the transition from ramfs to the root filesystem isn't done by the
init scripts but by init itself. I issues a switch-root, that means all
contents from the ramfs is deleted and the root is mounted over with the
new root filesystem. I can't do that because the old rootfs is a normal
partition on a hard drive and the contents can't be simply deleted. So I
need to do some kind of pivot-root. Perhaps there is an alternative? The
problem atm is that it's not possible to unmount to old root fs.

K. Haselhorst


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/54563.137.248.74.196.1269335883.squirrel(a)www.mathematik.uni-marburg.de
From: Stephen Powell on 23 Mar 2010 11:40
On Tue, 23 Mar 2010 05:18:03 -0400 (EDT), K. Haselhorst wrote:
> Stephen Powell wrote:
>> But where exactly is the failure occuring?
>> Does the mount command fail?
>> Does the pivot_root command fail? Does exec chroot fail?
>
> The umount command fails with "device is busy". privot root and chroot
> work fine.

So everything works except the umount. Interesting. From the example
in the man page they obviously expect it to be possible to umount the
old root file system.

>> Kill should be able to kill any process *except* init itself.
>> And "telinit -u" should be able to refresh init.
>
> I did a telinit u after the chroot and killed the remaining processes.
> After that lsof doesn't show any open files under old-root but umount
> still fails with "device is busy".

Maybe lsof doesn't necessarily list everything. What does "fuser -m /old_root"
show? What about doing "fuser -k -m /old_root"?

--
.''`. Stephen Powell <zlinuxman(a)wowway.com>
: :' :
`. `'`
`-


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/814445304.21091291269358324667.JavaMail.root(a)md01.wow.synacor.com
From: brandlk on 24 Mar 2010 04:20
>> The umount command fails with "device is busy". privot root and chroot
>> work fine.
>
> So everything works except the umount. Interesting. From the example
> in the man page they obviously expect it to be possible to umount the
> old root file system.
>
>>> Kill should be able to kill any process *except* init itself.
>>> And "telinit -u" should be able to refresh init.
>>
>> I did a telinit u after the chroot and killed the remaining processes.
>> After that lsof doesn't show any open files under old-root but umount
>> still fails with "device is busy".
>
> Maybe lsof doesn't necessarily list everything. What does "fuser -m
> /old_root"
> show? What about doing "fuser -k -m /old_root"?

Ok, I finally got the old root unmounted. There were some tmpfs mounted
unter old-root/dev/shm and old-root/lib/init/... - after unmounting these
I could also unmount the old-root. It's strange that neither lsof nor
fuser did show any open files for these mountpoints... I really wonder how
the pivot_root guys expect their examples to work ;)

What I still need to figure out is how I can replace init with a custom
process... but I think for that I will have to patch init itself.


K. Haselhorst


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/35890.137.248.74.37.1269418580.squirrel(a)www.mathematik.uni-marburg.de
From: Stephen Powell on 24 Mar 2010 09:50
On Wed, 24 Mar 2010 04:16:20 -0400 (EDT), K. Haselhorst wrote:
> Stephen Powell wrote:
>>
>> Maybe lsof doesn't necessarily list everything. What does "fuser -m
>> /old_root"
>> show? What about doing "fuser -k -m /old_root"?
>
> Ok, I finally got the old root unmounted. There were some tmpfs mounted
> unter old-root/dev/shm and old-root/lib/init/... - after unmounting these
> I could also unmount the old-root. It's strange that neither lsof nor
> fuser did show any open files for these mountpoints... I really wonder how
> the pivot_root guys expect their examples to work ;)

Of course! Why didn't I think of that! There is nothing keeping the file
system structure from from being umounted, which is what "fuser -m" was
designed to show. But it still has to be umounted "from the bottom up."
I guess I just assumed that the shutdown scripts would umount that stuff,
but I guess since it's not a permanent file system they don't bother.
If you're shutting down or rebooting, you don't need to do that. They
remount the permanent root file system read-only, which causes the write
cache to be flushed to disk, but that's as far as they go. If you
want to do a pivot_root and umount the old root, you do actually have to
umount that stuff. I'm sorry I didn't think of it. Nice sleuthing!

>
> What I still need to figure out is how I can replace init with a custom
> process... but I think for that I will have to patch init itself.

Why do you need to patch init?

--
.''`. Stephen Powell <zlinuxman(a)wowway.com>
: :' :
`. `'`
`-


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/1814062284.21318171269438010030.JavaMail.root(a)md01.wow.synacor.com
From: Katharina Haselhorst on 26 Mar 2010 04:00
>> What I still need to figure out is how I can replace init with a custom
>> process... but I think for that I will have to patch init itself.
>
> Why do you need to patch init?

I'm not sure if I really have to but I don't want to run all init
scripts of the new system right away but do some other stuff. Would be
nice to put the whole system back into the state of the early initramfs
phase. But perhaps some workaround with init is sufficient. I'll do some
research on that topic.
Thx, for your help with the pivot_root issue!

K. Haselhorst


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4BAC7564.90402(a)mathematik.uni-marburg.de
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: freenas-like solution for aoe?
Next: Small snort/oinkmaster problem