Ubuntu
ifupdown package

ifupdown-clean script fails

Bug #28559 reported by hunger
18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ifupdown (Ubuntu)
Fix Released
Medium
Scott James Remnant (Canonical)

Bug Description

The ifupdown-clean init script fails to remove the ifstate file since at the time it is run in dapper (before checkrootfs.sh!) that filesystem is still mounted ro by most users.

This problem results in the lo interface not coming up (as ifstate is still there, claiming lo to be up) once the ifupdown init script is run.

Please move ifupdown-clean to after checkrootfs.sh and document this behaviour by adding the init-script info comment block into the script.

Thanks!

Regards,
Tobias

Revision history for this message
Martin Pitt (pitti) wrote :

To make bootlog work as well, checkrootfs should be moved back to priority 10, as it was in Breezy.

Changed in ifupdown:
assignee: nobody → pitti
status: Unconfirmed → Confirmed
Revision history for this message
Martin Pitt (pitti) wrote :

Scott, would moving checkroot.sh back to 10 interfere with your boot modifications?

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

Yes, because then it would happen before udev starts, which would mean it'd be checking a device that probably doesn't exist yet!

The ifupdown-clean script is going, I just need to upload the new version. Please don't revert this, as I'd just have to put it back again.

Revision history for this message
Martin Pitt (pitti) wrote : Re: [Bug 28559] ifupdown-clean script fails

Hi Scott!

Scott James Remnant [2006-01-17 13:01 -0000]:
> Comment:
> Yes, because then it would happen before udev starts, which would mean
> it'd be checking a device that probably doesn't exist yet!
>
> The ifupdown-clean script is going, I just need to upload the new
> version. Please don't revert this, as I'd just have to put it back
> again.

Alright. What do we do with S18bootlogd then? It also needs an r/w
root partition (well, actually /var, but the common case will be that
/var is on /).

Thanks,

Martin

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

I was thinking we'd make that use /var/run now -- just as ifupdown is being modified to use /var/run for its state file.

Anything that needs a writable partition throughout the boot process can use that, without any worries about race conditions.

Anything that needs one from initramfs on (bootchart, usplash, etc.) can use /dev/.*

Changed in ifupdown:
assignee: pitti → keybuk
Revision history for this message
Martin Pitt (pitti) wrote :

Hi Scott!

Scott James Remnant [2006-01-17 14:12 -0000]:
> Comment:
> I was thinking we'd make that use /var/run now -- just as ifupdown is
> being modified to use /var/run for its state file.
>
> Anything that needs a writable partition throughout the boot process can
> use that, without any worries about race conditions.

Hmm, I'm not sure whether storing log files on a tmpfs makes much
sense. It might be nice to keep /var/log/boot (and older copies)
around after a reboot, or after shutdown and mounting the drive from
another OS (for failure analysis, etc.).

Martin

--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

Revision history for this message
hunger (hunger) wrote :

The script is no longer installed on dapper, so I consider this bug to be fixed.

Changed in ifupdown:
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.