wrong display resolution, F16, eeepc 901, should be 1024x600
by Fred Smith
Just did a test install of F16 (from the DVD, not live) on my eeepc
901. everything so far seems to be working, though I haven't yet
entered the wireless key.
but it failed to detect the correct display resolution. Every version
of Fedora since F10 has properly detected it, but this one thinks
it's 800x600.
This hardware has an older pre-Poulsbo intel video chip that has
always "just worked".
What to do now? create a org.conf, or some such?
Thanks in advance!
--
---- Fred Smith -- fredex(a)fcshome.stoneham.ma.us -----------------------------
"For him who is able to keep you from falling and to present you before his
glorious presence without fault and with great joy--to the only God our Savior
be glory, majesty, power and authority, through Jesus Christ our Lord, before
all ages, now and forevermore! Amen."
----------------------------- Jude 1:24,25 (niv) -----------------------------
12 years, 2 months
lapack
by Patrick Dupre
Hello,
I need to use the lapack library in fedora 16, but I cannot find
a lapack.h file!
lapack-devel-3.3.1-1 provides
liblapack.so only
while fedora 17 provides:
/usr/include/lapacke
/usr/include/lapacke/lapacke.h
/usr/include/lapacke/lapacke_config.h
/usr/include/lapacke/lapacke_utils.h
/usr/lib/liblapack.so
/usr/lib/liblapacke.so
Where can I get a lapack.h include file compatible?
Thank.
--
---
==========================================================================
Patrick DUPRÉ | |
Department of Chemistry | | Phone: (44)-(0)-1904-434384
The University of York | | Fax: (44)-(0)-1904-432516
Heslington | |
York YO10 5DD United Kingdom | | email: patrick.dupre(a)york.ac.uk
==========================================================================
12 years, 2 months
wodim. Burning an iso image
by Emilio Lopez
Hello,
Im trying to burn a dvd, but I get an error with wodim. What I'm missing?
Thank you.
Emilio.
I created the image like this
$>genisoimage -J -V mulo0 -o /media/backups/pcAlmeria/isos2/image0.iso
/media/backups/pcAlmeria/mulo/mulo.7z.001
/media/backups/pcAlmeria/mulo/mulo.7z.002
When I try to burn it, I get this error
$> wodim -v dev=1,0,0 /media/backups/pcAlmeria/isos2/image0.iso
wodim: No write mode specified.
wodim: Assuming -tao mode.
wodim: Future versions of wodim may have different drive dependent defaults.
TOC Type: 1 = CD-ROM
wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits.
scsidev: '1,0,0'
scsibus: 1 target: 0 lun: 0
WARNING: the deprecated pseudo SCSI syntax found as device specification.
Support for that may cease in the future versions of wodim. For now,
the device will be mapped to a block device file where possible.
Run "wodim --devices" for details.
Linux sg driver version: 3.5.34
Wodim version: 1.1.11
SCSI buffer size: 64512
Device type : Removable CD-ROM
Version : 5
Response Format: 2
Capabilities :
Vendor_info : 'hp '
Identification : 'CDDVDW TS-L633N '
Revision : '0300'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Current: 0x0011 (DVD-R sequential recording)
Profile: 0x0015 (DVD-R/DL sequential recording)
Profile: 0x0016 (DVD-R/DL layer jump recording)
Profile: 0x002B (DVD+R/DL)
Profile: 0x001B (DVD+R)
Profile: 0x001A (DVD+RW)
Profile: 0x0014 (DVD-RW sequential recording)
Profile: 0x0013 (DVD-RW restricted overwrite)
Profile: 0x0012 (DVD-RAM)
Profile: 0x0011 (DVD-R sequential recording) (current)
Profile: 0x0010 (DVD-ROM)
Profile: 0x000A (CD-RW)
Profile: 0x0009 (CD-R)
Profile: 0x0008 (CD-ROM)
Profile: 0x0002 (Removable disk)
Using generic SCSI-3/mmc DVD-R(W) driver (mmc_mdvd).
Driver flags : SWABAUDIO BURNFREE
Supported modes: PACKET SAO
Drive buf size : 1406976 = 1374 KB
Beginning DMA speed test. Set CDR_NODMATEST environment variable if device
communication breaks or freezes immediately after that.
FIFO size : 4194304 = 4096 KB
Track 01: data 4600 MB
Total size: 5283 MB (523:25.09) = 2355382 sectors
Lout start: 5283 MB (523:27/07) = 2355382 sectors
Current Secsize: 2048
HINT: use dvd+rw-mediainfo from dvd+rw-tools for information extraction.
Blocks total: 2298496 Blocks current: 2298496 Blocks remaining: -56886
wodim: WARNING: Data may not fit on current disk.
wodim: Notice: Most recorders cannot write CD's >= 90 minutes.
wodim: Notice: Use -ignsize option to allow >= 90 minutes.
wodim: Notice: Use -overburn option to write more than the official
disk capacity.
wodim: Notice: Most CD-writers do overburning only on SAO or RAW mode.
12 years, 2 months
preupgrade to Fedora 16 with grub2 upgrade failure?
by Michael D. Setzer II
Did a preupgrade from Fedora 14 to Fedora 16 on a system, and
everything seemed to go fine except the grub was not updated to
the grub2 as other upgrades I had done had.
I was able to get the older grub to boot the new kernel, by
manually editing the grub.conf file, but have not been able to fine
a way to get the grub2 to work or find info to fix it.
The fdisk shows the first partition starts at sector 63, and this
seems to give a message that the embeded area is to small.
The strange thing is that I have other systems that I upgraded that
have the same first partition starting at 63, but they have the
grub2 working? It might be that they were upgraded earlier, and
the grub2 might have fit in that area, but have seen messages
that say an update has made it no longer fit in that area.
Another system has a clean install of Fedora 16, and it has the
first partition starting at 2048.
Have thought of moving the first partition to free up space, but
gparted mentions that this might make the boot fail.
Is there some documentation that can help in getting the grub2
working?
+----------------------------------------------------------+
Michael D. Setzer II - Computer Science Instructor
Guam Community College Computer Center
mailto:mikes@kuentos.guam.net
mailto:msetzerii@gmail.com
http://www.guam.net/home/mikes
Guam - Where America's Day Begins
G4L Disk Imaging Project maintainer
http://sourceforge.net/projects/g4l/
+----------------------------------------------------------+
http://setiathome.berkeley.edu (Original)
Number of Seti Units Returned: 19,471
Processing time: 32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)
BOINC@HOME CREDITS
SETI 11891943.081134 | EINSTEIN 7431934.479852
ROSETTA 4285134.245134 | ABC 11488114.290956
12 years, 2 months
is fedora really bleeding edge?
by Stuart McGraw
One of the reason for using Fedora is quick access
to the latest software -- sometimes even too quick
(hence the "bleeding edge" moniker.)
But I have noticed this is not true for some things.
For example, in Fedora 15 python seems frozen at
python-2.7.1 even though -2.7.2 was released a long
time ago and fixes a number of bugs.
Another example is postgresql which remains in the
9.0.x release although 9.1.x contains a number of
significant new features.
Why do many packages follow the upstream faithfully
yet others seem to use a boat-anchor update policy?
Is there an official policy about this or is it a
matter of individual packagers' choice?
12 years, 2 months
Katello and Spacewalk
by Zoltan Hoppar
Hi,
Can somebody aggregate for me what are the differences and
similarities between the two software's?
Thanks,
Zoltan
--
PGP: 06853DF7
12 years, 2 months
USB3/PCIe -
by Bob Goodwin
I have an Fedora-16/64 computer in which I have plugged in an
SIIG "DP USB 3.0 4-port PCIe i/e host adapter." The computer, an
HP DM5700, acts as though it's not there? Dmidecode shows the
PCI Express system slot "available" with the card present.
I looked at the BIOS setup stuff and saw nothing that I
recognize as controlling that, but it could be something I don't
know.
So I guess my question is does it seem that I should be able to
plug the card in and have Fedora-16 recognize it? Does the fact
that it doesn't show up in dmidecode indicate that there is a
more basic problem, perhaps a jumper missing, etc. None of the
HP DM5700 documentation I have found is of much use in this area.
Bob
12 years, 2 months
lvm
by Patrick Dupre
Hello,
fdisk -l gives:
/dev/sda9 174809088 205529087 15360000 83 Linux
/dev/sda10 205531136 208603135 1536000 83 Linux
/dev/sda11 208605184 221302783 6348800 83 Linux
/dev/sda12 221304832 291960831 35328000 83 Linux
while
pvscan
PV /dev/sda12 VG VolGrpSys2 lvm2 [33.69 GiB / 0 free]
So sda12 is a lvm partition, but not recognized by fdisk
How can I fix this issue?
Thank.
--
---
==========================================================================
Patrick DUPRÉ | |
Department of Chemistry | | Phone: (44)-(0)-1904-434384
The University of York | | Fax: (44)-(0)-1904-432516
Heslington | |
York YO10 5DD United Kingdom | | email: patrick.dupre(a)york.ac.uk
==========================================================================
12 years, 2 months
Corrupt PV (wrong size)
by Richard Petty
GOAL: Retrieve a KVM virtual machine from an inaccessible LVM volume.
DESCRIPTION: In November, I was working on a home server. The system boots to software mirrored drives but I have a hardware-based RAID5 array on it and I decided to create a logical volume and mount it at /var/lib/libvirt/images so that all my KVM virtual machine image files would reside on the hardware RAID.
All that worked fine for a while. Later, I decided to expand that logical volume and that's when I made a mistake which wasn't discovered until about six weeks later when I accidentally rebooted the server. (Good problems usually require several mistakes.)
Somehow, I accidentally mis-specified the second LMV physical volume that I added to the volume group. When trying to activate the LV filesystem, the device mapper now complains:
LOG ENTRY: table: 253:3: sdc2 too small for target: start=2048, len=1048584192, dev_size=1048577586
As you can see, the length is greater than the device size.
I do not know how this could have happened. I assumed that LVM tool sanity checking would have prevented this from happening but....
I tried to migrate the data from the corrupt PV1 to a newly added PV3 and then drop PV1. PV1 is not full and PV3 has enough space to be a migration destination.
Unfortunately, is seems that using some of the LMV tools is predicated on the kernel being able to activate everything, which it refuses to do.
Can't migrate the data, can't resize anything. I'm stuck. If course I've done a lot of Google research over the months but I have yet to see a problem such as this solved.
Got ideas? Know an LVM guru?
==========================
LMV REPORT FROM /etc/lvm/archive BEFORE THE CORRUPTION
vg_raid {
id = "JLeyHJ-saON-6NSF-4Hqc-1rTA-vOWE-CU5aDZ"
seqno = 2
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192 # 4 Megabytes
max_lv = 0
max_pv = 0
metadata_copies = 0
physical_volumes {
pv0 {
id = "QaF9P6-Q9ch-bFTa-O3z2-3Idi-SdIw-YMLkQI"
device = "/dev/sdc1" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 419430400 # 200 Gigabytes
pe_start = 2048
pe_count = 51199 # 199.996 Gigabytes
}
}
logical_volumes {
kvmfs {
id = "Hs636n-PLcl-aivI-VbTe-CAls-Zul8-m2liRY"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 1
segment1 {
start_extent = 0
extent_count = 50944 # 199 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0
]
}
}
}
}
==========================
LMV REPORT FROM /etc/lvm/archive AS SEEN TODAY
vg_raid {
id = "JLeyHJ-saON-6NSF-4Hqc-1rTA-vOWE-CU5aDZ"
seqno = 13
status = ["RESIZEABLE", "READ", "WRITE"]
flags = []
extent_size = 8192 # 4 Megabytes
max_lv = 0
max_pv = 0
metadata_copies = 0
physical_volumes {
pv0 {
id = "QaF9P6-Q9ch-bFTa-O3z2-3Idi-SdIw-YMLkQI"
device = "/dev/sdc1" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 419430400 # 200 Gigabytes
pe_start = 2048
pe_count = 51199 # 199.996 Gigabytes
}
pv1 {
id = "8o0Igh-DKC8-gsof-FuZX-2Irn-qekz-0Y2mM9"
device = "/dev/sdc2" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 2507662218 # 1.16772 Terabytes
pe_start = 2048
pe_count = 306110 # 1.16772 Terabytes
}
pv2 {
id = "NuW7Bi-598r-cnLV-E1E8-Srjw-4oM4-77RJkU"
device = "/dev/sdb5" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 859573827 # 409.877 Gigabytes
pe_start = 2048
pe_count = 104928 # 409.875 Gigabytes
}
pv3 {
id = "eL40Za-g3aS-92Uc-E0fT-mHrP-5rO6-HT7pKK"
device = "/dev/sdc3" # Hint only
status = ["ALLOCATABLE"]
flags = []
dev_size = 1459084632 # 695.746 Gigabytes
pe_start = 2048
pe_count = 178110 # 695.742 Gigabytes
}
}
logical_volumes {
kvmfs {
id = "Hs636n-PLcl-aivI-VbTe-CAls-Zul8-m2liRY"
status = ["READ", "WRITE", "VISIBLE"]
flags = []
segment_count = 2
segment1 {
start_extent = 0
extent_count = 51199 # 199.996 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv0", 0
]
}
segment2 {
start_extent = 51199
extent_count = 128001 # 500.004 Gigabytes
type = "striped"
stripe_count = 1 # linear
stripes = [
"pv1", 0
]
}
}
}
}
==========================
I do have a intermediate versions of the /etc/lvm/archive files produced as I tinkered, in case they might be useful.
12 years, 2 months