[Bug 48734] Re: Home permissions too open
Just two things that are broken with DIR_MODE=0750 (Which are still perfectly supported with the proof-of-concept lock-down plus improved-usability script from last the post. Independently from the additional group directories that it introduces.) * samba usershares * ~/public_html -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/48734 Title: Home permissions too open To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 48734] Re: Home permissions too open
--- Avoiding the caveat of "this does not work"? --- You may just not have thought yet of this solution that can be implemented with little adjustment: ( Privacy by default? YES, even with improved usability! ) Here is a trial script: https://salsa.debian.org/freedombox-team/freedombox/-/snippets/518 The privacy by default solution goes along these lines: * Simply let $HOME point to /home//public_html * /home//incoming * /home/group/users/ * /home/group/admin/private * /home/group/admin/incoming These kind of different problems just need to be seen and solved together. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/48734 Title: Home permissions too open To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/48734/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1888632] Re: sct doesn't reduce colour temperature on second monitor (Ubuntu 20.04 LTS)
Among other things the fork? at https://github.com/faf0/sct claims to "iterate over all screens of the default display and change the color temperature". -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1888632 Title: sct doesn't reduce colour temperature on second monitor (Ubuntu 20.04 LTS) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/setcolortemperature/+bug/1888632/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 820895] Re: no way to log network connections and traffic of applications (processes)
This report does not need any logs attatched to be complete and confirmed. ** Changed in: linux (Ubuntu) Status: Incomplete = Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/820895 Title: no way to log network connections and traffic of applications (processes) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/820895/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 872220] Re: Fails to boot when there's problems with softraid
@Marcus Overhagen: Thanks for your message. You may update the ReliableRaid wiki page. I found it worthwhile that I migrated my raid systems to debian, now I am doing the same with the debian desktop howto, and welcoming the debian tanglu project. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/872220 Title: Fails to boot when there's problems with softraid To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/872220/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1166086] [NEW] raid assembly can break into divergent parts with conflicting changes
Public bug reported: Consider a laptop with a raid setup that consists of one internal disk and a second external disk that resides in the laptops docking station. Undocking the laptop during operation, causes the raid to switch into degraded operation and the laptop is turned off afterwards. Back in the office, the laptop gets mounted in the dock and is switched on. The hardware setup is such that the disk in the docking station is found first. Mdadm --incremental sets up the raid device with the external disk (the internal disk is refused by --incremental or may have been ejected). Because the raid does not come up completely, the raid device is then started in degraded mode with only the external disk. We now have two divergent parts of the same raid device. The machine runns with the old disk state as of the undocking of the laptop. All changes made during the undocked state have been saved to the internal disks, but they are not used now. New changes will only be written to the external disk. Suggested Fix: Store the state of the event counter at the time of the degradation for each missing device in the superblocks on the remaining member devices. --incremental should continue to (re)add a device automatically (only) if the event count shows the state of the new member device that is to be (re)added is equal or older than at the time the device failed. When the incrementally assembled raid device is already running in the (auto) read only state from an device that had failed earlier, attempt to switch to the newer state of the added device, if that device correctly describes the failed state of the older device (older device event counter is equal or older than at the time it failed). Otherwise, abort and print an error message that the devices contain conflicting changes. ** Affects: mdadm (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1166086 Title: raid assembly can break into divergent parts with conflicting changes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1166086/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1088532] Re: pluging in a missing raid member does not (re)add it to array
** Description changed: 12.04.1 regression (worked before, maybe without the mentioned safety check, but it worked) + + Depends on: Bug #1166086 (re-add refers to speeding up the sync using a bitmap) The --incremental (udev) call refuses to (re)add a temporarily diconnected member back to an already restarted (active) raid. (Even thought the event count clearly shows its state is equal or older than at the time the array was started (run) degraded.) This seems to have come by an attempt to fix bug #557429, without considering the discussion bejond comment 68 https://bugs.launchpad.net/mdadm/+bug/557429/comments/68 And when attempting to do it manually: # mdadm /dev/md2 --re-add /dev/sda6 mdadm: --re-add for /dev/sda6 to /dev/md2 is not possible (missing info: bacause the array has no write intent bitmap) # mdadm /dev/md2 --add /dev/sda6 mdadm: /dev/sda6 reports being an active member for /dev/md2, but a --re-add fails. mdadm: not performing --add as that would convert /dev/sda6 in to a spare. mdadm: To make this a spare, use mdadm --zero-superblock /dev/sda6 first. This is not how things are supposed to work in times of hotpluging. A warning/question if the device that is to be added contains newer data - than at its time of failure is appropriate, but otherwise, get the job - of adding that device back to its raid done! + than at its time of failure is appropriate and very important Bug + #1166086, but otherwise, get the job of adding that device back to its + raid done! To avoid regression: - Let the mdadm --incremental command (re)add members to running arrays automatically again. Not doing so does not guard against running from alternating (diverging) parts of an array anyway (if the devices come up in random order, the both parts get started degraded, when they come up first). - - True fix to prevent diverging array parts: - Store the state of the event counter at the time of the degradation for each missing device in the superblocks on the remaining member devices. - --incremental should continue to (re)add a device automatically (only) if the event count shows the state of the member device that is to be (re)added is equal or older than at the time the device failed. (Otherwise, abort and print an error message that the device contains conflicting changes.) + Let the mdadm --incremental command (re)add members to running arrays automatically again. Not doing so does not guard against running from alternating (diverging) parts of an array anyway (if the devices come up in random order, the both parts get started degraded, when they come up first Bug #1166086), but at least it prevents overwriting on version with the other. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1088532 Title: pluging in a missing raid member does not (re)add it to array To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1088532/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 320638] Re: hot-add/remove in mixed (IDE/SATA/USB/SD-card/...) RAIDs with device mapper on top = data corruption (bio too big device md0 (248 240))
I don't know, how it behaves with USB3. Same data corruption as well, unfortunately. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/320638 Title: hot-add/remove in mixed (IDE/SATA/USB/SD-card/...) RAIDs with device mapper on top = data corruption (bio too big device md0 (248 240)) To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/320638/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 320638] Re: hot-add/remove in mixed (IDE/SATA/USB/SD-card/...) RAIDs with device mapper on top = data corruption (bio too big device md0 (248 240))
** Description changed: Problem: md changes max_sector setting of an already running and busy md device, when a (hotplugable) device is added or removed. However, the device mapper and filesystem layer on top of the raid can not (always?) cope with that. Observations: * bio too big device mdX (248 240) messages in the syslog * read/write errors (some dropped silently, no noticable errors reported during operation, until things like dhcpclient looses its IP etc.) Expected: Adding and removing members to running raids (hotplugging) should not change the raid device characteristics. If the new member supports only smaller max_sector values, buffer and split the data steam, until the raid device can be set up from a clean state with a more appropriate max_sector value. To avoid buffering and splitting in the future, md could save the smallest max_sector value of the known members in the superblock, and use that when setting up the raid even if that member is not present. - Note: This is reproducible in much more common scenarios as the original reporter had (e.g. --add a USB (3.0 these days) drive to an already running SATA raid1 and grow the number of devices). + Note: This is reproducible in much more common scenarios as the original + reporter had (e.g. --add a USB (3.0 these days) drive to an already + running SATA raid1 and grow the number of devices). + + Fix: + Upsteam has no formal bug tracking, but a mailing list. The response was that finally this needs to be fixed [outside of mdadm] by cleaning up the bio path so that big bios are split by the device that needs the split, not be the fs sending the bio. + + However, in the meantime mdadm needs to saveguard against the date + corruption: + + [The mdadm] fix is to reject the added device [if] its limits are + too low. + + Good Idea to avoid the data corruption. MD could save the + max_sectors default limit for arrays. If the array is modified and the new + limit gets smaller, postpone the sync until the next assembe/restart. + + And of course print a message if postponing, that explains when --force would be save. + What ever that would be: no block device abstraction layer (device mapper, lvm, luks,...) + between an unmounted? ext, fat?, ...? filesystem and md? + + As upsteam does not do public bug tracking, the status and rememberence + of this need remains unsure though. + + --- This is on a MSI Wind U100 and I've got the following stack running: HDD SD card (USB card reader) - RAID1 - LUKS - LVM - Reiser Whenever I remove the HDD from the Raid1 mdadm /dev/md0 --fail /dev/sda2 mdadm /dev/md0 --remove /dev/sda2) for powersaving reasons, I cannot run any apt related tools. sudo apt-get update [...] Hit http://de.archive.ubuntu.com intrepid-updates/multiverse Sources Reading package lists... Error! E: Read error - read (5 Input/output error) E: The package lists or status file could not be parsed or opened. Taking a look at the kernel log shows (and many more above): dmesg|tail [ 9479.330550] bio too big device md0 (248 240) [ 9479.331375] bio too big device md0 (248 240) [ 9479.332182] bio too big device md0 (248 240) [ 9611.980294] bio too big device md0 (248 240) [ 9742.929761] bio too big device md0 (248 240) [ 9852.932001] bio too big device md0 (248 240) [ 9852.935395] bio too big device md0 (248 240) [ 9852.938064] bio too big device md0 (248 240) [ 9853.081046] bio too big device md0 (248 240) [ 9853.081688] bio too big device md0 (248 240) $ sudo mdadm --detail /dev/md0 /dev/md0: Version : 00.90 Creation Time : Tue Jan 13 11:25:57 2009 Raid Level : raid1 Array Size : 3871552 (3.69 GiB 3.96 GB) Used Dev Size : 3871552 (3.69 GiB 3.96 GB) Raid Devices : 2 Total Devices : 1 Preferred Minor : 0 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Fri Jan 23 21:47:35 2009 State : active, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 0 Spare Devices : 0 UUID : 89863068:bc52a0c0:44a5346e:9d69deca (local to host m-twain) Events : 0.8767 Number Major Minor RaidDevice State 0 000 removed 1 8 171 active sync writemostly /dev/sdb1 $ sudo ubuntu-bug -p linux-meta dpkg-query: failed in buffer_read(fd): copy info file `/var/lib/dpkg/status': Input/output error dpkg-query: failed in buffer_read(fd): copy info file `/var/lib/dpkg/status': Input/output error [...] Will provide separate attachements. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/320638 Title: hot-add/remove in mixed (IDE/SATA/USB/SD-card/...) RAIDs with device mapper on top = data
[Bug 1088532] Re: pluging in a missing raid member does not (re)add it to array
** Description changed: 12.04.1 regression (worked before, maybe without the mentioned safety check, but it worked) (re-add refers to speeding up the sync using a bitmap) The --incremental (udev) call refuses to (re)add a temporarily diconnected member back to an already restarted (active) raid. (Even thought the event count clearly shows its state is equal or older than at the time the array was started (run) degraded.) This seems to have come by an attempt to fix bug #557429, without considering the discussion bejond comment 68 https://bugs.launchpad.net/mdadm/+bug/557429/comments/68 - And when attempting to do it manually: # mdadm /dev/md2 --re-add /dev/sda6 mdadm: --re-add for /dev/sda6 to /dev/md2 is not possible (missing info: bacause the array has no write intent bitmap) # mdadm /dev/md2 --add /dev/sda6 mdadm: /dev/sda6 reports being an active member for /dev/md2, but a --re-add fails. mdadm: not performing --add as that would convert /dev/sda6 in to a spare. mdadm: To make this a spare, use mdadm --zero-superblock /dev/sda6 first. - This is not how things are supposed to work in times of hotpluging. A warning/question if the device that is to be added contains newer data than at its time of failure is appropriate, but otherwise, get the job of adding that device back to its raid done! + To avoid regression: + Let the mdadm --incremental command (re)add members to running arrays again. Not doing so does not guard against running from alternating (diverging) parts of an array anyway (if they come up in random order). - To avoid regression: - Let --incremental (re)add members to running array again. Not doing so does not guard against running from alternating parts of an array anyway (if they come up in random order). - - True fix: + True fix to prevent diverging array parts: Store the state of the event counter at the time of degradation in the superblock. - --incremental should continue to (re)add a device if the event count shows its state is equal or older than at the time the array degraded. + --incremental should continue to (re)add a device automatically (only) if the event count shows the state of the member device that is to be (re)added is equal or older than at the time the array degraded. (Otherwise, fail and print an error message that the device contains conflicting changes.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1088532 Title: pluging in a missing raid member does not (re)add it to array To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1088532/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1088532] Re: pluging in a missing raid member does not (re)add it to array
** Description changed: 12.04.1 regression (worked before, maybe without the mentioned safety check, but it worked) (re-add refers to speeding up the sync using a bitmap) The --incremental (udev) call refuses to (re)add a temporarily diconnected member back to an already restarted (active) raid. (Even thought the event count clearly shows its state is equal or older than at the time the array was started (run) degraded.) This seems to have come by an attempt to fix bug #557429, without considering the discussion bejond comment 68 https://bugs.launchpad.net/mdadm/+bug/557429/comments/68 And when attempting to do it manually: # mdadm /dev/md2 --re-add /dev/sda6 mdadm: --re-add for /dev/sda6 to /dev/md2 is not possible (missing info: bacause the array has no write intent bitmap) # mdadm /dev/md2 --add /dev/sda6 mdadm: /dev/sda6 reports being an active member for /dev/md2, but a --re-add fails. mdadm: not performing --add as that would convert /dev/sda6 in to a spare. mdadm: To make this a spare, use mdadm --zero-superblock /dev/sda6 first. This is not how things are supposed to work in times of hotpluging. A warning/question if the device that is to be added contains newer data than at its time of failure is appropriate, but otherwise, get the job of adding that device back to its raid done! To avoid regression: Let the mdadm --incremental command (re)add members to running arrays again. Not doing so does not guard against running from alternating (diverging) parts of an array anyway (if they come up in random order). True fix to prevent diverging array parts: - Store the state of the event counter at the time of degradation in the superblock. + Store the state of the event counter at the time of the degradation for each degraded device in the superblocks on the remaining member devices. --incremental should continue to (re)add a device automatically (only) if the event count shows the state of the member device that is to be (re)added is equal or older than at the time the array degraded. (Otherwise, fail and print an error message that the device contains conflicting changes.) ** Description changed: 12.04.1 regression (worked before, maybe without the mentioned safety check, but it worked) (re-add refers to speeding up the sync using a bitmap) The --incremental (udev) call refuses to (re)add a temporarily diconnected member back to an already restarted (active) raid. (Even thought the event count clearly shows its state is equal or older than at the time the array was started (run) degraded.) This seems to have come by an attempt to fix bug #557429, without considering the discussion bejond comment 68 https://bugs.launchpad.net/mdadm/+bug/557429/comments/68 And when attempting to do it manually: # mdadm /dev/md2 --re-add /dev/sda6 mdadm: --re-add for /dev/sda6 to /dev/md2 is not possible (missing info: bacause the array has no write intent bitmap) # mdadm /dev/md2 --add /dev/sda6 mdadm: /dev/sda6 reports being an active member for /dev/md2, but a --re-add fails. mdadm: not performing --add as that would convert /dev/sda6 in to a spare. mdadm: To make this a spare, use mdadm --zero-superblock /dev/sda6 first. This is not how things are supposed to work in times of hotpluging. A warning/question if the device that is to be added contains newer data than at its time of failure is appropriate, but otherwise, get the job of adding that device back to its raid done! To avoid regression: - Let the mdadm --incremental command (re)add members to running arrays again. Not doing so does not guard against running from alternating (diverging) parts of an array anyway (if they come up in random order). + Let the mdadm --incremental command (re)add members to running arrays automatically again. Not doing so does not guard against running from alternating (diverging) parts of an array anyway (if the devices come up in random order, the both parts get started degraded, when they come up first). True fix to prevent diverging array parts: - Store the state of the event counter at the time of the degradation for each degraded device in the superblocks on the remaining member devices. + Store the state of the event counter at the time of the degradation for each missing device in the superblocks on the remaining member devices. --incremental should continue to (re)add a device automatically (only) if the event count shows the state of the member device that is to be (re)added is equal or older than at the time the array degraded. (Otherwise, fail and print an error message that the device contains conflicting changes.) ** Description changed: 12.04.1 regression (worked before, maybe without the mentioned safety check, but it worked) (re-add refers to speeding up the sync using a bitmap) The --incremental (udev) call refuses to
[Bug 1043336] Re: Swiss keyboard layout with Apple keyboard (period instead of comma)
No updates, manually setting iso_layout=0 fixed the swapped keys for me, so someone still needs to fix that module. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1043336 Title: Swiss keyboard layout with Apple keyboard (period instead of comma) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1043336/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 268663] Re: files incoming through nautilus-share should be created with user ownership, instead of nobody
** Bug watch added: Debian Bug tracker #678834 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678834 ** Also affects: nautilus-share via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678834 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to samba in Ubuntu. https://bugs.launchpad.net/bugs/268663 Title: files incoming through nautilus-share should be created with user ownership, instead of nobody To manage notifications about this bug go to: https://bugs.launchpad.net/nautilus-share/+bug/268663/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 945117] Re: can't edit files in my public guest allow rw folder
** Bug watch added: Debian Bug tracker #678834 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678834 ** Also affects: samba (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678834 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to samba in Ubuntu. https://bugs.launchpad.net/bugs/945117 Title: can't edit files in my public guest allow rw folder To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/945117/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1099401] [NEW] samba maps guest users to reserved user nobody
Public bug reported: The reserved system user nobody should never be the owner of files. This ensures that an access granted with the least privileged nobody user will never be able to access or even corrupt files on the system. The nobody user may not even be suited for granting public read access, if it is intended to just run unprivileged local deamons. Samba however creates files as the nobody user when samba guests are allowed to create files (e.g. a public share). Expected: Samba gets configured to use an appropriate user id for guests that are able to create files. This may be a samba specific user, e.g. guest user = smbguest to show the origin of the file, together with guest group = users (to which all local users should belong, bug #253103). The latter enables all system users to access/modify/delete the files of smbguest also directly on the filesystem (without going through samba shares that may have been enabled only temporarily). ** Affects: samba (Ubuntu) Importance: Undecided Status: New ** Description changed: - - The reserved system user nobody should never be the owner of files. This ensures that the least privileged nobody user will never be able to access or even corrupt files. This user may not even be suited for granting public read access, if it is intended to just run unprivileged local deamons. + The reserved system user nobody should never be the owner of files. + This ensures that an access granted with the least privileged nobody + user will never be able to access or even corrupt files on the system. + The nobody user may not even be suited for granting public read + access, if it is intended to just run unprivileged local deamons. Samba however creates files as the nobody user when samba guests are allowed to create files (e.g. a public share). Expected: Samba gets configured to use an appropriate user id for guests that are able to create files. This may be a samba specific user, e.g. guest user = smbguest to show the origin of the file, together with guest group = users (to which all local users should belong, bug #253103). The latter enables all system users to access/modify/delete the files of smbguest also directly on the filesystem. ** Description changed: The reserved system user nobody should never be the owner of files. This ensures that an access granted with the least privileged nobody user will never be able to access or even corrupt files on the system. The nobody user may not even be suited for granting public read access, if it is intended to just run unprivileged local deamons. Samba however creates files as the nobody user when samba guests are allowed to create files (e.g. a public share). Expected: - Samba gets configured to use an appropriate user id for guests that are able to create files. This may be a samba specific user, e.g. guest user = smbguest to show the origin of the file, together with guest group = users (to which all local users should belong, bug #253103). The latter enables all system users to access/modify/delete the files of smbguest also directly on the filesystem. + Samba gets configured to use an appropriate user id for guests that are able to create files. This may be a samba specific user, e.g. guest user = smbguest to show the origin of the file, together with guest group = users (to which all local users should belong, bug #253103). The latter enables all system users to access/modify/delete the files of smbguest also directly on the filesystem (without going through samba shares that may have been enabled only temporarily). ** Summary changed: - samba maps guest user to reserved user nobody + samba maps guest users to reserved user nobody -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to samba in Ubuntu. https://bugs.launchpad.net/bugs/1099401 Title: samba maps guest users to reserved user nobody To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1099401/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 268663] Re: files incoming through nautilus-share should be created with user ownership, instead of nobody
** Bug watch added: Debian Bug tracker #678834 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678834 ** Also affects: nautilus-share via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678834 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/268663 Title: files incoming through nautilus-share should be created with user ownership, instead of nobody To manage notifications about this bug go to: https://bugs.launchpad.net/nautilus-share/+bug/268663/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 39717] Re: When guest (nobody) account exists, smbpasswd should default to none
seems fixed after the switch to usershares and usershare allow guests = yes + map to guest = bad user ** Changed in: gnome-system-tools (Ubuntu) Status: Confirmed = Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to the bug report. https://bugs.launchpad.net/bugs/39717 Title: When guest (nobody) account exists, smbpasswd should default to none To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-system-tools/+bug/39717/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 945117] Re: can't edit files in my public guest allow rw folder
** Bug watch added: Debian Bug tracker #678834 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678834 ** Also affects: samba (Debian) via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678834 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/945117 Title: can't edit files in my public guest allow rw folder To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/945117/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1099401] [NEW] samba maps guest users to reserved user nobody
Public bug reported: The reserved system user nobody should never be the owner of files. This ensures that an access granted with the least privileged nobody user will never be able to access or even corrupt files on the system. The nobody user may not even be suited for granting public read access, if it is intended to just run unprivileged local deamons. Samba however creates files as the nobody user when samba guests are allowed to create files (e.g. a public share). Expected: Samba gets configured to use an appropriate user id for guests that are able to create files. This may be a samba specific user, e.g. guest user = smbguest to show the origin of the file, together with guest group = users (to which all local users should belong, bug #253103). The latter enables all system users to access/modify/delete the files of smbguest also directly on the filesystem (without going through samba shares that may have been enabled only temporarily). ** Affects: samba (Ubuntu) Importance: Undecided Status: New ** Description changed: - - The reserved system user nobody should never be the owner of files. This ensures that the least privileged nobody user will never be able to access or even corrupt files. This user may not even be suited for granting public read access, if it is intended to just run unprivileged local deamons. + The reserved system user nobody should never be the owner of files. + This ensures that an access granted with the least privileged nobody + user will never be able to access or even corrupt files on the system. + The nobody user may not even be suited for granting public read + access, if it is intended to just run unprivileged local deamons. Samba however creates files as the nobody user when samba guests are allowed to create files (e.g. a public share). Expected: Samba gets configured to use an appropriate user id for guests that are able to create files. This may be a samba specific user, e.g. guest user = smbguest to show the origin of the file, together with guest group = users (to which all local users should belong, bug #253103). The latter enables all system users to access/modify/delete the files of smbguest also directly on the filesystem. ** Description changed: The reserved system user nobody should never be the owner of files. This ensures that an access granted with the least privileged nobody user will never be able to access or even corrupt files on the system. The nobody user may not even be suited for granting public read access, if it is intended to just run unprivileged local deamons. Samba however creates files as the nobody user when samba guests are allowed to create files (e.g. a public share). Expected: - Samba gets configured to use an appropriate user id for guests that are able to create files. This may be a samba specific user, e.g. guest user = smbguest to show the origin of the file, together with guest group = users (to which all local users should belong, bug #253103). The latter enables all system users to access/modify/delete the files of smbguest also directly on the filesystem. + Samba gets configured to use an appropriate user id for guests that are able to create files. This may be a samba specific user, e.g. guest user = smbguest to show the origin of the file, together with guest group = users (to which all local users should belong, bug #253103). The latter enables all system users to access/modify/delete the files of smbguest also directly on the filesystem (without going through samba shares that may have been enabled only temporarily). ** Summary changed: - samba maps guest user to reserved user nobody + samba maps guest users to reserved user nobody -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1099401 Title: samba maps guest users to reserved user nobody To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1099401/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 253103] Re: users are not added to users group
*** This bug is a duplicate of bug 549117 *** https://bugs.launchpad.net/bugs/549117 ** Tags added: patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/253103 Title: users are not added to users group To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/253103/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 371434] Re: PCI ExpressCard hotplug requires pciehp.pciehp_force=1
What is the problem with this bug, that module acpiphp has still not been enabled by default in ubuntu since 2009? ** Changed in: linux (Ubuntu) Status: Incomplete = Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/371434 Title: PCI ExpressCard hotplug requires pciehp.pciehp_force=1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/371434/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 320638] Re: hot-add/remove in mixed (IDE/SATA/USB/SD-card/...) RAIDs with device mapper on top = data corruption (bio too big device md0 (248 240))
** Description changed: - Note: Bug is also present when hot-plugging USB, Firewire etc. devices. + Problem: md changes max_sector setting of an already running and busy md + device, when a (hotplugable) device is added or removed. However, the a + device mapper and filesystem layer on top of the raid can not (always?) + cope with that. - Also reproducable in much more common usage as originally reported (e.g. --add a USB (3.0 these days) drive to an already running SATA raid1 and grow the number of devices). + Observations: + * bio too big device mdX (248 240) messages in the syslog + * read/write errors (some dropped silently, no noticable errors reported during operation, until things like dhcpclient looses its IP etc.) + + Expected: + Adding and removing members to running raids (hotplugging) does not change the raid device characteristics. If the new member supports only smaller max_sector values, buffer and split the data steam, until the raid device can be set up from a clean state with a more appropriate max_sector value. To avoid buffering and splitting in the future, md could save the smallest max_sector value of the known members in the superblock, and use that when setting up the raid even if that member is not present. + + + Note: This is reproducible in much more common scenarios as the original reporter had (e.g. --add a USB (3.0 these days) drive to an already running SATA raid1 and grow the number of devices). --- This is on a MSI Wind U100 and I've got the following stack running: HDD SD card (USB card reader) - RAID1 - LUKS - LVM - Reiser Whenever I remove the HDD from the Raid1 mdadm /dev/md0 --fail /dev/sda2 mdadm /dev/md0 --remove /dev/sda2) for powersaving reasons, I cannot run any apt related tools. sudo apt-get update [...] Hit http://de.archive.ubuntu.com intrepid-updates/multiverse Sources Reading package lists... Error! E: Read error - read (5 Input/output error) E: The package lists or status file could not be parsed or opened. Taking a look at the kernel log shows (and many more above): dmesg|tail [ 9479.330550] bio too big device md0 (248 240) [ 9479.331375] bio too big device md0 (248 240) [ 9479.332182] bio too big device md0 (248 240) [ 9611.980294] bio too big device md0 (248 240) [ 9742.929761] bio too big device md0 (248 240) [ 9852.932001] bio too big device md0 (248 240) [ 9852.935395] bio too big device md0 (248 240) [ 9852.938064] bio too big device md0 (248 240) [ 9853.081046] bio too big device md0 (248 240) [ 9853.081688] bio too big device md0 (248 240) $ sudo mdadm --detail /dev/md0 /dev/md0: Version : 00.90 Creation Time : Tue Jan 13 11:25:57 2009 Raid Level : raid1 Array Size : 3871552 (3.69 GiB 3.96 GB) Used Dev Size : 3871552 (3.69 GiB 3.96 GB) Raid Devices : 2 Total Devices : 1 Preferred Minor : 0 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Fri Jan 23 21:47:35 2009 State : active, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 0 Spare Devices : 0 UUID : 89863068:bc52a0c0:44a5346e:9d69deca (local to host m-twain) Events : 0.8767 Number Major Minor RaidDevice State 0 000 removed 1 8 171 active sync writemostly /dev/sdb1 $ sudo ubuntu-bug -p linux-meta dpkg-query: failed in buffer_read(fd): copy info file `/var/lib/dpkg/status': Input/output error dpkg-query: failed in buffer_read(fd): copy info file `/var/lib/dpkg/status': Input/output error [...] Will provide separate attachements. ** Description changed: Problem: md changes max_sector setting of an already running and busy md - device, when a (hotplugable) device is added or removed. However, the a + device, when a (hotplugable) device is added or removed. However, the device mapper and filesystem layer on top of the raid can not (always?) cope with that. Observations: * bio too big device mdX (248 240) messages in the syslog * read/write errors (some dropped silently, no noticable errors reported during operation, until things like dhcpclient looses its IP etc.) Expected: Adding and removing members to running raids (hotplugging) does not change the raid device characteristics. If the new member supports only smaller max_sector values, buffer and split the data steam, until the raid device can be set up from a clean state with a more appropriate max_sector value. To avoid buffering and splitting in the future, md could save the smallest max_sector value of the known members in the superblock, and use that when setting up the raid even if that member is not present. - Note: This is reproducible in much more common scenarios as the original reporter had (e.g. --add a USB (3.0 these days) drive to an
[Bug 320638] Re: hot-add/remove in mixed (IDE/SATA/USB/SD-card/...) RAIDs with device mapper on top = data corruption (bio too big device md0 (248 240))
** Also affects: mdadm Importance: Undecided Status: New ** Changed in: mdadm Status: New = Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/320638 Title: hot-add/remove in mixed (IDE/SATA/USB/SD-card/...) RAIDs with device mapper on top = data corruption (bio too big device md0 (248 240)) To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/320638/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 320638] Re: Raid1 HDD and SD card - data corruption (bio too big device md0 (248 200))
** Also affects: mdadm (Ubuntu) Importance: Undecided Status: New ** Also affects: debian-installer (Ubuntu) Importance: Undecided Status: New ** Also affects: ubiquity (Ubuntu) Importance: Undecided Status: New ** Description changed: + Note: Bug is also present when hot-plugging USB, Firewire etc. devices. + + --- + This is on a MSI Wind U100 and I've got the following stack running: HDD SD card (USB card reader) - RAID1 - LUKS - LVM - Reiser Whenever I remove the HDD from the Raid1 mdadm /dev/md0 --fail /dev/sda2 - mdadm /dev/md0 --remove /dev/sda2) + mdadm /dev/md0 --remove /dev/sda2) for powersaving reasons, I cannot run any apt related tools. sudo apt-get update [...] Hit http://de.archive.ubuntu.com intrepid-updates/multiverse Sources Reading package lists... Error! E: Read error - read (5 Input/output error) E: The package lists or status file could not be parsed or opened. Taking a look at the kernel log shows (and many more above): dmesg|tail [ 9479.330550] bio too big device md0 (248 240) [ 9479.331375] bio too big device md0 (248 240) [ 9479.332182] bio too big device md0 (248 240) [ 9611.980294] bio too big device md0 (248 240) [ 9742.929761] bio too big device md0 (248 240) [ 9852.932001] bio too big device md0 (248 240) [ 9852.935395] bio too big device md0 (248 240) [ 9852.938064] bio too big device md0 (248 240) [ 9853.081046] bio too big device md0 (248 240) [ 9853.081688] bio too big device md0 (248 240) $ sudo mdadm --detail /dev/md0 /dev/md0: - Version : 00.90 - Creation Time : Tue Jan 13 11:25:57 2009 - Raid Level : raid1 - Array Size : 3871552 (3.69 GiB 3.96 GB) - Used Dev Size : 3871552 (3.69 GiB 3.96 GB) -Raid Devices : 2 - Total Devices : 1 + Version : 00.90 + Creation Time : Tue Jan 13 11:25:57 2009 + Raid Level : raid1 + Array Size : 3871552 (3.69 GiB 3.96 GB) + Used Dev Size : 3871552 (3.69 GiB 3.96 GB) + Raid Devices : 2 + Total Devices : 1 Preferred Minor : 0 - Persistence : Superblock is persistent + Persistence : Superblock is persistent - Intent Bitmap : Internal + Intent Bitmap : Internal - Update Time : Fri Jan 23 21:47:35 2009 - State : active, degraded - Active Devices : 1 + Update Time : Fri Jan 23 21:47:35 2009 + State : active, degraded + Active Devices : 1 Working Devices : 1 - Failed Devices : 0 - Spare Devices : 0 + Failed Devices : 0 + Spare Devices : 0 -UUID : 89863068:bc52a0c0:44a5346e:9d69deca (local to host m-twain) - Events : 0.8767 + UUID : 89863068:bc52a0c0:44a5346e:9d69deca (local to host m-twain) + Events : 0.8767 - Number Major Minor RaidDevice State -0 000 removed -1 8 171 active sync writemostly /dev/sdb1 + Number Major Minor RaidDevice State + 0 000 removed + 1 8 171 active sync writemostly /dev/sdb1 $ sudo ubuntu-bug -p linux-meta - dpkg-query: failed in buffer_read(fd): copy info file `/var/lib/dpkg/status': Input/output error - dpkg-query: failed in buffer_read(fd): copy info file `/var/lib/dpkg/status': Input/output error + dpkg-query: failed in buffer_read(fd): copy info file `/var/lib/dpkg/status': Input/output error + dpkg-query: failed in buffer_read(fd): copy info file `/var/lib/dpkg/status': Input/output error [...] Will provide separate attachements. ** Bug watch added: Debian Bug tracker #624343 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624343 ** Also affects: linux via http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624343 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/320638 Title: hot-add/remove in mixed HDD/USB/SD-card RAIDs - data corruption (bio too big device md0 (248 200)) To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/320638/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 320638] Re: hot-add/remove in mixed HDD/USB/SD-card RAIDs - data corruption (bio too big device md0 (248 200))
** Summary changed: - Raid1 HDD and SD card - data corruption (bio too big device md0 (248 200)) + hot-add/remove in mixed HDD/USB/SD-card RAIDs - data corruption (bio too big device md0 (248 200)) ** Summary changed: - hot-add/remove in mixed HDD/USB/SD-card RAIDs - data corruption (bio too big device md0 (248 200)) + hot-add/remove in mixed (HDD/USB/SD-card/...) RAIDs - data corruption (bio too big device md0 (248 200)) ** Changed in: debian-installer (Ubuntu) Status: New = Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/320638 Title: hot-add/remove in mixed (HDD/USB/SD-card/...) RAIDs - data corruption (bio too big device md0 (248 200)) To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/320638/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 320638] Re: hot-add/remove in mixed (HDD/USB/SD-card/...) RAIDs - data corruption (bio too big device md0 (248 200))
This is a very severe data corrupting bug. Thus, even if the the md devs can not fix the bio abstraction or whatever would be necessary to support mixed interface setups, the md module should definitely have a safeguard and make sure to return a failure on hot add/remove under these circumstances, instead of letting this bug eat it's user's data. ** Changed in: mdadm (Ubuntu) Status: New = Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/320638 Title: hot-add/remove in mixed (HDD/USB/SD-card/...) RAIDs - data corruption (bio too big device md0 (248 200)) To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/320638/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 320638] Re: hot-add/remove in mixed (HDD/USB/SD-card/...) RAIDs with device mapper on top - data corruption (bio too big device md0 (248 200))
** Summary changed: - hot-add/remove in mixed (HDD/USB/SD-card/...) RAIDs - data corruption (bio too big device md0 (248 200)) + hot-add/remove in mixed (HDD/USB/SD-card/...) RAIDs with device mapper on top - data corruption (bio too big device md0 (248 200)) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/320638 Title: hot-add/remove in mixed (HDD/USB/SD-card/...) RAIDs with device mapper on top - data corruption (bio too big device md0 (248 200)) To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/320638/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 320638] Re: hot-add/remove in mixed (HDD/USB/SD-card/...) RAIDs with device mapper on top - data corruption (bio too big device md0 (248 200))
** Description changed: Note: Bug is also present when hot-plugging USB, Firewire etc. devices. + Also reproducable in much more common usage as originally reported (e.g. --add a USB (3.0 these days) drive to an already running SATA raid1 and grow the number of devices). --- This is on a MSI Wind U100 and I've got the following stack running: HDD SD card (USB card reader) - RAID1 - LUKS - LVM - Reiser Whenever I remove the HDD from the Raid1 mdadm /dev/md0 --fail /dev/sda2 mdadm /dev/md0 --remove /dev/sda2) for powersaving reasons, I cannot run any apt related tools. sudo apt-get update [...] Hit http://de.archive.ubuntu.com intrepid-updates/multiverse Sources Reading package lists... Error! E: Read error - read (5 Input/output error) E: The package lists or status file could not be parsed or opened. Taking a look at the kernel log shows (and many more above): dmesg|tail [ 9479.330550] bio too big device md0 (248 240) [ 9479.331375] bio too big device md0 (248 240) [ 9479.332182] bio too big device md0 (248 240) [ 9611.980294] bio too big device md0 (248 240) [ 9742.929761] bio too big device md0 (248 240) [ 9852.932001] bio too big device md0 (248 240) [ 9852.935395] bio too big device md0 (248 240) [ 9852.938064] bio too big device md0 (248 240) [ 9853.081046] bio too big device md0 (248 240) [ 9853.081688] bio too big device md0 (248 240) $ sudo mdadm --detail /dev/md0 /dev/md0: Version : 00.90 Creation Time : Tue Jan 13 11:25:57 2009 Raid Level : raid1 Array Size : 3871552 (3.69 GiB 3.96 GB) Used Dev Size : 3871552 (3.69 GiB 3.96 GB) Raid Devices : 2 Total Devices : 1 Preferred Minor : 0 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Fri Jan 23 21:47:35 2009 State : active, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 0 Spare Devices : 0 UUID : 89863068:bc52a0c0:44a5346e:9d69deca (local to host m-twain) Events : 0.8767 Number Major Minor RaidDevice State 0 000 removed 1 8 171 active sync writemostly /dev/sdb1 $ sudo ubuntu-bug -p linux-meta dpkg-query: failed in buffer_read(fd): copy info file `/var/lib/dpkg/status': Input/output error dpkg-query: failed in buffer_read(fd): copy info file `/var/lib/dpkg/status': Input/output error [...] Will provide separate attachements. ** Summary changed: - hot-add/remove in mixed (HDD/USB/SD-card/...) RAIDs with device mapper on top - data corruption (bio too big device md0 (248 200)) + hot-add/remove in mixed (HDD/USB/SD-card/...) RAIDs with device mapper on top = data corruption (bio too big device md0 (248 240)) ** Summary changed: - hot-add/remove in mixed (HDD/USB/SD-card/...) RAIDs with device mapper on top = data corruption (bio too big device md0 (248 240)) + hot-add/remove in mixed (IDE/SATA/USB/SD-card/...) RAIDs with device mapper on top = data corruption (bio too big device md0 (248 240)) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/320638 Title: hot-add/remove in mixed (IDE/SATA/USB/SD-card/...) RAIDs with device mapper on top = data corruption (bio too big device md0 (248 240)) To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/320638/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1043336] Re: Swiss keyboard layout with Apple keyboard (period instead of comma)
The hid_apple module will have set iso_layout=0 for some locales (all non-US?). ** Changed in: gnome-control-center (Ubuntu) Status: Invalid = Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1043336 Title: Swiss keyboard layout with Apple keyboard (period instead of comma) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1043336/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1043336] Re: Swiss keyboard layout with Apple keyboard (period instead of comma)
set it _automatically_ of course -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1043336 Title: Swiss keyboard layout with Apple keyboard (period instead of comma) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1043336/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 262408] Re: SysRq key equivalent needed
Hello ikus060, could you adapt your patch to provide a configurable parameter as iso_layout and fnmode do? (maybe see the patchwork link from last post for an example) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/262408 Title: SysRq key equivalent needed To manage notifications about this bug go to: https://bugs.launchpad.net/mactel-support/+bug/262408/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 262408] Re: SysRq key equivalent needed
For a full set of keyboard workarounds see https://aur.archlinux.org/packages/un-apple-keyboard . A real fix will require a patches to the hid_apple kernel module that add appropriate parameter options. Additionally, the swapmodifiers option from this patch https://patchwork.kernel.org/patch/10259 to improve the usability of the typical linux keybord modifier combinations. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/262408 Title: SysRq key equivalent needed To manage notifications about this bug go to: https://bugs.launchpad.net/mactel-support/+bug/262408/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 262408] Re: SysRq key equivalent needed
As macbooks do not seem to have F13-F15 keys, also provide some alternatives. For example, map alt-eject to SysRq. scancodes: http://ubuntuforums.org/archive/index.php/t-762665.html -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/262408 Title: SysRq key equivalent needed To manage notifications about this bug go to: https://bugs.launchpad.net/mactel-support/+bug/262408/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1088532] Re: pluging in a missing raid member does not (re)add it to array
** Description changed: 12.04.1 regression (worked before, maybe without the mentioned safety check, but it worked) (re-add refers to speeding up the sync using a bitmap) The --incremental (udev) call refuses to (re)add a temporarily diconnected member back to an already restarted (active) raid. (Even thought the event count clearly shows its state is equal or older than at the time the array was started (run) degraded.) - And manually: + This seems to have come by an attempt to fix bug #557429, without considering the discussion bejond comment 68 + https://bugs.launchpad.net/mdadm/+bug/557429/comments/68 + + + And when attempting to do it manually: # mdadm /dev/md2 --re-add /dev/sda6 mdadm: --re-add for /dev/sda6 to /dev/md2 is not possible + (missing info: bacause the array has no write intent bitmap) # mdadm /dev/md2 --add /dev/sda6 mdadm: /dev/sda6 reports being an active member for /dev/md2, but a --re-add fails. mdadm: not performing --add as that would convert /dev/sda6 in to a spare. mdadm: To make this a spare, use mdadm --zero-superblock /dev/sda6 first. + This is not how things are supposed to work in times of hotpluging. A warning/question if the device that is to be added contains newer data than at its time of failure is appropriate, but otherwise, get the job of adding that device back to its raid done! + + + To avoid regression: + Let --incremental (re)add members to running array again. Not doing so does not guard against running from alternating parts of an array anyway (if they come up in random order). + + True fix: + Store the state of the event counter at the time of degradation in the superblock. + --incremental should continue to (re)add a device if the event count shows its state is equal or older than at the time the array degraded. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1088532 Title: pluging in a missing raid member does not (re)add it to array To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1088532/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1088884] [NEW] no option to force --incremental (re)add to active array
Public bug reported: The --incremental call (as also done by udev rules) refuses to (re)add a temporarily disconnected members back to an already restarted (active) raid array. # mdadm --incremental /dev/sdb1 mdadm: not adding /dev/sdb1 to active array (without --run) /dev/md/0 # mdadm --incremental --run /dev/sdb1 mdadm: failed to add /dev/sdb1 to /dev/md/0: Invalid argument. Even though this refusal may in the future only happen for true conflicts (Bug #1088532), there is still an option missing to --force the addition anyway. Using --force with --incremental (where mdadm will still apply sanity checks to not add it to a completely wrong array etc.) seems much less dangerous than forcing the user to have to --zero-superblock around in the system. ** Affects: mdadm (Ubuntu) Importance: Undecided Status: New ** Description changed: + The --incremental (udev) call refuses to (re)add a temporarily + disconnected members back to an already restarted (active) raid. - The --incremental (udev) call refuses to (re)add a temporarily disconnected members back to an already restarted (active) raid. + # mdadm --incremental /dev/sdb1 + mdadm: not adding /dev/sdb1 to active array (without --run) /dev/md/0 - Even though the refusal may in the future only happen for obvious + # mdadm --incremental --run /dev/sdb1 + mdadm: failed to add /dev/sdb1 to /dev/md/0: Invalid argument. + + Even though this refusal may in the future only happen for true conflicts (Bug #1088532), there is still an option missing to --force the addition anyway. Using --force with --incremental (where mdadm will still apply sanity checks to not add it to a completely wrong array etc.) seems much less dangerous than forcing the user to have to --zero-superblock around in the system. ** Description changed: - The --incremental (udev) call refuses to (re)add a temporarily - disconnected members back to an already restarted (active) raid. + The --incremental call (as also done by udev rules) refuses to (re)add a + temporarily disconnected members back to an already restarted (active) + raid array. # mdadm --incremental /dev/sdb1 mdadm: not adding /dev/sdb1 to active array (without --run) /dev/md/0 # mdadm --incremental --run /dev/sdb1 mdadm: failed to add /dev/sdb1 to /dev/md/0: Invalid argument. Even though this refusal may in the future only happen for true conflicts (Bug #1088532), there is still an option missing to --force the addition anyway. Using --force with --incremental (where mdadm will still apply sanity checks to not add it to a completely wrong array etc.) seems much less dangerous than forcing the user to have to --zero-superblock around in the system. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/104 Title: no option to force --incremental (re)add to active array To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/104/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1062159] Re: Raid is incorrectly determined as DEGRADED preventing boot in 12.04
** Changed in: mdadm (Ubuntu) Status: New = Confirmed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1062159 Title: Raid is incorrectly determined as DEGRADED preventing boot in 12.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1062159/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1057889] Re: mdadm depends on postfix
It is currently a requirement to notify the sysadmin about failing disks etc.. Bug #535417 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1057889 Title: mdadm depends on postfix To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1057889/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 535417] Re: mdadm monitor feature broken, email notification not set up, nor using beep/wall/notify-send
** Description changed: Binary package hint: mdadm - Anybody who cares about redundancy to use mdadm probably cares enough - about redundancy to want being informed if redundancy is degraded. + Anybody who cares enough about redundancy to use mdadm probably cares + enough to want getting informed if redundancy is degraded. Debian systems do have at least local mail enabled and package mdadm asks for a mail address to notify during mdadm install. By default ubuntu systems do not support local mail, and the mdadm package was patched to suppress the installation of an MTA/MDA (only if installed during the initial installation Bug #379882 ), without adapting mdadm --monitor to use wall or notify-send as a replacement. As informing a human is a serious data protection topic, mdadm should depend on a package providing at least local mail services and/or use beep/wall/notify-send to get the message out. --- The monitoring facility of mdadm is very important to get notice if somthing goes wrong with your raid. So you can replace disks etc. ahead of a total failure. To send out notifications mdadm needs a sendmail command (MTA mail transport agent ). To deliver mail localy you need a mail delivery agent (MDA) Things like exim, postfix open network ports and are large and not easy to configure, but of course provide the sendmail command and delivery. - If no MTA/MDA is installed, yes mdadm should pull in (require) one. However, maybe a small replacement like esmtp + procmail (if they are supported) instead of postfix on desktops. - + --- - + Workaround to manually set up local delivery for email send to root: - - #apt-get install postfix procmail - # (choose to configure for local use only) - #echo root: YOUR-USER-NAME-HERE /etc/aliases - #newaliases - #mdadm --monitor /dev/md0 --test - #^C + + #apt-get install postfix procmail + # (choose to configure for local use only) + #echo root: YOUR-USER-NAME-HERE /etc/aliases + #newaliases + #mdadm --monitor /dev/md0 --test + #^C Then set up an mail program or to check for email in your local mailbox (/var/mail/YOUR-USER-NAME-HERE). ** Description changed: Binary package hint: mdadm Anybody who cares enough about redundancy to use mdadm probably cares enough to want getting informed if redundancy is degraded. Debian systems do have at least local mail enabled and package mdadm asks for a mail address to notify during mdadm install. By default ubuntu systems do not support local mail, and the mdadm package was patched to suppress the installation of an MTA/MDA (only if installed during the initial installation Bug #379882 ), without adapting mdadm --monitor to use wall or notify-send as a replacement. As informing a human is a serious data protection topic, mdadm should depend on a package providing at least local mail services and/or use beep/wall/notify-send to get the message out. --- The monitoring facility of mdadm is very important to get notice if somthing goes wrong with your raid. So you can replace disks etc. ahead of a total failure. To send out notifications mdadm needs a sendmail command (MTA mail transport agent ). To deliver mail localy you need a mail delivery agent (MDA) Things like exim, postfix open network ports and are large and not easy to configure, but of course provide the sendmail command and delivery. If no MTA/MDA is installed, yes mdadm should pull in (require) one. However, maybe a small replacement like esmtp + procmail (if they are supported) instead of postfix on desktops. --- Workaround to manually set up local delivery for email send to root: #apt-get install postfix procmail # (choose to configure for local use only) #echo root: YOUR-USER-NAME-HERE /etc/aliases #newaliases #mdadm --monitor /dev/md0 --test #^C - Then set up an mail program or to check for email in your local mailbox + Then set up an mail program to check for email in your local mailbox (/var/mail/YOUR-USER-NAME-HERE). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/535417 Title: mdadm monitor feature broken, email notification not set up, nor using beep/wall/notify-send To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/535417/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 872220] Re: Fails to boot when there's problems with softraid
This is completely unbelievable. Somebody not competent enough broke the debian raid setup for ubuntu years ago, and the issues has still not been resolved? Man, fix up ubuntu mdadm to issue proper notifications (bug #535417). Get rid of that bogus boot_degraded question (bug #539597), and finally implement a reliable raid. @simon: good job! Maybe the notes about the required dependencies in https://wiki.ubuntu.com/ReliableRaid are of interst to you. What a mistake to assume improvements in ubuntu raid and retry. Instead, use a debian installation. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/872220 Title: Fails to boot when there's problems with softraid To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/872220/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 778520] Re: install on degraded raid1 does not boot, drops to initramfs shell
Vak, if you need more recent versions, look for a howto to set up a debian (desktop) box with testing or sid. These releases contain recent software with continious updates, while still being conservative on the finishing of features, and not just dumping them on users and forgetting about them. After all, ubuntu copies and releases a debian version from before it is stable, but seems to stop adding updates after releasing that premature version. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/778520 Title: install on degraded raid1 does not boot, drops to initramfs shell To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/778520/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1088464] [NEW] missing --incremental on array that is part of another array (nested)
Public bug reported: http://www.spinics.net/lists/raid/msg40832.html when booting, the system dumps into initramfs shell with the raid array in an inactive state. There are two problems here. Firstly, the fact that the array doesn't assemble completely should not cause the boot to fail. A degraded raid1 is perfectly sufficient for booting. What is happening is that the initrd is relying on udev to assemble the array by passing each new device to mdadm --incremental $DEVNAME. This will assemble the array as soon as all devices are present, but not before. If a device failed before shutdown that will be recorded in the metadata and mdadm --incremental will not wait for it. If it disappears during reboot, mdadm will still expect it. To deal with this issue, the initrd should run mdadm --incremental --scan --run [better: only degrade the required raid, not all !!! ] which means look for all arrays that are being incrementally assembled, and start them. This should be called after running udevadm settle and before mounting the root filesystem. However fixing this won't fix your problem [with a nested array], it will just change it. The udev rules files which is calling mdadm --incremental does so on /dev/sdb1 /dev/sdc1 and /dev/sde1, but apparently not on /dev/md0. If at the initrd shell prompt you run mdadm -I /dev/md0 it should finish assembling md1 for you. For some reason udev isn't doing that. Have a look in /lib/udev/rules.d or /etc/udev/rules.d for a file that runs mdadm --incremental or mdadm -I and see how it works. Maybe post it. BTW what distro are you using? NeilBrown ** Affects: mdadm (Ubuntu) Importance: Undecided Status: New ** Summary changed: - missing --incremental on array that is part of another arrays (nested) + missing --incremental on array that is part of another array (nested) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1088464 Title: missing --incremental on array that is part of another array (nested) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1088464/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 251164] Re: boot impossible due to missing initramfs failure hook / event driven initramfs
I am sorry I had to find out the same as Teemu for 12.04.1. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/251164 Title: boot impossible due to missing initramfs failure hook / event driven initramfs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/251164/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1088532] [NEW] pluging in a missing raid member does not (re)add it to array
Public bug reported: 12.04.1 regression (worked before, maybe without the mentioned safety check, but it worked) (re-add refers to speeding up the sync using a bitmap) The --incremental (udev) call refuses to (re)add a temporarily diconnected member back to an already restarted (active) raid. (Even thought the event count clearly shows its state is equal or older than at the time the array was started (run) degraded.) And manually: # mdadm /dev/md2 --re-add /dev/sda6 mdadm: --re-add for /dev/sda6 to /dev/md2 is not possible # mdadm /dev/md2 --add /dev/sda6 mdadm: /dev/sda6 reports being an active member for /dev/md2, but a --re-add fails. mdadm: not performing --add as that would convert /dev/sda6 in to a spare. mdadm: To make this a spare, use mdadm --zero-superblock /dev/sda6 first. This is not how things are supposed to work in times of hotpluging. A warning/question if the device that is to be added contains newer data than at its time of failure is appropriate, but otherwise, get the job of adding that device back to its raid done! ** Affects: mdadm (Ubuntu) Importance: Undecided Status: Confirmed ** Tags: regression-release ** Description changed: - + 12.04.1 (re-add refers to speed up the sync using a bitmap) The --incremental (udev) call refuses to (re)add the temporarily diconnected member back to a restarted (active) raid. (Even thought the event count clearly shows its state is equal or older than at the time the array was started (run) degraded.) And manually: # mdadm /dev/md2 --re-add /dev/sda6 mdadm: --re-add for /dev/sda6 to /dev/md2 is not possible # mdadm /dev/md2 --add /dev/sda6 mdadm: /dev/sda6 reports being an active member for /dev/md2, but a --re-add fails. mdadm: not performing --add as that would convert /dev/sda6 in to a spare. mdadm: To make this a spare, use mdadm --zero-superblock /dev/sda6 first. This is not how things are supposed to work in times of hotpluging. A warning/question if the device that is to be added contains newer data is appropriate, but otherwise get the job of adding that device back to its raid done. ** Description changed: 12.04.1 (re-add refers to speed up the sync using a bitmap) - The --incremental (udev) call refuses to (re)add the temporarily - diconnected member back to a restarted (active) raid. (Even thought the - event count clearly shows its state is equal or older than at the time - the array was started (run) degraded.) + The --incremental (udev) call refuses to (re)add a temporarily + diconnected member back to an already restarted (active) raid. (Even + thought the event count clearly shows its state is equal or older than + at the time the array was started (run) degraded.) And manually: # mdadm /dev/md2 --re-add /dev/sda6 mdadm: --re-add for /dev/sda6 to /dev/md2 is not possible # mdadm /dev/md2 --add /dev/sda6 mdadm: /dev/sda6 reports being an active member for /dev/md2, but a --re-add fails. mdadm: not performing --add as that would convert /dev/sda6 in to a spare. mdadm: To make this a spare, use mdadm --zero-superblock /dev/sda6 first. - This is not how things are supposed to work in times of hotpluging. A - warning/question if the device that is to be added contains newer data - is appropriate, but otherwise get the job of adding that device back to - its raid done. + This is not how things are supposed to work in times of hotpluging. + + A warning/question if the device that is to be added contains newer data + than at its time of failure is appropriate, but otherwise, get the job + of adding that device back to its raid done! ** Description changed: - 12.04.1 - (re-add refers to speed up the sync using a bitmap) + 12.04.1 regression (worked before, maybe without the mentioned safety + check, but it worked) + + (re-add refers to speeding up the sync using a bitmap) The --incremental (udev) call refuses to (re)add a temporarily diconnected member back to an already restarted (active) raid. (Even thought the event count clearly shows its state is equal or older than at the time the array was started (run) degraded.) And manually: # mdadm /dev/md2 --re-add /dev/sda6 mdadm: --re-add for /dev/sda6 to /dev/md2 is not possible # mdadm /dev/md2 --add /dev/sda6 mdadm: /dev/sda6 reports being an active member for /dev/md2, but a --re-add fails. mdadm: not performing --add as that would convert /dev/sda6 in to a spare. mdadm: To make this a spare, use mdadm --zero-superblock /dev/sda6 first. This is not how things are supposed to work in times of hotpluging. A warning/question if the device that is to be added contains newer data than at its time of failure is appropriate, but otherwise, get the job of adding that device back to its raid done! ** Tags added: regression-release ** Changed in: mdadm (Ubuntu) Status: New = Confirmed -- You received this bug notification
[Bug 984449] Re: Palimpsest doesn't allow precisely-sized partitions
I'd suggest to report the failure to create raid partition with the correct (equal, large enough) size as a separate bug. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/984449 Title: Palimpsest doesn't allow precisely-sized partitions To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/984449/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 984449] Re: Palimpsest doesn't allow precisely-sized partitions
PS launchpad is a waste of time, get in contact with upstrem directly. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/984449 Title: Palimpsest doesn't allow precisely-sized partitions To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/984449/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 984449] Re: Palimpsest doesn't allow precisely-sized partitions
Forgot to mention: conifirmed the failure to create lage enough raid partition when trying to extend a raid 1 with another 333MiB sized parttion (gui shows 349 MB). Nevertheless, it worked with a 18.62GiB (20GB) raid. Seems like messing up with with MB and MiB (MiB being the only sane unit as this is the default alignment anyway.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/984449 Title: Palimpsest doesn't allow precisely-sized partitions To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-disk-utility/+bug/984449/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 985882] Re: units shown are not equal to the units asked for creation
The workarout to see the MiB size in copy/resize dialog does not work with unknown partitions (raids containing luks). ** Description changed: Try to recreate or clone the OS partition on another harddrive of a different size as the original. GParted shows only an impresize size of the existing partition such as 32.63GB, whereas to create the new partition the exact size in MiB is required. Hidden in the Properties, gparted does tell the number of sectors in the old partition, but that can't be directly used to create the new partition either. (V 0.7.0) Use case is not to copy but create two disks with same partiton sizes (only some of them raid partition clones). -- Suggested fix: - * Add the size in MiB to the detailed properties, since this is the - standard allign unit anyway. + * Also show the (full length) size in MiB in the detailed properties + window, since this is the standard allign unit anyway. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/985882 Title: units shown are not equal to the units asked for creation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/985882/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 985882] Re: units shown are not equal to the units asked for creation
console workaround to get the size in MiB: # parted /dev/sda unit MiB print -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/985882 Title: units shown are not equal to the units asked for creation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/985882/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 425979] Re: Holding shift fails to display grub2 menu
This is grub bug someone forward this to grub authors! http://askubuntu.com/questions/117525/hide-grub2-menu-unless-you-hold- down-shift-key-how-to-make-this-happen Somehow even if HIDDEN_TIMEOUT is set to a positive value, the shiftkey (said to be only the right-shift !!!) is said to only work if there is also GRUB_DISABLE_OS_PROBER=true -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/425979 Title: Holding shift fails to display grub2 menu To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/425979/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 989814] Re: Albatross: GTK3 apps are hard to read (white on light grey)
Thanks for the honest assessment. Too bad if LTS support is such that it means to be stuck with countless bugs. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/989814 Title: Albatross: GTK3 apps are hard to read (white on light grey) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shimmer-themes/+bug/989814/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 535417] Re: mdadm monitor feature broken, email notification not set up, nor using beep/wall/notify-send
** Description changed: Binary package hint: mdadm Anybody who cares about redundancy to use mdadm probably cares enough about redundancy to want being informed if redundancy is degraded. Debian systems do have at least local mail enabled and package mdadm asks for a mail address to notify during mdadm install. By default ubuntu system support no local mail and mdadm package was patched to suppress the debconf email question, without setting up mdadm --monitor to use wall or notify-send as an alternative. As informing a human is a serious data protection topic mdadm should depend on a package providing at least local mail services and/or use beep/wall/notify-send to get the message out. --- The monitoring facility of mdadm is very important to get notice if somthing goes wrong with your raid. So you can replace disks etc. ahead of a total failure. To send out notifications mdadm needs a sendmail command (MTA mail transport agent ). To deliver mail localy you need a mail delivery agent (MDA) Things like exim, postfix open network ports and are large and not easy to configure, but of course provide the sendmail command and delivery. If no MTA/MDA is installed, yes mdadm should pull in (require) one, maybe a replacement like esmtp + procmail (if they are supported) but not postfix on desktops. --- Workaround to set up local delivery for email send to root (to a user mailbox in /var/mail): #apt-get install esmtp-run procmail #echo mda=\'/usr/bin/formail -a \Date: \`date -R\`\ \| /usr/bin/procmail -d %T\' /etc/esmtprc - #echo root: YOUR-USER-NAME-HERE /etc/alias + #echo root: YOUR-USER-NAME-HERE /etc/aliases #newaliases -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/535417 Title: mdadm monitor feature broken, email notification not set up, nor using beep/wall/notify-send To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/535417/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 535417] Re: mdadm monitor feature broken, email notification not set up, nor using beep/wall/notify-send
** Description changed: Binary package hint: mdadm Anybody who cares about redundancy to use mdadm probably cares enough about redundancy to want being informed if redundancy is degraded. Debian systems do have at least local mail enabled and package mdadm asks for a mail address to notify during mdadm install. By default ubuntu system support no local mail and mdadm package was patched to suppress the debconf email question, without setting up mdadm --monitor to use wall or notify-send as an alternative. As informing a human is a serious data protection topic mdadm should depend on a package providing at least local mail services and/or use beep/wall/notify-send to get the message out. --- The monitoring facility of mdadm is very important to get notice if somthing goes wrong with your raid. So you can replace disks etc. ahead of a total failure. To send out notifications mdadm needs a sendmail command (MTA mail transport agent ). To deliver mail localy you need a mail delivery agent (MDA) Things like exim, postfix open network ports and are large and not easy to configure, but of course provide the sendmail command and delivery. If no MTA/MDA is installed, yes mdadm should pull in (require) one, maybe a replacement like esmtp + procmail (if they are supported) but not postfix on desktops. + + + --- + + Workaround to set up local delivery for email send to root (to a user + mailbox in /var/mail): + + #apt-get install esmtp-run procmail + #echo mda=\'/usr/bin/formail -a \Date: \`date -R\`\ \| /usr/bin/procmail -d %T\' /etc/esmtprc + #echo root: your-user-name /etc/alias + #newaliases ** Description changed: Binary package hint: mdadm Anybody who cares about redundancy to use mdadm probably cares enough about redundancy to want being informed if redundancy is degraded. Debian systems do have at least local mail enabled and package mdadm asks for a mail address to notify during mdadm install. By default ubuntu system support no local mail and mdadm package was patched to suppress the debconf email question, without setting up mdadm --monitor to use wall or notify-send as an alternative. As informing a human is a serious data protection topic mdadm should depend on a package providing at least local mail services and/or use beep/wall/notify-send to get the message out. --- The monitoring facility of mdadm is very important to get notice if somthing goes wrong with your raid. So you can replace disks etc. ahead of a total failure. To send out notifications mdadm needs a sendmail command (MTA mail transport agent ). To deliver mail localy you need a mail delivery agent (MDA) Things like exim, postfix open network ports and are large and not easy to configure, but of course provide the sendmail command and delivery. If no MTA/MDA is installed, yes mdadm should pull in (require) one, maybe a replacement like esmtp + procmail (if they are supported) but not postfix on desktops. - --- Workaround to set up local delivery for email send to root (to a user mailbox in /var/mail): #apt-get install esmtp-run procmail #echo mda=\'/usr/bin/formail -a \Date: \`date -R\`\ \| /usr/bin/procmail -d %T\' /etc/esmtprc - #echo root: your-user-name /etc/alias + #echo root: YOUR-USER-NAME-HERE /etc/alias #newaliases -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/535417 Title: mdadm monitor feature broken, email notification not set up, nor using beep/wall/notify-send To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/535417/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 535417] Re: mdadm monitor feature broken, email notification not set up, nor using beep/wall/notify-send
** Description changed: Binary package hint: mdadm Anybody who cares about redundancy to use mdadm probably cares enough about redundancy to want being informed if redundancy is degraded. Debian systems do have at least local mail enabled and package mdadm asks for a mail address to notify during mdadm install. By default ubuntu system support no local mail and mdadm package was patched to suppress the debconf email question, without setting up mdadm --monitor to use wall or notify-send as an alternative. As informing a human is a serious data protection topic mdadm should depend on a package providing at least local mail services and/or use beep/wall/notify-send to get the message out. --- The monitoring facility of mdadm is very important to get notice if somthing goes wrong with your raid. So you can replace disks etc. ahead of a total failure. To send out notifications mdadm needs a sendmail command (MTA mail transport agent ). To deliver mail localy you need a mail delivery agent (MDA) Things like exim, postfix open network ports and are large and not easy to configure, but of course provide the sendmail command and delivery. - If no MTA/MDA is installed, yes mdadm should pull in (require) one, - maybe a replacement like esmtp + procmail (if they are supported) but - not postfix on desktops. + If no MTA/MDA is installed, yes mdadm should pull in (require) one. + However, maybe a small replacement like esmtp + procmail (if they are + supported) instead of postfix on desktops. --- - Workaround to set up local delivery for email send to root (to a user - mailbox in /var/mail): + Workaround to manually set up local delivery for email send to root: - #apt-get install esmtp-run procmail - #echo mda=\'/usr/bin/formail -a \Date: \`date -R\`\ \| /usr/bin/procmail -d %T\' /etc/esmtprc + #apt-get install postfix procmail + # (choose to configure for local use only) #echo root: YOUR-USER-NAME-HERE /etc/aliases #newaliases + #mdadm --monitor /dev/md0 --test + #^C + + Then set up an mail program or to check for email in your local mailbox + (/var/mail/YOUR-USER-NAME-HERE). ** Description changed: Binary package hint: mdadm Anybody who cares about redundancy to use mdadm probably cares enough about redundancy to want being informed if redundancy is degraded. Debian systems do have at least local mail enabled and package mdadm asks for a mail address to notify during mdadm install. By default ubuntu system support no local mail and mdadm package was patched to suppress the debconf email question, without setting up mdadm --monitor to use wall or notify-send as an alternative. As informing a human is a serious data protection topic mdadm should depend on a package providing at least local mail services and/or use beep/wall/notify-send to get the message out. --- The monitoring facility of mdadm is very important to get notice if somthing goes wrong with your raid. So you can replace disks etc. ahead of a total failure. To send out notifications mdadm needs a sendmail command (MTA mail transport agent ). To deliver mail localy you need a mail delivery agent (MDA) Things like exim, postfix open network ports and are large and not easy to configure, but of course provide the sendmail command and delivery. If no MTA/MDA is installed, yes mdadm should pull in (require) one. However, maybe a small replacement like esmtp + procmail (if they are supported) instead of postfix on desktops. --- Workaround to manually set up local delivery for email send to root: #apt-get install postfix procmail # (choose to configure for local use only) #echo root: YOUR-USER-NAME-HERE /etc/aliases #newaliases #mdadm --monitor /dev/md0 --test #^C - Then set up an mail program or to check for email in your local mailbox + Then set up an mail program to check for email in your local mailbox (/var/mail/YOUR-USER-NAME-HERE). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/535417 Title: mdadm monitor feature broken, email notification not set up, nor using beep/wall/notify-send To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/535417/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 535417] Re: mdadm monitor feature broken, email notification not set up, nor using beep/wall/notify-send
** Description changed: Binary package hint: mdadm Anybody who cares about redundancy to use mdadm probably cares enough about redundancy to want being informed if redundancy is degraded. Debian systems do have at least local mail enabled and package mdadm asks for a mail address to notify during mdadm install. - By default ubuntu system support no local mail and mdadm package was - patched to suppress the debconf email question, without setting up mdadm - --monitor to use wall or notify-send as an alternative. + By default ubuntu systems do not support local mail, and the mdadm + package was patched to suppress the installation of an MTA/MDA (only if + installed during the initial installation Bug #379882 ), without + adapting mdadm --monitor to use wall or notify-send as a + replacement. - As informing a human is a serious data protection topic mdadm should + As informing a human is a serious data protection topic, mdadm should depend on a package providing at least local mail services and/or use beep/wall/notify-send to get the message out. --- The monitoring facility of mdadm is very important to get notice if somthing goes wrong with your raid. So you can replace disks etc. ahead of a total failure. To send out notifications mdadm needs a sendmail command (MTA mail transport agent ). To deliver mail localy you need a mail delivery agent (MDA) Things like exim, postfix open network ports and are large and not easy to configure, but of course provide the sendmail command and delivery. - If no MTA/MDA is installed, yes mdadm should pull in (require) one. - However, maybe a small replacement like esmtp + procmail (if they are - supported) instead of postfix on desktops. - - --- - - Workaround to manually set up local delivery for email send to root: - - #apt-get install postfix procmail - # (choose to configure for local use only) - #echo root: YOUR-USER-NAME-HERE /etc/aliases - #newaliases - #mdadm --monitor /dev/md0 --test - #^C - - Then set up an mail program to check for email in your local mailbox - (/var/mail/YOUR-USER-NAME-HERE). + If no MTA/MDA is installed, yes mdadm should pull in (require) one, + maybe a replacement like esmtp + procmail (if they are supported) but + not postfix on desktops. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/535417 Title: mdadm monitor feature broken, email notification not set up, nor using beep/wall/notify-send To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/535417/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 535417] Re: mdadm monitor feature broken, email notification not set up, nor using beep/wall/notify-send
** Description changed: Binary package hint: mdadm Anybody who cares about redundancy to use mdadm probably cares enough about redundancy to want being informed if redundancy is degraded. Debian systems do have at least local mail enabled and package mdadm asks for a mail address to notify during mdadm install. By default ubuntu systems do not support local mail, and the mdadm package was patched to suppress the installation of an MTA/MDA (only if installed during the initial installation Bug #379882 ), without adapting mdadm --monitor to use wall or notify-send as a replacement. As informing a human is a serious data protection topic, mdadm should depend on a package providing at least local mail services and/or use beep/wall/notify-send to get the message out. --- The monitoring facility of mdadm is very important to get notice if somthing goes wrong with your raid. So you can replace disks etc. ahead of a total failure. To send out notifications mdadm needs a sendmail command (MTA mail transport agent ). To deliver mail localy you need a mail delivery agent (MDA) Things like exim, postfix open network ports and are large and not easy to configure, but of course provide the sendmail command and delivery. - If no MTA/MDA is installed, yes mdadm should pull in (require) one, - maybe a replacement like esmtp + procmail (if they are supported) but - not postfix on desktops. + + If no MTA/MDA is installed, yes mdadm should pull in (require) one. + However, maybe a small replacement like esmtp + procmail (if they are + supported) instead of postfix on desktops. + + --- + + Workaround to manually set up local delivery for email send to root: + + #apt-get install postfix procmail + # (choose to configure for local use only) + #echo root: YOUR-USER-NAME-HERE /etc/aliases + #newaliases + #mdadm --monitor /dev/md0 --test + #^C + + Then set up an mail program or to check for email in your local mailbox + (/var/mail/YOUR-USER-NAME-HERE). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/535417 Title: mdadm monitor feature broken, email notification not set up, nor using beep/wall/notify-send To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/535417/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 989301] Re: large rsync runs stall system perfomance (missing --drop-cache)
** Tags added: patch ** Description changed: - - Please build the package with the --drop-cache patch available in the tarball, to avoid filling up the io cache with not re-queried copied data. The current behavior pushes the data of other process out of the cache and thus slows them down. + Please build the package with the --drop-cache patch that is available + in the tarball, to avoid filling up the io cache with not re-queried + copied data. The current behavior pushes the data of other process out + of the cache and thus slows them down. http://insights.oetiker.ch/linux/fadvise.html -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/989301 Title: large rsync runs stall system perfomance (missing --drop-cache) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsync/+bug/989301/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 989814] Re: Albatross: GTK3 apps are hard to read (white on light grey)
Will the resizing handle in the bottom right window corner and albatross readability fix come to the LTS? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/989814 Title: Albatross: GTK3 apps are hard to read (white on light grey) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shimmer-themes/+bug/989814/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 878997] Re: setting nopasswdlogin removes user password
*** This bug is a duplicate of bug 882255 *** https://bugs.launchpad.net/bugs/882255 ** Also affects: gnome-system-tools (Ubuntu) Importance: Undecided Status: New ** Also affects: accountsservice (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/878997 Title: setting nopasswdlogin removes user password To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/878997/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 882255] Re: No administrative actions possible (password refused) after enabling passwordless login
** Also affects: accountsservice (Ubuntu) Importance: Undecided Status: New ** Also affects: gnome-system-tools (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/882255 Title: No administrative actions possible (password refused) after enabling passwordless login To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/882255/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 882255] Re: No administrative actions possible (password refused) after enabling passwordless login
** Description changed: If I choose not to have a password for my operating account, every operation fails if it needs root access. Reproducible even on a newly set up machine. See: http://ubuntuforums.org/showthread.php?t=1862543 Release: 11.10 + + Cause: The password is cleared (which prevents authentification for + security reasons). However, the user only needs to be added to the + nopasswordlogin group, to enable passwordless login with gdm (and other + DMs that ship with a corresponding pam configuration). Steps to reproduce: 1. Install Ubuntu 11.10 as normal. During installation, when you are asked to choose a password, enter one, since the installation can not continue if you do not do so. 2. Boot the newly installed system and log in as usual. 3. Choose System Settings from the launcher on the left and open User Accounts. 4. In the User Accounts window, click on Unlock at the top right of the dialog. Enter your user password when prompted. 5. Click on the four dots next to the Password label to change your password. 6. Select Log in without a password from the dropdown box. Close the window. 7. Try to perform an action requiring administrative privileges. For example, try running sudo apt-get update from a terminal. Expected behavior: sudo should require the user's password and accept it, or proceed without requiring any password altogether. Actual behavior: sudo requires the user's password and does not accept it (since it is set to an empty string in /etc/shadow). Further notes: After disabling the password request at login, the /etc/shadow file related to the test user account I created looked like this: test::15283:0:9:7::: This shows that the password hash is made completely empty; that conflicts with the policies listed in /etc/sudoers, which require a password to be given in order to perform administrative actions. Workaround: -If you can not perform administrative actions but can still login without a password, open a terminal and type passwd. This command should prompt you for a new password and change it without any problems. -If you can not login, you can reset your password by booting into recovery mode and changing it there. Follow the instructions at http://psychocats.net/ubuntu/resetpassword. You may also choose to use a password for your account and to enable autologin at the same time. This choice will enable you to benefit the advantage of not entering a password at boot time with the security of Ubuntu requiring your password when attempting to perform privileged actions. Of course, this helps when you are the only desktop user or the primary one. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/882255 Title: No administrative actions possible (password refused) after enabling passwordless login To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/882255/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 882255] Re: No administrative actions possible (password refused) after enabling passwordless login
** Description changed: If I choose not to have a password for my operating account, every operation fails if it needs root access. Reproducible even on a newly set up machine. See: http://ubuntuforums.org/showthread.php?t=1862543 Release: 11.10 - Cause: The password is cleared (which prevents authentification for - security reasons). However, the user only needs to be added to the - nopasswordlogin group, to enable passwordless login with gdm (and other - DMs that ship with a corresponding pam configuration). + Cause: The password is cleared to be empty, and this prevents + authentification for many admin tasks for security reasons. However, the + user only needs to be added to the nopasswdlogin group, to enable + passwordless login with gdm (and any other DM that ships with a + corresponding auth sufficient pam_succeed_if.so user ingroup + nopasswdlogin configuration). + + Fix: + * lightdm to add pam rule + * account managing tools not clearing password but only adding user to +nopasswdlogin group + Steps to reproduce: 1. Install Ubuntu 11.10 as normal. During installation, when you are asked to choose a password, enter one, since the installation can not continue if you do not do so. 2. Boot the newly installed system and log in as usual. 3. Choose System Settings from the launcher on the left and open User Accounts. 4. In the User Accounts window, click on Unlock at the top right of the dialog. Enter your user password when prompted. 5. Click on the four dots next to the Password label to change your password. 6. Select Log in without a password from the dropdown box. Close the window. 7. Try to perform an action requiring administrative privileges. For example, try running sudo apt-get update from a terminal. Expected behavior: sudo should require the user's password and accept it, or proceed without requiring any password altogether. Actual behavior: sudo requires the user's password and does not accept it (since it is set to an empty string in /etc/shadow). Further notes: After disabling the password request at login, the /etc/shadow file related to the test user account I created looked like this: test::15283:0:9:7::: This shows that the password hash is made completely empty; that conflicts with the policies listed in /etc/sudoers, which require a password to be given in order to perform administrative actions. Workaround: -If you can not perform administrative actions but can still login without a password, open a terminal and type passwd. This command should prompt you for a new password and change it without any problems. -If you can not login, you can reset your password by booting into recovery mode and changing it there. Follow the instructions at http://psychocats.net/ubuntu/resetpassword. You may also choose to use a password for your account and to enable autologin at the same time. This choice will enable you to benefit the advantage of not entering a password at boot time with the security of Ubuntu requiring your password when attempting to perform privileged actions. Of course, this helps when you are the only desktop user or the primary one. ** Also affects: lightdm (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/882255 Title: No administrative actions possible (password refused) after enabling passwordless login To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/accountsservice/+bug/882255/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 158918] Re: [-UUIDudev] installing mdadm (or outdated mdadm.conf) breaks bootup
You might want to use the original debian on your server instead. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/158918 Title: [-UUIDudev] installing mdadm (or outdated mdadm.conf) breaks bootup To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/158918/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 251646] Re: {upstream} missing command to start *single* arrays in auto-read mode (like --incremental)
I don't think so.
My guess is that if initramfs calls
mdadm --incremental --run
it would run all arrays and not just the single array (mdX) that contains the
root filesystem.
Degrading not yet fully available non-root arrays is bad, as it may nullify the
redundancy and take hours to get the arrays resynced again.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/251646
Title:
{upstream} missing command to start *single* arrays in auto-read
mode (like --incremental)
To manage notifications about this bug go to:
https://bugs.launchpad.net/mdadm/+bug/251646/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 487729] Re: /etc/login.defs propagates incorrect information
** Changed in: shadow (Ubuntu) Status: New = Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/487729 Title: /etc/login.defs propagates incorrect information To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/487729/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 379451] Re: provide /etc/skel/private/ and incoming/ dirs
** Description changed: Binary package hint: base-files + + see https://wiki.ubuntu.com/MultiUserManagement for context Please provide the directories /etc/skel/private (rwx--) and /etc/skel/incoming with appropriate permissions. In the user private group scheme used in debian/ubuntu the homedirs are created with permissions allowing the users to share and access files in each others home directories. These two directories will provide the users with a private space and a possibility give and receive files to/from other users. - - The following wiki page contains more information and ties together related bugs. - https://wiki.ubuntu.com/MultiUserManagement -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/379451 Title: provide /etc/skel/private/ and incoming/ dirs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/379451/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 379431] Re: set up a /home/group/users directory
** Description changed: Binary package hint: user-setup - Set up a sgid /home/group/users directory for the users group if it - doesn't exist, so that users are provided with a way to collaborate on - local files. + see https://wiki.ubuntu.com/MultiUserManagement + + + Set up a sgid /home/group/users directory for the users group if it doesn't exist, so that users are provided with a way to collaborate on local files. This will also seed the answer of how smaller groups can collaborate. For full control: The directory can contain private/, public/ and incoming/ subdirectories. The first two further containing readonly/ and writeable/ directories. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/379431 Title: set up a /home/group/users directory To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/user-setup/+bug/379431/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 379421] Re: addgroup option to auto-create /home/group/new-group sgid directories
** Description changed: + + see https://wiki.ubuntu.com/MultiUserManagement + Let groupadd have the option to create /home/group/groupname sgid directories. Sgid group directories are the means for users to easily collaborate on local files with the user private group scheme used in debian/ubuntu. Graphical tools can then adopt to this addgroup option. 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) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/379421 Title: addgroup option to auto-create /home/group/new-group sgid directories To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/379421/+subscriptions -- 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
This kind of information would be perfect for presentation by the installer during the copying phase. ** Description changed: Binary package hint: debian-installer Following is a little informative text for the set up users and passwords stage: --- - The informational text suggested is updated under User's perspective - on https://wiki.ubuntu.com/MultiUserManagement + The informational text suggested is now updated under User's + perspective on https://wiki.ubuntu.com/MultiUserManagement --- 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) ** Also affects: debian-installer (Ubuntu) Importance: Undecided Status: New ** Summary changed: - provide some info about users and file permissions + provide some info about users and file permissions (while copying) ** Description changed: Binary package hint: debian-installer Following is a little informative text for the set up users and passwords stage: --- The informational text suggested is now updated under User's perspective on https://wiki.ubuntu.com/MultiUserManagement --- - - 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) ** Summary changed: - provide some info about users and file permissions (while copying) + provide some info about user collaboration and file permissions (while copying) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/252351 Title: provide some info about user collaboration and file permissions (while copying) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/252351/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 379421] Re: addgroup option to auto-create /home/group/new-group sgid directories
** Summary changed: - addgroup option to create /home/group/groupname sgid directories + addgroup option to auto-create /home/group/new-group sgid directories -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/379421 Title: addgroup option to auto-create /home/group/new-group sgid directories To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/379421/+subscriptions -- 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
I am not sure, last time I looked (when still using ubuntu), initramfs was not using --incremental to set up the rootfs. The issue itself may be something worth forwarding/asking to upstream, though. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/244792 Title: -ARs fails with prior --no-degraded assemblies To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/244792/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 251646] Re: {upstream} missing command to start *single* arrays in auto-read mode (like --incremental)
Are you aware that starting all arrays degraded (what the initramfs
scripts currently have to do) is a serious bug? The replicas will
diverge, and if the non-rootfs devices become accessible later they need
to resync.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/251646
Title:
{upstream} missing command to start *single* arrays in auto-read
mode (like --incremental)
To manage notifications about this bug go to:
https://bugs.launchpad.net/mdadm/+bug/251646/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 251646] Re: {upstream} missing command to start *single* arrays in auto-read mode (like --incremental)
** Description changed:
Binary package hint: mdadm
+ Proposed command: mdadm --incremental --run /dev/mdX
- 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.)
+ Initramfs must be able to start (selected) md devices in degraded mode
+ (only the ones that contain the rootfs and swap/resume partition), if
+ they didn't start after some time of udev hotplugging. Starting all
+ arrays, that are not yet complete at that early stage, degraded is not
+ acceptable.
- 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.
+ Initramfs could use the old non-incremental commands,
- But the boot script should only start selected arrays, i.e. the one
- containing the rootfs not all incomplete ones.
+ ( i.e. mdadm --run /dev/mdX is preferable to mdadm --assemble --scan
+ to start only selected array degraded)
- So where mdadm --run /dev/mdX is preferable to mdadm --assemble
- --scan (only start selected array degraded),
+ but the old commands break the support for auto-read mode set up and
+ smooth inclusion of members that appear later on.
- something like: mdadm --incremental --run /dev/mdX or to start all
- arrays in auto-read mode by default might be preferable to both.
+
+ Alternatively to a new --incremental option, make the old commands compatible
and also start degraded arrays in auto-read mode and incrementally extendable
by default.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/251646
Title:
{upstream} missing command to start *single* arrays in auto-read
mode (like --incremental)
To manage notifications about this bug go to:
https://bugs.launchpad.net/mdadm/+bug/251646/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 251646] Re: {upstream} missing command to start *single* arrays in auto-read mode (like --incremental)
All right, hopefully some of the stuff I filed is of help to you,
thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/251646
Title:
{upstream} missing command to start *single* arrays in auto-read
mode (like --incremental)
To manage notifications about this bug go to:
https://bugs.launchpad.net/mdadm/+bug/251646/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 251164] Re: boot impossible due to missing initramfs failure hook / event driven initramfs
Looking at the timouts suggested in Comment #15, I think they may actually be realizable with modular scripts. A base rootdelay script, and separate mdadm and cryptsetup sripts (that get called by their udev rules) can halt/extend the regular rootdelay (exported variable? named pipe?), if waiting for user input or a new level of raid degrading timeout. (As pipes block, reading from pipes may do good for event based processing.) Phillip, your idea of handling udev events by modular event handlers (that may again trigger udev events, if I interpret you correctly) may also be what appears in part of the OpenRC discussion. On init in Debian http://lists.debian.org/debian-devel/2012/03/msg00452.html RFC: OpenRC as Init http://lists.debian.org/debian-devel/2012/04/msg00547.html -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/251164 Title: boot impossible due to missing initramfs failure hook / event driven initramfs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/251164/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 987420] Re: allow to set restart/resume time on shutdown/suspend
I don't know if daily wake events can be programmed in the hardware real time clock. Yes, a small +wakup again checkbox or similar collapsible UI to enter a date would be sufficient I guess. But if it the UI could remember the last setting used this might already also allow daily (next day) wakeups. For facility wide power saving schedules I think debian has a shutdown- at-night package. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/987420 Title: allow to set restart/resume time on shutdown/suspend To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/987420/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 251164] Re: boot impossible due to missing initramfs failure hook / event driven initramfs
I believe the initramfs only sets up the rootfs, other partitions (/home) are set up afterwards. If I remeber correct cryptsetup is called by udev rules. In any case, that is the way it has to be, event driven, to catch on upon (/home) devices appearing without polling loops and sleep delays. When I looked, I think bootwait, mdadm and cryptsetup where all looping and sleeping in initramfs independently in whatever course they get called. Therefore I suggested the watchdog timers I mentioned above and in the wiki. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/251164 Title: boot impossible due to missing initramfs failure hook / event driven initramfs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/251164/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 251164] Re: boot impossible due to missing initramfs failure hook / event driven initramfs
The udev rules don't need to prompt, the cryptsetup that gets called will prompt. Actually, these things work quite well in the normal system. It seems preferable to me to adjust/improve the regular tools to be usable in initramfs as well, rather then trying to script up and maintain! another thing inherently limited. Failure hooks for example will be called in a specific order (not necessarily matching the setup), if you are looping this should time out with a message, then if the user plugs in the missing disk it won't come up automatically (and if it does possibly only with a large delay as all unrelated loops need to time out first), etc. Thus, its better to go event driven, and then why not favor a proven tool. Reasonable timeouts (see above and https://wiki.ubuntu.com/ReliableRaid) are another reason to go event driven, they should not be several waiting loops stacked up and possibly blocking each other. Bug #491463 support upstart within an initramfs https://launchpad.net/~csurbhi/+archive/natty-initramfs -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/251164 Title: boot impossible due to missing initramfs failure hook / event driven initramfs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/251164/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 251164] Re: boot impossible due to missing initramfs failure hook / event driven initramfs
Since udev already provides an event driven framework in the initramfs, why add another one? Hmm, if you would like to realize event driven init scripts, I believe you may be able to rework the scripts from doing linear pre...post things to just call a watchdog script that mostly sleeps and checks how things are going on. And then have separate task scripts that get only called by udev events, or the watchdog. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/251164 Title: boot impossible due to missing initramfs failure hook / event driven initramfs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/251164/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 531240] Re: silently breaking raid: root raid_members opened as luks
Thank you for testing, Phillip! Cryptsetup support should be on the CD. But it only seemed to run in the first boot up stage of the rescue CD and used to try to open the raid members there, even before you set up the raids with the debian installer. Good that it does not do that any more. I thus consent that the bug can not be reproduced with new installs anymore. It could be though, that this is only due to a newer mdadm superblock version being used in newer installs. (I think the 0.9 version is at the end of the partion.) Nevertheless, as you can see mdadm, lvm, and cryptsetup will need an improved event driven (udev) setup in the the rootfs and initramfs (both used also in the installer system) to setup the devices no matter how they are stacked up. Bug #251164 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/531240 Title: silently breaking raid: root raid_members opened as luks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/531240/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 531240] Re: silently breaking raid: root raid_members opened as luks
@alfonso: mdadm monitor will send you an email if the raid can not be set up completely (is degraded) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/531240 Title: silently breaking raid: root raid_members opened as luks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/531240/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 531240] Re: silently breaking raid: root raid_members opened as luks
If you still have the vm setup, you could just try to boot the text installer media again, enter the rescue mode and see how it wants to mount the existing raid disks (not degraded, both present) in the vm. That's where it used to always happen. Oherwise, only occasionally during normal reboots. When trying to boot with one disk missing, the system would not boot Right, after way too many release cycles with the unmaintained mdadm modifications in ubuntu, I moved upstream. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/531240 Title: silently breaking raid: root raid_members opened as luks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/531240/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 987664] Re: allow to set restart/resume time
** Description changed: The desktop environments would help saving energy, if their shutdown dialogs could by default provide the option (button/checkbox) to schedule a restart. Linux provides a simple way to schedule a restart event that is particularly usefull in conjuction with initiating or scheduling a shutdown or suspend. - rtcwake -m on -s seconds-util-start-event + rtcwake -m no -s seconds-util-start-event Howerever, just as the shutdown command it requires root privileges. Thus the need for a similar consolekit support. The particular command given in the example above avoids that rtcwake does any switching into another power state (mode -m stays on). This allows that all power state switching is still contolled by whatever power management (userspace) tools are installed, which may often be more stable than the pure kernel/rtcwake method, especially on resume. To test it, just schedule a wake event like above as root, then do a regular shutdown/suspend. Wait, and watch how the real time clock triggers the scheduled power up event and the machine comes back up. ** Summary changed: - allow to set restart/resume time + allow to set restart/resume time in shutdown dialog ** Description changed: The desktop environments would help saving energy, if their shutdown dialogs could by default provide the option (button/checkbox) to schedule a restart. Linux provides a simple way to schedule a restart event that is particularly usefull in conjuction with initiating or scheduling a shutdown or suspend. rtcwake -m no -s seconds-util-start-event Howerever, just as the shutdown command it requires root privileges. Thus the need for a similar consolekit support. - The particular command given in the example above avoids that rtcwake does any switching into another power state (mode -m stays on). + The particular command given in the example above avoids that rtcwake does any switching into another power state (no new mode -m no). This allows that all power state switching is still contolled by whatever power management (userspace) tools are installed, which may often be more stable than the pure kernel/rtcwake method, especially on resume. To test it, just schedule a wake event like above as root, then do a regular shutdown/suspend. Wait, and watch how the real time clock triggers the scheduled power up event and the machine comes back up. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/987664 Title: allow to set restart/resume time in shutdown dialog To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-session-shutdown/+bug/987664/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 531240] Re: silently breaking raid: root raid_members opened as luks
Best way to reproduce the actual wrong opening seemed to be in a virtualbox as in comment #42. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/531240 Title: silently breaking raid: root raid_members opened as luks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-release-notes/+bug/531240/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 985882] Re: units shown are not equal to the units asked for creation
Agreed. Thank you! ** Description changed: Try to recreate or clone the OS partition on another harddrive of a different size as the original. GParted shows only an impresize size of the existing partition such as 32.63GB, whereas to create the new partition the exact size in MiB is required. Hidden in the Properties, gparted does tell the number of sectors in the old partition, but that can't be directly used to create the new partition either. (V 0.7.0) Use case is not to copy but create two disks with same partiton sizes (only some of them raid partition clones). -- Suggested fix: * Add the size in MiB to the detailed properties, since this is the standard allign unit anyway. - - * Provide the option to use LBA units for creation, to allow full - precision. - - (Provide an option to use same as allign unit?) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/985882 Title: units shown are not equal to the units asked for creation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/985882/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 985882] Re: units shown are not equal to the units asked for creation
When I had the problem I finally had to turn to CLI-parted to get the proper numbers. Nothing a graphical tool user may like to do, but I could work around the problem that way. Fortunately, I was using the MiB allignment on all newer disks, so they should have ended up to have the same size as I defined exact MiB, too. It just feels really wrong if the graphical partitioning tool you are using asks for information in a unit that it can not supply (without going into unrelated modes). It would have been no problem if the info is in the detailed properties. Thus if you could add it there, that would be great. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/985882 Title: units shown are not equal to the units asked for creation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/985882/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 985882] Re: units shown are not equal to the units asked for creation
Can't sectors per MiB be different on different harddisks? But the LBA size sectors? may be the right option for below MiB alligning. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/985882 Title: units shown are not equal to the units asked for creation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/985882/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 985882] Re: units shown are not equal to the units asked for creation
** Description changed: Try to recreate or clone the OS partition on another harddrive of a different size as the original. GParted shows only an impresize size of the existing partition such as 32.63GB, whereas to create the new partition the exact size in MiB is required. Hidden in the Properties, gparted does tell the number of sectors in the old partition, but that can't be directly used to create the new partition either. (V 0.7.0) Use case is not to copy but create two disks with same partiton sizes (only some of them raid partition clones). + + -- + + Suggested fix: + + * Add the size in MiB to the detailed properties, since this is the + standard allign unit anyway. + + * Provide the option to use LBA units for creation, to allow full + precision. + + (Provide an option to use same as allign unit?) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/985882 Title: units shown are not equal to the units asked for creation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/985882/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 551719] Re: MD_AUTODETECT=y kernel option is obsolete (boot delay and udev/mdadm (raid) disturbance)
Same symptoms do not mean the same cause (bug). Many thanks for hinting to the module restriction. This bug can be closed then. :) ** Changed in: mdadm (Ubuntu) Status: Confirmed = Invalid ** Changed in: linux (Ubuntu) Status: Confirmed = Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/551719 Title: MD_AUTODETECT=y kernel option is obsolete (boot delay and udev/mdadm (raid) disturbance) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/551719/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 985882] Re: units shown are not equal to the units asked for creation
Thanks for the workaround! Having to look into Move/Resize before creating new partitions is still strange, though. I would expect the required unit numbers are available, at least in the detailed properties of partitions. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/985882 Title: units shown are not equal to the units asked for creation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/985882/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 985882] Re: units shown are not equal to the units asked for creation
Use case was, not to copy but create two disks with same partiton sizes (only some of them raid partition clones). ** Description changed: Try to recreate or clone the OS partition on another harddrive of a different size as the original. GParted shows only an impresize size of the existing partition such as 32.63GB, whereas to create the new partition the exact size in MiB is required. Hidden in the Properties, gparted does tell the number of sectors in the old partition, but that can't be directly used to create the new partition either. (V 0.7.0) + + Use case is not to copy but create two disks with same partiton sizes + (only some of them raid partition clones). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/985882 Title: units shown are not equal to the units asked for creation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/985882/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 551719] Re: boot delay and udev/mdadm (raid) disturbance (obsolete MD_AUTODETECT=y)
** This bug is no longer a duplicate of bug 942106 mdadm-functions missing udevadm settle (?) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/551719 Title: boot delay and udev/mdadm (raid) disturbance (obsolete MD_AUTODETECT=y) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/551719/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 551719] Re: boot delay and udev/mdadm (raid) disturbance (obsolete MD_AUTODETECT=y)
This can not be a duplicate of bug #942106. This is about an obsolete kernel option for very old style kernel raid assembly. It slows mdadm assembly down and can grab devices. In case a patch to another bug fixes this bug too, please mark the patch as closing multiple bugs. ** Summary changed: - boot delay and udev/mdadm (raid) disturbance (obsolete MD_AUTODETECT=y) + MD_AUTODETECT=y is obsolete (boot delay and udev/mdadm (raid) disturbance) ** Summary changed: - MD_AUTODETECT=y is obsolete (boot delay and udev/mdadm (raid) disturbance) + MD_AUTODETECT=y kernel option is obsolete (boot delay and udev/mdadm (raid) disturbance) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/551719 Title: MD_AUTODETECT=y kernel option is obsolete (boot delay and udev/mdadm (raid) disturbance) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/551719/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 987664] Re: allow to set restart/resume time
I don't know how all the desktop parts work together. However, it is a waste of resources to let your computer run only because for example you need to access it remotely in a couple of hours/days/month, or have it do some task. And I see many user that keep their machines running, just because they do not see a way to schedule it. The desktop environments would help saving energy, if their shutdown dialogs could by default provide the option (button/checkbox) to schedule a restart. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/987664 Title: allow to set restart/resume time To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-session-shutdown/+bug/987664/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 987664] Re: allow to set restart/resume time
** Description changed: + The desktop environments would help saving energy, if their shutdown + dialogs could by default provide the option (button/checkbox) to + schedule a restart. + Linux provides a simple way to schedule a restart event that is particularly usefull in conjuction with initiating or scheduling a shutdown or suspend. rtcwake -m on -s seconds-util-start-event Howerever, just as the shutdown command it requires root privileges. + Thus the need for a similar consolekit support. The particular command given in the example above avoids that rtcwake does any switching into another power state (mode -m stays on). - This allows that the power state fully handled by the regular installed power managment (userspace) tools, which is often more stable than the pure kernel/rtcwake, especially on resume. + This allows that all power state switching is still contolled by whatever power management (userspace) tools are installed, which may often be more stable than the pure kernel/rtcwake method, especially on resume. - To test it, just schedule a wake event, then do a regular - shutdown/suspend. Later, the real time clock will trigger the scheduled - power up event and the machine comes back up. + To test it, just schedule a wake event like above as root, then do a + regular shutdown/suspend. Wait, and watch how the real time clock + triggers the scheduled power up event and the machine comes back up. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/987664 Title: allow to set restart/resume time To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-session-shutdown/+bug/987664/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 987664] Re: allow to set restart/resume time
** Also affects: xfdesktop4 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/987664 Title: allow to set restart/resume time To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-session-shutdown/+bug/987664/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 884011] Re: regression: lost ability to show continuous status with tray/appindicator icon
Hi Peter-Alexander, you're right, and I agree it still is a regression looking at the --notification function alone. As far as I understand the reason for the change was the decision for an updated semantic. Notification now only means a bubble message, and is different from a status icon or window. Going with this might be more precise. But changing this without giving apps the chance to adopt and use a --trayicon option if they actually do need a continuous status indication one is really bad. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/884011 Title: regression: lost ability to show continuous status with tray/appindicator icon To manage notifications about this bug go to: https://bugs.launchpad.net/zenity/+bug/884011/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 884011] Re: regression: lost ability to show continuous status with tray/appindicator icon
** Description changed: The change in the zenity --notification behavior completely removed the functionality to display an unobtrusive, always visible tray icon - from zenity. Instead, that functionality should have been moved into a + from zenity. + + For clarity, the tray icon functionality should be made available with a proper zenity --trayicon feature. + + For backwards compatibility, the --notification option would have to + continue to show an icon, but may be switched to just bring up a + notification bubble for clarity, once a separate --trayicon feature is + available. + --- Ubuntu 11.10 zenity 3.2.0-0ubuntu1 In a script I use following line: exec 3 (zenity --notification --window-icon=icon.svg --listen --text=some text) so I can change the tray icon based on what the script does. What I expect to happen: zenity --notification should show an icon in the tray or appindicator. What happens instead: A zenity --warning style dialog window pops up. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/884011 Title: regression: lost ability to show continuous status with tray/appindicator icon To manage notifications about this bug go to: https://bugs.launchpad.net/zenity/+bug/884011/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 884011] Re: regression: lost ability to show continuous status with tray/appindicator icon
In any case, it would be good if you could post the issue to the upstram bugtracker. ** Description changed: The change in the zenity --notification behavior completely removed the functionality to display an unobtrusive, always visible tray icon from zenity. For clarity, the tray icon functionality should be made available with a proper zenity --trayicon feature. For backwards compatibility, the --notification option would have to - continue to show an icon, but may be switched to just bring up a - notification bubble for clarity, once a separate --trayicon feature is - available. - + continue to show an icon. It may do so only together with the the + --listen option (this then implies status updates should follow), and + emit only a simple notification bubble and exit otherwise. --- Ubuntu 11.10 zenity 3.2.0-0ubuntu1 In a script I use following line: exec 3 (zenity --notification --window-icon=icon.svg --listen --text=some text) so I can change the tray icon based on what the script does. What I expect to happen: zenity --notification should show an icon in the tray or appindicator. What happens instead: A zenity --warning style dialog window pops up. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/884011 Title: regression: lost ability to show continuous status with tray/appindicator icon To manage notifications about this bug go to: https://bugs.launchpad.net/zenity/+bug/884011/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 884011] Re: regression: lost ability to show continuous status with tray/appindicator icon
** Bug watch added: GNOME Bug Tracker #675064 https://bugzilla.gnome.org/show_bug.cgi?id=675064 ** Changed in: zenity Importance: Undecided = Unknown ** Changed in: zenity Status: New = Unknown ** Changed in: zenity Remote watch: None = GNOME Bug Tracker #675064 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/884011 Title: regression: lost ability to show continuous status with tray/appindicator icon To manage notifications about this bug go to: https://bugs.launchpad.net/zenity/+bug/884011/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 987664] Re: allow to set restart/resume time
Hi jacopoL, you set this to invalid, because you don't know about start events? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/987664 Title: allow to set restart/resume time To manage notifications about this bug go to: https://bugs.launchpad.net/gnome-session-shutdown/+bug/987664/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
