[Bug 131976] Re: apparmor doesn't work on stacked file system (livecd) -- DHCP/cups/others fail to start

[Sid MacT]

IF the problem is the stacked file system, then why am I able to, after
booting, do:

sudo /etc/init.d/apparmor  start

on my persistent 9.10 Live CD and have no errors?

Is it possible that this 'bug' with the stacked file system is just a
problem caused by the Ubuntu initrd.lz trying to load apparmor profiles
before the casper script has had a chance to fully create the stacked
file system? (please see prior post #44 that addresses the sequence of
script events during the Live CD boot process) I am just wondering if
the problem is with the Ubuntu customization of the 'init' and 'casper'
scripts within the Ubuntu initrd.lz, and not really an upstream problem
at all.

-- 
apparmor doesn't work on stacked file system (livecd) -- DHCP/cups/others fail 
to start
https://bugs.launchpad.net/bugs/131976
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 131976] Re: apparmor doesn't work on stacked file system (livecd) -- DHCP/cups/others fail to start

[Sid MacT]

Is it possible this problem is caused by a sequencing problem with the
Live CD scripts? I run the Karmic LiveCD in persistent mode on a hard
disk drive. Once I am logged in to Ubuntu, I can run 'sudo
/etc/init.d/apparmor start' and see no errors in the terminal nor the
log files. The kernel log shows all the aparmor profiles are loaded.
Everything works normally.

In looking at the Karmic initrd.lz content, it appears that the '/init'
script calls '/scripts/init-bottom/apparmor', which then tests for the
existence of a file called '/scripts/casper-bottom/42disable-apparmor'.
The latter file will be found when booting with the Live CD software,
and finding that file will cause '/scripts/init-bottom/apparmor' to
early exit instead of loading the apparmor profiles. The apparent reason
for the early exit, in lieu of loading the profiles, is the assumed
failure of apparmor to deal deal with the union file system created by
the live CD software. BUT, when the early exit is taken, the
'/scripts/casper' script that sets up the union files system has NOT YET
RUN, as far as I can see, so of course apparmor would have a problem
finding and loading profiles?

Is it possible that simply changing the apparmor profile load process to
follow the creation of the union file system, would allow apparmor to
execute properly? It seems like an odd coincidence that lots of software
EXCEPT apparmor appears to run flawlessly on the 'stacked' file system,
and that apparmor is happy to load profiles after booting the Live CD?

-- 
apparmor doesn't work on stacked file system (livecd) -- DHCP/cups/others fail 
to start
https://bugs.launchpad.net/bugs/131976
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 268808] [NEW] superblock last write time is in the future

[Sid MacT]

Public bug reported:

When /etc/default/rcS has the line
UTC=no
then when Ubuntu startup runs fsck one receives the message:
'superblock last write time is in the future. FIXED'
googling reveals the problem is the hardware clock is set to local time,
but the Ubuntu shutdown process writes the UTC, i.e., GMT time to the 
superblock.
So on reboot, when the fsck compares the hardware clock to the superblock,
the GMT time in the superblock is 'in the future'.

Note: my time zone is California, so GMT is 7 or 8 hours ahead of my
local time.

All the google links talk about the problem being that the startup process does 
the
superblock compare, via fsck, before the routine runs that resets the system 
time.

My perception is that the real issue is that the shut-down scripts write the 
GMT time to
the superblock instead of the local time.

I know there is the work-around of setting UTC=yes; but this messes up
people the dual-boot(ugh) Windows.

** Affects: ubuntu
 Importance: Undecided
 Status: New


** Tags: fsck superblock utc

** Description changed:

  When /etc/default/rcS has the line
  UTC=no
  then when Ubuntu startup runs fsck one receives the message:
  'superblock last write time is in the future. FIXED'
  googling reveals the problem is the hardware clock is set to local time,
  but the Ubuntu shutdown process writes the UTC, i.e., GMT time to the 
superblock.
  So on reboot, when the fsck compares the hardware clock to the superblock,
  the GMT time in the superblock is 'in the future'.
  
  All the google links talk about the problem being that the startup process 
does the
  superblock compare, via fsck, before the routine runs that resets the system 
time.
  
- My perception is that the real issue is that the shut-down routing writes the 
GMT time to
+ My perception is that the real issue is that the shut-down scripts write the 
GMT time to
  the superblock instead of the local time.
  
  I know there is the work-around of setting UTC=yes; but this messes up
  people the dual-boot(ugh) Windows.

** Tags added: fsck superblock utc

** Description changed:

  When /etc/default/rcS has the line
  UTC=no
  then when Ubuntu startup runs fsck one receives the message:
  'superblock last write time is in the future. FIXED'
  googling reveals the problem is the hardware clock is set to local time,
  but the Ubuntu shutdown process writes the UTC, i.e., GMT time to the 
superblock.
  So on reboot, when the fsck compares the hardware clock to the superblock,
  the GMT time in the superblock is 'in the future'.
  
+ Note: my time zone is California, so GMT is 7 or 8 hours ahead of my
+ local time.
+ 
  All the google links talk about the problem being that the startup process 
does the
  superblock compare, via fsck, before the routine runs that resets the system 
time.
  
  My perception is that the real issue is that the shut-down scripts write the 
GMT time to
  the superblock instead of the local time.
  
  I know there is the work-around of setting UTC=yes; but this messes up
  people the dual-boot(ugh) Windows.

-- 
superblock last write time is in the future
https://bugs.launchpad.net/bugs/268808
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs