[Bug 239419] Re: pm-utils has laptop-tools script which conflicts with laptop-mode-tools
Disk-idleing (aka "laptop-mode") and power states are quite separate things. https://wiki.ubuntu.com/PowerManagement Since ubuntu by default ships with laptop-mode-tools (thus disabled) which handles all the things associated with disk-idleing, (like mount options, hdparm options, low battery exceptions, disk- idleing on AC when on the road, etc.) just remove the "laptop-tools" script from pm-tools. Package laptop-mode-tools needs to put scripts in that place if pm-tools are chosen to handle power states. #244844 -- pm-utils has laptop-tools script which conflicts with laptop-mode-tools https://bugs.launchpad.net/bugs/239419 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 42052] Re: Screen not locked on resume from hibernate/suspend
Same in hardy maybe putting a script in a pm-tools directory to lock the screens (and open consoles Alt-Ctrl-F1, ...) -- Screen not locked on resume from hibernate/suspend https://bugs.launchpad.net/bugs/42052 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 238555] Re: pm-utils doesn't reload hdparm.conf after a suspend
Disk-idleing (aka "laptop-mode") and power states are quite separate things. https://wiki.ubuntu.com/PowerManagement Since ubuntu by default ships with laptop-mode-tools (thus disabled) which handles all the things associated with disk-idleing, (like mount options, hdparm options, low battery exceptions, disk- idleing on AC when on the road, etc.) laptop-mode-tools will handle it. The ubuntu package does not work yet as well as the debian package, though. Package laptop-mode-tools needs to put scripts into pm-tools directories. #244844 (The current laptop-mode disk-idleing approach seems to be a left-over from before the ubuntu-laptop-mode package was droped for laptop-mode- tools.) Also package acpi-support is still preveting much of laptop-mode-tools working. #244833 #244831 #244832 #244839 #244836 #244838 -- pm-utils doesn't reload hdparm.conf after a suspend https://bugs.launchpad.net/bugs/238555 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 241590] Re: dirty writeback set longer when on ac than battery
Disk-idleing (aka "laptop-mode") and power states are quite separate things. https://wiki.ubuntu.com/PowerManagement Since ubuntu by default ships with laptop-mode-tools (thus disabled) which handles all the things associated with disk-idleing, (like mount options, hdparm options, low battery exceptions, disk- idleing on AC when on the road, etc.) let laptop-mode-tools handle disk-idleing. (#239419 remove the "laptop-tools" script from pm-tools.) Package laptop-mode-tools lets you configure your settings. -- dirty writeback set longer when on ac than battery https://bugs.launchpad.net/bugs/241590 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 244859] [NEW] lm-profiler: monitoring read access
Public bug reported: Binary package hint: laptop-mode-tools The lm-profiler is very helpful to identfy processes that write to the disk periodically. Since there are still disk spinn-up events without any write access reported and no user activity going on, it would be good to have lm- profiler report programs that do read accesses. ** Affects: laptop-mode-tools (Ubuntu) Importance: Undecided Status: New -- lm-profiler: monitoring read access https://bugs.launchpad.net/bugs/244859 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 230671] Re: Mounts external USB hard drive in a different point after resuming sleep
I am sorry my comments have been misunderstandable and caused this bug to be set to invalid even if it may be valid. My first comment was made to point to solution, that is possible with new kernels. The second to point out that USB_PERSIST should better be patched to check USB IDs when somone fixes this bug by enabling USB_PERSIST for usb-storage devices in ubuntu. Ubuntu 8.04 does NOT yet make use of USB_PERSIST with usb-storage devices. Devices get mounted on different positions, breaking old mounts points that stay around. If nobody has fixed this, this bug is probably still valid. If the design says to break usb mounts, this bug may be a valid bug to fix the design. -- Mounts external USB hard drive in a different point after resuming sleep https://bugs.launchpad.net/bugs/230671 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 230671] Re: Mounts external USB hard drive in a different point after resuming sleep
My comments did not describe an implemented design, but pointed to a possibility to fix this in ubuntu. ** Changed in: linux (Ubuntu) Status: Invalid => Confirmed -- Mounts external USB hard drive in a different point after resuming sleep https://bugs.launchpad.net/bugs/230671 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 83025] Re: initramfs-tools script doesn't wait for device initialization, preventing mdadm to assemble md arrays
To fix the issue the md, cryptsetup, etc. scripts that set up the root device need to wait for their device to get set up by udev and timeout after a while (possibly running a degraded raid). https://wiki.ubuntu.com/HotplugRaid https://wiki.ubuntu.com/BootDegradedRaid -- initramfs-tools script doesn't wait for device initialization, preventing mdadm to assemble md arrays https://bugs.launchpad.net/bugs/83025 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 247153] Re: Volume group containing encrypted root not initialized if device is slow to appear
** Changed in: initramfs-tools (Ubuntu) Status: New => Confirmed -- Volume group containing encrypted root not initialized if device is slow to appear https://bugs.launchpad.net/bugs/247153 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 247153] Re: Volume group containing encrypted root not initialized if device is slow to appear
IMHO the cryptsetup scripts in initramfs should go into a waiting loop (0.5 sec intervals) for their devices (going on quickly when device is available) and timeout after a while. Lets get rid of long sleep workarounds and race conditions. ** Summary changed: - Volume group containing encrypted root not initialized if device is slow to appear + encrypted root initialisation does not wait for its device to appear -- encrypted root initialisation does not wait for its device to appear https://bugs.launchpad.net/bugs/247153 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 247153] Re: encrypted root initialisation does not wait for its device to appear
Alternatively cryptsetup may be handled by udev rules, similar as md and lvm devices are. -- encrypted root initialisation does not wait for its device to appear https://bugs.launchpad.net/bugs/247153 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 83025] Re: initramfs-tools script doesn't wait for device initialization, preventing mdadm to assemble md arrays
md and lvm devices are actually handled by udev rules. For one, cryptsetup handling needs go into a waiting loop (Bug #247153), or also be handled by udev rules. For two, the initramfs script that mounts the rootfs needs go into a waiting loop (0.5 sec intervals) for their devices (going on quickly when device gets available) and timeout after a while. -- initramfs-tools script doesn't wait for device initialization, preventing mdadm to assemble md arrays https://bugs.launchpad.net/bugs/83025 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 247153] Re: encrypted root initialisation does not wait for its device to appear
Just checked that the same applies for encrypted non-rootfilesystems on external disks, too. (/etc/init.d/cryptdisks*) Since md and lvm devices are set up by udev, cryptdisks scripts need to contain a waiting loop for their disks, or need to be called by udev rules themselves. -- encrypted root initialisation does not wait for its device to appear https://bugs.launchpad.net/bugs/247153 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 251164] [NEW] crypdisk setup does not wait properly for its devices to appear
Public bug reported: Binary package hint: cryptsetup ubuntu 8.04 md and lvm devices are set up by udev rules. cryptsetup races the hotplug system and fails if they are not set up instantly. cryptsetup scripts in initramfs and /etc/init.d/ should go into a waiting loop (0.5 sec intervals) for their devices (going on quickly when device is available) and timeout after a while. while timeout not reached, do: if my device has come up, continue wait a 0.5 seconds done. if timeout has been reached ... Lets get rid of long sleep workarounds and race conditions. Alternatively cryptsetup may be handled by udev rules, similar as md and lvm devices are. ** Affects: cryptsetup (Ubuntu) Importance: Undecided Status: New -- crypdisk setup does not wait properly for its devices to appear https://bugs.launchpad.net/bugs/251164 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 244808] Re: --incremental --scan --run does not start anything
** Description changed:
Binary package hint: mdadm
(ubuntu 8.04)
- When --incremental is used to assemble array incrementally (as is envisioned
for udev hotplugging)
- --incremental --scan --run does not start anything.
+ The man page suggests that "mdadm -IRs" will start the arrays that have
+ been assembled incrementally, but which are still missing some redundant
+ members (degraded mode).
- "mdadm --incremental --scan --run" does not start the arrays that have
- been partially assembled by prior "mdadm --incremental "
- commands.
-
- We would need a command to start a specific arrays that we have found
incrementally after a timeout has passed.
- (Having to starting all partially assembled arrays degraded would be
depreciated.)
-
- Idealy this should still allow to --increment further members (auto-
- readonly) later on.
-
- Something like: "mdadm --incremental --run /dev/mdX"
+ But this does not seem to have any effect on inactive arrays here.
+ ("mdadm --incremental --scan --run" does not start the (multiple) arrays that
have been partially assembled by prior "mdadm --incremental "
commands.)
--
--incremental --scan --run does not start anything
https://bugs.launchpad.net/bugs/244808
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 251646] [NEW] option to start selected arrays in "auto-read" mode (like --incremental)
Public bug reported: Binary package hint: mdadm Initramfs has to start (selected) md devices in degraded mode. (The ones that contain the rootfs and swap/resume partition, if they didn't start after some time of udev hotplugging.) It seems to be preferable to use --incremental not only in the udev rules but also in the boot scripts, because is said to support "auto- read" mode for smoth inclusion of members that appear later on. But the boot script should only start selected arrays, i.e. the one containing the rootfs not all incomplete ones. So where "mdadm --run /dev/mdX" is preferable to "mdadm --assemble --scan" (only start selected array degraded), something like: "mdadm --incremental --run /dev/mdX" or to start all arrays in "auto-read" mode by default might be preferable to both. ** Affects: mdadm (Ubuntu) Importance: Undecided Status: New ** Summary changed: - option to start selected arrays in "auto-read" mode (--incremental) + option to start selected arrays in "auto-read" mode (like --incremental) -- option to start selected arrays in "auto-read" mode (like --incremental) https://bugs.launchpad.net/bugs/251646 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 226484] Re: boot from raid1 root fails because of missing hostname in initramfs
The installer seems to work around the issue of an unset hostname in initramfs by putting an ARRAY line into the mdadm.conf file, or by having an unset hostname when creating the md device. Whichever, this error does not appear after raid installations. -- boot from raid1 root fails because of missing hostname in initramfs https://bugs.launchpad.net/bugs/226484 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 157981] Re: udev not using mdadm incremental
--incremental is available in hardy (8.04) Some info on howto enable it is available on: https://wiki.ubuntu.com/BootDegradedRaid -- udev not using mdadm incremental https://bugs.launchpad.net/bugs/157981 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 83025] Re: mount script doesn't wait for root device initialization, preventing udev+mdadm/cryptsetup to assemble md arrays
** Summary changed: - initramfs-tools script doesn't wait for device initialization, preventing mdadm to assemble md arrays + mount script doesn't wait for root device initialization, preventing udev+mdadm/cryptsetup to assemble md arrays ** Description changed: script '/usr/share/initramfs-tools/scripts/init-premount/udev' launches cold plugging of devices on background, then terminates immediately. this causes mdadm md array assembly to fail, because it doesn't see it's /dev/sd?? devices yet. Ugly hack is to sleep 20 after launching the coldplug. + + The script that mounts the root fs should enter a loop checking if all + the root device has come up, and if that has not happened for a while + start an md device in degraded mode. + + Something like + If rootfs depends on a md device, + while timeout not reached, do: + if root md device has come up, continue booting + wait 0.5 seconds + done. + if timeout has been reached: + mdadm --run + + The udev lvm/crypt/ hotplug then goes on, so... + if rootfs then depends on a lvm device + while timeout not reached + + (check https://wiki.ubuntu.com/BootDegradedRaid) ** Summary changed: - mount script doesn't wait for root device initialization, preventing udev+mdadm/cryptsetup to assemble md arrays + mount script doesn't poll if root device has been initialized, preventing udev+mdadm/lvm/cryptsetup to do its job -- mount script doesn't poll if root device has been initialized, preventing udev+mdadm/lvm/cryptsetup to do its job https://bugs.launchpad.net/bugs/83025 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 244803] Re: Segfault when readding hotplug devices
** Summary changed: - Segfault when readding removable devices + Segfault when readding hotplug devices ** Description changed: Binary package hint: mdadm - When an external drive with a raid 1 member (say /dev/sdc1) gets disconnected and is subsequently re-added with "mdadm --add /dev/md0 /dev/sdd1" mdadm quits with "segmentation fault". + When an hotplugable raid 1 member (say /dev/sdc1) gets disconnected and is subsequently re-added with "mdadm --add /dev/md0 /dev/sdd1" mdadm quits with "segmentation fault". - The udev rules supplied for mdadm should trigger a "mdadm --fail - --remove " as soon as possible on an udev removal - event. + The udev rules supplied with mdadm need to trigger a "mdadm --fail + --remove " as soon as possible on udev removal + events. - This needs to be removed quickly (ACTION=="remove", SUBSYSTEM=="scsi_generic") bevore the device node ist deleted and the device can't be removed any more. + The member partitions need to be removed quickly (i.e. ACTION=="remove", SUBSYSTEM=="scsi_generic") before the device node ist deleted, because then the device can't be removed from the array any more. (German testreport http://www.rob-schulze.de/publikationen/frickelworx/usb-raid/) -- Segfault when readding hotplug devices https://bugs.launchpad.net/bugs/244803 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 251663] [NEW] --incremental not creating device nodes
Public bug reported: Binary package hint: mdadm ubuntu 8.04 When "mdadm --incremental /dev/sdXY" is used to incremantaly assemble an array (as udev is supposed to do instead of --assemble --scan), after a reboot that cleared device nodes from prior --assemblies, mdadm fails because of missing device nodes instead of creating them. ** Affects: mdadm (Ubuntu) Importance: Undecided Status: New -- --incremental not creating device nodes https://bugs.launchpad.net/bugs/251663 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 251646] Re: option to start selected arrays in "auto-read" mode (like --incremental)
can not change this to wishlist / upstream -- option to start selected arrays in "auto-read" mode (like --incremental) https://bugs.launchpad.net/bugs/251646 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 251671] [NEW] suspend with root and swap on raid1 failed
Public bug reported: ubuntu 8.04 Running on a degraded 2 device raid1 array with a single member. [2/1] [U_] that holds lv_root and lv_swap. It may be that the raid was not cleanly stopped prior to powerdown (as the rc scripts don't do that), or that it was first restarted ok, or being incrementaly assebled, but somehow when the old state should be or was resumed.. It may be that the resume was ok but the raid had changed state and got broken with the old state. The machine allways resumed ok without raid before. "mdadm -E" reported status active and a checksum error on the raid partition. The array would not start even with --force. (Fortunately I was able to recover recreating the array with "mdadm --create --assume-clean -n 2 /dev/md0 /dev/sdb1 missing" and fsck'ing the rest out of it :) ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- suspend with root and swap on raid1 failed https://bugs.launchpad.net/bugs/251671 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 251671] Re: suspend with root and swap on raid1 failed
I also noticed that mdadm -E also reported the member device flaged as "write-mostly", even though I have never set this. It may have been the installer because it was on a usb drive, I tested on a new install but have not seen that. So it may have been set during suspend/resume or have been part of the corruption. -- suspend with root and swap on raid1 failed https://bugs.launchpad.net/bugs/251671 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 251999] [NEW] kernel does not honor ext2/ext3 mount option
Public bug reported: ubuntu 8.04 (2.6.24-19) When mounting an ext3 fs with -t ext2 (to stop the constant journal updates even no data is written or read), or when setting the mount option in fstab, the kernel does not honor this. The mount command lists the mount as ext2 but the filesystem is still journaling during idle times. ** Affects: linux (Ubuntu) Importance: Undecided Status: New -- kernel does not honor ext2/ext3 mount option https://bugs.launchpad.net/bugs/251999 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 244792] Re: -ARs fails with prior --no-degraded assemblies
Using --incremental (Bug #157981) avoids this bug with ubuntu udev hotplugging. -- -ARs fails with prior --no-degraded assemblies https://bugs.launchpad.net/bugs/244792 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 83025] Re: mount script doesn't poll if root device has been initialized, preventing udev+mdadm/lvm/cryptsetup to do its job
/usr/share/initramfs-tools/scripts/local in 8.04 contains a checking loop. ** Changed in: initramfs-tools (Ubuntu) Status: Confirmed => Fix Released -- mount script doesn't poll if root device has been initialized, preventing udev+mdadm/lvm/cryptsetup to do its job https://bugs.launchpad.net/bugs/83025 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 120375] Re: cannot boot raid1 with only one disk
Hi, some feedback about the patches.
Does it matter if call_failure_hooks is allways called?
"mdadm --run --scan" will start all arrays degraded not only the one needed for
the rootfs (and its lvm and crypt respectively).
It will start for example a partial array from a removable disk that was
attatched and hasn't been forgotten when the computer was turned off. Remember
starting an array degraded means it will also start degraded next time. To
prevent accidential degration and sideeffect just start the required arrays
with "mdadm --run /dev/mdX" or even better by UUID.
This means of course we need to know the required array in initramfs.
Another point are required non-root filesystems, like a /home array that
needs to startdegraded.
We need a way to configure non-root raid devices to startdegraded
anyway, so this configuration could as well be used (hooked into
initramfs like the cryptroot script does) for the root device. (The
bootdegraded kernel parameter might not be neccesary then.)
A regular init.d script (like the former mdadm-raid or mdadm-degreade)
can handle the non-root startdegraded devices.
Instead of fixed sleep 5 in init-premount/mdadm, you could introduce a check &
timeout loop after call_failure_hooks in the local script. (So we can resume
booting ASAP.) Maybe just copy the slumber while loop from above the
call_failure_hooks.
The error output could be more informative:
Instead of "Check rootdelay= (did the system wait long enough?)"
-->"If rootdelay=${VARIABLE} is not long enough, customize kernel parameter."
I have updated the comments on
https://wiki.ubuntu.com/BootDegradedRaid#head-59fd70893e835c25f3c7a40741e1b24ad6066a64
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
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 120375] Re: cannot boot raid1 with only one disk
After # We've given up, A while loop is calling panic. An if statement might look better. -- cannot boot raid1 with only one disk https://bugs.launchpad.net/bugs/120375 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 251164] Re: crypdisk setup does not wait properly for its devices to appear
This applies to both initramfs and init.d scripts. (root and home raids with devices on external disks take longer) sleep 0.1 seconds intervalls are probably ok ** Summary changed: - crypdisk setup does not wait properly for its devices to appear + crypdisk setup does not wait properly for its source devices to appear ** Description changed: Binary package hint: cryptsetup ubuntu 8.04 md and lvm devices are set up by udev rules. cryptsetup races the hotplug system and fails if they are not set up instantly. cryptsetup scripts in initramfs and /etc/init.d/ should go into a waiting loop (0.5 sec intervals) for their devices (going on quickly when device is available) and timeout after a while. while timeout not reached, do: if my device has come up, continue - wait a 0.5 seconds + wait a 0.1 seconds done. if timeout has been reached ... - Lets get rid of long sleep workarounds and race conditions. + Lets get rid of failure, long sleep workarounds and race conditions. Alternatively cryptsetup may be handled by udev rules, similar as md and lvm devices are. -- crypdisk setup does not wait properly for its source devices to appear https://bugs.launchpad.net/bugs/251164 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 120375] Re: cannot boot raid1 with only one disk
Thank you for your comments and I'm sorry me slowly commenting overlapped with
your updated patches. (Of course you just worked to fast ;-), and fixed things
beforehand, perfect. :)
It's good to see that happen, and I've seen the merrit of the while loop
in intrepid now. It looks much better than in hardy.
Yes, lets fix things avoiding immeadiate pittfalls.
Lets think crucial things like initramfs through while we are at it. I'll try
to shake the ends over here that together we'll get those bugs thoroughly out
of our puppy.
>> This means of course we need to know the required array in initramfs.
>Well, that part is doable for the root filesystem at least. It's
${ROOT} within the initramfs scripts.
${ROOT} may be the md device that needs to be run degraded in the corner
case of a non-partitionable, non-crypted, non-lvm, md device.
>What you're talking about is going to be more complicated, and can be handled
>at a later time, by subsequent patches.
Yes, initramfs setup doesn't seem to be easy to me. I'd like to make
much later work unneccesary.
> How about opening a separate bug for independently
allowing/disallowing each array to be started in degraded mode?
It's more than that. For example the --incremental option is neccessary,
because there is this nasty Bug #244792 waiting, (For that reason I have
gathered all that in the BootDegradedRaid comments.)
---
I tested the changes and a crypted root does not yet come up degraded.
The init-premount/mdadm script is responsible to set up arrays. (the
local script depends on it) With udev+mdadm init-premount/mdadm doesn't
have to do more then register its mountfail hook and degrade arrays if
they are not available after a while, if requested.
init-premount/mdadm needs to degrade the array before local-
top/cryptroot.
I see two changes for package mdadm.
-> in init-premount/mdadm:mountroot_fail() run the array degraded imediately
(implemented by ppa9). This will start degraded arrays that are made of several
_crypt devices, after the rootdelay.
-> Regular degraded arrays should be run degraded directly in
init-premount/mdadm, if a "while array not active" slumber loop timed out. (not
yet implemented in ppa9)
Here is why:
With the second change local-top/cryptroot can find its source device.
Cryptsetup is not triggered by udev (and can not be, because non-luks
partitions can not trigger events), its run by local-top/cryptroot. It
doesn't make much sence to enter local-top/cryptroot with an inactive
array, only to let it fail and then wait rootdelay to see that mounting
the rootfs also fails and then try to recover with another rootdelay.
The rootdelay is there to wait for removable root devices. But encrypted
root devices won't show up.
(Its another bug 251164, but serves the understanding:
local-top/cryptroot fails even with full array present when the disk has not
triggerd an udev event. This is because cryptroot does not have its own
checking loop, just as mdadm does not have its own checking loop yet. Only
mounting root has its checking loop. Mixing one into another is not such a good
idea because dependencies get lost and no while condition is adequate for all
waiting involved.)
If a missing encrypted array member shows up 1 second into the rootdelay,
cryptroot can't set up the root device before the failure hooks kick in, the
root device won't show up for sure.
(And maybe we don't want the cryptsetup to be part of a loop with unlimited
trys.)
When instad mdadm waits for the raid device to become active,
local-top/cryptroot will start to set the root device up a second later and
rootdelay would exit immediately.
On my testing system (8.04) local-top/cryptroot is not run at all after
the array is degraded, and the root mounting fails. (cryptroot has no
failure hooks) Ok, cryptsetup is a different package producing the issue
at hand, but we are not yet done with package mdadm.
With manual cryptsetup and mounting of the rootfilesystem, the system
still did not come up degraded. The /home raid isn't set up. Of course
this part of "cannot boot raid1 with only one disk" can be dealt with
in /etc/init.d/mdadm-raid with a "while array inactive" delay loop.
---
When the confusion sets in, orchestred or not, recall.
Do stay on top. Fix the system, not the numberd bugs.
Orientation is your mastership.
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
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 251164] Re: crypdisk setup does not wait properly for its source devices to appear
Hallo Reinhard, are you refering to udev settling? One of my usb disks is so slow in initializing, that it won't even trigger an udev event until 8 seconds after udev has been started in initramfs. Is the intrepid initramfs-tools/scripts/local-top/cryptroot viewable somewhere on the web? -- crypdisk setup does not wait properly for its source devices to appear https://bugs.launchpad.net/bugs/251164 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 120375] Re: cannot boot raid1 with only one disk
I think it can be understood that using "mdadm --assemble --scan" instead of
doing selective "mdadm --run " calls on all devices ${ROOT} depends on
could be a reasonable and quick fix, if the information is not available
somwhere allready. Full support here.
My interest lies in getting the algorithm right, so that it will work
out for most if not all possible ways of udev,raid,crypt,lvm, etc.
stacked configs. And we won't hit a whole waterfall of subsequent bugs.
Also configuring selective arrays to be run or not run degraded might be
somthing that can be postponed. The list of md devices that are needed
to fully bring up a server or desktop system consists of the md devices
on which the devices listed in fstab depend on.
When a disk fails in a running system, it doesn't stop by default, and
probably should't. This is the reason for the mdadm notification
functionality. So defaulting to bootdegraded=yes seems reasonable, once
the patches are tested to work with enough configurations, and will be
safe if no other md devices than the ones neccessary to set up the fstab
are touched.
https://wiki.ubuntu.com/BootDegradedRaid updated
--
cannot boot raid1 with only one disk
https://bugs.launchpad.net/bugs/120375
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 251164] Re: crypdisk setup does not wait properly for its source devices to appear
Ok, a timeout loop looking for (slower) source devices sounds just what I was missing / suffering from in hardy. I whish there were a webcvs or somthing, would make it easier to compare/check, maybe there is and I don't know. http://packages.ubuntu.com seems unavailable. You may change status if you wish, I'll take your word, thank you. Alles Gute. -- crypdisk setup does not wait properly for its source devices to appear https://bugs.launchpad.net/bugs/251164 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 244810] Re: inconsistency with the --no-degraded option
> clearer when staring degraded raids stays the resposibility of startup scripts. Or the user manually starting an array. (possibly by right clicking) Then, when two array disks are pluged in and it doesn't come up it is always clear they the array is not complete. -- inconsistency with the --no-degraded option https://bugs.launchpad.net/bugs/244810 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 252333] [NEW] hdparm.conf comments should mention that udev rules use it too
Public bug reported: Binary package hint: hdparm Mention that (in debian and ubuntu) hdparm settings may be set by a script startup script or when a device is plugged in by udev rules. And that some packages like laptop-mode-tools can take care of setting some hdparm parameters dynamicly during operation. ** Affects: hdparm (Ubuntu) Importance: Undecided Status: New -- hdparm.conf comments should mention that udev rules use it too https://bugs.launchpad.net/bugs/252333 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 252336] [NEW] error behaviour with multiple partions on one disk
Public bug reported: Binary package hint: thunar If there are two partiontions thunar will umount both if one is unmounted. This is good because it makes unpluging save. With one partition mounted through fstab though the error message does not relate to the partition that one tried to unmount. Wish: The relations betwen the partition icons would be clear if multiple partitions on single device would be represented as one folder containing multiple disk icons. ** Affects: thunar (Ubuntu) Importance: Undecided Status: New -- error behaviour with multiple partions on one disk https://bugs.launchpad.net/bugs/252336 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 252345] [NEW] mdadm.conf is crated with explicit ARRAY statements prevents hotplug autodetection
Public bug reported: Binary package hint: debian-installer On systems that are set up statically mdadm.conf is often used to list the md devices that should be set up and the startup script just calls mdadm --assemble --scan. But on systems oriented towards hotplug ability this prevents arrays from being assembled by the hotplug system. Ubuntu has switched to set up complete (non-degraded) arrays automatically with udev rules. But any ARRAY line in mdadm.conf created during (package) installation prevents the hotplugging to work with other arrays. As only complete (non-degraded) arrays are run automatically the automatic assembly will leave partial arrays that may be plugged in untouched, thus the system shoud be save even without the ARRAY restriction. (The --no-degraded and --increamental options have been implemented with this hotplugging in mind.) The ARRAY lines should not be created on udev+mdadm systems. ** Affects: debian-installer (Ubuntu) Importance: Undecided Status: New -- mdadm.conf is crated with explicit ARRAY statements prevents hotplug autodetection https://bugs.launchpad.net/bugs/252345 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 252351] [NEW] provide some info about users and file permissions
Public bug reported: Binary package hint: debian-installer Following is a little informative text for the "set up users and passwords" stage: --- It is easy for multiple users to collaborate on a debian/ubuntu system. Just keep in mind that access to files always depends on the permissions of the file itself AND the permissions of the directory path to it. Files are by default readable for whoever has access to them, just as paper files are, but not writeable. If you don't want others to read your files, keep them in a private/ subdirectory. The path into your home directory is not restricted, just as the path others can take to ring your bell at home. As a matter of fact you may post some files on your door for others or to read, many services act on config files that you deposit in your home path. Besides other users may want to leave files for you personally in your incomming/ directory. In debian the primary group of each user is by default a private user group, the single member being the user itself. This allows to grant group write permissions to created files by default. No one exept the owning user will be able to write to the file if it has not been created in a group directory. Group directories (directories with the set-group-id flag set) are special places that all users are able to visit and the members of the group that owns the directory will be allowed to write files in it. Files created in these places will belong not only to the creating user but to the group. Other than that, group directories work simmilar as home directories, the group can keep files that should be readable only by group members in a private subdirectory. Group directories may be set up by regular users in their home directories, or in /home/shared by the system administrator or the addgroup command. --- Things that ease collaboration further: create: /etc/skel/priv or private (drwxrwx---) /etc/skel/incomming (drws--s-wt or something) /home/shared/users (drwxrwsr-x root:users) For the latter to work /etc/security/groups needs to contain "*;*;*;Al-2400;users" then all users will automatically belong to the "users" group on systems with private user groups) (a /etc/skel/public might be misleading, so we leave this one out) ** Affects: debian-installer (Ubuntu) Importance: Undecided Status: New -- provide some info about users and file permissions https://bugs.launchpad.net/bugs/252351 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 120375] Re: cannot boot raid1 with only one disk
I just noticed that with slowly-appearing drives (with md devices on it) the md device will not exist on the regular run of init-premount/mdadm. But since introducing another waiting loop into the coldplug driven boot does not make much sence it'll be preferable to just do degration with failure hooks after a full rootdelay. That means that with a degraded md array two wainting loops will have to time out. (the one in local-top/cryptroot and the rootwait in local) But this is now an issue of local and local-top/cryptroot. So the remaining list for package mdadm is down to the array degration of md devices on which the fstab depends in /etc/init.d/mdadm. BTW /usr/share/initramfs-tools/hooks/cryptroot contains code to determine cryptdevices that the rootdevice depends on. Similar approach may work to find md devices the rootdevice depends on. It may help to identify the particular arrays to degrade and solve this bug in a way that does not introduce new problems. -- cannot boot raid1 with only one disk https://bugs.launchpad.net/bugs/120375 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 251164] Re: crypdisk setup does not wait properly for its source devices to appear
Ah, packages server is back up.
I see the whole rootdelay loop has been copied from the local script and
also the dropping to the console when ${cryptsource} is missing.
But the recent local script will execute additional failure hooks. For
example degraded arrays will only get started by these.
When cryptroot drops to a console is like it does now it will basically prevent
the local script from running any failure hooks. A system with a degraded array
that contains the cryptroot for example won't come up. The array will only be
run degraded after the rootdelay in local has timed out.
(Relevant is Bug 120375 and the updated mdadm packages from
https://launchpad.net/~kirkland/+archive)
It should be save to just remove the loop that drops to the console in
init-top/cryptroot and exit to local instead. That would mean another
rootdelay loop will have timeout for sure, though, until failure hooks
might eventually help out. (And if for example the array can be started
degraded, init-top/cryptsetup will still need to provide a failurehook,
or won't be run again to open the rootdevice).
But here is a suggestion for further improvement:
Have the local script call cryptroot (or better an "eventhook",
registerd on the first run just like the failure hooks) from within the
rootdelay loop in the local script.
The eventhook of local-top/cryptroot should be called (once) if
${cryptsource} comes available.
The eventhook would only be needed for things like cryptsetup that may not be
set up by udev rules in an coldplug driven boot process.
Instead, they would set a trigger within the single rootdelay loop in local.
(Or would it be possible to generate special udev rules during initramfs
generation that can recognize non-luks partitions, and have a fully
coldpluggable system?)
--
crypdisk setup does not wait properly for its source devices to appear
https://bugs.launchpad.net/bugs/251164
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 252649] [NEW] Support for chainloadable / or /boot partitions
Public bug reported: Binary package hint: grub (I don't know if this is grub or grub-installer) It would be nice if grub-install could default to always setup the boot sector of the / or /boot partition to be chainloadable also (as a backup). * Recovering from an overwritten MBR would be as easy as chainloading the /boot or dedicated grub partition. (With a DOS mbr in place only the boot flag of the /boot partition needs to be set.) * update-grub could by default generate simple menu.lst entries (root ; setup (hd0)) to setup or recreate MBRs (hdX) or floppies (fd0) to boot /boot/grub * It is very convenient to have a dedicated grub partition to boot parallel installations of a distribution or different OSes. * A dedicated /grub partition on hd0 can be created by mounting a partition from hd0 to /mnt and issuing "grub-install --root- directory=/mnt (hd0)". * The dedicated grub partition will just need maintainance free chainloader menu.lst entries. * Grub on a read-only boot media (floppy, cd, dvd, usb,...) could check the integrity of MBRs, grub and /boot partitions. ** Affects: grub (Ubuntu) Importance: Undecided Status: New -- Support for chainloadable / or /boot partitions https://bugs.launchpad.net/bugs/252649 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 252485] Re: Mdadm segfault on booting Hardy
Hi, concerning the boot process you can test the current patches https://wiki.ubuntu.com/BootDegradedRaid for Bug #120375 -- Mdadm segfault on booting Hardy https://bugs.launchpad.net/bugs/252485 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 252345] Re: mdadm.conf is crated with explicit ARRAY statements prevents hotplug autodetection
Well, the issue filed here, is autocreated mdadm.conf prevents autodetection of cold- and hotplugging. I found out not only the ARRAY lines, but also the homehost prevents autotection of arrays. The homehost feature may have been good to prevent systems with global "mdadm --assemble --scan" booting from unsyncing partly pluged in arrays and device name switchtichg in the old days. With UUID checking in mdadm, udev and dynamic device names working, we need a way to unset the homehost, to set it to "any" or some other way so "mdadm --incremental /dev/%k" will really setup all completed arrays that are attatched when it is called from udev rules. Something like: HOMEHOST "" in mdadm.conf or --homehost=any on the comandline. -- mdadm.conf is crated with explicit ARRAY statements prevents hotplug autodetection https://bugs.launchpad.net/bugs/252345 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 251164] Re: crypdisk setup does not wait properly for its source devices to appear
Just checked that the same applies for encrypted non-rootfilesystems, too. (/etc/init.d/cryptdisks*) If for example external disks are slow crypdisk fails. Since md and lvm devices are set up by udev: init.d/cryptdisk-early and cryptdisks (or just cryptdisk.functions) need to contain a timeout loop checking for their source device before failing. Or better: If the cryptsetup can done by udev rules. (Maybe udev rules that are created on the fly by the boot script with the help of crypttab and a raw signature of the device?) ** Summary changed: - crypdisk setup does not wait properly for its source devices to appear + crypdisk boot scripts do not wait properly for source devices to appear ** Description changed: Binary package hint: cryptsetup ubuntu 8.04 md and lvm devices are set up by udev rules. cryptsetup races the hotplug system and fails if they are not set up instantly. cryptsetup scripts in initramfs and /etc/init.d/ should go into a - waiting loop (0.5 sec intervals) for their devices (going on quickly + waiting loop (0.1 sec intervals) for their devices (going on quickly when device is available) and timeout after a while. while timeout not reached, do: if my device has come up, continue wait a 0.1 seconds done. if timeout has been reached ... Lets get rid of failure, long sleep workarounds and race conditions. Alternatively cryptsetup may be handled by udev rules, similar as md and lvm devices are. -- crypdisk boot scripts do not wait properly for source devices to appear https://bugs.launchpad.net/bugs/251164 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 120375] Re: cannot boot raid1 with only one disk
4 of the 5 bugs taged as duplicates use a separate home array, the fix will not let such systems boot degraded. WARNING: The mdadm - 2.6.7-3ubuntu2fix uses "mdadm --assemble --scan" on a system based on udev hotplugging. It will start all partly attatched arrays in degraded mode. When any members of the arrays that got degraded comes available (very likely for arrys that got started degraded only as a sideeffect) you risk Bug #244792 corrupting your data. (As long as ubuntu still uses --assemble --scan --no-degraded in the udev rule.) -- cannot boot raid1 with only one disk https://bugs.launchpad.net/bugs/120375 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 251663] Re: --incremental not creating device nodes
To reproduce change /etc/udev/rules.d/85-mdadm* to do "mdadm --incremental /dev/%k" and reboot. After initramfs drops you to a console try mdadm --incremental manually. -- --incremental not creating device nodes https://bugs.launchpad.net/bugs/251663 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 118283] Re: can't easily use unison-gtk to sync a local folder to my VFAT USB drive
You can make your fat filesystem permissions look like matching to your default umask. Mount options: for umask 002: dmask=002,fmask=113 for umask 022: dmask=022,fmask=133 (do not use the unspecific umask option) As a workaround adjust your personal hal vfat mount options in the gconf-editor, but the defaults need to dealt with by ubuntu. -- can't easily use unison-gtk to sync a local folder to my VFAT USB drive https://bugs.launchpad.net/bugs/118283 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 118283] Re: can't easily use unison-gtk to sync a local folder to my VFAT USB drive
More information on a corresponging debian bug, that has been closed by maintainers without resolving. http://bugs.debian.org/344278 -- can't easily use unison-gtk to sync a local folder to my VFAT USB drive https://bugs.launchpad.net/bugs/118283 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 60722] Re: Set better umasks for FAT filesystems (USB drives etc)
You can make your fat filesystem permissions look like matching to your default umask. Mount options: for umask 002: dmask=002,fmask=113 for umask 022: dmask=022,fmask=133 (do not use the unspecific umask option) As a workaround adjust your personal hal vfat mount options in the gconf-editor, but the defaults need to be dealt with by ubuntu. Other usefull mount options can be found on: http://bugs.debian.org/344278 -- Set better umasks for FAT filesystems (USB drives etc) https://bugs.launchpad.net/bugs/60722 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 204577] Re: The default umask should be set to 077. XDG_PUBLICSHARE_DIR should have umask 022
More info in Bug #252351 -- The default umask should be set to 077. XDG_PUBLICSHARE_DIR should have umask 022 https://bugs.launchpad.net/bugs/204577 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 252351] Re: provide some info about users and file permissions
It's ment to inform the user during install and GPL of course. -- provide some info about users and file permissions https://bugs.launchpad.net/bugs/252351 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 253096] Re: pam_umask.so missing in common-session
Oh, the problem with the current state is that umask is set all over the place in shell config files, xsessions, and do not work for ssh logins for example. -- pam_umask.so missing in common-session https://bugs.launchpad.net/bugs/253096 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 253096] [NEW] pam_umask.so missing in common-session
Public bug reported: pam_umask.so determines the umask (from system and user config files (see man page)) and sets it accordingly. The umask should not be set in common-session because it would override all user specific configs, but the option usergroups is neccessary to let it check if ubuntus private user groups are in effect to ease user collaboration (Info on Bug #252351). The line that is needed in common-session is: session optional pam_umask.so usergroups (This just reflects the settings that are in /etc/login.defs but have not been working since the switch to pam.) ** Affects: pam (Ubuntu) Importance: Undecided Status: New -- pam_umask.so missing in common-session https://bugs.launchpad.net/bugs/253096 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 253103] [NEW] users not belonging to users group
Public bug reported: Ubuntu uses private user groups. In order for the users to belong be added to the users group by default /etc/security/groups needs to contain a line like this one: *; *; *; Al-2400; users (Context is also Bug #252351) ** Affects: pam (Ubuntu) Importance: Undecided Status: New -- users not belonging to users group https://bugs.launchpad.net/bugs/253103 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 253213] [NEW] remove obsolete package pam-umask from repository
Public bug reported: pam_umask.so is now included in libpam-modules. ** Affects: pam-umask (Ubuntu) Importance: Undecided Status: New -- remove obsolete package pam-umask from repository https://bugs.launchpad.net/bugs/253213 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 83025] Re: mount script doesn't poll if root device has been initialized, preventing udev+mdadm/lvm/cryptsetup to do its job
initramfs/scripts/local in 8.04 does have a timeout loop for the root device. The remaining mdadm bug numbers are listed on https://wiki.ubuntu.com/BootDegradedRaid ** Changed in: initramfs-tools Status: New => Fix Released -- mount script doesn't poll if root device has been initialized, preventing udev+mdadm/lvm/cryptsetup to do its job https://bugs.launchpad.net/bugs/83025 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 251663] Re: --incremental not creating device nodes
Don't forget to "update-initramfs -k all -u" with the new udev rule before rebooting, though. -- --incremental not creating device nodes https://bugs.launchpad.net/bugs/251663 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 253096] Re: pam_umask.so missing in common-session
Hello Steve, thank you for improving ubuntu. The example came from the pam_umask man page, maybe I had some typo. There is some history why this bug should be fixed. It is a regression that is now easy to fix. Before pam was introduced "login" provided the central point to set the UMASK value in login.defs and also containded the USERGROUPS_ENAB checking feature. The switch to pam was made before pam supported this functionality. Since umask is an important parameter that people need to have set, they began to set umask in shell rc scripts, xsessions, ssh_config, some display mangers even hardcoded the umask etc. (And some of this had to be done to face the regression in day to day use.) Finaly pam_umask.so reintroduced the functionality in pam and has now been merged from its own package (pam-umask) into the libpam-modules upstream. From the pam-umask package description: This package is useful to ensure that users' umasks are set consistently whether their session is initiated by login, SSH, a display manager for the X Window System, or some other means. -- pam_umask.so missing in common-session https://bugs.launchpad.net/bugs/253096 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 253096] Re: pam_umask.so missing in common-session
FYI here is a summary of a Sep 2005 discussion in debian, by now it may be added that, as pam_umask supports the "usergroups" feature, it is no longer neccessary to set the umask to 002 for all users, with pam_umask's "usergroups" feature it will check if users are in a private primary user group. (Debian/Ubuntu has allways used private user groups by default, the switch to pam only broke adequate umask adjustment. Those that are not familiar with the merrits of private user groups for collaborating with other users may have a look at explanation supplied with Bug #252351) It might be desireable to supply a patch to pam_umask to not only fetch UMASK but also the USERGROUPS_ENAB setting from login.defs (or /etc/default/login), then "usergroups" does not have to be set in common-session. Here is the report about the related debian discussion: Christian Perrier <[EMAIL PROTECTED]> wrote: > >(adding the shadow maintainers list to the CC, and therefore keeping a >whole citation, sorry fot this) > >> Summary for technical comittee: setting the umask >> >> Inconsistent umask settings; user private groups concept requires umask 002 >> to >> work. >> Relates to #248140 #248150 #314539 >> >> >> Please successively reasign to base-files (and other packages containing >> umask >> settings), login and libpam-umask packages to resolve the situation. >> >> >> Debian ships defaulting to put newly created users into private primary >> groups. The so called User Private Group (UPG) concept allows easy access >> right management for users. In sgid group-directories access rights of files >> can be set correctly automaticly. It is proven to work fine. >> >> Even though UPGs are the default in debian, they are not set up to work >> properly. The umask is currently set at different places and to conflicting >> values. The result is that the settings to 002 are in most cases not active. >> >> >> CURRENT SITUATION >> >> The settings in /etc/login.defs do reflect the use of UPGs and are adjusted >> to >> generate the correct umask: >> >> # Enable setting of the umask group bits to be the same as owner bits >> # (examples: 022 -> 002, 077 -> 007) for non-root users, if the uid is >> # the same as gid, and username is the same as the primary group name. >> # >> # This also enables userdel to remove user groups if no members exist. >> # >> USERGROUPS_ENAB yes >> >> However: >> a) This login.def functionality is not active on systems with PAM (now >> standard in debian). And the pam_umask funktionality is not part of the base >> system. >> >> b) The umask gets overwritten in shells that source rc files like >> /etc/profile >> which ships with an umask line. >> >> >> SUGGESTED SOLUTION >> >> 1) remove/comment out any umask settings in all shell configuration files >> shiped with debian (i.e. /etc/profile) and add a comments >> that /etc/login.defs or better pam_umask ist the right place for global >> umask >> setting. >> It might be /etc/default/login (LSB?) now, pam_umask looks at both. Setting umask in common-session is only to override user specific GECOS settings. >> 2) In /etc/login.defs correctly move all settings that are overridden by PAM >> below that comment (i.e. USERGROUPS_ENAB) and vice versa[1]. Set the umask >> to 002 for the case that libpam-umask is not installed, but point the admin >> to libpam-umask and the right file for the umask setting. >> The historical UMASK 022 may be set (uncommented again) if /etc/default/login is not adopted, pam_umask support for usergroups (man pam_umask) should be mentioned. >> 3) Add libpam-umask to the base system. And enable the default umask of 002 >> as >> described in the README. pam_umask.so is now part of regular libpam-modules and looks for umask settings in starndard places. No need to supply an override umask in common-session. >> >> >> --- >> >> The articulated reason for closing #248140 has been that if an umask of 002 >> would be active instead of the 022 this could lend to unexpected behaviour. >> The example given was that when copying with scp to systems without UPGs >> might unexpectedly expose files to write access. >> >> However scp should nomaly respect the umask on the target system. >> >> Only when explicitly using "scp -p" (preserving permissions) that might not >> be >> the case. But when copying files between systems with explicity using >> switches like these, it seems the user has to be aware of possible >> implications and inconsistencies in user and group IDs anyway. With "scp -p" >> as a normal user the copy might belong to the destination user and its >> primary group, done as root numerical UIDs taken from other systems may >> always belong to different users. >> >> The possibly of users (accidentially) having scp aliased to "scp -p" may >> seem >> a little far fetched to warrant shiping debian with a non-working user >> private group setup by default. >> > >All this seems to
[Bug 245210] Re: login.defs references libpam-umask which is a obsolete package
Actually, libpam-modules are installed by default and this new pam_umask.so should be enabled in common-session by default (Bug #253096). pam_umask now recovers the umask functionality that login once had for pam systems. (see man pam_umask) It gets the users umask from several places. That means UMASK may be uncommented in login.defs or point to /etc/default/login if it is introduced (linux stardard base?). /etc/profile should then be commented, not contain umask settings anymore, and point to "man pam_umask" or /etc/default/login or /etc/default/login respectively. -- login.defs references libpam-umask which is a obsolete package https://bugs.launchpad.net/bugs/245210 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 245210] Re: login.defs references libpam-umask which is a obsolete package
See Bug #253096 for the current state of umask setting. -- login.defs references libpam-umask which is a obsolete package https://bugs.launchpad.net/bugs/245210 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 71295] Re: /etc/login.defs umask cleanup
See Bug #253096 for the current state of umask setting. -- /etc/login.defs umask cleanup https://bugs.launchpad.net/bugs/71295 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 253103] Re: users not belonging to users group
Hello Steve, yes, it may be that the adduser maintainer could change his package, adding redundant group configuration to all users. But other than that, some GUI tools don't seem to always rely on adduser (configuration) or even (debian) policy for user and group ids, unfortunately. (It's understood these are other bugs.) One compelling reason to populate the users group (it is allready present on any debian/ubuntu system) for any user of a *nix like system is collaboration amongst users. Without this stardard *nix procedure users of a system can not work on files together easily. (Inform about file permission usage, Bug #252351) Actually it would be good to provide a /home/share/users directory with set-guid permissions by default, to expose this functionality to ubuntu users. The system itself does not need to reference the users group much because it normally does not share write access with users, world read access is enough. On the other hand there is not much reason for users to grand world writeable access to deamons and server processes even to their shared ressources. All the system has to do is to make sure users belong to the users group. Again, the empty users group may be a regression as IIRC users properly belonged to the users group in the past. All I can do to improve ubuntu is providing summarized feedback, if feeling like you would need discussion amongst developers before fixing the issue, I would very much appreceate you, maybe just copying my comments and bringing this forward on appropriate lists, etc. Thank you for improving ubuntu. -- users not belonging to users group https://bugs.launchpad.net/bugs/253103 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 253283] [NEW] OK buttons in profile wizard reversed
Public bug reported: Binary package hint: unison Within the graphical profile wizard the right button aborts and the left button is OK. ** Affects: unison (Ubuntu) Importance: Undecided Status: New -- OK buttons in profile wizard reversed https://bugs.launchpad.net/bugs/253283 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 253282] [NEW] Links retrieved over dns-sd (service discovery) not working
Public bug reported: Binary package hint: kdebase To reproduce configure a domain that provides service discovery information in kcontrolcenter / zeroconf. For example "dns-sd.org". Then you will be able to browse their published services under Network shortcut in KDE. But when following the links konqueror will error on links that look like zeroconf://dns-sd.org/_http._tcp. instead of opening the referenced website. ** Affects: kdebase (Ubuntu) Importance: Undecided Status: New -- Links retrieved over dns-sd (service discovery) not working https://bugs.launchpad.net/bugs/253282 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 253282] Re: Links retrieved over dns-sd (service discovery) not working
This is ubuntu 8.04 (hardy) -- Links retrieved over dns-sd (service discovery) not working https://bugs.launchpad.net/bugs/253282 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 253319] [NEW] rename files instead of deleting and copying again.
Public bug reported: Binary package hint: unison When files gets renamed in replica A, unison shows that the original file is getting deleted in replica B and the renamed file is copied again. This is particulary unfortunate with picture archives, as they get more often renamed but less often is the file contents changed. Can't unison queue the cases that look like filedeletions, and at the end, check if they have not just been renamed? And if that is true, just rename the file in the other replica without retransmitting all the files? Maybe this mechanism could also catch the programmed data loss mentioned under invariants in the documentation (moving a directory with ignored items). ** Affects: unison (Ubuntu) Importance: Undecided Status: New -- rename files instead of deleting and copying again. https://bugs.launchpad.net/bugs/253319 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 157981] Re: udev not using mdadm incremental
Sorry prior post was ment for another bug, the race condition with degraded raids in this bug has different behaviour mentioned in aformentioned kernle list archive. -- udev not using mdadm incremental https://bugs.launchpad.net/bugs/157981 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 157981] Re: udev not using mdadm incremental
When this occurs the drives are accessed continously, system hangs. -- udev not using mdadm incremental https://bugs.launchpad.net/bugs/157981 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 244792] Re: -ARs fails with prior --no-degraded assemblies
When this bug occurs the drives are accessed continously, system hangs. -- -ARs fails with prior --no-degraded assemblies https://bugs.launchpad.net/bugs/244792 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 253096] Re: pam_umask.so missing in common-session
The wording of man pam_umask seems pretty much the same as what used to be in login.defs before. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;filename=login.defs.diff;att=1;bug=282822 I have also made the experience that some graphical user managment tools do not keep gids eqal to uids and that tools create subdirecories in the homes, mimiking other OSes behaviour, but /etc/skel is not used for this. The writers of desktop environment tools do not seem to allways follow unix philosophy. I noticed debian policy states: "Packages other than base-passwd must not modify /etc/passwd, /etc/shadow, /etc/group or /etc/gshadow." (http://www.debian.org/doc/debian-policy/ch- opersys.html#s9.2) --- Just as you write, configuring pam_umask to provide unified means to set the umask for all sessions does not yet automatically (re)enhence default permission handling. If the default umask enables easy usability of permission handling, or does pretty much not support it, it should maybe be less the the result of the shiped pam implementation and adhere to the all time shiped configuration. (USERGROUPS_ENAB yes) Which grants 002 only if it's pretty safe and a feature, many times reported to not work properly and hacked around. (Even though many ubuntu users may have never noticed, and may just think file permissions just allways are like an inflexible pita style thing.) As the user groups created by default have all the time been private ones, it should be pretty save to let the 022->002 mapping do its work for them. The corner case being of course those that are really using sticky sgid directories without actually figuring out to change the umask. Meaning those that manually change filepermissions every time to be able to collaborate with other users, even when they decide to expicitly save stuff into special group places instead of saving into more private (sub)dirs. If we find a good name for that behaviour, we could actually provide sticky non-sgid subdirectory examples to publish something readonly within a group. (Does /home/share//writings /home/share//readings compare to /home//private?) >From the point of the implemented private user groups, if you want that other members of a group can work on a file together with you, they need to be in a group with them and you have to save the file into a special setgid directory, if not keep the file at home, in a private place if you don't want others to be able to read it. For shared write access you save it under the (sgid) group directory. This seems to be the feature and having to fiddle with file permissions is bugging users. Private user groups with umask 002 and a nice set of default directories are quite a feature, I would say. They should be save as long as filessystems are not transfered verbatim to systems with other group setups, but then, when transfering filesystems to other machines one allways has to watch for differences in IDs, anyway. All copy processes should honor the umask on the target systems, if not explicitly overridden to preserve permissions and numerical ids. Maybe I just don't understand that much of the private user group approach that I see it as quite important to provide it for ubuntu users to easily share and lock up files by choosing the location and not having to fiddle with file permissions. From experience though, I've gotton complaints about "those ever complicated and never satisfying file permissions", and wishes to just do away with them, but with private user groups, umask 002, the almost self explanatory fact that access depends on the location where you put stuff (directiory) _and_ file permissions, and by providing some (sample) directories, users fiddling and getting fed up with filepermissions gets allmost a non issue. "Ok, just save that privately in our <...> group dir (/home/share/<...>/private), I'll take care of it"! (Hmm, you made me think of /writings now and I seem to like that idea.) What would be another way to provide good collaboration experience? If ubuntu really allways intended to ship current user and file permission setup with that umask, and the 022 setting in effect together with USERGROUPS_ENAB yes has not been just a result one wasn't particularily aware of, stemming from the once missing pam functionallity, waiting for a fix, and admins adjusting umask settings for multi user systems, what is the reason to ship private user groups? Comparing to umask 022 systems with all users belonging to the users group, users do not only have to manualy give write permission, to say to the users group in the simpliest case, but also need to change the group ownership on any file to collaboorate on it with others. (Note that its asumed the users group is usable and not empty.) This state does not look too consistent and in the best interest of the users to me, and might be just due to an unfortunate effect that the introduction of pam once had in debian. --- It's probably a matter that u
[Bug 253103] Re: users not belonging to users group
I agree, there are of course much more fine grained methods than the group of all users. And to be honest when adminstering larger systems the users group is probably not good for much more then giving all users write access to some device, or to files that are served on the net. Now, it's not unlikely that, as you are familiar with things like creating groups and adequate directory hierachies or ACLs, we tend to just go directly to what we know exists. When we think more like a beginner, as new to the GNU of linux, or how we often get to know things, they may not be aquainted with directory and file permissions etc. at first. But if we asume for a moment we see a directory called /home/share/users with a private subdirectory, where all users of a family computer can put stuff for all to update and modify. (Possibly including /writings and /readings subdirs.) It's foreseeable that finer grained group control might come to mind at some point. But then the answer is allready there, too. The next thoughts are special user groups, how the group direcotries are used is already old news then. In a sense the users group is the only group that can be set up by default, to work with right away and it serves as a seed. It is already there, usable if not just left empty and visible with a users group directory, for human beings to discover the logic of file permissions. And its a reasonable answer to the question: I can easily share files around the globe, but how do I share files with my honney who has another account on our ubuntu machine at home? Though, it is a little addition, using pam_group for this should be rather light on ressources and not make any server without users or really large multi-user setups run less perfect. (And keep /etc/group (or ldap etc.) less cluttered.) As a modern distribution, oriented towards usability, ubuntu of course used pam from the start, it may just feel like a regression for users were able to use unix file permissions that way for ages. Without the users group the easiest but not recomendable way is to resort to the bad habit of granting world write access. There is no risk associated with users belonging to the users group, or is there? Honestly, I did consider fixing "users not belonging to the users group" a non-issue. Just somthing that has been forgotten at some point of time. I consider the users group as a feature that can be used but does not have to. But if it is to be used it has to be set up to contain all users, there is no other way around it. -- users not belonging to users group https://bugs.launchpad.net/bugs/253103 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 244844] Re: Adapt invocation to ubuntu acpi-support / pm-tools packages
This bug report is inteded to document the adaption of laptop-mode- tools. Wouldn't the patch to pm-tools be the matter of a pm-tools bugreport? Though this bugreports may be linked with current pm-tools package interfering with package laptop-mode-tools, I do think this bug needs to be separate from pm-tools bugs (they are not duplicates). -- Adapt invocation to ubuntu acpi-support / pm-tools packages https://bugs.launchpad.net/bugs/244844 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 239419] Re: pm-utils has laptop-tools script which conflicts with laptop-mode-tools
*** This bug is a duplicate of bug 244844 *** https://bugs.launchpad.net/bugs/244844 This pm-utils bug is not a duplicate of the laptop-mode-tools bug #244844. This bug is about pm-utils provocing a conflict. The other is about adapting laptop-mode-tools to the pm-utils / acpi- support hooks. -- pm-utils has laptop-tools script which conflicts with laptop-mode-tools https://bugs.launchpad.net/bugs/239419 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 244844] Re: Adapt laptop-mode-tools invocation to ubuntu's acpi-support / pm-tools packages
** Summary changed: - Adapt invocation to ubuntu acpi-support / pm-tools packages + Adapt laptop-mode-tools invocation to ubuntu's acpi-support / pm-tools packages ** Description changed: Binary package hint: laptop-mode-tools + Adaption would would mean to include scripts that call + "/usr/bin/laptop_mode auto" in in /etc/acpi/ac.d, battery.d, resume.d + and start.d. - Include scripts that call "/usr/bin/laptop_mode auto" in in /etc/acpi/ac.d, battery.d, resume.d and start.d. - - It is suggested to acpi-support to stop calling laptop-mode-tools and hdparm directly. + It is suggested to acpi-support to stop calling laptop-mode-tools and hdparm directly (in non-config files). bug #244831, bug #244832, bug #244833, bug #244836 (Beware: resume.d, and start.d may be obsoleted by some pm-tools directory) bug #244839, bug #205005 (Adapt the approach from the original laptop-mode-tools debian package to current ubuntu acpi-support) laptop_mode may need the options "auto force" when called on resume events. (To reapply hdparm settings even though AC state has not changed.) - (The current laptop-mode disk-idleing approach seems to be a left-over - from before the ubuntu-laptop-mode package was droped for laptop-mode- - tools.) + (The current laptop-mode disk-idleing approach seems to be a left-over from before the ubuntu-laptop-mode package was droped for laptop-mode-tools.) + https://wiki.ubuntu.com/PowerManagement -- Adapt laptop-mode-tools invocation to ubuntu's acpi-support / pm-tools packages https://bugs.launchpad.net/bugs/244844 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 244844] Re: Adapt laptop-mode-tools invocation to ubuntu's acpi-support / pm-tools packages
I don't know. I believe in letting pm-utils manage power state changes (if that is the tool of choice) and letting acpi-support taking care of button, battery and ac events etc. A disk idleing tool like laptop-mode-tools can be hooked into these appropriately, when its packaged with scripts that go into the right directories. -- Adapt laptop-mode-tools invocation to ubuntu's acpi-support / pm-tools packages https://bugs.launchpad.net/bugs/244844 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 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime
A "howto get disks idleing correctly (without excessive load cycling)" has been added to: https://wiki.ubuntu.com/PowerManagement -- High frequency of load/unload cycles on some hard disks may shorten lifetime https://bugs.launchpad.net/bugs/59695 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 244844] Re: Adapt laptop-mode-tools invocation to ubuntu's acpi-support / pm-tools packages
There is now an overview about the related bugs in the wiki. https://wiki.ubuntu.com/PowerManagement#head-ab94c99627b86e9fbb29a09d3316178269c3e764 -- Adapt laptop-mode-tools invocation to ubuntu's acpi-support / pm-tools packages https://bugs.launchpad.net/bugs/244844 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 244833] Re: missing hdparm -B setting during resume
There is now an overview about the related bugs in the wiki. https://wiki.ubuntu.com/PowerManagement#head-ab94c99627b86e9fbb29a09d3316178269c3e764 -- missing hdparm -B setting during resume https://bugs.launchpad.net/bugs/244833 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 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime
** Description changed: This is not a support forum. Please do not use it as such (even though it has been used as such already). You can scan through the bug for links to the Ubuntu forums where many, many different questions have been asked, answered, and re-answered. The temporary workaround is just below, but you may need to use '254', or a bit lower, as opposed to '255'. If HD temperature gets high, you may want to set it all the way "down" to 200 or so. ~1 click every 2.5-3 minutes is fine. + + See https://wiki.ubuntu.com/PowerManagement for an overview about what + is involved and for a remedy. Temporary workaround: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/14 A more extensive description of the workaround: http://ubuntuforums.org/showthread.php?t=591503 Note: Some disks are unresponsive to having their APM changed by hdparm, and therefore the workaround doesn't work. It would be a good idea, in such cases, to disable APM in the BIOS if possible. Following is a summary of the issue: It is confirmed that some systems are seeing an unusually high number of load/unload cycles on their hard disks, as evidenced by smartctl. It was originally surmised that this was related to laptop-mode being enabled, but this affects systems *regardless* of whether or not laptop-mode has been enabled. In fact, aggressive APM is not a bad idea while a system is not on AC, as that system is much more likely to encounter a physical impact. But unfortunately, the heads are only parked for a very short period of time, making impact protection much less effective (and wearing out the drive as well). This problem has been confirmed in Ubuntu as well as in other distributions and on MacOS X and Windows. Symptoms of this bug are: * Frequent HD clicks -- more than one per 3 minutes while idle, louder than the typical access sounds. Often more than twice per minute. On some disks, the click is very quiet * Rapidly Increasing Load_Cycle_Count as displayed in the final number in "sudo smartctl -a /dev/hda | grep Load_Cycle_Count" (where /dev/hda is replaced with your own hard disk device) * Early hard disk failure never stay parked, due to very frequent disk activity. Thus this cycle occurs often, thus wearing out the drive, and any comparative benefit is negligible (whereas, if the-- some disks are cut down to less than a year of actual uptime. The problem is only present due to the existence of *all three* of the following factors: * Hardware is set (default or otherwise) to aggressive power management, causing heads to park. (default behaviour of many drives and often the only user available type of power management) * Disk is touched often, causing heads to unpark. (default behaviour of many distributions) * Drives are spec'd to a limited number of these cycles. (600,000 is the most common, although some may be spec'd higher or lower). Reasonable Limits / Criteria for a fix: * There should be fewer than ~15 load cycles per hour, except during heavy usage while on battery. * This provides a life expectancy of over four years, which is reasonable for a hard disk. Temporary Workaround: * Follow the above link. Permanent Fix: * Obtain utility from your hard drive manufacturer to change the head parking time if available. Some hardware with this issue: WD1200VE -- http://www.wdc.com/en/library/portable/2879-001121.pdf -- This aggressive parking is a feature of this disk, but that feature relies on behaviour that allows for significant amounts of (truly) idle time without the disk being touched. Notice the "Load/unload cycles" of 600,000. Example Load_Cycle_Counts: * Thinkpad Z60m/Hitachi HTS541080G9SA00 with well over 7000 load cycles in only 100 hours. That's >70 per hour. * Gateway MT6451/Western Digital WD1200VE with 164762 load cycles in 3747 hours (156 days) of uptime. That's ~43 per hour -- except that the system was patched during the initial third of its life, which puts it at ~63/hour since Gutsy was installed (and wasn't patched, as I had done with feisty). Please see for yourself how often your drive is load cycling: smartctl -d ata -a /dev/sda (This command is for an SATA drive; you'll need to install the smartmontools package first.) You can get the average per hour by the following division: Load_Cycle_Count / Power_On_Hours See also http://paul.luon.net/journal/hacking/BrokenHDDs.html for a rather dramatic account of the effects the current default values may have. -- High frequency of load/unload cycles on some hard disks may shorten lifetime https://bugs.launchpad.net/bugs/59695 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 244839] Re: /etc/acpi/start.d and resume.d scripts are not run.
Then the bug is that acpi-support contains these bogus directories. -- /etc/acpi/start.d and resume.d scripts are not run. https://bugs.launchpad.net/bugs/244839 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 244838] Re: laptop-mode needs to be activated in two places
There is now an overview about the related bugs in the wiki. https://wiki.ubuntu.com/PowerManagement#head-ab94c99627b86e9fbb29a09d3316178269c3e764 -- laptop-mode needs to be activated in two places https://bugs.launchpad.net/bugs/244838 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 244836] Re: /etc/acpi/power.sh overrides user settings
There is now an overview about the related bugs in the wiki. https://wiki.ubuntu.com/PowerManagement#head-ab94c99627b86e9fbb29a09d3316178269c3e764 -- /etc/acpi/power.sh overrides user settings https://bugs.launchpad.net/bugs/244836 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 244836] Re: /etc/acpi/power.sh overrides user settings
There is now an overview about the related bugs in the wiki. https://wiki.ubuntu.com/PowerManagement#head-ab94c99627b86e9fbb29a09d3316178269c3e764 -- /etc/acpi/power.sh overrides user settings https://bugs.launchpad.net/bugs/244836 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 244832] Re: missing hdparm -B setting during boot
There is now an overview about the related bugs in the wiki. https://wiki.ubuntu.com/PowerManagement#head-ab94c99627b86e9fbb29a09d3316178269c3e764 -- missing hdparm -B setting during boot https://bugs.launchpad.net/bugs/244832 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 244831] Re: /etc/acpi/power.sh overrides user scripts
There is now an overview about the related bugs in the wiki. https://wiki.ubuntu.com/PowerManagement#head-ab94c99627b86e9fbb29a09d3316178269c3e764 -- /etc/acpi/power.sh overrides user scripts https://bugs.launchpad.net/bugs/244831 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 244831] Re: /etc/acpi/power.sh overrides user scripts
There is now an overview about the related bugs in the wiki. https://wiki.ubuntu.com/PowerManagement#head-ab94c99627b86e9fbb29a09d3316178269c3e764 -- /etc/acpi/power.sh overrides user scripts https://bugs.launchpad.net/bugs/244831 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 239419] Re: pm-utils has laptop-tools script which conflicts with laptop-mode-tools
*** This bug is a duplicate of bug 244844 *** https://bugs.launchpad.net/bugs/244844 See https://wiki.ubuntu.com/PowerManagement#head- ab94c99627b86e9fbb29a09d3316178269c3e764 for the links between the separate bugs. -- pm-utils has laptop-tools script which conflicts with laptop-mode-tools https://bugs.launchpad.net/bugs/239419 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 59695] Re: High frequency of load/unload cycles on some hard disks may shorten lifetime
** Description changed: This is not a support forum. Please do not use it as such (even though it has been used as such already). You can scan through the bug for links to the Ubuntu forums where many, many different questions have been asked, answered, and re-answered. - The temporary workaround is just below, but you may need to use '254', - or a bit lower, as opposed to '255'. If HD temperature gets high, you - may want to set it all the way "down" to 200 or so. ~1 click every - 2.5-3 minutes is fine. + The temporary workaround is just below. See https://wiki.ubuntu.com/PowerManagement for an overview about what is involved and for a remedy. - Temporary workaround: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695/comments/14 - A more extensive description of the workaround: http://ubuntuforums.org/showthread.php?t=591503 - Note: Some disks are unresponsive to having their APM changed by hdparm, and therefore the workaround doesn't work. It would be a good idea, in such cases, to disable APM in the BIOS if possible. Following is a summary of the issue: - It is confirmed that some systems are seeing an unusually high number of load/unload cycles on their hard disks, as evidenced by smartctl. It was originally surmised that this was related to laptop-mode being enabled, but this affects systems *regardless* of whether or not laptop-mode has been enabled. In fact, aggressive APM is not a bad idea while a system is not on AC, as that system is much more likely to encounter a physical impact. But unfortunately, the heads are only parked for a very short period of time, making impact protection much less effective (and wearing out the drive as well). + It is confirmed that some systems are seeing an unusually high number of load/unload cycles on their hard disks, as evidenced by smartctl. + + It was originally surmised that this was related to laptop-mode being + enabled, but this especially affects systems where laptop-mode is + disabled. In fact, aggressive APM is not a bad idea while a system is + not on AC, as that system is much more likely to encounter a physical + impact. + + This is due to disk APM settings that let the heads park or disk spin + down after an idle period that is shorter than the regular disk access + patterns of the OS. + + Then, the heads are only parked for a very short period of time and + almost imediately loaded again. Making impact protection much + ineffective and wearing out the drive. + + It can happen when the disk asumes aggressive APM settings (like many + laptop disks) and the OS does not take care to set the APM settings + accordingly to its current disk access pattern. This problem has been confirmed in Ubuntu as well as in other distributions and on MacOS X and Windows. Symptoms of this bug are: * Frequent HD clicks -- more than one per 3 minutes while idle, louder than the typical access sounds. Often more than twice per minute. On some disks, the click is very quiet * Rapidly Increasing Load_Cycle_Count as displayed in the final number in "sudo smartctl -a /dev/hda | grep Load_Cycle_Count" (where /dev/hda is replaced with your own hard disk device) * Early hard disk failure never stay parked, due to very frequent disk activity. Thus this cycle occurs often, thus wearing out the drive, and any comparative benefit is negligible (whereas, if the-- some disks are cut down to less than a year of actual uptime. - The problem is only present due to the existence of *all three* of the following factors: + The problem is only present due to the existence of *all four* of the following factors: * Hardware is set (default or otherwise) to aggressive power management, causing heads to park. (default behaviour of many drives and often the only user available type of power management) * Disk is touched often, causing heads to unpark. (default behaviour of many distributions) * Drives are spec'd to a limited number of these cycles. (600,000 is the most common, although some may be spec'd higher or lower). + * The OS not setting disk APM variables according to current disk access pattern. Reasonable Limits / Criteria for a fix: * There should be fewer than ~15 load cycles per hour, except during heavy usage while on battery. * This provides a life expectancy of over four years, which is reasonable for a hard disk. Temporary Workaround: * Follow the above link. Permanent Fix: - * Obtain utility from your hard drive manufacturer to change the head parking time if available. + * Obtain utility from your hard drive manufacturer to change the default head parking time if available. + * Contrlolling the APM variables of hard drives according to the current disk access pattern. (i.e. chunked into blocks with minutes of idle time (disk-idleing or "laptop_mode") or continous disk access every x seconds expecting the disks to stay up all the time.)
[Bug 246192] [NEW] gksu to regular users broken
Public bug reported: Binary package hint: gksu In (x)ubuntu 8.04 it ist not possible to run an application as a different regular user with gksu. A simple test: Inserting the following line into /etc/sudoers (with visudo) user ALL=(otheruser) ALL leads to: [EMAIL PROTECTED]:~$ gksu -u otheruser firefox (graphical password prompt) Error: cannot open display: :0.0 [EMAIL PROTECTED]:~$ Inserting user ALL=(otheruser)NOPASSWD: ALL leads to: [EMAIL PROTECTED]:~$ gksu -u otheruser firefox [EMAIL PROTECTED]:~$ (doesn't even get to the error message) ** Affects: gksu (Ubuntu) Importance: Undecided Status: New -- gksu to regular users broken https://bugs.launchpad.net/bugs/246192 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 230671] USB device persistence across suspend (was: Mounts external USB hard drive in a different point after resuming sleep)
An "echo 1 >/sys/bus/usb/devices/.../power/persist" could be done for usb-storage devices? A pointer to kernel info: http://www.mjmwired.net/kernel/Documentation/usb/persist.txt and fix released bug #197166 "persist mode in hardy kernel" -- Mounts external USB hard drive in a different point after resuming sleep https://bugs.launchpad.net/bugs/230671 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 230671] Re: Mounts external USB hard drive in a different point after resuming sleep
The CONFIG_USB_PERSIST feature should probably be made to also check the serial numbers of the devices it has been enabled for. Because it is quite likely that one user or tow friends may have two disks of same manufacturer and type. (Especially in HotplugRaid laptop setups https://wiki.ubuntu.com/HotplugRaid) The doc from 2007/05 linked above says "Serial numbers and other strings are not compared." But at least its the manufacturers fault if two or more devices really come with equal serial numbers. -- Mounts external USB hard drive in a different point after resuming sleep https://bugs.launchpad.net/bugs/230671 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 253103] Re: users not belonging to users group
Just to state that I am indifferent wether this is fixed with pam_group or by adding to the default groups in adduser. pam_group wouldn't intruduce much redundant info and fix existing systems/users, too. real group memberships would work for cron/at jobs? (But maybe they use pam session I don't know.) -- users not belonging to users group https://bugs.launchpad.net/bugs/253103 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 268580] Re: Prompt for BOOT_DEGRADED=true|false in thre
When a disk fails in a running system a raid will run degraded. The System doesn't stop, and probably should't. The mdadm notification functionality brings this to the admins attention. So changing the default to bootdegraded=yes seems reasonable, once the patches are tested to work with enough configurations, and will be safe, if no other md devices than the ones neccessary to set up the fstab are touched. (This is when mdadm --incremental is used in udev rules and only specific raids will be run even degraded on boot with mdadm --run /dev/mdX) -- Prompt for BOOT_DEGRADED=true|false in thre https://bugs.launchpad.net/bugs/268580 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 253283] Re: OK buttons in profile wizard reversed
Thank you for the screenshots. The button order also seems reversed in the subsequent windows to create new profiles. I noticed this because I kept hitting cancel after entering the info. -- OK buttons in profile wizard reversed https://bugs.launchpad.net/bugs/253283 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 250938] Re: acpi-support should let laptop-mode-tools run properly
Alexey! I'd like to say thank you. For providing patches to the laptop-mode related things in ubuntu. It was good to see your work apear. -- acpi-support should let laptop-mode-tools run properly https://bugs.launchpad.net/bugs/250938 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 250935] Re: [intrepid] laptop-mode-tools needs to change its default settings to match acpi-support and add hooks for pm-utils
Hi Tormod, you asked: 3. Are some fixes needed in the pm-utils package as well? Can you reference other bug reports (with patches)? I do remeber two things, first Bug #239419 (pm-utils) "pm-utils has laptop-tools script which conflicts with laptop-mode-tools" has been wrongly set as a duplicate of this bug, but is actually messing with laptop-mode-tools job. IMHO the cleanest (and non misleading) fix would be to just remove the /usr/lib/pm-utils/power.d/laptop-tools script from pm-tools. (laptop- mode-tools does all that in a configurable way) And as Alexey has pointed out in a comment, as this script has (and currently is) setting /proc/sys/vm/laptop_mode unconditionaly. So it is tested is may be time now to enable laptop-mode by default with package laptop-mode-tools. (It will still only activate laptop-mode on battery by default.) But then finally Bug #59695 (High frequency of load/unload cycles on some hard disks may shorten lifetime) can be fixed. Simply by enabling CONTROL_HD_POWERMGMT=1 in laptop-mode.conf. The NOLM_AC_HD_POWERMGMT=254 setting that is present will then disable head parking by default. -- [intrepid] laptop-mode-tools needs to change its default settings to match acpi-support and add hooks for pm-utils https://bugs.launchpad.net/bugs/250935 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 252351] Re: provide some info about users and file permissions
Thank you for reassigning the bug. Yes, the info should really be in the documentation, too. I have filed this from practice. Many support requests deal with (new, aka ex windows) users that have installed ubuntu not able to easily collaborate with other users on their ubuntu installation. The explanation screen is almost empty when setting up the initial user account, and the question arises in new users "What,... is this good for?" The info should not prevent people to get though the installer as quickly as possible. But it will set the caucious first time installers right on track, just when they have taken the time to install their system. (They won't read docs on this later on, but complain about not being able to collaborate on ubuntu.) It might be possible to make this even more brief, if for example group directories will be created with new groups by default. "ubuntu is linux for humans" It's not about how to fiddle with unix file permissions, but how to collaborate in an debian/ubuntu setting. FYI the issue of "users not belonging to users group" is now separated out into Bug #253103 (Please comment if you think that that is a bug that needs fixing, as there is some hesitance.) -- provide some info about users and file permissions https://bugs.launchpad.net/bugs/252351 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 244838] Re: laptop-mode needs to be activated in /etc/default/acpi-support
Yes, I think you are right. Since the laptop-mode messing has fortunately been removed from acpi-support the setting is obsoleted there and serves only for confusion. Alexey wrote: It's interesting to know that current acpi-support in Debian unstable (1.109-5) has this comment in /etc/default/acpi-support: # Note: to enable "laptop mode" (to spin down your hard drive for longer # periods of time), install the laptop-mode-tools package and configure # it in /etc/laptop-mode/laptop-mode.conf. # # (Note to upgraders: earlier versions of the acpi-support package contained # an option to enable/disable laptop mode. This option has never actually # worked, and for that reason it has been removed.) (https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/250938/comments/5) --- This issue can be fixed when laptop-mode-tools and acpi-support from Debian is merged. package laptop-mode-tools: /etc/init.d/laptop-mode: drop sourcing of /etc/default/acpi-support (another packages conffile) package acpi-support: /etc/default/acpi-support: remove the ENABLE_LAPTOP_MODE setting and don't supress the above comment. -- laptop-mode needs to be activated in /etc/default/acpi-support https://bugs.launchpad.net/bugs/244838 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
