[bts-link] source package src:linux-2.6
# # bts-link upstream status pull for source package src:linux-2.6 # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html # user bts-link-upstr...@lists.alioth.debian.org # remote status report for #651532 (http://bugs.debian.org/651532) # Bug title: System crashes (kernel oops) when loading ATI firmware # * https://bugs.freedesktop.org/show_bug.cgi?id=43835 # * remote status changed: (?) - NEW usertags 651532 + status-NEW thanks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111219163935.7072.84193.btsl...@busoni.debian.org
Bug#652459: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Sun, Dec 18, 2011 at 03:37:43AM +0100, Marco d'Itri wrote: On Dec 17, Roger Leigh rle...@codelibre.net wrote: So WRT mounting /usr (and potentially /etc and other filesystems), I've pushed patches upstream for util-linux (initramfs mount option) and initramfs-tools (generate /etc/fstab from host and mount after rootfs). (Merging this and the reply to #652459) I'd just like to clear up a few points about the desired behaviour and requirements for the initramfs. I have some ideas about other ways to achieve this goal. 1) Generation of /etc/fstab in the initramfs, including the rootfs and all the filesystems desired to be mounted This is highly suboptimal, because it suddenly makes the initramfs not generic anymore. The initramfs should: - mount / as usual - look at the rootfs fstab - mount /usr using the information from the rootfs fstab Regarding keeping the initramfs generic, we already permit hardcoding of the rootfs into the image. This is overridden by root=xxx, but still permitted. I'm not sure I see the difference between hardcoding the root device rather than an fstab entry. There is of course the addition of the mount options, which might be incompatible if the fstype of the rootfs changes. 2) In local mountroot(), rather than just mounting the rootfs, loop over all mountpoints in /etc/fstab and mount them. If there is no need to mount file systems other than /usr, why do it? It would permit additional flexibility for initramfs extensions by users. I'm not sure if this is necessarily a good or bad thing. If it's desirable not to permit this, I'm sure we can find a better way. Mounting /usr is obviously the main goal here. Whether or not we migrate stuff to or from /usr, we would still need to have the ability to mount /usr in the initramfs for compatibility with systems with a separately-mounted /usr, in order to privide the guarantee that /usr is available in early boot. Mounting /etc separately is not essential, but this would be a nice-to- have feature for those who wish to encrypt it. and other files to the root filesystem. It additionally permits mounting of /etc separately, thereby permitting it to be encrypted and/or writable while the root filesystem is unencrypted and/or read-only. I do not believe that this is desireable, it is complex and would come for free anyway by a / - /usr move. Why would it come for free? You would still have files in places other than /etc on the rootfs. And if we are deprecating a separate /usr, it doesn't solve the problem at all, since everything would be on the rootfs, and then everything would be encrypted. As mentioned earlier in the thread, encrypting /etc is an entirely different problem than mounting /usr separately--a separate mount would IMO be the best solution to this problem, and mounting it in the initramfs is certainly technically possible. Regarding the objections above, which are primarily concerned with the creation of a non-generic initramfs, how does this alternative suggestion sound: - The addition of usr= options analogous to the root= options which permit the bootloader to specify the /usr filesystem to mount. By default would do nothing, but grub could be updated to generate such options on systems with a separate /usr. - We could also add an additional etc= option with the same semantics. I'll be happy to implement this if this sounds more acceptable than the existing approach. It does, I think, address your primary criticisms. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111219201051.gb5...@codelibre.net
Bug#652678: linux-image-3.1.0-1-amd64: psmouse fails to autodetect Elan touchpad
Package: linux-2.6 Version: 3.1.1-1 Severity: normal Dear Maintainer, the psmouse driver of the referenced kernel fails to recognise the Elan touchpad of my notebook; it reports a Logitech Wheel Mouse instead. Thus I couldn't get the middle button click to work under X (amongst other functions). After applying the patch as referenced in https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/681904/comments/64 the driver detects the touchpad as expected. cheers, aa -- Package-specific info: ** Version: Linux version 3.1.0-1-amd64 (Debian 3.1.1-1) (b...@decadent.org.uk) (gcc version 4.6.2 (Debian 4.6.2-4) ) #1 SMP Mon Nov 14 08:02:25 UTC 2011 ** Command line: BOOT_IMAGE=/boot/vmlinuz-3.1.0-1-amd64 root=UUID=b61405bd-d5ec-4f48-8f06-692aaded5b8f ro video=vesafb:mtrr:3,ywrap vga=792 quiet ** Tainted: PO (4097) * Proprietary module has been loaded. * Out-of-tree module has been loaded. ** Kernel log: [8.310300] input: WebCam SCB-1100N as /devices/pci:00/:00:13.2/usb2/2-2/2-2:1.0/input/input11 [8.310641] usbcore: registered new interface driver uvcvideo [8.310645] USB Video Class driver (1.1.1) [9.684302] Adding 9751548k swap on /dev/sda7. Priority:-1 extents:1 across:9751548k [9.690319] EXT4-fs (sda5): re-mounted. Opts: (null) [ 10.000650] EXT4-fs (sda5): re-mounted. Opts: errors=remount-ro [ 10.109404] loop: module loaded [ 11.050073] EXT4-fs (sda6): mounted filesystem with ordered data mode. Opts: (null) [ 11.978688] RPC: Registered named UNIX socket transport module. [ 11.978693] RPC: Registered udp transport module. [ 11.978695] RPC: Registered tcp transport module. [ 11.978696] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 12.110026] FS-Cache: Loaded [ 12.141846] FS-Cache: Netfs 'nfs' registered for caching [ 12.153373] Installing knfsd (copyright (C) 1996 o...@monad.swb.de). [ 13.328982] fuse init (API version 7.17) [ 15.100357] input: ACPI Virtual Keyboard Device as /devices/virtual/input/input12 [ 17.235458] r8169 :03:00.0: eth0: link down [ 17.236461] ADDRCONF(NETDEV_UP): eth0: link is not ready [ 17.458414] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 20.218850] vgaarb: this pci device is not a vga device [ 20.218877] vgaarb: this pci device is not a vga device [ 20.218890] vgaarb: this pci device is not a vga device [ 20.218902] vgaarb: this pci device is not a vga device [ 20.218915] vgaarb: this pci device is not a vga device [ 20.218930] vgaarb: this pci device is not a vga device [ 20.218943] vgaarb: this pci device is not a vga device [ 20.218956] vgaarb: this pci device is not a vga device [ 20.218968] vgaarb: this pci device is not a vga device [ 20.218981] vgaarb: this pci device is not a vga device [ 20.218993] vgaarb: this pci device is not a vga device [ 20.219006] vgaarb: this pci device is not a vga device [ 20.219018] vgaarb: this pci device is not a vga device [ 20.219030] vgaarb: this pci device is not a vga device [ 20.219042] vgaarb: this pci device is not a vga device [ 20.219054] vgaarb: this pci device is not a vga device [ 20.219067] vgaarb: this pci device is not a vga device [ 20.219079] vgaarb: this pci device is not a vga device [ 20.219091] vgaarb: this pci device is not a vga device [ 20.219104] vgaarb: this pci device is not a vga device [ 20.219116] vgaarb: this pci device is not a vga device [ 20.219127] vgaarb: this pci device is not a vga device [ 20.219139] vgaarb: this pci device is not a vga device [ 20.219151] vgaarb: this pci device is not a vga device [ 20.219163] vgaarb: this pci device is not a vga device [ 20.219176] vgaarb: this pci device is not a vga device [ 20.219187] vgaarb: this pci device is not a vga device [ 20.219200] vgaarb: this pci device is not a vga device [ 20.219221] vgaarb: device changed decodes: PCI::02:00.0,olddecodes=io+mem,decodes=none:owns=none [ 20.219240] vgaarb: this pci device is not a vga device [ 20.219254] vgaarb: this pci device is not a vga device [ 20.256343] [fglrx] ATIF platform detected with notification ID: 0x81 [ 20.386972] Bluetooth: Core ver 2.16 [ 20.387002] NET: Registered protocol family 31 [ 20.387005] Bluetooth: HCI device and connection manager initialized [ 20.387008] Bluetooth: HCI socket layer initialized [ 20.387010] Bluetooth: L2CAP socket layer initialized [ 20.387015] Bluetooth: SCO socket layer initialized [ 20.432599] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [ 20.432603] Bluetooth: BNEP filters: protocol multicast [ 20.447014] Bluetooth: RFCOMM TTY layer initialized [ 20.447021] Bluetooth: RFCOMM socket layer initialized [ 20.447022] Bluetooth: RFCOMM ver 1.11 [ 20.909033] lp: driver loaded but no devices found [ 21.000420] ppdev: user-space parallel port driver [ 24.522892] fglrx_pci :00:01.0: irq 43 for MSI/MSI-X [ 24.523703] [fglrx] Firegl kernel thread PID: 1834 [
Bug#652459: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Mon, 19 Dec 2011, Roger Leigh wrote: [..] Regarding the objections above, which are primarily concerned with the creation of a non-generic initramfs, how does this alternative suggestion sound: - The addition of usr= options analogous to the root= options which permit the bootloader to specify the /usr filesystem to mount. By default would do nothing, but grub could be updated to generate such options on systems with a separate /usr. Nonsense, should come from /etc/fstab. - We could also add an additional etc= option with the same semantics. Something like this would be necessary to support separately mounted /etc, but I see that as a completely separate discussion. Also note that you would need to patch _all_ existing bootloaders for _all_ arches to automatically include that option in any generated config file (namely by parsing the oneonly main config location which is /etc/fstab or possibly /etc/fstab.d). Related issue: how to specify desired fsck options (such as FSCKFIX) for / and /etc, while /etc is not yet mounted. Next, you'll be arguing that /etc/fstab should be moved to /. And /etc/default/rcS too. Oh, and now that I'm at it, do we also have initramfs support for bootlogd? and keyboard-setup? and hwclockfirst? (Last two could be required for proper fsck on various arches.) Plus their config files. Best regards, Anne Bezemer -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1112192352230.14...@wormhole.robuust.nl
Bug#652459: Bug#652011: general: Repeated pattern of FHS violation: Dependencies of /sbin and /bin, belong in /lib
On Tue, Dec 20, 2011 at 12:11:39AM +0100, J.A. Bezemer wrote: On Mon, 19 Dec 2011, Roger Leigh wrote: [..] Regarding the objections above, which are primarily concerned with the creation of a non-generic initramfs, how does this alternative suggestion sound: - The addition of usr= options analogous to the root= options which permit the bootloader to specify the /usr filesystem to mount. By default would do nothing, but grub could be updated to generate such options on systems with a separate /usr. Nonsense, should come from /etc/fstab. Of course. In case it wasn't implicit from the above, this information would necessarily need to be taken from /etc/fstab by update-grub or its equivalent for other bootloaders when generating grub.cfg (or its equivalent). They presumably already do the same for / (or look at the current rootfs), so it's simply copying existing practice for the rootfs. - We could also add an additional etc= option with the same semantics. Something like this would be necessary to support separately mounted /etc, but I see that as a completely separate discussion. Also note that you would need to patch _all_ existing bootloaders for _all_ arches to automatically include that option in any generated config file (namely by parsing the oneonly main config location which is /etc/fstab or possibly /etc/fstab.d). Agreed. In order to guarantee that /usr is always available, we will need to support this for all bootloaders. As an aside, this support would only be required for situations where a separate /usr is used /and/ stuff on /usr is required for early boot. Support for minor tools/platforms might not be required since the other solution is simple: keep /usr on the rootfs if you need those guarantees. Either way, having support in the initramfs is a prerequisite for updating the bootloaders. Related issue: how to specify desired fsck options (such as FSCKFIX) for / and /etc, while /etc is not yet mounted. I would presume that this would be unchanged. By the time fsck is run, you'll have / and additionally /etc and/or /usr mounted, so keeping it on /etc will be just fine. Next, you'll be arguing that /etc/fstab should be moved to /. And /etc/default/rcS too. No. I'm simply proposing a way to make additional guarantees about the availability of /usr in early boot. Nothing else is changed except for when /usr is mounted. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111220001514.gd5...@codelibre.net
