Re: Mass closing EOL bugs should not close bugs with pending updates
On 02/17/2013 03:26 PM, Christoph Wickert wrote: Am Sonntag, den 17.02.2013, 14:46 +0100 schrieb Tadej Janež: On Sun, 2013-02-17 at 12:02 +0100, Christoph Wickert wrote: I found that a couple of F16 bugs were closed by endoflife@fp.o even though there were pending updates for F17 and F18 to fix them. As a result, the bugs are now closed WONTFIX even they were or are going to be fixed. What you describe is another example of strange behavior of the Fedora EOL Closure script. I discovered two related problems that I described three days ago: http://lists.fedoraproject.org/pipermail/devel/2013-February/178649.html Since then I found a page that describes the Fedora 16 EOL Closure procedure: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora18#Fedora_16_EOL_Closure It says that the bugs with version == Fedora 16 and status != CLOSED are subject to automatic closure. Could you give an example of a bug that you described? https://admin.fedoraproject.org/updates/FEDORA-2013-2359/lxpanel-0.5.12-1.fc18 and https://admin.fedoraproject.org/updates/FEDORA-2013-2359/lxpanel-0.5.12-1.fc17 fix several bugs, among them two very old and annoying ones: https://bugzilla.redhat.com/show_bug.cgi?id=782431 and https://bugzilla.redhat.com/show_bug.cgi?id=785906 As you can see the bugs were already ON_QA before they were closed WONTFIX. Kind regards, Christoph I agree here. A number of my bugs just got closed and they are still valid and should have been moved to next version by someone who had authority to do it. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plans for anaconda LVM/RAID support
On 10/25/2012 03:04 PM, John Reiser wrote: On 10/25/2012 09:55 AM, Ken Dreyer wrote: On Thu, Oct 25, 2012 at 10:53 AM, Matthew Miller [snip] It is often useful in enterprise settings to do non-kickstart installs while prototyping. *And*, people running Fedora in those settings probably *are* prototyping. So, this seems like an important use case to me. I agree with this. It's also quite a simplification to say that kickstart only involves writing a single text file :) I see a couple other things here. Anaconda doesn't inter-operate well. The interactive graphical part has no provision for writing the kickstart file so far, so that is cumbersome to adapt: I need multiple passes. (How do I invoke anaconda with a partial kickstart file, use interactive features, then write the revised kickstart state, and stop? There should be a syntax-and-semantics-aware kickstart editor.) And, if what I want is guided generation of a kickstart file, then that should be an ordinary app (with root privileges to discover any existing configuration, but inhibiting all partition creating and formatting), not a stand-alone installer. Then anaconda balks at taking over a disk configuration that I create using other tools. Namely, anaconda won't format an unformatted existing partition, So, I must use another pass to discover Fedora's default arguments to mkfs before performing the mkfs somewhere else. What I use now is the latest gparted LiveCD ( http://gparted.org/ ; recently supports LVM!) to set the partitioning, and to create and format file systems with labels. Then I run anaconda only to assign those existing partitions to mount points. Just my 2c here. I gave up on anaconda a long time ago. I only care that anaconda will use an existing layout that I create using other tools. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: Saitek Pro Flight controls refuse to operate with kernel 3.6.1 upgrade
On 10/16/2012 05:41 PM, Gerry Reno wrote: I just found another problem with the upgrade to kernel 3.6.1 My Saitek Pro Flight controls (yoke and pedals) refuse to operate now. I can see them in dmesg but they do nothing when running FlightGear now. Solved by updating kernel-modules-extra. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: Illuminated keyboard turns off with kernel 3.6.1 upgrade
Filed: https://bugzilla.redhat.com/show_bug.cgi?id=867024 On 10/16/2012 03:40 AM, Vratislav Podzimek wrote: On Mon, 2012-10-15 at 19:48 -0400, Gerry Reno wrote: I just upgraded my F17 kernel to 3.6.1 and when I reboot then my Logitech illuminated keyboard is not lit until I touch a key and then it goes right back off. Kind of defeats the purpose of having an illuminated keyboard. Anyone know why this might happen after this particular kernel upgrade? I have no idea, but probably the best thing to do is file a bug and provide as much related information as you can. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: Illuminated keyboard turns off with kernel 3.6.1 upgrade
On 10/16/2012 12:59 PM, Stephen John Smoogen wrote: On 15 October 2012 17:48, Gerry Reno gr...@verizon.net wrote: I just upgraded my F17 kernel to 3.6.1 and when I reboot then my Logitech illuminated keyboard is not lit until I touch a key and then it goes right back off. Kind of defeats the purpose of having an illuminated keyboard. Anyone know why this might happen after this particular kernel upgrade? What model of Logitech Illuminated Keyboard. Both my wired Y-UY95 LIK seems to work correctly with the 3.6.1 kernel. The keyboard stays lit all the time. The wireless one I have at anotehr place I can test tomorrow as it has the capacitive reaction to light up when touched and goes out after a bit when not. I have the wired version of the Logitech Illuminated Keyboard. On the bottom it says LZ212BD . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F17: Saitek Pro Flight controls refuse to operate with kernel 3.6.1 upgrade
I just found another problem with the upgrade to kernel 3.6.1 My Saitek Pro Flight controls (yoke and pedals) refuse to operate now. I can see them in dmesg but they do nothing when running FlightGear now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F17: FlightGear
FlightGear 2.8.0 has been released. And it supports a lot more controllers. Can we have FlightGear updated to 2.8.0 for F17? Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: FlightGear
On 09/11/2012 12:03 AM, Tomas Dabašinskas wrote: FlightGear 2.8.0 Opened bug: https://bugzilla.redhat.com/show_bug.cgi?id=856053 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
Trying to run directfb on F17 I noticed 5 issues: 1) libdirectfb_vdpau.so: undefined symbol: XUnlockDisplay (Bug 852740: fixed) 2) Unable to run DirectFB as a normal user (Bug 852745: open) 3) permissions on /dev/tty* and /dev/fb* not set by udev (probably should be addressed and fixed under Bug 852745) 4) inteldrmfb driver emulation of fbdev interface incomplete (Bug 853268: open) 5) directfb needs updated to 1.6.1 (no bug yet) I tested the fix in Bug 852740 and that bug is fixed in 1.5.3-8 in F17 although the other errors still keep directfb from working. Is there anything else I can do to help test and get directfb upgraded to 1.6.1 and working for both regular and root users? Gerry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
On 08/30/2012 09:00 AM, Tom Callaway wrote:
On 08/29/2012 06:52 PM, Gerry Reno wrote:
(!) DirectFB/core/vt: Error opening `/dev/tty1'!
-- Permission denied
(!) DirectFB/Core: Could not initialize 'system_core' core!
-- A general initialization error occured
(#) DirectFBError [DirectFBCreate() failed]: A general initialization
error occured
Segmentation fault
I set the perms in the udev rules to 0666 but the tty does not setup
that way for some reason.
Did you reboot after setting the udev rules? My /dev/tty0 and /dev/tty1
are 0660. (I'm running Fedora 18).
If you chmod 660 /dev/tty*, does it work?
~tom
==
Fedora Project
Yes, these settings have been through many reboots and they are not setting the
tty mode correctly.
When I chmod g+r tty{0,1} the permission error goes away but it has other
problems with setting 1024x768 for fbdev.
$ dfbinfo
~~| DirectFB 1.6.1 |~~
(c) 2001-2012 The world wide DirectFB Open Source Community
(c) 2000-2004 Convergence (integrated media) GmbH
(*) DirectFB/Core: Single Application Core. (2012-08-29 21:15)
(*) Direct/Memcpy: Using libc memcpy()
(*) Direct/Thread: Started 'Fusion Dispatch' (-1) [MESSAGING OTHER/OTHER
0/0] 8388608...
(*) Direct/Thread: Started 'VT Switcher' (-1) [CRITICAL OTHER/OTHER 0/0]
8388608...
(*) Direct/Thread: Started 'VT Flusher' (-1) [DEFAULT OTHER/OTHER 0/0]
8388608...
(*) DirectFB/FBDev: Found 'inteldrmfb' (ID 0) with frame buffer at
0xc0064000, 8100k (MMIO 0x, 0k)
(*) Direct/Thread: Started 'Hotplug with Linux Input' (-1) [INPUT
OTHER/OTHER 0/0] 8388608...
(*) DirectFB/Input: Hot-plug detection enabled with Linux Input Driver
(*) DirectFB/Input: Hot-plug detection enabled with Input Hub Driver
(*) Direct/Thread: Started 'Keyboard Input' (-1) [INPUT OTHER/OTHER 0/0]
8388608...
(*) DirectFB/Input: Keyboard 0.9 (directfb.org)
(*) DirectFB/Genefx: MMX detected and enabled
(*) DirectFB/Graphics: MMX Software Rasterizer 0.7 (directfb.org)
(*) DirectFB/Core/WM: Default 0.3 (directfb.org)
(!!!) *** ONCE [no mode found for 1024x768] *** [fbdev.c:1354 in
dfb_fbdev_find_mode()]
(*) FBDev/Mode: Setting 1024x768 RGB32
(*) FBDev/Mode: Switched to 1024x768 (virtual 1024x768) at 32 bit (RGB32),
pitch 7680
(!) DirectFB/FBDev: Could not set gamma ramp-- Invalid argument
(*) FBDev/Mode: Setting 1024x768 RGB16
(*) FBDev/Mode: Switched to 1024x768 (virtual 1024x768) at 16 bit (RGB16),
pitch 7680
(!) DirectFB/FBDev: Could not set gamma ramp-- Invalid argument
Screen (00) FBDev Primary Screen(primary screen)
Caps: VSYNC POWER_MANAGEMENT
Layer (00) FBDev Primary Layer (primary layer)
Type:GRAPHICS
Caps:SURFACE BRIGHTNESS CONTRAST SATURATION
Input (00) Keyboard(primary keyboard)
Vendor ID: 0x
Product ID: 0x
Type: KEYBOARD
Caps: KEYS
Min. Keycode: 0
Max. Keycode: 127
Gerry
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
If I run the command under root I see a more extensive output but having same problems w/1024x768: # dfbinfo ~~| DirectFB 1.6.1 |~~ (c) 2001-2012 The world wide DirectFB Open Source Community (c) 2000-2004 Convergence (integrated media) GmbH (*) DirectFB/Core: Single Application Core. (2012-08-29 21:15) (*) Direct/Memcpy: Using libc memcpy() (*) Direct/Thread: Started 'Fusion Dispatch' (-1) [MESSAGING OTHER/OTHER 0/0] 8388608... (*) Direct/Thread: Started 'VT Switcher' (-1) [CRITICAL OTHER/OTHER 0/0] 8388608... (*) Direct/Thread: Started 'VT Flusher' (-1) [DEFAULT OTHER/OTHER 0/0] 8388608... (*) DirectFB/FBDev: Found 'inteldrmfb' (ID 0) with frame buffer at 0xc0064000, 8100k (MMIO 0x, 0k) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] 8388608... (*) DirectFB/Input: Power Button (1) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] 8388608... (*) DirectFB/Input: AT Translated Set 2 keyboard (2) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] 8388608... (*) DirectFB/Input: Hewlett-Packard HP f2100a Opti (3) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] 8388608... (*) DirectFB/Input: SynPS/2 Synaptics TouchPad (4) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] 8388608... (*) DirectFB/Input: Video Bus (5) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] 8388608... (*) DirectFB/Input: Logitech Logitech Illuminated K (6) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] 8388608... (*) DirectFB/Input: Logitech Logitech Illuminated K (7) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] 8388608... (*) DirectFB/Input: Video Bus (8) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] 8388608... (*) DirectFB/Input: ST LIS3LV02DL Accelerometer (9) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] 8388608... (*) DirectFB/Input: HP Truevision HD (10) 0.1 (directfb.org) (*) Direct/Thread: Started 'Linux Input' (-1) [INPUT OTHER/OTHER 0/0] 8388608... (*) DirectFB/Input: HP WMI hotkeys (11) 0.1 (directfb.org) (*) Direct/Thread: Started 'Hotplug with Linux Input' (-1) [INPUT OTHER/OTHER 0/0] 8388608... (*) DirectFB/Input: Hot-plug detection enabled with Linux Input Driver (*) DirectFB/Input: Hot-plug detection enabled with Input Hub Driver (*) Direct/Thread: Started 'Keyboard Input' (-1) [INPUT OTHER/OTHER 0/0] 8388608... (*) DirectFB/Input: Keyboard 0.9 (directfb.org) (*) Direct/Thread: Started 'PS/2 Input' (-1) [INPUT OTHER/OTHER 0/0] 8388608... (*) DirectFB/Input: IMPS/2 Mouse 1.0 (directfb.org) (*) DirectFB/Genefx: MMX detected and enabled (*) DirectFB/Graphics: MMX Software Rasterizer 0.7 (directfb.org) (*) DirectFB/Core/WM: Default 0.3 (directfb.org) (!!!) *** ONCE [no mode found for 1024x768] *** [fbdev.c:1354 in dfb_fbdev_find_mode()] (*) FBDev/Mode: Setting 1024x768 RGB32 (*) FBDev/Mode: Switched to 1024x768 (virtual 1024x768) at 32 bit (RGB32), pitch 7680 (!) DirectFB/FBDev: Could not set gamma ramp-- Invalid argument (*) FBDev/Mode: Setting 1024x768 RGB16 (*) FBDev/Mode: Switched to 1024x768 (virtual 1024x768) at 16 bit (RGB16), pitch 7680 (!) DirectFB/FBDev: Could not set gamma ramp-- Invalid argument Screen (00) FBDev Primary Screen(primary screen) Caps: VSYNC POWER_MANAGEMENT Layer (00) FBDev Primary Layer (primary layer) Type:GRAPHICS Caps:SURFACE BRIGHTNESS CONTRAST SATURATION Input (10) Power Button Vendor ID: 0x Product ID: 0x0001 Type: Caps: KEYS Min. Keycode: -1 Max. Keycode: -1 Input (00) AT Translated Set 2 keyboard(primary keyboard) Vendor ID: 0x0001 Product ID: 0x0001 Type: KEYBOARD REMOTE Caps: KEYS Min. Keycode: 0 Max. Keycode: 127 Input (01) Hewlett-Packard HP f2100a Opti (primary mouse) Vendor ID: 0x03f0 Product ID: 0x2003 Type: MOUSE Caps: KEYS AXES BUTTONS Min. Keycode: -1 Max. Keycode: -1 Max. Axis: 2 Max. Button: 2 Input (11) SynPS/2 Synaptics TouchPad Vendor ID: 0x0002 Product ID: 0x0007 Type: MOUSE Caps: KEYS AXES BUTTONS Min. Keycode: -1 Max. Keycode: -1 Max. Axis: 1 Max. Button: 1 Input (12) Video Bus
Re: F17: DirectFB
After manually setting tty0 and tty1 using the previous chmod command now when I reboot I get a strange mix of tty settings. Originally they would all have permissions like this: crw--w. 1 root tty 4, 10 Aug 30 2012 /dev/tty10 But now they are a mix of settings: # ls -l /dev/tty* crw-rw-rw-. 1 root tty 5, 0 Aug 30 2012 /dev/tty crw-rw. 1 root tty 4, 0 Aug 30 2012 /dev/tty0 crw-rw. 1 root tty 4, 1 Aug 30 2012 /dev/tty1 crw--w. 1 root tty 4, 10 Aug 30 2012 /dev/tty10 crw--w. 1 root tty 4, 11 Aug 30 2012 /dev/tty11 crw--w. 1 root tty 4, 12 Aug 30 2012 /dev/tty12 crw--w. 1 root tty 4, 13 Aug 30 2012 /dev/tty13 crw--w. 1 root tty 4, 14 Aug 30 2012 /dev/tty14 crw--w. 1 root tty 4, 15 Aug 30 2012 /dev/tty15 crw--w. 1 root tty 4, 16 Aug 30 2012 /dev/tty16 crw--w. 1 root tty 4, 17 Aug 30 2012 /dev/tty17 crw--w. 1 root tty 4, 18 Aug 30 2012 /dev/tty18 crw--w. 1 root tty 4, 19 Aug 30 2012 /dev/tty19 crw-rw. 1 root tty 4, 2 Aug 30 2012 /dev/tty2 crw--w. 1 root tty 4, 20 Aug 30 2012 /dev/tty20 crw--w. 1 root tty 4, 21 Aug 30 2012 /dev/tty21 crw--w. 1 root tty 4, 22 Aug 30 2012 /dev/tty22 crw--w. 1 root tty 4, 23 Aug 30 2012 /dev/tty23 crw--w. 1 root tty 4, 24 Aug 30 2012 /dev/tty24 crw--w. 1 root tty 4, 25 Aug 30 2012 /dev/tty25 crw--w. 1 root tty 4, 26 Aug 30 2012 /dev/tty26 crw--w. 1 root tty 4, 27 Aug 30 2012 /dev/tty27 crw--w. 1 root tty 4, 28 Aug 30 2012 /dev/tty28 crw--w. 1 root tty 4, 29 Aug 30 2012 /dev/tty29 crw-rw. 1 root tty 4, 3 Aug 30 2012 /dev/tty3 crw--w. 1 root tty 4, 30 Aug 30 2012 /dev/tty30 crw--w. 1 root tty 4, 31 Aug 30 2012 /dev/tty31 crw--w. 1 root tty 4, 32 Aug 30 2012 /dev/tty32 crw--w. 1 root tty 4, 33 Aug 30 2012 /dev/tty33 crw--w. 1 root tty 4, 34 Aug 30 2012 /dev/tty34 crw--w. 1 root tty 4, 35 Aug 30 2012 /dev/tty35 crw--w. 1 root tty 4, 36 Aug 30 2012 /dev/tty36 crw--w. 1 root tty 4, 37 Aug 30 2012 /dev/tty37 crw--w. 1 root tty 4, 38 Aug 30 2012 /dev/tty38 crw--w. 1 root tty 4, 39 Aug 30 2012 /dev/tty39 crw-rw. 1 root tty 4, 4 Aug 30 2012 /dev/tty4 crw--w. 1 root tty 4, 40 Aug 30 2012 /dev/tty40 crw--w. 1 root tty 4, 41 Aug 30 2012 /dev/tty41 crw--w. 1 root tty 4, 42 Aug 30 2012 /dev/tty42 crw--w. 1 root tty 4, 43 Aug 30 2012 /dev/tty43 crw--w. 1 root tty 4, 44 Aug 30 2012 /dev/tty44 crw--w. 1 root tty 4, 45 Aug 30 2012 /dev/tty45 crw--w. 1 root tty 4, 46 Aug 30 2012 /dev/tty46 crw--w. 1 root tty 4, 47 Aug 30 2012 /dev/tty47 crw--w. 1 root tty 4, 48 Aug 30 2012 /dev/tty48 crw--w. 1 root tty 4, 49 Aug 30 2012 /dev/tty49 crw-rw. 1 root tty 4, 5 Aug 30 2012 /dev/tty5 crw--w. 1 root tty 4, 50 Aug 30 2012 /dev/tty50 crw--w. 1 root tty 4, 51 Aug 30 2012 /dev/tty51 crw--w. 1 root tty 4, 52 Aug 30 2012 /dev/tty52 crw--w. 1 root tty 4, 53 Aug 30 2012 /dev/tty53 crw--w. 1 root tty 4, 54 Aug 30 2012 /dev/tty54 crw--w. 1 root tty 4, 55 Aug 30 2012 /dev/tty55 crw--w. 1 root tty 4, 56 Aug 30 2012 /dev/tty56 crw--w. 1 root tty 4, 57 Aug 30 2012 /dev/tty57 crw--w. 1 root tty 4, 58 Aug 30 2012 /dev/tty58 crw--w. 1 root tty 4, 59 Aug 30 2012 /dev/tty59 crw-rw. 1 root tty 4, 6 Aug 30 2012 /dev/tty6 crw--w. 1 root tty 4, 60 Aug 30 2012 /dev/tty60 crw--w. 1 root tty 4, 61 Aug 30 2012 /dev/tty61 crw--w. 1 root tty 4, 62 Aug 30 2012 /dev/tty62 crw--w. 1 root tty 4, 63 Aug 30 2012 /dev/tty63 crw-rw. 1 root tty 4, 7 Aug 30 2012 /dev/tty7 crw-rw. 1 root tty 4, 8 Aug 30 2012 /dev/tty8 crw-rw. 1 root tty 4, 9 Aug 30 2012 /dev/tty9 crw-rw. 1 root dialout 166, 0 Aug 30 2012 /dev/ttyACM0 crw-rw. 1 root dialout 4, 64 Aug 30 2012 /dev/ttyS0 crw-rw. 1 root dialout 4, 65 Aug 30 2012 /dev/ttyS1 crw-rw. 1 root dialout 4, 66 Aug 30 2012 /dev/ttyS2 crw-rw. 1 root dialout 4, 67 Aug 30 2012 /dev/ttyS3 Gerry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
On 08/30/2012 09:40 AM, Tom Callaway wrote: On 08/30/2012 09:26 AM, Gerry Reno wrote: If I run the command under root I see a more extensive output but having same problems w/1024x768: (*) DirectFB/Core/WM: Default 0.3 (directfb.org) (!!!) *** ONCE [no mode found for 1024x768] *** [fbdev.c:1354 in dfb_fbdev_find_mode()] Gerry, what's the video card in that computer, and are you using an out-of-Fedora driver? ~tom == Fedora Project My laptop has one of the new Intel i7 Ivy Bridge CPU w/iGPU (Intel HD4000) plus Nvidia Geforce GT 650M Gerry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
On 08/30/2012 09:47 AM, Gerry Reno wrote: On 08/30/2012 09:40 AM, Tom Callaway wrote: On 08/30/2012 09:26 AM, Gerry Reno wrote: If I run the command under root I see a more extensive output but having same problems w/1024x768: (*) DirectFB/Core/WM: Default 0.3 (directfb.org) (!!!) *** ONCE [no mode found for 1024x768] *** [fbdev.c:1354 in dfb_fbdev_find_mode()] Gerry, what's the video card in that computer, and are you using an out-of-Fedora driver? ~tom == Fedora Project My laptop has one of the new Intel i7 Ivy Bridge CPU w/iGPU (Intel HD4000) plus Nvidia Geforce GT 650M I did not install any third-party driver. Just installed and ran F17 as-is out of the box. Gerry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
On 08/30/2012 11:16 AM, Adam Jackson wrote: On 8/30/12 9:26 AM, Gerry Reno wrote: (*) DirectFB/FBDev: Found 'inteldrmfb' (ID 0) with frame buffer at 0xc0064000, 8100k (MMIO 0x, 0k) So this says you're using the intel drm driver... (*) DirectFB/Core/WM: Default 0.3 (directfb.org) (!!!) *** ONCE [no mode found for 1024x768] *** [fbdev.c:1354 in dfb_fbdev_find_mode()] (*) FBDev/Mode: Setting 1024x768 RGB32 (*) FBDev/Mode: Switched to 1024x768 (virtual 1024x768) at 32 bit (RGB32), pitch 7680 (!) DirectFB/FBDev: Could not set gamma ramp-- Invalid argument (*) FBDev/Mode: Setting 1024x768 RGB16 (*) FBDev/Mode: Switched to 1024x768 (virtual 1024x768) at 16 bit (RGB16), pitch 7680 (!) DirectFB/FBDev: Could not set gamma ramp-- Invalid argument ... and this I believe is saying that drm's emulation of an fbdev interface is rather incomplete. Which I believe means either directfb needs to be taught about KMS, or KMS's fbdev emulation needs to be better, or both. - ajax Opened bug: https://bugzilla.redhat.com/show_bug.cgi?id=853268 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
On 08/28/2012 11:57 AM, Gerry Reno wrote: On 08/27/2012 10:59 PM, Ilyes Gouta wrote: Hi Gerry, Try contacting the main dev. mailing-list of DirectFB. I'm sure you'll get an answer there. Btw, DirectFB-1.5.3 is rather old, DirectFB-1.6.1 is rather the latest stable release. -Ilyes Thanks Ilyes. I'll try posting over on the directfb dev list. Gerry DirectFB says that there are Fedora packaging errors which are causing the undefined symbol on XUnlockDisplay and inability to run as normal user. Opened bugs: https://bugzilla.redhat.com/show_bug.cgi?id=852740 https://bugzilla.redhat.com/show_bug.cgi?id=852745 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
On 08/29/2012 02:33 PM, Tom Callaway wrote: On 08/29/2012 09:25 AM, Gerry Reno wrote: DirectFB says that there are Fedora packaging errors which are causing the undefined symbol on XUnlockDisplay and inability to run as normal user. Upstream is wrong, btw. The dlopen problem is caused by the fact that they don't pass the $(X11VDPAU_LIBS) to the LDFLAGS for linking libdirectfb_vdpau.la. The core issue behind why dfbinfo doesn't run as a normal user is due to the fact that the Linux kernel requires CAP_SYS_TTY_CONFIG to do any TTY ioctl() calls. UID 0 (root) has that, but normal users do not. It is possible to give a binary that capability using the setcap command. The missing udev rules also factor into this, I suspect. Last but not least, I believe a normal user needs to be in at least the tty and video groups. (and they need to be active, as reported by `groups`). Since there is no real way to handle this in the package, it just needs to be done by any user who wants to use dfbinfo: usermod -a -G tty video USERNAME I made an updated package (1.6.1) that has these fixes applied and sets the CAP_SYS_TTY_CONFIG capability to the dfbinfo binary. (Other DirectFB binaries probably need the same magic, but as I am not a DirectFB user, I can't really say which ones.) Please note that I could only get the dfbinfo results as an unprivileged user from the console (not from within X), and those results are not identical to what I get when I run it as root. When I tried to run it from X, my X session crashed and the kernel panicked. Good times. :) Anyways, Gerry, please test and let me know if these packages work for you, and once I hear back, I'll push out updates. http://koji.fedoraproject.org/koji/taskinfo?taskID=4435408 ~tom == Fedora Project Thanks Tom. I'll try to check your updates later today and report back. Gerry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
Tom,
Ok, I tried testing with the following settings:
$ ls -l /dev/tty{,0,1} /dev/fb{,0}
lrwxrwxrwx. 1 root root 3 Aug 21 21:52 /dev/fb - fb0
crw-rw-rw-. 1 root video 29, 0 Aug 21 21:52 /dev/fb0
crw-rw-rw-. 1 root tty5, 0 Aug 21 21:52 /dev/tty
crw--w. 1 root tty4, 0 Aug 21 21:52 /dev/tty0
crw--w. 1 root tty4, 1 Aug 21 21:52 /dev/tty1
$ groups
greno tty wheel dialout video vboxusers
$ grep greno /etc/group
tty:x:5:greno
wheel:x:10:greno
video:x:39:greno
dialout:x:18:greno
greno:x:1000:
vboxusers:x:988:greno
$ cat /etc/udev/rules.d/40-permissions.rules
KERNEL==fb[0-9]*, GROUP=video, MODE=0666
KERNEL==tty[0-9]*,GROUP=tty, MODE=0666
KERNEL==mice, MODE=0666
The result is this:
$ dfbinfo
~~| DirectFB 1.6.1 |~~
(c) 2001-2012 The world wide DirectFB Open Source Community
(c) 2000-2004 Convergence (integrated media) GmbH
(*) DirectFB/Core: Single Application Core. (2012-08-29 21:15)
(*) Direct/Memcpy: Using Generic 64bit memcpy()
(*) Direct/Thread: Started 'Fusion Dispatch' (-1) [MESSAGING OTHER/OTHER
0/0] 8388608...
(!) DirectFB/core/vt: Error opening `/dev/tty1'!
-- Permission denied
(!) DirectFB/Core: Could not initialize 'system_core' core!
-- A general initialization error occured
(#) DirectFBError [DirectFBCreate() failed]: A general initialization error
occured
Segmentation fault
I set the perms in the udev rules to 0666 but the tty does not setup that
way for some reason.
Gerry
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
On 08/29/2012 06:43 PM, Ilyes Gouta wrote: Gerry, You could also use DirectFB's X11 system module, so that you can run DirectFB-based applications in a usual X11 window. You can tell DirectFB so by using the DFBARGS environment variable: $ export DFBARGS=system=x11,mode=1280x800 (probably also w/ disable-module=gl) $./your_directfb_application Nicolas Chauvet is now upstreaming changes for Fedora to directfb-dev ML. -Ilyes That's great. I am using something similar through my .directfbrc file: $ cat ~/.directfbrc system=fbdev depth=16 mode=1024x768 autoflip-window force-windowed # autoport=2 Gerry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
On 08/27/2012 10:59 PM, Ilyes Gouta wrote: Hi Gerry, Try contacting the main dev. mailing-list of DirectFB. I'm sure you'll get an answer there. Btw, DirectFB-1.5.3 is rather old, DirectFB-1.6.1 is rather the latest stable release. -Ilyes Thanks Ilyes. I'll try posting over on the directfb dev list. Gerry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: DirectFB
On 08/24/2012 06:56 PM, Gerry Reno wrote: I have had no success whatsoever getting DirectFB to run under F17 as a regular user on my HP laptop. # yum list DirectFB Installed Packages directfb.x86_64 1.5.3-7.fc17 @updates I have discussed the problems on the DirectFB mailing list and they direct me back to the distro. When trying to run any DirectFB command as a regular user I get permission errors like this: $ dfbinfo ~~| DirectFB 1.5.3 |~~ (c) 2001-2010 The world wide DirectFB Open Source Community (c) 2000-2004 Convergence (integrated media) GmbH (*) DirectFB/Core: Single Application Core. (2012-05-19 15:35) (*) Direct/Memcpy: Using Generic 64bit memcpy() (!) DirectFB/core/vt: Error opening `/dev/tty1'! -- Permission denied (!) DirectFB/Core: Could not initialize 'system_core' core! -- A general initialization error occured (#) DirectFBError [DirectFBCreate() failed]: A general initialization error occured Even when I go and change the permissions on /dev/ttyX and /dev/fb/0 and then put those into udev rules then I still get an error about MEDIUMRAW mode. I am able to run some DirectFB commands as root but that is no good for creating app for general user. Can anyone, developer, packager, shed some light on why DirectFB will not run on F17 as a regular user? Thank you. . So after fixing permissions on tty and fb I can get to here: $ dfbinfo ~~| DirectFB 1.5.3 |~~ (c) 2001-2010 The world wide DirectFB Open Source Community (c) 2000-2004 Convergence (integrated media) GmbH (*) DirectFB/Core: Single Application Core. (2011-08-23 22:08) (!) DirectFB/fbdev/vt: K_MEDIUMRAW failed! -- Operation not permitted (!) DirectFB/Core: Could not initialize 'system_core' core! -- A general initialization error occured (#) DirectFBError [DirectFBCreate() failed]: A general initialization error occured $ What needs to be done to fix this error? Google is absolutely no help. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F17: DirectFB
I have had no success whatsoever getting DirectFB to run under F17 as a regular user on my HP laptop. # yum list DirectFB Installed Packages directfb.x86_64 1.5.3-7.fc17 @updates I have discussed the problems on the DirectFB mailing list and they direct me back to the distro. When trying to run any DirectFB command as a regular user I get permission errors like this: $ dfbinfo ~~| DirectFB 1.5.3 |~~ (c) 2001-2010 The world wide DirectFB Open Source Community (c) 2000-2004 Convergence (integrated media) GmbH (*) DirectFB/Core: Single Application Core. (2012-05-19 15:35) (*) Direct/Memcpy: Using Generic 64bit memcpy() (!) DirectFB/core/vt: Error opening `/dev/tty1'! -- Permission denied (!) DirectFB/Core: Could not initialize 'system_core' core! -- A general initialization error occured (#) DirectFBError [DirectFBCreate() failed]: A general initialization error occured Even when I go and change the permissions on /dev/ttyX and /dev/fb/0 and then put those into udev rules then I still get an error about MEDIUMRAW mode. I am able to run some DirectFB commands as root but that is no good for creating app for general user. Can anyone, developer, packager, shed some light on why DirectFB will not run on F17 as a regular user? Thank you. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On 07/30/2012 10:58 AM, Pasi Kärkkäinen wrote: On Thu, Jul 26, 2012 at 05:35:20PM -0400, Gerry Reno wrote: On 07/26/2012 05:12 PM, Matthew Garrett wrote: On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote: When booting Fedora 17 x64 there's the GRUB bootloader with graphical background image, I let it boot the default entry Fedora 17, I see it the allocating memory pages, loading VMLINUZ etc, and then the display mode / resolution changes, and then there's just blank screen and a cursor blinking.. If you see a resoution change then try booting with nomodeset. You might also see if you can get one of the alternate terminals. If that works then the kernel is booted and its just X which is not starting. I can't change terminals. I assume the kernel doesn't boot at all, or crashes very early. I can't see any kind of activity from Linux kernel after GRUB-efi messages and the screen switches to blank.. -- Pasi Have you tried booting with more logging? Without quiet param? . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On 07/30/2012 11:28 AM, Pasi Kärkkäinen wrote: On Mon, Jul 30, 2012 at 11:21:54AM -0400, Gerry Reno wrote: On 07/30/2012 10:58 AM, Pasi Kärkkäinen wrote: On Thu, Jul 26, 2012 at 05:35:20PM -0400, Gerry Reno wrote: On 07/26/2012 05:12 PM, Matthew Garrett wrote: On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote: When booting Fedora 17 x64 there's the GRUB bootloader with graphical background image, I let it boot the default entry Fedora 17, I see it the allocating memory pages, loading VMLINUZ etc, and then the display mode / resolution changes, and then there's just blank screen and a cursor blinking.. If you see a resoution change then try booting with nomodeset. You might also see if you can get one of the alternate terminals. If that works then the kernel is booted and its just X which is not starting. I can't change terminals. I assume the kernel doesn't boot at all, or crashes very early. I can't see any kind of activity from Linux kernel after GRUB-efi messages and the screen switches to blank.. -- Pasi Have you tried booting with more logging? Without quiet param? There's no quiet param. The default UEFI boot options are verbose as a default. I can't see *any* output from Linux kernel. Also I tried settings up SOL serial console, but I can't see any Linux messages there either. SOL stays empty/silent. Is serial console supposed to work OK in the usual way, with UEFI boot? And again: Booting in legacy BIOS mode works OK, and the serial console works there aswell. I have problems only in UEFI mode, where I can't get *any* output from Linux. -- Pasi Are you booting x86 or x86_64 version? I don't think x86 is supported for UEFI boot. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
I encountered a similar problem when using a new Intel Xeon (Ivy Bridge) CPU. The issue occurred with Ivy Bridge w/iGPU onboard. Ref: https://bugzilla.redhat.com/show_bug.cgi?id=840180 . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
There are missing Ivy Bridge definitions in the intel_chipset.h file in libdrm which causes machines with Ivy Bridge CPU's w/embedded iGPU to fail when starting X. As I said in the bug, installing libdrm 2.4.37 from bodhi fixed the issue on my F17 machine. On 07/26/2012 02:05 PM, Gerry Reno wrote: I encountered a similar problem when using a new Intel Xeon (Ivy Bridge) CPU. The issue occurred with Ivy Bridge w/iGPU onboard. Ref: https://bugzilla.redhat.com/show_bug.cgi?id=840180 . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On 07/26/2012 04:31 PM, Pasi Kärkkäinen wrote: On Thu, Jul 26, 2012 at 02:44:24PM -0400, Gerry Reno wrote: There are missing Ivy Bridge definitions in the intel_chipset.h file in libdrm which causes machines with Ivy Bridge CPU's w/embedded iGPU to fail when starting X. As I said in the bug, installing libdrm 2.4.37 from bodhi fixed the issue on my F17 machine. bz#840180 is a probably a different issue. My problem is that I can't even boot the f16/f17/rhel63 installer dvds because the UEFI boot doesn't work (it gets stuck with a blank screen), so I'm not able to install OS in UEFI mode.. Installing the same distros using legacy BIOS boot works OK. -- Pasi On 07/26/2012 02:05 PM, Gerry Reno wrote: I encountered a similar problem when using a new Intel Xeon (Ivy Bridge) CPU. The issue occurred with Ivy Bridge w/iGPU onboard. Ref: https://bugzilla.redhat.com/show_bug.cgi?id=840180 . Maybe UEFI is looking for a boot file and not finding it on DVD. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Debugging Fedora UEFI boot problems on Intel DQ77MK
On 07/26/2012 05:12 PM, Matthew Garrett wrote: On Thu, Jul 26, 2012 at 08:59:20PM +0300, Pasi Kärkkäinen wrote: When booting Fedora 17 x64 there's the GRUB bootloader with graphical background image, I let it boot the default entry Fedora 17, I see it the allocating memory pages, loading VMLINUZ etc, and then the display mode / resolution changes, and then there's just blank screen and a cursor blinking.. If you see a resoution change then try booting with nomodeset. You might also see if you can get one of the alternate terminals. If that works then the kernel is booted and its just X which is not starting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: kernel 3.4.4-5 refuses to boot
It worked. I grabbed the libdrm 2.4.37 rpm from bodhi and it fixed the problem on my Xeon(Ivy Bridge) machine. On 07/18/2012 05:32 PM, Adam Jackson wrote: On Wed, 2012-07-18 at 16:33 -0400, Gerry Reno wrote: On 07/18/2012 04:12 PM, Bruno Wolff III wrote: On Wed, Jul 18, 2012 at 15:21:24 -0400, Gerry Reno gr...@verizon.net wrote: Has there been any trouble booting the 3.4.4-5 kernel? I didn't have issues with it, but have now switched to 3.4.5-2 which is available from koji. It appears my machine has been bitten by this Xeon(Ivy Bridge) bug: https://bugzilla.redhat.com/show_bug.cgi?id=840180 There's a newer libdrm in koji that ought to resolve this, afaict: http://koji.fedoraproject.org/koji/buildinfo?buildID=328864 But it also changes a bunch of nouveau-related things that I don't feel comfortable touching. Ben, if the nouveau changes in 2.4.37 are safe, can you create an update for libdrm in bodhi? - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
kernel 3.4.4-5 refuses to boot
Has there been any trouble booting the 3.4.4-5 kernel? I updated one of my F17 machines today and it brought in a new kernel, 3.4.4-5. When I rebooted the box after all the updates completed it refused to boot. It just hangs with a non-blinking cursor in the upper left hand corner of a totally blank screen. The drive light will continue to blink for about 30 seconds and then no further drive activity. Have to power cycle the box to recover and boot into the previous kernel. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: kernel 3.4.4-5 refuses to boot
On 07/18/2012 04:12 PM, Bruno Wolff III wrote: On Wed, Jul 18, 2012 at 15:21:24 -0400, Gerry Reno gr...@verizon.net wrote: Has there been any trouble booting the 3.4.4-5 kernel? I didn't have issues with it, but have now switched to 3.4.5-2 which is available from koji. It appears my machine has been bitten by this Xeon(Ivy Bridge) bug: https://bugzilla.redhat.com/show_bug.cgi?id=840180 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
On 06/08/2012 08:07 AM, Mario Torre wrote: On Thu, 2012-06-07 at 14:34 -0500, Chris Adams wrote: that would not allow custom kernel and such. Don't support the locked down platform; the answer to Fedora on ARM is don't buy a Win8 ARM system and expect to run Fedora. One should be very, very careful with sentences like this one. With more and more machines turning to ARM, simply dismiss it as a don't buy a Win8 ARM *may* possibly work right now, but it will turn against us in the future. You don't need to be an Oracle to see where all of this is going. Cheers, Mario And I expect this idea of preventing other OS's from being installed on Win8 ARM hardware will not fly in the EU. It's anti-competitive. In fact, the whole concept of preventing dual-booting, and requiring x86 hardware to come with Secure Boot enabled by default probably won't fly either. That too is anti-competitive. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
On 06/08/2012 09:00 AM, drago01 wrote: On Fri, Jun 8, 2012 at 2:47 PM, Gerry Reno gr...@verizon.net wrote: On 06/08/2012 08:07 AM, Mario Torre wrote: On Thu, 2012-06-07 at 14:34 -0500, Chris Adams wrote: that would not allow custom kernel and such. Don't support the locked down platform; the answer to Fedora on ARM is don't buy a Win8 ARM system and expect to run Fedora. One should be very, very careful with sentences like this one. With more and more machines turning to ARM, simply dismiss it as a don't buy a Win8 ARM *may* possibly work right now, but it will turn against us in the future. You don't need to be an Oracle to see where all of this is going. Cheers, Mario And I expect this idea of preventing other OS's from being installed on Win8 ARM hardware will not fly in the EU. It's anti-competitive. Doubt that as they have near zero market power in that segment right now. One of the leaders in that space is selling locked down devices and nobody seems to care. In fact, the whole concept of preventing dual-booting, Nothing is preventing dual booting. and requiring x86 hardware to come with Secure Boot enabled by default probably won't fly either. Adding a security feature does fly just fine. That too is anti-competitive. Not really no. Oh please. It's disrupting the entire x86 ecosystem. It's destroying the existing freedoms that users of other operating systems currently enjoy on x86 hardware. It's impacting business models of companies that rely on open-source operating systems that run on x86 hardware. And it's security in name only. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
On 06/08/2012 09:20 AM, Peter Robinson wrote: On Fri, Jun 8, 2012 at 2:11 PM, Gerry Reno gr...@verizon.net wrote: On 06/08/2012 09:00 AM, drago01 wrote: On Fri, Jun 8, 2012 at 2:47 PM, Gerry Reno gr...@verizon.net wrote: On 06/08/2012 08:07 AM, Mario Torre wrote: On Thu, 2012-06-07 at 14:34 -0500, Chris Adams wrote: that would not allow custom kernel and such. Don't support the locked down platform; the answer to Fedora on ARM is don't buy a Win8 ARM system and expect to run Fedora. One should be very, very careful with sentences like this one. With more and more machines turning to ARM, simply dismiss it as a don't buy a Win8 ARM *may* possibly work right now, but it will turn against us in the future. You don't need to be an Oracle to see where all of this is going. Cheers, Mario And I expect this idea of preventing other OS's from being installed on Win8 ARM hardware will not fly in the EU. It's anti-competitive. Doubt that as they have near zero market power in that segment right now. One of the leaders in that space is selling locked down devices and nobody seems to care. In fact, the whole concept of preventing dual-booting, Nothing is preventing dual booting. and requiring x86 hardware to come with Secure Boot enabled by default probably won't fly either. Adding a security feature does fly just fine. That too is anti-competitive. Not really no. Oh please. It's disrupting the entire x86 ecosystem. It's destroying the existing freedoms that users of other operating systems currently enjoy on x86 hardware. It's impacting business models of companies that rely on open-source operating systems that run on x86 hardware. It's not doing any of that because you can disable it in the BIOS on x86. The whole purpose of this is to allow for a more secure OS and for something that works out of the box. Peter It does all that on x86 exactly because it is enabled by default. And on Win8 ARM you cannot disable. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
On 06/08/2012 10:11 AM, Chris Adams wrote: Once upon a time, Gerry Reno gr...@verizon.net said: And I expect this idea of preventing other OS's from being installed on Win8 ARM hardware will not fly in the EU. It's anti-competitive. You mean they don't have iPads and Android tablets in the EU? They do. And there are certainly anti-competitive claims that can be made related to certain ARM platforms. And now Samsung on latest devices has made it almost dead simple to unlock the bootloader. They can see the handwriting on the wall. And I expect we'll see all these bootloaders unlocked in the near future. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
On 06/08/2012 11:55 AM, Chris Murphy wrote: On Jun 8, 2012, at 6:47 AM, Gerry Reno wrote: And I expect this idea of preventing other OS's from being installed on Win8 ARM hardware will not fly in the EU. It's anti-competitive. There's no such prevention. It's just that by voluntary agreement some ARM hardware is being manufactured with Secure Boot enabled and disabling it isn't possible. To use other OS's requires they be capable of supporting Secure Boot, on such hardware. That doesn't seem to be anti-competitive at all. No. It's entirely anti-competitive: http://www.softwarefreedom.org/blog/2012/jan/12/microsoft-confirms-UEFI-fears-locks-down-ARM/ http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora ARM and SecureBoot
On 06/08/2012 01:04 PM, Adam Williamson wrote: On Fri, 2012-06-08 at 14:07 +0200, Mario Torre wrote: On Thu, 2012-06-07 at 14:34 -0500, Chris Adams wrote: that would not allow custom kernel and such. Don't support the locked down platform; the answer to Fedora on ARM is don't buy a Win8 ARM system and expect to run Fedora. One should be very, very careful with sentences like this one. With more and more machines turning to ARM, simply dismiss it as a don't buy a Win8 ARM *may* possibly work right now, but it will turn against us in the future. That is only assuming that Windows on ARM is successful, of which so far there's been precious little indication. There is a tidal wave of these PC ARM devices coming: http://www.itworld.com/hardware/240039/qualcomm-targets-pcs-takes-aim-intels-ultrabooks -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: System problems
On 06/07/2012 01:25 PM, Richard Vickery wrote: since the upgrade to 17, I've been experiencing system freezes on frequent occasions when getting up from the computer. The term frequent used in this context has a different meaning from constantly; there are many moments when I can get up to accomplish other tasks, and come back to a usable computer without rebooting, but there seem to be as many times when coming back to a system that is using all the resources to complete some task and not giving me access for at least 5 minutes. Most of the time I end up rebooting after waiting for 5 minutes. This is a much different experience from the experience up to F16. I may be operating under the influences left by the kernel panics during the testing phase. Might try testing the Live CD to see if it happens there as well. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F17: fatal errors on install
Today tried installing F17 x86_64 from DVD and get these errors: ERROR: could not insert 'floppy': No such device Loading Fedora 17 x86_64 installer... dracut Warning: Unable to process initqueue dracut Warning: /dev/disk/by-label/Fedorax2017x20x86_64 does not exist dracut Warning: /dev/mapper/live-rw does not exist Dropping to debug shell. dracut:/# This laptop does not have a 'floppy' device. Should installing F17 not be as simple as inserting DVD into drive and rebooting? Is there a workaround to get F17 installed from DVD? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/04/2012 10:24 AM, Jon Ciesla wrote: On Fri, Jun 1, 2012 at 3:10 PM, Gerry Reno gr...@verizon.net wrote: On 06/01/2012 03:56 PM, Jon Ciesla wrote: On Fri, Jun 1, 2012 at 2:37 PM, Gerry Reno gr...@verizon.net wrote: Drive manufacturers need to do nothing. One drive probably SSD at this point, gets dedicated to OS. Other drive to everything else. The read-write controllable interfaces already exist as I pointed out and are in use by forensic firms. And how many consumer OEMs ship them? -J Any Chinese fab would be able to produce any quantity needed within weeks to any number of OEM's. Key words, would be able. What OEM ships this *today*? That's my point. There are plenty of buttons/keys on machines right now that can be used to toggle this interface. It's 100% doable today with existing hardware. The whole point is that is that I provided just one example of an equally effective solution to SecureBoot that has much less impact on both Microsoft and Linux. The entire x86 industry is going to become a mess if SecureBoot is implemented. It'll be signature-HELL and a lot more. This whole SecureBoot runaway train needs to have the brakes slammed on. I'm not saying I love SecureBoot, but that ship has sailed. Yes, and just like the Titanic it will have a lasting horrible impact. Gerry I also wish Amiga hadn't futzed with their floppy drive stepper motors to squeeze in more sectors per disk and made my floppies unreadable without a trip to eBay, but that ship has sailed as well, so I pretty have to find the best solution available for the situation at hand. I would love for SecureBoot not to have happened, or to have happened differently. If wishes were horses, even the poor would eat. -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: fatal errors on install
On 06/04/2012 03:19 PM, Kevin Fenzi wrote: On Mon, 04 Jun 2012 15:06:46 -0400 Gerry Reno gr...@verizon.net wrote: Today tried installing F17 x86_64 from DVD and get these errors: ERROR: could not insert 'floppy': No such device Loading Fedora 17 x86_64 installer... dracut Warning: Unable to process initqueue dracut Warning: /dev/disk/by-label/Fedorax2017x20x86_64 does not exist dracut Warning: /dev/mapper/live-rw does not exist Dropping to debug shell. dracut:/# This laptop does not have a 'floppy' device. Should installing F17 not be as simple as inserting DVD into drive and rebooting? Is there a workaround to get F17 installed from DVD? Please help debug this issue at: https://bugzilla.redhat.com/show_bug.cgi?id=827644 kevin Burned another DVD and booting it got some other errors (rpcbind?) but it runs the installer at least. I'm doing custom partitioning and I selected to encrypt the LVM physical volume (LUKS) but now it is also asking about encrypting the filesystem for logical volume. Do I need both of these? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: fatal errors on install
On 06/04/2012 06:23 PM, Gerry Reno wrote: On 06/04/2012 03:19 PM, Kevin Fenzi wrote: On Mon, 04 Jun 2012 15:06:46 -0400 Gerry Reno gr...@verizon.net wrote: Today tried installing F17 x86_64 from DVD and get these errors: ERROR: could not insert 'floppy': No such device Loading Fedora 17 x86_64 installer... dracut Warning: Unable to process initqueue dracut Warning: /dev/disk/by-label/Fedorax2017x20x86_64 does not exist dracut Warning: /dev/mapper/live-rw does not exist Dropping to debug shell. dracut:/# This laptop does not have a 'floppy' device. Should installing F17 not be as simple as inserting DVD into drive and rebooting? Is there a workaround to get F17 installed from DVD? Please help debug this issue at: https://bugzilla.redhat.com/show_bug.cgi?id=827644 kevin Burned another DVD and booting it got some other errors (rpcbind?) but it runs the installer at least. I'm doing custom partitioning and I selected to encrypt the LVM physical volume (LUKS) but now it is also asking about encrypting the filesystem for logical volume. Do I need both of these? And another problem. You cannot edit the Volume Group name field. I need several Volume Groups but now I have no way to do this since there's no way to make them unique. :-( . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: fatal errors on install
On 06/04/2012 07:37 PM, Gerry Reno wrote: On 06/04/2012 06:23 PM, Gerry Reno wrote: On 06/04/2012 03:19 PM, Kevin Fenzi wrote: On Mon, 04 Jun 2012 15:06:46 -0400 Gerry Reno gr...@verizon.net wrote: Today tried installing F17 x86_64 from DVD and get these errors: ERROR: could not insert 'floppy': No such device Loading Fedora 17 x86_64 installer... dracut Warning: Unable to process initqueue dracut Warning: /dev/disk/by-label/Fedorax2017x20x86_64 does not exist dracut Warning: /dev/mapper/live-rw does not exist Dropping to debug shell. dracut:/# This laptop does not have a 'floppy' device. Should installing F17 not be as simple as inserting DVD into drive and rebooting? Is there a workaround to get F17 installed from DVD? Please help debug this issue at: https://bugzilla.redhat.com/show_bug.cgi?id=827644 kevin Burned another DVD and booting it got some other errors (rpcbind?) but it runs the installer at least. I'm doing custom partitioning and I selected to encrypt the LVM physical volume (LUKS) but now it is also asking about encrypting the filesystem for logical volume. Do I need both of these? And another problem. You cannot edit the Volume Group name field. I need several Volume Groups but now I have no way to do this since there's no way to make them unique. :-( . Opened bug on inability to edit Volume Group name: https://bugzilla.redhat.com/show_bug.cgi?id=828592 . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17: fatal errors on install
On 06/04/2012 07:44 PM, Kevin Fenzi wrote: On Mon, 04 Jun 2012 19:37:07 -0400 Gerry Reno gr...@verizon.net wrote: Burned another DVD and booting it got some other errors (rpcbind?) but it runs the installer at least. I'm doing custom partitioning and I selected to encrypt the LVM physical volume (LUKS) but now it is also asking about encrypting the filesystem for logical volume. Do I need both of these? And another problem. You cannot edit the Volume Group name field. I need several Volume Groups but now I have no way to do this since there's no way to make them unique. :-( The install guide might be of help... http://docs.fedoraproject.org/en-US/Fedora/17/html-single/Installation_Guide/index.html#encrypt-x86 And this is really the sort of question best suited to the users list: http://lists.fedoraproject.org/mailman/listinfo/users not the devel list. ;) kevin Hey Kevin, I've been custom partitioning Fedora installs since the beginning of anaconda. Look back several years and you'll find still unaddressed installation bugs for anaconda/preupgrade. For example /boot on RAID. And things in F17 installer are not exactly as described on the guide. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
So everyone needs to go out and buy twice as much RAM so F18+ can run /tmp as tmpfs without causing memory shortfalls for everything else they do. That's crazy. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 06/01/2012 11:05 AM, Gregory Maxwell wrote: On Fri, Jun 1, 2012 at 9:50 AM, Gerry Reno gr...@verizon.net wrote: So everyone needs to go out and buy twice as much RAM so F18+ can run /tmp as tmpfs without causing memory shortfalls for everything else they do. That's crazy. Thats not true (and I've used tmpfs for tmp for years, so I'm speaking from experience)— tmpfs is backed by swap on demand. Just add the space that you would have used for /tmp to your swap. Wait a minute. Back in this thread it says that half of RAM is allocated to the tmpfs for /tmp. Plus the purported benefit from this is causing less write cycles on SSD. (See Wiki page) That may have been a benefit a few years ago but newer SSD's will gain almost nothing from this because of the enormous number of write cycles they handle. This feature may have some benefits but I think they are infinitesimally small. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 11:18 AM, Cosimo Cecchi wrote: On Fri, 2012-06-01 at 03:14 +0200, Kevin Kofler wrote: Chris Adams wrote: - Secure boot is required to be able to be disabled on x86 (the only platform Fedora will support it). And this is exactly why we should just require our users to disable it! I don't want to jump in the technicality of this discussion, but I can only hope any solution that *requires* users to fiddle with BIOS settings in order to install Fedora won't be seriously considered as viable. Regards, Cosimo The better solution would be for users for want SecureBoot to have to set it in the BIOS. It should be disabled by default. Windows is the OS with all the attack vectors open. Users of every other OS should not be hostage to this SecureBoot by default. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Action required: Rawhide: /tmp is now on tmpfs
On 06/01/2012 11:52 AM, Alexey I. Froloff wrote: On Fri, Jun 01, 2012 at 11:31:21AM -0400, Brian Wheeler wrote: Well, since I'm probably going to turn it off, can someone give me a good reason why it should be turned _on_ by default? For me, the Benefit to Fedora bullets are not compelling. One good reason is to separate /tmp from /. When choosing between failed sort and failed passwd (or anything else, that modifies files in /), both because of No space left on device error I prefer failed sort and working passwd. And tmpfs is faster than any other filesystem, and easily resized both ways. Has anyone even done any real testing of this across the spectrum of installation types? How is this going to affect VM installations where RAM and swap is usually very minimal levels? 256mb or 512mb in many instances. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 12:07 PM, Kevin Kofler wrote: Peter Jones wrote: Next year if we don't implement some form of Secure Boot support, the majority of Fedora users will not be able to install Fedora on new machines. Nonsense. They will be able to install it very easily, they just need to set a single boolean in their BIOS setup from Enabled to Disabled. Kevin Kofler And what happens to all the people who now dual-boot both Linux and Windows. How can you boot Windows w/SecureBoot and Linux w/o SecureBoot? . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 12:10 PM, Gerry Reno wrote: On 06/01/2012 12:07 PM, Kevin Kofler wrote: Peter Jones wrote: Next year if we don't implement some form of Secure Boot support, the majority of Fedora users will not be able to install Fedora on new machines. Nonsense. They will be able to install it very easily, they just need to set a single boolean in their BIOS setup from Enabled to Disabled. Kevin Kofler And what happens to all the people who now dual-boot both Linux and Windows. How can you boot Windows w/SecureBoot and Linux w/o SecureBoot? . How are you going to dual-boot: Windows-8 and Windows-7 Windows-8 and Windows-XP Windows-8 and Windows 2008 Server Windows-8 and Fedora 16 Windows-8 and Fedora 17 Windows-8 and Fedora 18 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 12:30 PM, Kevin Kofler wrote: Debarshi Ray wrote: By the way, I am assuming that you know that one can't modify Firefox and redistribute it as Firefox without certification. I've been pointing out this issue in several threads. That's exactly why Fedora should finally follow Debian's lead and just rename Firefox. Kevin Kofler It's not going to matter b/c Chrome is eating Firefox lunch as far as market share. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 12:10 PM, Gerry Reno wrote: On 06/01/2012 12:07 PM, Kevin Kofler wrote: Peter Jones wrote: Next year if we don't implement some form of Secure Boot support, the majority of Fedora users will not be able to install Fedora on new machines. Nonsense. They will be able to install it very easily, they just need to set a single boolean in their BIOS setup from Enabled to Disabled. Kevin Kofler And what happens to all the people who now dual-boot both Linux and Windows. How can you boot Windows w/SecureBoot and Linux w/o SecureBoot? . How are you going to dual-boot: Windows-8 and Windows-7 Windows-8 and Windows-XP Windows-8 and Windows 2008 Server Windows-8 and Fedora 16 Windows-8 and Fedora 17 Windows-8 and Fedora 18 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 12:45 PM, Matthew Garrett wrote: On Fri, Jun 01, 2012 at 06:16:37PM +0200, Kevin Kofler wrote: Adam Jackson wrote: False. Quoting from Matthew's original post: A system in custom mode should allow you to delete all existing keys and replace them with your own. After that it's just a matter of re-signing the Fedora bootloader (like I said, we'll be providing tools and documentation for that) and you'll have a computer that will boot Fedora but which will refuse to boot any Microsoft code. Removing the M$ key is not viable because the firmware on some peripheral hardware will be signed only with the M$ key. It may be a little more awkward for desktops because you may have to handle the Microsoft-signed UEFI drivers on your graphics and network cards, but this is also solvable. I'm looking at ways to implement a tool to allow you to automatically whitelist the installed drivers. We are all, Microsoft included, headed for signature-HELL. This is going to gum up the entire x86 hardware ecosystem to such a point and Microsoft will rue the day they ever dreamt up this nonsense. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 12:55 PM, Kevin Kofler wrote: Tom Callaway wrote: Do we want to support dual-booting with Windows 8? Microsoft describes SecureBoot enablement as Required for Windows 8 client [1]? What does that mean? We're not sure. At best, it means that BitLocker isn't going to work, at worst, big chunks of Windows 8 functionality will simply refuse to function until you turn SecureBoot back on. You are assuming here that there will not be some cracker (or even just some frustrated dual boot user) patching this requirement out of Window$ 8 (no matter whether doing that is legal or not). (See what has been done to OS X and its restriction to Apple hardware only.) wHackindows-8 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 06/01/2012 12:27 PM, DJ Delorie wrote: The feature may be adopted/promoted on the basis of SSD writecycle preservation, I'm about to put in an SSD boot disk, so I care about this argument, but I'm still not using tmpfs, for my reasons stated previously. but tmpfs also offers considerable performance improvements for workloads that create/remove files in /tmp at high speed— This conclusion is NOT TRUE for me. I've checked it. /tmp on ext3 on my system does NOT incur any disk I/O until long after the process using it has finished, if at all, as long as the files are small and transient. And if they're neither small nor transient, RAM is the wrong place for them anyway. Perhaps a better solution is to look at TRIM support for the I/O buffers, and see if they're writing to the disk after the file has been deleted? If they're doing the sane thing, there should be no disk I/O at all anyway, unless you really needed disk storage in the first place. You may be interested in this bug: https://bugzilla.redhat.com/show_bug.cgi?id=826258 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
Windows-8 will install/boot on existing hardware w/o SecureBoot. Will Windows-8 install/boot on new hardware that contains SecureBoot without SecureBoot enabled? Can users flash BIOS to remove SecureBoot? . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 02:19 PM, Kevin Fenzi wrote: On Fri, 01 Jun 2012 14:16:45 -0400 Gerry Reno gr...@verizon.net wrote: Windows-8 will install/boot on existing hardware w/o SecureBoot. My understanding: no. There are multiple examples on the web of people installing Windows-8 on existing hardware. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 02:24 PM, Matthew Garrett wrote: On Fri, Jun 01, 2012 at 02:16:45PM -0400, Gerry Reno wrote: Windows-8 will install/boot on existing hardware w/o SecureBoot. Yes. Will Windows-8 install/boot on new hardware that contains SecureBoot without SecureBoot enabled? Yes. Can users flash BIOS to remove SecureBoot? No. Everyone is singing a different tune about these possibilities. My guesses would have been: Yes. No. Yes. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
I just read through the MS docs on SecureBoot and this is the biggest Rube-Goldberg machine. I could not think of a nastier solution to a problem than what they've dreamt up here. The whole problem they are trying to solve is that of booting only known-good code. That would be much easier accomplished by having the OS reside on a read-only device that could only be written to by the user actively using hardware to enable the write during installation. That would create a system where there was no possible programmatic means of corrupting the OS during normal operation. No signatures, no crypto-databases, or other SecureBoot gobbledy-gook needed. To implement this would require only that new systems support two drives, one with controllable-by-user read-write-controller interface for storing the OS. Forensic firms have been using these types of read-write controllable drive interfaces for years. Hardware already exists. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 03:22 PM, Adam Williamson wrote: On Fri, 2012-06-01 at 15:14 -0400, Gerry Reno wrote: I just read through the MS docs on SecureBoot and this is the biggest Rube-Goldberg machine. I could not think of a nastier solution to a problem than what they've dreamt up here. The whole problem they are trying to solve is that of booting only known-good code. That would be much easier accomplished by having the OS reside on a read-only device that could only be written to by the user actively using hardware to enable the write during installation. That would create a system where there was no possible programmatic means of corrupting the OS during normal operation. No signatures, no crypto-databases, or other SecureBoot gobbledy-gook needed. To implement this would require only that new systems support two drives, one with controllable-by-user read-write-controller interface for storing the OS. Forensic firms have been using these types of read-write controllable drive interfaces for years. Hardware already exists. What is your practical point? My practical point is that Microsoft chose this particular solution not as the best way to solve the issue of booting known-good code but as a way of impacting Linux and it whole concept of software freedoms. I don't think anybody in the Linux community should be supporting this SecureBoot solution in any way, shape or form. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 03:32 PM, Chris Murphy wrote: On Jun 1, 2012, at 1:14 PM, Gerry Reno wrote: That would be much easier accomplished by having the OS reside on a read-only device that could only be written to by the user actively using hardware to enable the write during installation. Except this hardware does not exist, and it only took about a decade to get 512e AF drives from concept to ship. Ergo not only not easier, not possible (practically anyway as people want to use SSDs and HDDs). And also except that your premise that all users, by default, have the competency to determine what software is to be trusted, and push a button on hardware typically located inside of an enclosure, is flawed. You're basically requiring a.) all users with laptops have the ability to physically open their laptops to push this button; or b.) a laptop case design that exposes this button, as if that isn't fraught with all sorts of potential problems. Forensic firms have been using these types of read-write controllable drive interfaces for years. Hardware already exists. And the commonality in environment, workflow, and user competency between forensic firms and Fedora users is maybe 5%? I mean, if we're going to just throw spaghetti at a wall, I get to make wild guesses too. It appears not even remotely practical, let alone in a ~6-12 month time frame. And there's zero incentive for drive manufacturers to do this and pass the cost onto all of their consumers. Chris Murphy Drive manufacturers need to do nothing. One drive probably SSD at this point, gets dedicated to OS. Other drive to everything else. The read-write controllable interfaces already exist as I pointed out and are in use by forensic firms. There are plenty of buttons/keys on machines right now that can be used to toggle this interface. It's 100% doable today with existing hardware. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 06/01/2012 03:56 PM, Jon Ciesla wrote: On Fri, Jun 1, 2012 at 2:37 PM, Gerry Reno gr...@verizon.net wrote: Drive manufacturers need to do nothing. One drive probably SSD at this point, gets dedicated to OS. Other drive to everything else. The read-write controllable interfaces already exist as I pointed out and are in use by forensic firms. And how many consumer OEMs ship them? -J Any Chinese fab would be able to produce any quantity needed within weeks to any number of OEM's. There are plenty of buttons/keys on machines right now that can be used to toggle this interface. It's 100% doable today with existing hardware. The whole point is that is that I provided just one example of an equally effective solution to SecureBoot that has much less impact on both Microsoft and Linux. The entire x86 industry is going to become a mess if SecureBoot is implemented. It'll be signature-HELL and a lot more. This whole SecureBoot runaway train needs to have the brakes slammed on. Gerry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs
On 05/31/2012 09:27 AM, Brian Wheeler wrote: On 05/31/2012 08:59 AM, Lennart Poettering wrote: * We bring Fedora closer to commercial Unixes and other Linux distributions. Um, so? Any solaris admin worth their salt kills the ram-based /tmp as soon as the install is finished. Its been that way since the 90's. Yes, so we too can be just like everyone else and have to kill the ram-based /tmp as soon as install finishes. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement SecureBoot is not about security. It is about restriction. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 12:06 PM, Peter Jones wrote: On 05/31/2012 12:04 PM, Gerry Reno wrote: SecureBoot is not about security. It is about restriction. If you're looking for a mantra to recite ad infinitum, that's a fine one, but right now we're looking for ideas that are helpful and productive instead. This is a monopolistic attack disguised as a security effort. The highly restrictive technological approach that has been taken needs to be challenged in the courts. I'd rather see Microsoft users have to attach a dongle to their system to get the security that they need. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 12:13 PM, Miloslav Trmač wrote: On Thu, May 31, 2012 at 6:04 PM, Gerry Reno gr...@verizon.net wrote: http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement SecureBoot is not about security. It is about restriction. That is just untrue. SecureBoot can be used to make sure you only run the software you intended to run, which is impossible without SecureBoot (e.g. this cannot be done with a TPM). The idea is solid, the technology is or can be made solid. No. The user is not in control here. Microsoft is in control. Try user-modifying a previously approved installation and see if you, the user, can boot it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 12:22 PM, Peter Jones wrote: On 05/31/2012 12:11 PM, Gerry Reno wrote: This is a monopolistic attack disguised as a security effort. The argument that it's a security effort is bolstered in many vendors eyes by the existence of attacks in the wild which Secure Boot would prevent. SecureBoot should only be Default:ON for Microsoft OS's and any other OS's that want to deal with that and should be Default:OFF for all others. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 12:46 PM, Peter Jones wrote: On 05/31/2012 12:16 PM, Gerry Reno wrote: On 05/31/2012 12:13 PM, Miloslav Trmač wrote: On Thu, May 31, 2012 at 6:04 PM, Gerry Renogr...@verizon.net wrote: http://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/statement SecureBoot is not about security. It is about restriction. That is just untrue. SecureBoot can be used to make sure you only run the software you intended to run, which is impossible without SecureBoot (e.g. this cannot be done with a TPM). The idea is solid, the technology is or can be made solid. No. The user is not in control here. Microsoft is in control. That's what we said in the working group. I'm not able to expand on that, as working group conversations are under NDA, but suffice it to say that argument didn't get us anywhere. The issue could be solved by having the SecureBoot default setting depend on the OS being booted: SecureBoot should only be Default:ON for Microsoft OS's and any other OS's that want to deal with that and should be Default:OFF for all others. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 12:57 PM, Basil Mohamed Gohar wrote: On 05/31/2012 12:53 PM, Gerry Reno wrote: On 05/31/2012 12:51 PM, Matthew Garrett wrote: On Thu, May 31, 2012 at 12:49:53PM -0400, Gerry Reno wrote: The issue could be solved by having the SecureBoot default setting depend on the OS being booted: SecureBoot should only be Default:ON for Microsoft OS's and any other OS's that want to deal with that and should be Default:OFF for all others. How do you distinguish between a non-Microsoft OS and a piece of malware that will then boot a Microsoft OS? The Microsoft OS should refuse to boot if it is being invoked in an unauthorized manner. . I take it that virtualization of the OS is completely off the table as well, then? (I think it must be, if this is the case.) Why would that be? VM's have a BIOS. And SecureBoot can be part of that BIOS. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 01:03 PM, Matthew Garrett wrote: On Thu, May 31, 2012 at 12:53:30PM -0400, Gerry Reno wrote: On 05/31/2012 12:51 PM, Matthew Garrett wrote: On Thu, May 31, 2012 at 12:49:53PM -0400, Gerry Reno wrote: The issue could be solved by having the SecureBoot default setting depend on the OS being booted: SecureBoot should only be Default:ON for Microsoft OS's and any other OS's that want to deal with that and should be Default:OFF for all others. How do you distinguish between a non-Microsoft OS and a piece of malware that will then boot a Microsoft OS? The Microsoft OS should refuse to boot if it is being invoked in an unauthorized manner. How does the Microsoft OS know that it's being invoked in an unauthorised manner? Could be any of a thousand ways to implement this. Maybe it checks the BIOS to determine whether some SecureBoot flag is set. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 01:10 PM, Gregory Maxwell wrote: On Thu, May 31, 2012 at 1:07 PM, Gerry Reno gr...@verizon.net wrote: Could be any of a thousand ways to implement this. Maybe it checks the BIOS to determine whether some SecureBoot flag is set. While it pains me to argue with someone on my side— you're incorrect. The compromised system would just intercept and emulate or patch out that test. Then what's missing here is a way for booted OS's to test themselves for integrity. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 01:19 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:16 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:10 PM, Gregory Maxwell wrote: On Thu, May 31, 2012 at 1:07 PM, Gerry Reno gr...@verizon.net wrote: Could be any of a thousand ways to implement this. Maybe it checks the BIOS to determine whether some SecureBoot flag is set. While it pains me to argue with someone on my side— you're incorrect. The compromised system would just intercept and emulate or patch out that test. Then what's missing here is a way for booted OS's to test themselves for integrity. Maybe some sort of cryptographic signature stored in the hardware? ducks -J /sarcasm Just not dictated by one monopoly. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 01:34 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:22 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:19 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:16 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:10 PM, Gregory Maxwell wrote: On Thu, May 31, 2012 at 1:07 PM, Gerry Reno gr...@verizon.net wrote: Could be any of a thousand ways to implement this. Maybe it checks the BIOS to determine whether some SecureBoot flag is set. While it pains me to argue with someone on my side— you're incorrect. The compromised system would just intercept and emulate or patch out that test. Then what's missing here is a way for booted OS's to test themselves for integrity. Maybe some sort of cryptographic signature stored in the hardware? ducks -J /sarcasm Just not dictated by one monopoly. Ideally, no. But you see the problem. I'm divided on the solution myself, but I've yet to see one I feel better about. -J This game of cat and mouse with the blackhats is not going to end until we have some type of read-only partitions where known good code resides. And the user must hit a hardware button to enable read-write to change anything there. We just keep pushing these blackhats to different layers. Next they'll be flashing our BIOSes and eliminating all protections SecureBoot and otherwise. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 01:47 PM, Matthew Garrett wrote: Platforms implementing secure boot will require cryptographically signed firmware updates, so the only way an attacker will be able to modify your system is by having physical access to the flash. Well, at least that part is good. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 01:48 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:42 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:34 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:22 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:19 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:16 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:10 PM, Gregory Maxwell wrote: On Thu, May 31, 2012 at 1:07 PM, Gerry Reno gr...@verizon.net wrote: Could be any of a thousand ways to implement this. Maybe it checks the BIOS to determine whether some SecureBoot flag is set. While it pains me to argue with someone on my side— you're incorrect. The compromised system would just intercept and emulate or patch out that test. Then what's missing here is a way for booted OS's to test themselves for integrity. Maybe some sort of cryptographic signature stored in the hardware? ducks -J /sarcasm Just not dictated by one monopoly. Ideally, no. But you see the problem. I'm divided on the solution myself, but I've yet to see one I feel better about. -J This game of cat and mouse with the blackhats is not going to end until we have some type of read-only partitions where known good code resides. We have that, ISO9660. Known good == known good to whom? Nah, can't be iso. Has to be HDD partitions whose ro/rw state is controlled by hardware. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 01:57 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:52 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:48 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:42 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:34 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:22 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:19 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:16 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:10 PM, Gregory Maxwell wrote: On Thu, May 31, 2012 at 1:07 PM, Gerry Reno gr...@verizon.net wrote: Could be any of a thousand ways to implement this. Maybe it checks the BIOS to determine whether some SecureBoot flag is set. While it pains me to argue with someone on my side— you're incorrect. The compromised system would just intercept and emulate or patch out that test. Then what's missing here is a way for booted OS's to test themselves for integrity. Maybe some sort of cryptographic signature stored in the hardware? ducks -J /sarcasm Just not dictated by one monopoly. Ideally, no. But you see the problem. I'm divided on the solution myself, but I've yet to see one I feel better about. -J This game of cat and mouse with the blackhats is not going to end until we have some type of read-only partitions where known good code resides. We have that, ISO9660. Known good == known good to whom? Nah, can't be iso. Has to be HDD partitions whose ro/rw state is controlled by hardware. Which brings us back to the issue of how the hardware knows what to trust for that ro/rw state. The hardware is under control of the user. At some point the user has to know what they consider trusted. During installation from a known good installation source: DVD, network, whatever, the user enables the install to write on the partition by actively pressing a hardware button that allows the write. After the installation is finished the user switches it back to read-only through pressing the hardware button. The user now has a known good read-only installation to boot from. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 02:17 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 1:08 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:57 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:52 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:48 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:42 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:34 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:22 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:19 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:16 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:10 PM, Gregory Maxwell wrote: On Thu, May 31, 2012 at 1:07 PM, Gerry Reno gr...@verizon.net wrote: Could be any of a thousand ways to implement this. Maybe it checks the BIOS to determine whether some SecureBoot flag is set. While it pains me to argue with someone on my side— you're incorrect. The compromised system would just intercept and emulate or patch out that test. Then what's missing here is a way for booted OS's to test themselves for integrity. Maybe some sort of cryptographic signature stored in the hardware? ducks -J /sarcasm Just not dictated by one monopoly. Ideally, no. But you see the problem. I'm divided on the solution myself, but I've yet to see one I feel better about. -J This game of cat and mouse with the blackhats is not going to end until we have some type of read-only partitions where known good code resides. We have that, ISO9660. Known good == known good to whom? Nah, can't be iso. Has to be HDD partitions whose ro/rw state is controlled by hardware. Which brings us back to the issue of how the hardware knows what to trust for that ro/rw state. The hardware is under control of the user. At some point the user has to know what they consider trusted. During installation from a known good installation source: DVD, network, whatever, the user enables the install to write on the partition by actively pressing a hardware button that allows the write. After the installation is finished the user switches it back to read-only through pressing the hardware button. The user now has a known good read-only installation to boot from. Is there an implementation of this existing today for HDD? Not yet. But HDD technology is changing rapidly. Just look at hybrid drives, SSD. No reason they could not add this capability. Because otherwise with existing technology, AFAIK, that limits your media choices for root fs medium to CD/DVD-R, Floppy, Zip/Jaz disc, or some models of USB flash drive. Yes, all these would currently support what I'm suggesting. Some of these would work better than others. :) -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 02:52 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 1:21 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 02:17 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 1:08 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:57 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:52 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:48 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:42 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:34 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:22 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:19 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:16 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:10 PM, Gregory Maxwell wrote: On Thu, May 31, 2012 at 1:07 PM, Gerry Reno gr...@verizon.net wrote: Could be any of a thousand ways to implement this. Maybe it checks the BIOS to determine whether some SecureBoot flag is set. While it pains me to argue with someone on my side— you're incorrect. The compromised system would just intercept and emulate or patch out that test. Then what's missing here is a way for booted OS's to test themselves for integrity. Maybe some sort of cryptographic signature stored in the hardware? ducks -J /sarcasm Just not dictated by one monopoly. Ideally, no. But you see the problem. I'm divided on the solution myself, but I've yet to see one I feel better about. -J This game of cat and mouse with the blackhats is not going to end until we have some type of read-only partitions where known good code resides. We have that, ISO9660. Known good == known good to whom? Nah, can't be iso. Has to be HDD partitions whose ro/rw state is controlled by hardware. Which brings us back to the issue of how the hardware knows what to trust for that ro/rw state. The hardware is under control of the user. At some point the user has to know what they consider trusted. During installation from a known good installation source: DVD, network, whatever, the user enables the install to write on the partition by actively pressing a hardware button that allows the write. After the installation is finished the user switches it back to read-only through pressing the hardware button. The user now has a known good read-only installation to boot from. Is there an implementation of this existing today for HDD? Not yet. But HDD technology is changing rapidly. Just look at hybrid drives, SSD. No reason they could not add this capability. Right. But it's not there now, which is my point. Actually it seems the forensic firms have been doing this for a while: http://www.digitalintelligence.com/forensicwriteblockers.php Their interfaces toggle the write wire to the drive. Because otherwise with existing technology, AFAIK, that limits your media choices for root fs medium to CD/DVD-R, Floppy, Zip/Jaz disc, or some models of USB flash drive. Yes, all these would currently support what I'm suggesting. Actually, if you're willing to flip a lot of switches, you could probably make your / a raid5 of floppies, but the performance would be suboptimal. -J Ok, now you're just being silly. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 04:04 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 2:57 PM, Jon Ciesla limburg...@gmail.com wrote: On Thu, May 31, 2012 at 2:07 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 02:52 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 1:21 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 02:17 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 1:08 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:57 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:52 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:48 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:42 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:34 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:22 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:19 PM, Jon Ciesla wrote: On Thu, May 31, 2012 at 12:16 PM, Gerry Reno gr...@verizon.net wrote: On 05/31/2012 01:10 PM, Gregory Maxwell wrote: On Thu, May 31, 2012 at 1:07 PM, Gerry Reno gr...@verizon.net wrote: Could be any of a thousand ways to implement this. Maybe it checks the BIOS to determine whether some SecureBoot flag is set. While it pains me to argue with someone on my side— you're incorrect. The compromised system would just intercept and emulate or patch out that test. Then what's missing here is a way for booted OS's to test themselves for integrity. Maybe some sort of cryptographic signature stored in the hardware? ducks -J /sarcasm Just not dictated by one monopoly. Ideally, no. But you see the problem. I'm divided on the solution myself, but I've yet to see one I feel better about. -J This game of cat and mouse with the blackhats is not going to end until we have some type of read-only partitions where known good code resides. We have that, ISO9660. Known good == known good to whom? Nah, can't be iso. Has to be HDD partitions whose ro/rw state is controlled by hardware. Which brings us back to the issue of how the hardware knows what to trust for that ro/rw state. The hardware is under control of the user. At some point the user has to know what they consider trusted. During installation from a known good installation source: DVD, network, whatever, the user enables the install to write on the partition by actively pressing a hardware button that allows the write. After the installation is finished the user switches it back to read-only through pressing the hardware button. The user now has a known good read-only installation to boot from. Is there an implementation of this existing today for HDD? Not yet. But HDD technology is changing rapidly. Just look at hybrid drives, SSD. No reason they could not add this capability. Right. But it's not there now, which is my point. Actually it seems the forensic firms have been doing this for a while: http://www.digitalintelligence.com/forensicwriteblockers.php Their interfaces toggle the write wire to the drive. But that's not currently available COTS hardware. Because otherwise with existing technology, AFAIK, that limits your media choices for root fs medium to CD/DVD-R, Floppy, Zip/Jaz disc, or some models of USB flash drive. Yes, all these would currently support what I'm suggesting. Actually, if you're willing to flip a lot of switches, you could probably make your / a raid5 of floppies, but the performance would be suboptimal. -J Ok, now you're just being silly. Absolutely. And to clarify, I was being silly to illustrate that what we're after cannot be practically done with currently available hardware. -J Hmm... Yes, but neither can Secure Boot. And I'd rather see a User-Controlled implementation rather than a Monopoly-Controlled implementation. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 04:26 PM, Gregory Maxwell wrote: On Thu, May 31, 2012 at 4:19 PM, Gerry Reno gr...@verizon.net wrote: And I'd rather see a User-Controlled implementation rather than a Monopoly-Controlled implementation. SecureBoot is (currently, on x86 but not arm) _also_ user-controlled. The monopoly controlled is just the default. I guess what I am saying is a User-only controlled implementation. No monopoly implementation needed. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 05:47 PM, Adam Williamson wrote: On Thu, 2012-05-31 at 16:31 -0400, Gerry Reno wrote: On 05/31/2012 04:26 PM, Gregory Maxwell wrote: On Thu, May 31, 2012 at 4:19 PM, Gerry Reno gr...@verizon.net wrote: And I'd rather see a User-Controlled implementation rather than a Monopoly-Controlled implementation. SecureBoot is (currently, on x86 but not arm) _also_ user-controlled. The monopoly controlled is just the default. I guess what I am saying is a User-only controlled implementation. No monopoly implementation needed. SecureBoot itself is exactly this. It specifies a framework. It just says, basically, 'hey, if we sign all these bits then we have a trusted boot path'. It doesn't state who should sign the bits. It doesn't care. It's Microsoft's Windows 8 Client labelling program that implements the 'monopoly control'. That's the program which requires compliant hardware to trust the Microsoft signing key. If you want to Opt Out Of The Monopoly, Man all you have to do is buy hardware which doesn't comply with Microsoft's program and trust Microsoft's key. Such hardware will exist. 99.,9% of x86 hardware is probably going to comply with this monopoly label program. Which means very limited hardware choices for those who want to opt-out. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: *countable infinities only
On 05/31/2012 09:14 PM, Kevin Kofler wrote: Chris Adams wrote: - Secure boot is required to be able to be disabled on x86 (the only platform Fedora will support it). And this is exactly why we should just require our users to disable it! I don't see any advantage at all from supporting this feature, just problems: * extra restrictions added to GRUB and the kernel to comply with the security (lockout) requirements. Even if they're all conditional on secure boot being enabled (are they really?), that still means extra code which can cause extra breakage even when running in normal mode (the one every Free Software user should be using). * possible GPL violation. Did Red Hat Legal have a look at the plans already? Are they sure they're compliant with the GPL, v2 when it comes to the kernel, v3 when it comes to GRUB 2? (What's sure is that they aren't compliant with the spirit of the GPL, whatever version!) * ineffectiveness of the added restrictions: Can't you still bring up a Blue Pill with a Window$ VM even with only unsigned userspace apps? And if we don't even allow those, where's the freedom? * exercising your freedom to change the kernel (or even just to load an out- of-tree module!) requires you to disable Secure (Restricted) Boot anyway, so why support the restricted mode? (As much as I hate proprietary drivers, you can definitely expect a horde of their users showing up at your door with a pitchfork…) * implicit endorsement of M$ and their signature racket (including a monetary payment to their racketing partner Veri$ign – was that already made?). It might even lead M$ to drop the requirement to allow disabling Secure Boot (or even invert it into a prohibition as on ARM!), arguing that Linux (sic, should be GNU/Linux) supports it too anyway. * dependence on the racket, which can change its terms at any moment. Just saying disable 'Secure' Boot in the BIOS is the easiest solution to the problem. I remember the days where one had to disable PlugPlay Operating System in the BIOS to get GNU/Linux to boot at all on some machines, it didn't cause any real problems. Kevin Kofler Agree 100%. This whole signature racket is the proverbial camel's nose under the tent which will eventually lead to Linux being ejected from x86 hardware. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SSD drives
On 05/25/2012 04:40 AM, Roberto Ragusa wrote: On 05/24/2012 03:20 PM, Gerry Reno wrote: Since I'm putting an SSD in my laptop this is important because the laptop drive must be encrypted. I hope your CPU has AES-NI. A powerful i7 does AES at 50MiB/s (don't remember exactly, but below 100MiB/s) without AES-NI and about 900MiB/s with AES-NI. SSDs speed is usually around 250MiB/s, so AES-NI is required to maintain speed. Additional hint: I would avoid xts modes, as the speed is halved (450MiB/s) for not really convincing security reasons. I'm running AES with NI on a SSD and the CPUs are almost undisturbed by disk activities. Cipher name:aes Cipher mode:cbc-essiv:sha256 Hash spec: sha256 Thanks Roberto. Yes, I have AES-NI in my i7 cpu. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: SSD drives
On 05/24/2012 04:45 AM, drago01 wrote: On Thu, May 24, 2012 at 10:30 AM, Juan Orti Alcaine j.orti.alca...@gmail.com wrote: 2012/5/24 Gerry Reno gr...@verizon.net What does Fedora do currently, if anything, to optimize for solid-state drives (SSD). Things like swap and logging can generate a huge number of writes. So I suppose those should maybe be placed on a rotating drive if one is available but if not does Fedora do anything to reduce the amount of writes? Or is everything related to SSD the responsibility of the user? Apart from correctly aligning the partitions, I think there are no more optimizations done by Fedora. I use a SSD and to get the best performance I use ext4 directly on the partitions, without LVM, Luks, RAID, etc. Also, here are a few tips: - Mount options: noatime to reduce writes. discard if your unit supports TRIM Yeah those too make sense (even though realatime should be enough). - Change the default scheduler: I created /etc/rc.d/rc.local with: #!/bin/bash /bin/echo noop /sys/block/sda/queue/scheduler This does not gain you much and hurts in some workloads. - Disable the readahead service: systemctl disable systemd-readahead-collect.service systemctl disable systemd-readahead-replay.service systemd should just do that by default (it disables it already when running on a VM). I also read here: http://ask.fedoraproject.org/question/909/enabling-trimdiscard-on-f16-using-lvm-on-luks about using TRIM with LUKS. Since I'm putting an SSD in my laptop this is important because the laptop drive must be encrypted. So is F17 going to support TRIM w/LUKS automatically? Or do we need to perform some special configuration to get TRIM w/LUKS? (Yes, I understand some attacker might be able to guess my filesystem type due to erased blocks - seems very low risk though). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
SSD drives
What does Fedora do currently, if anything, to optimize for solid-state drives (SSD). Things like swap and logging can generate a huge number of writes. So I suppose those should maybe be placed on a rotating drive if one is available but if not does Fedora do anything to reduce the amount of writes? Or is everything related to SSD the responsibility of the user? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RealHotspot availability
In looking back through some of the meeting minutes I saw that RealHotspot has been approved for Fedora 18. === #fedora-meeting: FESCO (2012-03-19) === Meeting started by limburgher at 18:00:23 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-03-19/fesco.2012-03-19-18.00.log.html . Meeting summary --- ... * #823 F18 Feature: Network Manager hotspots - https://fedoraproject.org/wiki/Features/RealHotspot (limburgher, 18:08:10) * AGREED: F18 Network Manager hotspots is passed (+8,-:0,0:0) (limburgher, 18:10:51) ... What are the chances of having RealHotspot backported for F17 and F16 and available as an update? None of my devices will connect using adhoc connection in my Fedora 16 installation and having a true AP hotspot would certainly improve things tremendously. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RealHotspot availability
On 05/18/2012 09:42 PM, Dan Williams wrote: On Fri, 2012-05-18 at 18:21 -0400, Gerry Reno wrote: In looking back through some of the meeting minutes I saw that RealHotspot has been approved for Fedora 18. === #fedora-meeting: FESCO (2012-03-19) === Meeting started by limburgher at 18:00:23 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-03-19/fesco.2012-03-19-18.00.log.html . Meeting summary --- ... * #823 F18 Feature: Network Manager hotspots - https://fedoraproject.org/wiki/Features/RealHotspot (limburgher, 18:08:10) * AGREED: F18 Network Manager hotspots is passed (+8,-:0,0:0) (limburgher, 18:10:51) ... What are the chances of having RealHotspot backported for F17 and F16 and available as an update? For F17 at least, quite good if your network card supports it. At the moment, that means Intel 6xxx and later, ath5k, ath9k, and perhaps a few others. Try this: iw phy and if under Supported interface modes: you see AP, then your card and driver are capable of real AP mode. Dan None of my devices will connect using adhoc connection in my Fedora 16 installation and having a true AP hotspot would certainly improve things tremendously. . Thanks Dan. # iw list | sed -n '/Supported interface modes/,/AP/p' Supported interface modes: * IBSS * managed * AP Looks like I'm good as far as my card and driver. Just hoping for a backport to F16 since I have one of those nvidia video cards that couldn't run F17. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]
On 05/14/2012 08:15 PM, Adam Williamson wrote: On Mon, 2012-05-14 at 11:49 -0700, John Reiser wrote: On 05/12/2012 09:51 PM, Matthew Garrett wrote: On Thu, May 10, 2012 at 11:00:48AM -0400, Adam Jackson wrote: So the set of people we'd be inconveniencing is exactly the set of people with no bandwidth and the inability to boot from anything larger than a CD. Not only that - the people who have no bandwidth, the inability to boot from anything larger than a CD and no USB ports that can be bootstrapped from a bootloader sitting on a CD or floppy. USB has been required by Microsoft's logo program since 1999 and was effectively ubiquitous on Pentium 2 before that, so the set of hardware we're ruling out is at least 13 years old and more realistically probably 15. We've already dropped support for x86 hardware that was in production more recently than that. Reality can differ from the press releases. I have two running machines that contradict the conclusions above. Instead of 13 or 15 years, such an effective cutoff would be closer to about 8 years. I consider that to be uncomfortably young to be declared obsolete, especially when the declaration is issued at the end of a release cycle instead of at the beginning. The most important issue in this thread is ability to boot from USB2.0. No, it isn't. mjg59 wrote: the inability to boot from anything larger than a CD and no USB ports that can be bootstrapped from a bootloader sitting on a CD or floppy. So you're talking past each other. You are assuming that direct boot from USB is the minimum. Matthew reckons bootstrapping from a CD or floppy is fine. You can bootstrap from a CD to then boot from USB drives: Example: http://www.howtogeek.com/howto/16822/boot-from-a-usb-drive-even-if-your-bios-wont-let-you/ . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]
On 05/15/2012 12:21 PM, Adam Williamson wrote: On Tue, 2012-05-15 at 09:52 -0400, Gerry Reno wrote: The most important issue in this thread is ability to boot from USB2.0. No, it isn't. mjg59 wrote: the inability to boot from anything larger than a CD and no USB ports that can be bootstrapped from a bootloader sitting on a CD or floppy. So you're talking past each other. You are assuming that direct boot from USB is the minimum. Matthew reckons bootstrapping from a CD or floppy is fine. You can bootstrap from a CD to then boot from USB drives: Example: http://www.howtogeek.com/howto/16822/boot-from-a-usb-drive-even-if-your-bios-wont-let-you/ U...yes. That's exactly what mjg59 said and what I pointed out more clearly that he said. Your saying it again does not immediately appear to contribute much to the debate. :) Just a concrete example for those that like such things. :-) . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]
If you watch, you can get DVD burners for about $15 USD. eg: http://slickdeals.net/permadeal/62972/newegg-liteon-external-cddvd-burner-w-lightscribe-support Or used for about $5-$10 at any flea market. On 05/09/2012 04:33 PM, drago01 wrote: On Wed, May 9, 2012 at 10:07 PM, Jaroslav Reznik jrez...@redhat.com wrote: I know I've said this before, but: we should break the CD size barrier precisely so people can't burn things to CDs. If you must burn to optical media, do yourself a favor and burn a DVD, the reduced seek time is entirely worth it. I'd like to break CD limit too but we should not forgot there are users for which CD is top technology from dreams and we have a lot of these users among some countries... Where are the numbers to back this nonsense up? A DVD burner costs ~12 € ... and any computer that old isn't really that capable of running fedora reasonably anyway. For me personally CD is history, even DVD, same 1 GB flash drive. We can afford it. But some people can't and are our users thanks to the ability to get a cheap OS, that can run on cheap HW and is still modern. See above. The question is - how many people will be affected? Or should we provide some fallback option - stripped down CD media size image? And make the bigger one primary one? Well anyone can create a specialized spin for ancient hardware, but we should not restrict ourselves because of ancient hardware. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]
On 05/09/2012 05:34 PM, John Reiser wrote: On 05/09/2012 01:33 PM, drago01 wrote: On Wed, May 9, 2012 at 10:07 PM, Jaroslav Reznik jrez...@redhat.com wrote: I'd like to break CD limit too but we should not forgot there are users for which CD is top technology from dreams and we have a lot of these users among some countries... Where are the numbers to back this nonsense up? A DVD burner costs ~12 € ... and any computer that old isn't really that capable of running fedora reasonably anyway. Such a claim is FALSE. My 700MHz PentiumIII with 384MB RAM runs Fedora 11 just fine. OpenOffice is eminently usable, for example. It's a 2001 laptop that has only CD-ROM and USB1.1, and the BIOS cannot boot from USB. I have added USB2.0 via PCMCIA card, and somewhere around Fedora 12 could boot from external DVD via USB2.0 (via trampoline from the harddrive) because the PCMCIA drivers for the bridge that enables the USB2.0 card were in the initrd. But then the PCMCIA drivers were dropped from initrd, so it no longer boots newer Fedora from DVD. Meanwhile deteriorating support for RagePro graphics has nudged me back to Fedora 11. Fedora 11 is only 3 years old. Just install over the network and not be stuck in Fedora 11. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F16: compile shotwell 0.12
Shotwell 0.10 has a nasty event name corruption bug so I thought I would try to compile 0.12 from source. I installed the dependencies: # yum install vala GConf2-devel libgee-devel libgexiv2-devel glib2-devel gstreamer-devel gstreamer-plugins-base-devel gtk3-devel libgudev1-devel libexif-devel libgphoto2-devel LibRaw-devel libsoup-devel libstdc++-devel libxml2-devel rest-devel sqlite-devel m4 unique3-devel webkitgtk3-devel ... Complete! # Then installed the source and tried to build: $ git clone git://yorba.org/shotwell Cloning into 'shotwell'... remote: Counting objects: 19253, done. remote: Compressing objects: 100% (6565/6565), done. remote: Total 19253 (delta 15637), reused 15439 (delta 12585) Receiving objects: 100% (19253/19253), 9.95 MiB | 1.84 MiB/s, done. Resolving deltas: 100% (15637/15637), done. $ cd shotwell $ ./configure Configured. Type 'make' to build, 'make install' to install. $ make Requested 'gexiv2 = 0.3.92' but version of GExiv2 is 0.2.2 make: *** [pkgcheck] Error 1 I thought I saw 0.3.91 available in F17 but that would fail as well. Has anybody managed to compile Shotwell 0.12 on F16 successfully? . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Booting Fedora from LVM with grub2
On 03/23/2012 11:26 AM, Reindl Harald wrote: Am 23.03.2012 16:19, schrieb Michael Cronenworth: David Lehman wrote: I was able to complete an install of F17-Alpha just now with all lvm. I had to force the use of MSDOS disklabel instead of GPT (used parted's mklabel command on tty2 while the anaconda prerelease warning was on screen on tty6) Does the anaconda option nogpt no longer exist? you have to boot with noefi as kernel-param to get rid of this whole GPT/EFI crap and end in a successful customized disk layout this took me THREE HOURS last monday to get a machne setup with 3 raid1 (/boot, / and /data), really poor have a OS installer not supporting /boot on a mirrored RAID leading in a unbootable system if the wrong disk fails in the year 2012 the F16 error message is useless, so i burned F15 again, got a better error message which brought the noefi option by google and since it was a DVD-RW after the first setup upgrade to F16 anaconda is really one of the most hated things of me since many years and because F17 alpha falls back on text-installation while manual partitioning is rmeoved in text-mode currently more than ever /boot on RAID is related to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=54 which I opened 3 years ago. Things have only gotten worse since. I can create virtually any type of layout when installing Ubuntu/Debian but not so with Fedora. Two things that would be useful are /boot on md0 array and creating RAID-1 arrays with just one disk (degraded, other disk to be added later). You can do all of these things manually outside of anaconda and then just tell anaconda to use existing setup. But that is not very user friendly. . -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 16 and Firefox 11 crashing hard
If I might interrupt this non-stop streaming ARM discussion for just a second, is anyone else having problems with Firefox 11 in Fedora 16? Firefox is crashing hard, as in shutting down the entire computer. And this is happening quite frequently. Firefox is stock. No addons, or changes. Just as it came from the packager. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 and Firefox 11 crashing hard
On 03/22/2012 05:20 PM, Gerry Reno wrote: On 03/22/2012 05:13 PM, Heiko Adams wrote: Am 22.03.2012 22:04, schrieb Gerry Reno: If I might interrupt this non-stop streaming ARM discussion for just a second, is anyone else having problems with Firefox 11 in Fedora 16? Firefox is crashing hard, as in shutting down the entire computer. And this is happening quite frequently. Firefox is stock. No addons, or changes. Just as it came from the packager. No problems here. Did you run memtest to make shure your RAM is okay? Regards, Heiko Haven't been having any other problems with other apps but I'll look at running memtest. Here are some particulars: kernel-PAE-3.2.10-3.fc16.i686 firefox-11.0-1.fc16.i686 Ok, I ran memtest86+ v4.20 and it passed with no errors. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 and Firefox 11 crashing hard
On 03/22/2012 07:44 PM, Chris Murphy wrote: On Mar 22, 2012, at 4:58 PM, Gerry Reno wrote: Just odd that Firefox is the only app causing the problem. I'll let memtest run a while. Yeah different apps have different memory requirements so it just may be doing something a little different than other apps. Plus it's kindof a princess porker when it comes to memory compared to most apps I use regularly. And I just updated to the new kernel, 3.3.0, so I'll try that out as well to see if it has any effect on this FF issue. LiveCD is slow but it regresses you on multiple fronts all in one whack, including kernel. Chris Murphy I may have found something. I started trying to keep track of what pages were causing the crashes in Firefox. All of them were on some secure pages. So I played around with the encryption settings and when I disabled TLS the crashes stopped. At least so far. I haven't had a crash in a couple hours now. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 and Firefox 11 crashing hard
On 03/22/2012 09:18 PM, Chris Murphy wrote: On Mar 22, 2012, at 6:58 PM, Gerry Reno wrote: So I played around with the encryption settings and when I disabled TLS the crashes stopped. At least so far. I haven't had a crash in a couple hours now. Change them back, reproduce crash, post the settings you're using. Chris Murphy I changed it back to using TLS and within 2 minutes it crashed. So what do you want? about:config? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 and Firefox 11 crashing hard
On 03/22/2012 10:00 PM, Gerry Reno wrote:
On 03/22/2012 09:18 PM, Chris Murphy wrote:
On Mar 22, 2012, at 6:58 PM, Gerry Reno wrote:
So I played around with the encryption settings and when
I disabled TLS the crashes stopped. At least so far. I haven't had a
crash in a couple hours now.
Change them back, reproduce crash, post the settings you're using.
Chris Murphy
I changed it back to using TLS and within 2 minutes it crashed.
So what do you want? about:config?
Here my prefs:
# Mozilla User Preferences
/* Do not edit this file.
*
* If you make changes to this file while the application is running,
* the changes will be overwritten when the application exits.
*
* To make a manual change to preferences, you can visit the URL
about:config
* For more information, see
http://www.mozilla.org/unix/customizing.html#prefs
*/
user_pref(accessibility.typeaheadfind.flashBar, 0);
user_pref(app.update.lastUpdateTime.addon-background-update-timer,
1332395740);
user_pref(app.update.lastUpdateTime.blocklist-background-update-timer,
1332395860);
user_pref(app.update.lastUpdateTime.search-engine-update-timer,
1332455292);
user_pref(browser.bookmarks.restore_default_bookmarks, false);
user_pref(browser.cache.disk.capacity, 1048576);
user_pref(browser.cache.disk.smart_size.first_run, false);
user_pref(browser.cache.disk.smart_size_cached_value, 727040);
user_pref(browser.migration.version, 5);
user_pref(browser.places.smartBookmarksVersion, 2);
user_pref(browser.preferences.advanced.selectedTabIndex, 3);
user_pref(browser.rights.3.shown, true);
user_pref(browser.startup.homepage, http://www.google.com/;);
user_pref(browser.startup.homepage_override.buildID,
20120313114719);
user_pref(browser.startup.homepage_override.mstone, rv:11.0);
user_pref(browser.startup.page, 3);
user_pref(browser.syncPromoViewsLeft, 0);
user_pref(extensions.blocklist.pingCountTotal, 4);
user_pref(extensions.blocklist.pingCountVersion, 4);
user_pref(extensions.bootstrappedAddons, {});
user_pref(extensions.databaseSchema, 12);
user_pref(extensions.enabledAddons,
{972ce4c6-7e08-4474-a285-3208198ce6fd}:11.0);
user_pref(extensions.installCache,
[{\name\:\app-global\,\addons\:{\{972ce4c6-7e08-4474-a285-3208198ce6fd}\:{\descriptor\:\/usr/lib/firefox/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}\,\mtime\:1332102434000}}}]);
user_pref(extensions.lastAppVersion, 11.0);
user_pref(extensions.lastPlatformVersion, 11.0);
user_pref(extensions.pendingOperations, false);
user_pref(extensions.ui.dictionary.hidden, true);
user_pref(extensions.ui.lastCategory, addons://discover/);
user_pref(extensions.ui.locale.hidden, true);
user_pref(idle.lastDailyNotification, 1332397019);
user_pref(intl.charsetmenu.browser.cache, us-ascii, ISO-8859-1,
UTF-8);
user_pref(network.cookie.prefsMigrated, true);
user_pref(places.database.lastMaintenance, 1332123449);
user_pref(places.history.expiration.transient_current_max_pages,
26301);
user_pref(privacy.sanitize.migrateFx3Prefs, true);
user_pref(security.disable_button.openCertManager, false);
user_pref(security.enable_tls, false);
user_pref(security.warn_viewing_mixed, false);
user_pref(storage.vacuum.last.index, 1);
user_pref(storage.vacuum.last.places.sqlite, 1332123449);
user_pref(urlclassifier.keyupdatetime.https://sb-ssl.google.com/safebrowsing/newkey;,
1334710422);
user_pref(xpinstall.whitelist.add, );
user_pref(xpinstall.whitelist.add.36, );
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 16 and Firefox 11 crashing hard
On 03/23/2012 12:50 AM, Chris Murphy wrote: On Mar 22, 2012, at 8:00 PM, Gerry Reno wrote: On 03/22/2012 09:18 PM, Chris Murphy wrote: On Mar 22, 2012, at 6:58 PM, Gerry Reno wrote: So I played around with the encryption settings and when I disabled TLS the crashes stopped. At least so far. I haven't had a crash in a couple hours now. Change them back, reproduce crash, post the settings you're using. Chris Murphy I changed it back to using TLS and within 2 minutes it crashed. You changed what back to what, exactly? Chris Murphy Under Preferences | Advanced | Encryption: Toggled TLS box -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: Fedora 16 w/encrypted filesystem: unable to boot Xen kernels
From xen-devel list. How can I downgrade my Fedora 16 kernel to get around this kernel bug identified by Konrad? Yum does not list any other kernels other than 3.2.10. Original Message Subject:Re: [Xen-devel] Fedora 16 w/encrypted filesystem: unable to boot Xen kernels Date: Wed, 21 Mar 2012 14:03:25 -0400 From: Konrad Rzeszutek Wilk konrad.w...@oracle.com To: Gerry Reno gr...@verizon.net CC: xen-de...@lists.xensource.com On Wed, Mar 21, 2012 at 01:04:42PM -0400, Gerry Reno wrote: I installed Fedora 16 on my laptop and selected encrypted filesystem for security. I then installed Xen from yum. I have the following grub entries: Fedora Linux, with Linux 3.2.10-3.fc16.i686.PAE Fedora Linux, with Linux 3.2.10-3.fc16.i686.PAE (recovery mode) Xen 4.1 Xen 4.1.2 Xen syms-4.1.2 Xen xen When I boot the baremetal kernel entries I get prompted for the encrypted disk password and the machine boots fine (no Xen). When I boot from any of the Xen entries I do not get prompted for the encrypted disk password and get an immediate kernel panic. How do I boot Xen kernel from encrypted filesystem on my laptop? Wel, the 3.2.10 has a bug that crashes the kernel. So use the older kernel (3.2.6?) There is a BZ openned for this. ___ Xen-devel mailing list xen-de...@lists.xen.org http://lists.xen.org/xen-devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
