"mdadm --detail" isn't a "major mode", I guess that's why it is not
listed. Have you looked at "mdadm --misc --help"?
--
mdadm --help should include --detail
https://bugs.launchpad.net/bugs/567928
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to U
Installed the 3.1.2 package on a machine and ...
it was the first time mdadm --incremental actually succeeded in re-
adding a drive when it was attached to an ubuntu machine after booting.
Thumbs up!
You wrote about /var/run/map, but in the running system I see mdadm
created /var/run/mdadm.map an
Fixed in Jools' packages linked in Bug #495370
--
install fails missing obsolete /dev/MAKEDEV
https://bugs.launchpad.net/bugs/368986
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.co
Not installable in 9.10 either.
# aptitude install scsiadd
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Lese Status-Informationen ein... Fertig
Lese erweiterte Statusinformationen
Initialisiere Paketstatus... Fertig
Schreibe erweiterte Statusinformationen... F
maybe try "sudo rescan-scsi-bus.sh" from package scsitools
--
"sudo aptitude install scsiadd" removes packages (wiped out system)
https://bugs.launchpad.net/bugs/374189
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mail
with synaptic it does not seem to want to remove packages
--
"sudo aptitude install scsiadd" removes packages (wiped out system)
https://bugs.launchpad.net/bugs/374189
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs maili
OK, as there is no "close", I guess you could mark it "invalid" or
pursue it upstream, just as you like.
--
mdadm --help should include --detail
https://bugs.launchpad.net/bugs/567928
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
u
** Changed in: mdadm (Ubuntu)
Status: New => Incomplete
** Changed in: mdadm (Ubuntu)
Status: Incomplete => Invalid
--
mdadm --help should include --detail
https://bugs.launchpad.net/bugs/567928
You received this bug notification because you are a member of Ubuntu
Bugs, which is su
** Description changed:
- Binary package hint: util-linux
-
- When using luks on top of software raid devices, linux_raid_member
- devices can get opened as luks instead of being assembled into md
- devices. It is adviseable not to use luks on raid since some updates
- introduced in karmic and un
For me also only the combination of pciehp.pciehp_force=1 and loading
the acpiphp seems to work for me, too (most of the times). Thanks for
the hint!
(Even though we were originally supposed to set pciehp.pciehp_force=0
with acpiphp, right?)
Concerning my lspci output from above:
02:00.0 SATA co
3.1.2-0ubuntu2 here too, and if you ls /var/run/md* in the running
system you don't have the mdadm.map file?
>From the comments I am not sure if 3.1.2 is supposed to already have
that unplug support or not, at least for me it does not yet unbind
unplugged disks automatically.
https://raid.wiki.ker
Actually I agree the help could be improved, i.e. it could first clearly
mention that it is only showing "major modes", or just append the help-
options page. I am just a user like you, and the thing is mdadm could be
considered unmaintained in ubuntu, just check the bugs and the version.
So I'd su
Because it could be misunderstood, by "devs" in my last comment I meant
the upstream developders of mdadm (they seem to just use a mailinglist
and not an explicit bug tracker).
Well, thank you for filing and caring about mdadm!
--
mdadm --help should include --detail
https://bugs.launchpad.net/b
I'd suggest to consider the following option about whether to assemble
segments known to contain conflicting changes or not:
AUTO -SINGLE_SEGMENTS_WITH_KNOWN_ALTERNATIVE_VERSIONS
> That's because it DOESN'T break hot-plugging. I have explained why.
You have the right to think that, obviously we
> Even if you intentionally caused the divergence you don't want both
> disks to show up as the same volume when plugged in.
Right, they'd need to show up under an additionally enumerated (or
mangled) "version name", if another segment (version) of the same array
is allready running. For hot-plug
> In --incremental mode it goes ahead and adds removed disks to
> the array
Yes it would be nice if the states would get sorted out a little better.
Running an array degraded during boot would only have to mark missing
disks as failed for example, just as if they had failed while the array
was run
$ mdadm --version
mdadm - v3.1.2 - 10th March 2010
$ls -l /var/run/md*
-rw--- 1 root root 108 2010-04-23 20:51 /var/run/mdadm.map
/var/run/mdadm:
-rw-r--r-- 1 root root 5 2010-04-23 20:51 monitor.pid
--
Please upgrade to 3.1.x for lucid
https://bugs.launchpad.net/bugs/495370
You received th
Maybe udev rules fire before /etc/init.d/mdadm is processed.
But it also looks pretty empty under /dev/.initramfs on this 9.10
machine, so nothing is copied.
#ls -R /dev/.initramfs
/dev/.initramfs:
varrun
/dev/.initramfs/varrun:
sendsigs.omit
Whats the best way to boot into a initramfs shell t
Its an LTS version, not want to have it install well at least with its
first point release?
--
Installer on UNR image creates too small swap partition
https://bugs.launchpad.net/bugs/345126
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Summary changed:
- Installer on UNR image creates too small swap partition
+ Installer creates too small swap partition (hibernation fails)
--
Installer creates too small swap partition (hibernation fails)
https://bugs.launchpad.net/bugs/345126
You received this bug notification because you a
What's your business messing with bug status? Please explain.
** Changed in: mdadm (Ubuntu)
Assignee: vingslagsvisvid...@gmail.com (bjerry) => (unassigned)
--
mdadm : boot failed sometimes, no devices found
https://bugs.launchpad.net/bugs/120504
You received this bug notification because yo
Something is wrong with the non-existing maintenance of a basic system
component like mdadm in ubuntu. Not even the updated debian packages get
synced.
** Summary changed:
- Please upgrade to 3.1.x for lucid
+ Please upgrade to a non-outdated version
--
Please upgrade to a non-outdated version
10.04
Opening update-manager manually showed it hasn't run since 25 days!!!
(Contrary to the setting to check for updates daily, and the computer is
used several times each day.)
And after manually checking for updates: Contrary to the setting to
install security updates automatically, no securit
** Summary changed:
- Update manager not showing notification of daily updates
+ security updates not installed daily as configured
--
security updates not installed daily as configured
https://bugs.launchpad.net/bugs/549217
You received this bug notification because you are a member of Ubuntu
B
The impotance is serious. (please adjust)
Have confirmed this behavior on another machine.
Security updates are available but don't get installed automatically as
the configuration option claims, nor are updates signaled to the user.
--
security updates not installed daily as configured
https:/
Did you follow README.debian and issued the following to create the user?:
#su - postgres -c "createuser --createdb --no-createrole --pwprompt openerp"
However #327998 says NOT to createdb ! What to do?
Did you edit /etc/openerp-server.conf and added the password you chose
to the "db_password ="
The README.debian seems in fact to miss point "2. Save the chosen
openerp database user password to /etc/openerp-server.conf" (it goes "0.
1. 3. 4.")
** Description changed:
Binary package hint: openerp-server
- When starting the openerp-server, it is not working.
- I guess it there is a p
Debconf may, during install,
if /etc/openerp-server.conf is not present already,
ask for the name, server and password for the openerp database,
create the user if its a local database and user does not exist, and
and save the details to /etc/openerp-server.conf.
--
server can not start
Public bug reported:
Binary package hint: openerp-server
README.debian says:
* openerp-server in the upstreams configuration listens by default to *all*
interfaces. For security reasons, we do restrict it in the Debian packages
to listen only on localhost. If you need to change this, ed
** Summary changed:
- server can not start after install
+ server can not start after package is installed
--
server can not start after package is installed
https://bugs.launchpad.net/bugs/528006
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
The createuser line mentioned in README.debian (and any debconf
configuration should probably also contain "--no-superuser", to not make
crateuser prompt for that decision. (The openerp user does not need to
be able to mess with the whole postgres setup.)
--
server can not start after package is
Public bug reported:
Binary package hint: openerp-server
README.debian advices to create an openerp database user like this:
#su - postgres -c "createuser --createdb --no-createrole --pwprompt
openerp"
However this advice (and any debconf postinst configuration should
probably also contain the
** Description changed:
Original Report (also confirmed with 9.10 and 10.04 beta1):
On a freshly installed ubuntu-7.10-alternate, with latest apt-get
update.
When the 'mdadm' package is installed, the system fails to boot
successfully, and ends up at the initrd '(busybox)' prompt.
You could check #158918 and mark this a duplicate if appropriate.
--
Installing mdadm renders lucid desktop unbootable
https://bugs.launchpad.net/bugs/591696
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ub
May this be Bug #469574 or Bug #532960 ? They have workarounds.
--
if array is given a name, a strange inactive md device appears instead of the
one created upon reboot
https://bugs.launchpad.net/bugs/576147
You received this bug notification because you are a member of Ubuntu
Bugs, which is sub
Michel, I don't understand how that could explain why some users are not
notified with the "download all in background" option.
The boxes that show pending security updates when manually opening
update-manager even though "install security updates without
confirmation" has been configured actually
Micheal of course, sorry.
> I can confirm the lucid behavior of no update notification with auto
security updates enabled on a fresh install.
That looks like a separate issue, though.
--
security updates not installed daily as configured
https://bugs.launchpad.net/bugs/549217
You received this
You searched the wiki for "offline update"?
--
Ubuntu should provide update packages for download and use for offline users
https://bugs.launchpad.net/bugs/572776
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing li
Beware of old superblocks, getting available again when (re-)creating
partitions. Superblocks stay on the disks if you don't "mdadm --zero-
superblock" the partition, prior to deleting the partition from the
partition table.
--
Mdadm array fails to assemble on boot.
https://bugs.launchpad.net/bug
Since we have to consider mdadm/raid as not maintained in ubuntu, maybe
check other bug reports to see if their workarounds may help for this
case.
--
Mdadm array fails to assemble on boot.
https://bugs.launchpad.net/bugs/573477
You received this bug notification because you are a member of Ubunt
This is simpy an unneeded and adverse option enabled in the default
kernel configuration. Not much to to with upstream.
** Tags added: kernel-config
** Tags removed: kernel-series-unknown kj-triage needs-kernel-logs
needs-upstream-testing
--
enabled kernel raid autodetection disturbs udev/mdad
** Description changed:
+ Ubuntu still uses the kernel option
+ CONFIG_MD_AUTODETECT=y
+ thus enables the kernel's RAID autodetection during boot.
- Ubuntu's current kernel option
- CONFIG_MD_AUTODETECT=y
- enables the kernel's RAID autodetection during boot.
-
- Aside from causing a delay for
The boot loader really needs provide some more verbose output to give
any hints of what it's trying to do and may go wrong.
** Summary changed:
- "Grub loading." takes very long
+ "Grub loading." raid1 rootfs takes very long
--
"Grub loading." raid1 rootfs takes very long
https://bugs.launchpad
There doesn't seem anything special to be necessary to reproduce.
Maybe it's the usage pattern. The computers are usually not running for
more then 2-3 hours at at time, then shut down until next boot.
Konstantin does not get any out of the box notifications of security updates.
Original reporter
Please get the PPA fix for this crash bug into the lucid release.
--
[MASTER] Lucid 2.6.32-16 crashed to login screen - miCopyRegion
https://bugs.launchpad.net/bugs/539772
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs m
Coz: So other distros dont't take ages to detect your disks?
Maybe the boot option "raid=noautodetect" helps in you case? Bug #551719
--
disk detection is real slow with some hardware (timout shell drops)
https://bugs.launchpad.net/bugs/278176
You received this bug notification because you are a
** Summary changed:
- enabled kernel raid autodetection disturbs udev/mdadm (initramfs & later)
+ boot delay and udev/mdadm disturbance (obsolete kernel raid autodetection)
--
boot delay and udev/mdadm disturbance (obsolete kernel raid autodetection)
https://bugs.launchpad.net/bugs/551719
You re
** Changed in: adduser (Ubuntu)
Status: Incomplete => New
** Summary changed:
- adduser silently removes users from groups
+ adduser removes all other ldap users from group
--
adduser removes all other ldap users from group
https://bugs.launchpad.net/bugs/260086
You received this bug
>cryptsetup is event-driven in lucid.
good news!
including in initramfs?
can you tell if "cryptsetup isLuks" correctly reports false for luks on
raid members?
(or with what test command can I tell? This gives me nothing:
r...@localhost:~# cryptsetup isLuks /dev/hda7
r...@localhost:~#
)
--
brea
** Summary changed:
- mdadm degrades all arrays (from initramfs) instead of just those required to
boot
+ initramfs' mdadm degrades all arrays (not just those required to boot)
--
initramfs' mdadm degrades all arrays (not just those required to boot)
https://bugs.launchpad.net/bugs/497186
You r
** Description changed:
Binary package hint: mdadm
-
- It is said that the intrepid fix to Bug #120375 added support to mdadm and
initramfs-tools for configurable booting degraded RAIDs, but a systems with
/home on a degraded array doesn't come up.
+ It is said that the intrepid fix to Bug
On https://wiki.ubuntu.com/ReliableRaid See: How would you decide what
device is needed?
Only raids required for the rootfs should be started degraded if they
haven't come up for a while.
(Within the ubuntu hotplug-scheme /usr/share/initramfs-
tools/hooks/cryptroot contains code that may be usefu
** Description changed:
Binary package hint: mdadm
+ after a timeout mdadm in initrams degrades all arrays instead of just
+ those required for the rootfs.
- The dependencies are not checked, it looks into /proc/mdstat and uses "mdadm
--assemble --scan --run".
+ The dependencies are not c
** Summary changed:
- mdadm.conf with explicit ARRAY statements, and HOMEHOST !=any prevents
hotplug autodetection
+ mdadm.conf created with explicit ARRAY statements, and HOMEHOST !=any
prevents hotplug autodetection
--
mdadm.conf created with explicit ARRAY statements, and HOMEHOST !=any pre
@SoulWax: Did you follow and use the manual fix of the ubuntuforums link
on https://wiki.ubuntu.com/ReliableRaid ?
Sounds like bug #252345
--
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
This behaviour actually not only breaks the autodetection of (complete)
hot plugged md arrays from another systems, but breaks every array newly
created on ubuntu systems (as ubuntu uses the hotplug scheme) .
For instructions on updating the initramfs refer to:
http://ubuntuforums.org/showthread
** Changed in: mdadm (Ubuntu)
Status: Incomplete => Fix Released
--
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@l
** Summary changed:
- mdadm.conf with explicit ARRAY statements, and HOMEHOST !=any prevents
hotplug setup
+ raid setup fails due to mdadm.conf with explicit ARRAY statements and
HOMEHOST !=any
--
raid setups fail due to mdadm.conf with explicit ARRAY statements and HOMEHOST
!=any
https://bug
** Description changed:
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
The following will recreate a static mdadm.conf (a workaround) but is not a fix
to the issue (disfunctional hotpluging):
# /usr/share/mdadm/mkconf force-generate /etc/mdadm/mdadm.conf
# update-initramfs -k all -u
--
raid setups fail due to mdadm.conf with explicit ARRAY statements and HOMEHOST
I think on hotplug systems mdadm.conf should generally not contain any
specific ARRAY references, maybe it should explicity mention "any" like
this:?
DEVICE
HOMEHOST
ARRAY
This whole bussiness of locking down array assembly (homehost,ARRAY) may
just be due to the historical (suboptimal) mdadm
** Summary changed:
- [karmic] mdadm, initramfs missing ARRAY lines
+ [karmic] mdadm.conf w/o ARRAY lines but udev/mdadm not assembling arrays.
--
[karmic] mdadm.conf w/o ARRAY lines but udev/mdadm not assembling arrays.
https://bugs.launchpad.net/bugs/136252
You received this bug notification
This is a bug with mdadm --incremental not doing hotplug, because it looks for
permission to do so in mdadm.conf.
On hotplug systems mdadm.conf should not have contain any specific references,
maybe it should explicity mention "any" like this:?
DEVICE
HOMEHOST
ARRAY
This whole bussiness o
** Summary changed:
- boot from manually constructed raid1 root fails because of missing hostname
in initramfs
+ boot fails: mdadm not looking for UUIDs but hostname in superblocks
--
boot fails: mdadm not looking for UUIDs but hostname in superblocks
https://bugs.launchpad.net/bugs/226484
Yo
>[cryptsetup] waits for the physical device to be available, decrypts it
as needed, then mounts it. No other event handling is required or
appropriate.
Think of the following example.
As far as I can see cryptsetup in initramfs is not called on the event
that a crypt device appears. It seems cryp
copying this conclusion from #531240 as it rather belongs here
As far as I can see cryptsetup in initramfs is not called on the event that a
crypt device appears. It seems cryptsetup in initramfs is currently rather
linear script driven: the cryptsetup script has its own while loop waiting
** Changed in: mdadm (Ubuntu)
Status: Invalid => Confirmed
--
boot fails: mdadm not looking for UUIDs but hostname in superblocks
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-b
** Summary changed:
- boot impossible due to missing initramfs failure hook integration
+ boot impossible due to missing initramfs failure hook / event driven initramfs
--
boot impossible due to missing initramfs failure hook / event driven initramfs
https://bugs.launchpad.net/bugs/251164
You re
Scott, I put you on here because from your upstart/mountall experience you may
well spot flaws and benefits in the design.
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/251164/comments/15
--
boot impossible due to missing initramfs failure hook / event driven initramfs
https://bugs.l
A (more or less wild) guess why this misreporting may not have surfaced
with any bad effects before:
After booting manually and reassembling the array manually I noticed the
usb disk did fail after a while and was dropped from the array, so it
has become unreliably.
So maybe it is this condition
> ...we should also ship PolicyKit config files that make use of these
groups.
You're tres right, Milan. But you showed already twice "a desktop guy
that actually learned/understands the *nix systems before not breaking
them but hooking in to them" :) Kudos!
--
User Privileges ignored
https://b
New observation: When booting the alternate CD into rescue-mode in a
luks on raid system, it asks passphrases for the raid members instead of
the md device.
Problem: cryptsetup (not beeing udev but boot script driven, and looking
for luks headers on its own?) really needs to be hooked into the eve
** Summary changed:
- blkid reports root raid_member (on usb) as luks, which is booted while raid
remains "inactive"
+ breaking raid: root raid_member opened as luks
--
breaking raid: root raid_member opened as luks
https://bugs.launchpad.net/bugs/531240
You received this bug notification becau
** Description changed:
Binary package hint: util-linux
- I noticed /proc/mdstat reported the root raid as inactive (although the
- system seemed to run fine!).
+ After the member is opened as luks device it is booted instead of the md
+ device, while the raid remains "inactive".
+
+ I first
debian init script has been removed but no upstart job has been created
to start/run necessary regular (non-rootfs) arrays degraded.
--
non-root raids fail to run degraded on boot
https://bugs.launchpad.net/bugs/259145
You received this bug notification because you are a member of Ubuntu
Bugs, wh
9.10
I got an eSATA disk hotpluged now only once with acpiphp, and only when
it was connected after inserting the express card eSATA controller.
Most of the times it did not work. I notice an eSATA disk gets
disconnected when connecting an USB disk, I added comments about what
worked an what not
Thanks for the hint mlx, I could see that the express card is present after
boot and disappears when removed. I mistakenly confused the internal SATA
controller with the express card because it seems to be made of the same
chipset.
lspci
00:00.0 Host bridge: ATI Technologies Inc RS480 Host Bri
For me (on 9.10) the issue with group dirs resolved to be an issue with
the list view not showing all emblems.
I have no idea why you are not seeing the correct emblems for non
writeable dirs. (even though a lock may suggest you can not even enter
the dir)
But I can confirm that dirs owned by ano
** Description changed:
Binary package hint: nautilus
9.10: Nautilus 2.28.1
In the list view the difference in permissions does not result in
appropriate icon differences. (only one emblem is shown)
- A lock is shown (suggesting heavy access restriction but meaning "read-
- only",
** Description changed:
Binary package hint: nautilus
9.10: Nautilus 2.28.1
In the list view the difference in permissions does not result in
appropriate icon differences. (only one emblem is shown)
i.e. in the case below a lock emblem is shown but the X emblem for
inaccessibl
Found that in #371434, maybe it can help some of you:
>Would the subscribers of this bug please try booting with kcmdline
pciehp.pciehp_force=0 and then "sudo modprobe acpiphp" ?
--
JMicron internal card reader recognizes SD only when inserted at startup
https://bugs.launchpad.net/bugs/258446
Yo
The eSATA hotpluging seems to work regulary after booting with the
express card inserted, but as described the express card hotpluging is
messed up.
--
PCI ExpressCard hotplug requires pciehp.pciehp_force=1
https://bugs.launchpad.net/bugs/371434
You received this bug notification because you are
can you identify this with Bug #527401 maybe?
why should this be invalid in lucid (grub2 also)?
--
karmic server 64 bit installer fails at GRUB when installing with RAID1
https://bugs.launchpad.net/bugs/485604
You received this bug notification because you are a member of Ubuntu
Bugs, which is su
is this 10.04?
https://wiki.ubuntu.com/ReliableRaid
--
GRUB2 boots from raid1 device only after "grub rescue> insmod linux" +
"rescue:grub> normal"
https://bugs.launchpad.net/bugs/493268
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Intented to mark ths as fixed for newer release (lucid) in launchpad but
could not do it.
--
RAID1 data-checks cause CPU soft lockups
https://bugs.launchpad.net/bugs/212684
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
** Changed in: mdadm (Ubuntu)
Status: New => Confirmed
--
mdadm monitor feature broken, not depending on local MTA/MDA or using
wall/notify-send
https://bugs.launchpad.net/bugs/535417
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu
Public bug reported:
Binary package hint: debian-installer
Install fails with debian installer complainig about not finding a
common cdrom drive.
A module missing on CD?
The machine has a regular ide (pata) combo drive that works fine with the 9.10
alternate installer.
(For hardware specs see
** Attachment added: "BootDmesg.txt"
http://launchpadlibrarian.net/41884605/BootDmesg.txt
** Attachment added: "CurrentDmesg.txt"
http://launchpadlibrarian.net/41884606/CurrentDmesg.txt
** Attachment added: "DiskUsage.txt"
http://launchpadlibrarian.net/41884607/DiskUsage.txt
** Attachm
Here /boot is on /dev/md0 (raid1), the installer installed grub2 into sda and
sdb, and I am seeing the huge delay.
Grub2 finds /boot always/never to be on the same drive?
Does the proposed patch fix the delay in this case?
** Changed in: grub2 (Ubuntu)
Status: Fix Released => In Progress
** Summary changed:
- pam_umask.so missing in common-session
+ pam_umask.so missing in common-account
--
pam_umask.so missing in common-account
https://bugs.launchpad.net/bugs/253096
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
u
** Description changed:
+ The pam_umask.so module determines the umask (from system and user
+ config files) and sets it for users accordingly.
- pam_umask.so determines the umask (from system and user config files (see man
page)) and sets it accordingly.
+ The umask itself should not be set i
** Description changed:
The pam_umask.so module determines the umask (from system and user
config files) and sets it for users accordingly.
+ from /etc/login.defs:
+ # the use of pam_umask is recommended as the solution which
+ # catches all these cases on PAM-enabled systems.
+
The umas
forget comment #7
Properly fixing this issue of no central, consistent and tunable umask
setting in debian and ubuntu systems is now only a matter of adding the
line "session optional pam_umask.so usergroups" to /etc/pam.d/common-
account.
Thanks to pam_umask and its inclusion, and the all the ef
** Description changed:
Current behaviour is:
- The "users" group exists but when setting up a (set group ID) groupdirectory
(i.e. /home/group/users) it does not work as expected, because the users group
is not populated (empty).
+ The "users" group exists but is not populated (empty). When s
** Description changed:
+ This is broken behavior (bug not wish).
+
Current behaviour is:
The "users" group exists but is not populated (empty). When setting up a
(set group ID) group directory (i.e. /home/group/users) users can not
collaborate on files in that directory.
- Changed beha
Could you consider the adduser patch for building packages that can be
tested/used (independently from g-s-t)?
--
patch: makes adduser.conf a symlink to a profile (provides switchable profile
feature to all frontends)
https://bugs.launchpad.net/bugs/489136
You received this bug notification beca
As this problem was introduced by commenting out EXTRA_GROUPS in
adduser.conf completely instead of just removing the device groups
handled by g-s-t, please set importance back to "bug".
--
users are not added to "users" group
https://bugs.launchpad.net/bugs/253103
You received this bug notificat
Public bug reported:
Binary package hint: gnome-system-tools
Current behaviour is:
The "users" group exists but is not populated (empty). When setting up a (set
group ID) group directory (i.e. /home/group/users) users can not collaborate on
files in that directory.
As long as g-s-t is overridi
*** This bug is a duplicate of bug 549117 ***
https://bugs.launchpad.net/bugs/549117
Attaching a simple patch that targets adduser. Please consider it for
quick inclusion for the next release to stop creating broken user
accounts.
* Re-enables EXTRA_GROUPS="users".
* Its not proposing a new b
Public bug reported:
Binary package hint: adduser
Current behaviour is:
The "users" group exists but is not populated (empty). When setting up a (set
group ID) group directory (i.e. /home/group/users) users can not collaborate on
files in that directory.
(This was originally broken because gno
701 - 800 of 1101 matches
Mail list logo
