Re: [Mageia-dev] beta 4 installer notes
'Twas brillig, and Thierry Vignaud at 10/04/13 06:03 did gyre and gimble: On 10 April 2013 06:58, Liam R E Quin l...@holoweb.net wrote: (5) a message, script failed for mailman_2.1.15-3.mga3-x86-64: (there was a blank line underneath but no more text) the exact error should be in your /root/drakx/install.log (also included in your /root/drakx/report.bug.xz) it is, but the blank message doesn't seem very polished. we can just be notified by rpm there was an error in a callback. We don't have details at that stage. Those were spit by rpm itself in the log file. There's nothing we can do [[ /var/tmp/rpm-tmp.J7elL9: line 31: crontab: command not found /usr/sbin/postconf: warning: inet_protocols: disabling IPv6 name/address support: Address family not supported by protocol postalias: warning: inet_protocols: disabling IPv6 name/address support: Address family not supported by protocol su: Insufficient credentials to access authentication data su: Insufficient credentials to access authentication data %post(mailman-2.1.15-3.mga3.x86_64) scriptlet failed, exit status 1 mailman-2.1.15-3.mga3.x86_64 ]] This is due to moving 'filesystem' %post script in basesystem-minimal I think. Out of completeness, why does this cause problems? Also I see no %post script in basesystem-minimal anyway so not sure how it could cause problems :D Do you maybe mean the pretrans stuff in filesystem package itself (written in lua)? Even still I'm not sure how this would affect paths as the symlinks should mean all binaries are available under the same paths as they were before. I can't rule it out of course, but I (so far) don't see how this could affect things. Could be fixed by making mailman doing this: Requires(post): basesystem-minimal That should solve the crontab issue (so a grep for that should also be done I guess - although having now done that, it seems only mailman uses it :D). Colin, could you grep for packages invoking su in their post script so that we can fix them all? Not many: openbravo/current/SPECS/openbravo.spec bacula/current/SPECS/bacula.spec mailman/current/SPECS/mailman.spec mercurial-server/current/SPECS/mercurial-server.spec cyrus-imapd/current/SPECS/cyrus-imapd.spec -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] M3 beta - where to report problems?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/04/13 20:48, Frank Griffin wrote: On 04/08/2013 02:41 PM, Anne Wilson wrote: No, it doesn't. When I ran XFdrake the test did display colours, though at a resolution I wouldn't want to work with :-) However, on reboot I still have a backlit black screen. I'm sure you are on the right track. It's not radeon, though, it's Intel 810 and later. I see that listed in XFdrake, but if I try to use it I'm told that there are no screens. Not sure what that means, though. When booting into rescue, I saw several items listed as Intel Corporation:NM10/ICH7 Family which sounds right to me. So - I need Intel drivers (and firmware). Can I use the same rescue processes to get the Internet working so that I can download them? Odd, though, that even VESA didn't work. Let me get this straight. You ran XFdrake for VESA chrooted to your root partition, got a decent test, and the real boot *still* screws up ? Weird. If you follow the process I gave, you should be able to start the network from within the chroot (provided you were able to start it from the rescue boot), or else it should already be up. You should then be able to run urpmi from within the chroot to install the firmware packages from nonfree. You'll need at least kernel-firmware-nonfree. Here's what else is there: [root@ftgme2 ftg]# cd /mnt/cauldron/x86_64/media/nonfree/release [root@ftgme2 release]# ls *firm* atmel-firmware-1.3-5.mga3.nonfree.noarch.rpm bluez-firmware-1.2-9.mga3.nonfree.noarch.rpm ipw2100-firmware-1.3-5.mga3.nonfree.noarch.rpm ipw2200-firmware-3.1-3.mga3.nonfree.noarch.rpm ivtv-firmware-20080701-1.mga3.nonfree.noarch.rpm kernel-firmware-nonfree-20130307-1.mga3.nonfree.noarch.rpm radeon-firmware-20120322-5.mga3.nonfree.noarch.rpm ralink-firmware-20130307-1.mga3.nonfree.noarch.rpm rtlwifi-firmware-20130307-1.mga3.nonfree.noarch.rpm speedtouch-firmware-0.1-10.mga3.nonfree.noarch.rpm If that doesn't work, then it sounds like your TTY configuration is screwed, and if that's the case, I'm tapped out. Colin would probably be the best one to ask what controls getty under systemd and how it's configured. I went through the following steps again: 1) Boot the rescue system 2) drvinst 3) mount your root as /mnt 4) do a mount --bind /dev /mnt/dev 5) do a chroot /mnt 6) do a mount -t proc none /proc 7) do a mount -t sysfs none /sys 8) do XFdrake 9) choose the x11 VESA or VGA driver (way down at bottom of list) except that this time I chose the Other:VESA (generic) driver. On closing XFdrake I got ioctl EVIOCGBIT failed: Inappropriate ioctl for device Is this to be expected? Anyway, on reboot it was exactly the same as before. Starting afresh, I followed the steps up to running XFdrake (but not running XFdrake yet). I tried 'ifup eth0' but 'Running in chroot. Ignoring request'. After exit this changed to Running in chroot. ignoring request. ./network-functions: line 260: cd: /var/run/netreport: No such file or directory. Incidentally, how do you reboot or shutdown when in chroot - and/or how do you reverse the chroot? So - I'm back in console, without running any of the steps yet. Can you give me the command to add the non-free source and tell me how to get eth0 working? Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFlK3wACgkQj93fyh4cnBdNUgCeN1y9uB2DAkfJoueP3Fd9iVG1 Ci8AnidZeNz0E7+YTtxC1OpWPkPPaGwx =Rq2y -END PGP SIGNATURE-
Re: [Mageia-dev] M3 beta - where to report problems?
On 04/10/2013 05:06 AM, Anne Wilson wrote: I went through the following steps again: 1) Boot the rescue system 2) drvinst 3) mount your root as /mnt 4) do a mount --bind /dev /mnt/dev 5) do a chroot /mnt 6) do a mount -t proc none /proc 7) do a mount -t sysfs none /sys 8) do XFdrake 9) choose the x11 VESA or VGA driver (way down at bottom of list) except that this time I chose the Other:VESA (generic) driver. On closing XFdrake I got ioctl EVIOCGBIT failed: Inappropriate ioctl for device Is this to be expected? Anyway, on reboot it was exactly the same as before. No idea, sorry. Starting afresh, I followed the steps up to running XFdrake (but not running XFdrake yet). I tried 'ifup eth0' but 'Running in chroot. Ignoring request'. After exit this changed to Running in chroot. ignoring request. ./network-functions: line 260: cd: /var/run/netreport: No such file or directory. I guess just bring up eth0 before entering the chroot Incidentally, how do you reboot or shutdown when in chroot - and/or how do you reverse the chroot? chroot starts a shell. When you exit from that shell, you're out of the chroot. An ls /mnt should indicate where you are: if you see all of your root partition's root directories, you're out of it. Inside it, /mnt will contain whatever it contains on your root partition (if it even exists). So - I'm back in console, without running any of the steps yet. Can you give me the command to add the non-free source and tell me how to get eth0 working? It's urpmi.addmedia', but the exact syntax depends on where your mirror is. Check the man page.
Re: [Mageia-dev] M3 beta - where to report problems?
'Twas brillig, and Frank Griffin at 10/04/13 12:00 did gyre and gimble: Starting afresh, I followed the steps up to running XFdrake (but not running XFdrake yet). I tried 'ifup eth0' but 'Running in chroot. Ignoring request'. After exit this changed to Running in chroot. ignoring request. ./network-functions: line 260: cd: /var/run/netreport: No such file or directory. I guess just bring up eth0 before entering the chroot After entering the chroot, you can also do: mount -t tmpfs none /run systemd-tmpfiles --create rm -f /run/nologin That should initialise all the temporary files you might need for a running system. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] M3 beta - where to report problems?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/04/13 12:00, Frank Griffin wrote: Starting afresh, I followed the steps up to running XFdrake (but not running XFdrake yet). I tried 'ifup eth0' but 'Running in chroot. Ignoring request'. After exit this changed to Running in chroot. ignoring request. ./network-functions: line 260: cd: /var/run/netreport: No such file or directory. I guess just bring up eth0 before entering the chroot ifup: configuration for eth0 not found - I had already tried that. Incidentally, how do you reboot or shutdown when in chroot - and/or how do you reverse the chroot? chroot starts a shell. When you exit from that shell, you're out of the chroot. An ls /mnt should indicate where you are: if you see all of your root partition's root directories, you're out of it. Inside it, /mnt will contain whatever it contains on your root partition (if it even exists). That's what I thought, but still after exit I get the Running in chroot messages :-( So - I'm back in console, without running any of the steps yet. Can you give me the command to add the non-free source and tell me how to get eth0 working? It's urpmi.addmedia', but the exact syntax depends on where your mirror is. Check the man page. As usual, lots of detail if you already understand it, but it seems to rely on you knowing URLs. I thought I could simply copy the URL from this system, adapting the version if it looked necessary, but if I look at Edit on the add-media page of MCC it just says $MIRRORLIST - and echo $MIRRORLIST doesn't tell me anything at all. There's obviously a real problem with the Intel drivers being removed by accident during the update. For everyone's sake, I'd like to try to identify the problem, but I feel as though I'm banging my head against a brick wall. Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFlTWoACgkQj93fyh4cnBfiNwCePLNYEFijQJcq7dzH1TUGSOfx G5UAn2x2U3C068Cpvv0F8RzJ1KF6NkPi =DBAF -END PGP SIGNATURE-
Re: [Mageia-dev] M3 beta - where to report problems?
On 04/10/2013 07:31 AM, Anne Wilson wrote: ifup: configuration for eth0 not found - I had already tried that. Interesting. I guess you didn't configure eth0 from the Install Summary. You can do it from the chroot (using Colin's suggestion) by running drakconnect. That's what I thought, but still after exit I get the Running in chroot messages :-( It's odd that a rescue system brought up through a network connection doesn't have it at runtime. Maybe try Colin's suggestion from the rescue system ? As usual, lots of detail if you already understand it, but it seems to rely on you knowing URLs. I thought I could simply copy the URL from this system, adapting the version if it looked necessary, but if I look at Edit on the add-media page of MCC it just says $MIRRORLIST - and echo $MIRRORLIST doesn't tell me anything at all. The syntax won't be identical, but you can get an idea of the URL to use by looking in /etc/urpmi/urpmi.cfg on your root partition to see what's being used for core release. There's obviously a real problem with the Intel drivers being removed by accident during the update. For everyone's sake, I'd like to try to identify the problem, but I feel as though I'm banging my head against a brick wall. There are really two issues here. One is getting your system to work again. The other is finding out what went wrong to begin with. For the latter, you should probably open a bug describing exactly what you did in the initial upgrade, and attaching the files from /root/drakx. I've never done a distro upgrade myself, as I install multiple fairly identical systems, and I keep a set of post-install scripts to bring a newly-installed system to the same state as a previous one. So I know virtually nil about the internals of how an upgrade actually works. If all else fails (and after you attach the files to the new bug), you could try re-running the upgrade. If you can get to package selection, Individual Package Selection may get you what you need, and Summary will allow you to configure video and network. But this will overlay the /root/drakx files.
[Mageia-dev] freeze push: ldetect-lst
Hi Please let in ldetect-lst. It fix using modesetting instead of fbdev for Poulsbo US15W(GMA500) (mga#8258) Please rebuild drakx-installer-stage2 with it once available. Thx
Re: [Mageia-dev] Mailing list migration: this list is closing
On 08/04/13 00:54, Mageia Sysadmins wrote: When the Mageia project was started, it didn't have any server. Fortunatly people from zarb.org proposed to host the basic project infrastructure (mainly the website, wiki and mailing lists) until the project can have its own servers. Mageia.Org now have a few servers since October 2010 (thanks to donations for the servers and Lost Oasis and Gandi for the hosting), but until now the existing mailing lists hosted by zarb.org had not been migrated to the Mageia mailing lists server. It is now time to do it and close this mailing list. This mailing list will be closed in coming hours and is now replaced by d...@ml.mageia.org. What does it mean, we cannot access it anymore from newsgroup gmane? If so, that sucks :-/
Re: [Mageia-dev] freeze push: ldetect-lst
Thierry Vignaud skrev 10.4.2013 19:12: Hi Please let in ldetect-lst. It fix using modesetting instead of fbdev for Poulsbo US15W(GMA500) (mga#8258) Please rebuild drakx-installer-stage2 with it once available. Thx Done .. Thomas
Re: [Mageia-dev] Freeze push: whois
Le 05/04/2013 14:54, Damien Lallement a écrit : Please submit whois 5.0.22 (5.0.20 for now): * Fixed cross-compiling, this time for real. (See #695442.) * Fixed parsing of 6to4 addresses: the last two bytes of the IPv4 address in 6to4 addresses were not parsed correctly since version 5.0.19. (Closes: #699928) * Added the .xn--j1amh (.укр, Ukraine) TLD server. * Updated the .bi, .se and .vn TLD servers. (Closes: #697753) * Removed whois.pandi.or.id from the list of servers which support the RIPE extensions, since it does not anymore and queries are broken. (Closes: #704115) * Updated some disclaimer suppression strings. * Respect DEB_HOST_GNU_TYPE when selecting CC for cross-compiling. (Closes: #695442) Thanks! Please submit 5.0.23: - whois.nic.or.kr switched from EUC-KR to UTF-8. (LP#1132526) Thanks! -- Damien Lallement twitter: damsweb - IRC: damsweb/coincoin
Re: [Mageia-dev] M3 beta - where to report problems?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/04/13 13:07, Frank Griffin wrote: On 04/10/2013 07:31 AM, Anne Wilson wrote: I think there may be some misunderstandings, so I'll try to correct them inline. Interesting. I guess you didn't configure eth0 from the Install Summary. I configured it to use dhcp, since netbooks are used in other places (I use the hotel cabled network when in Madeira). You can do it from the chroot (using Colin's suggestion) by running drakconnect. Drakconnect ran, I saw the waiting for network to be up followed by OK. If I now offer ifup eth0 I get Running in a chroot. ignoring request bind: Cannot assign requested address RTNETLINK answers: Network is unreachable ERROR: [etc/sysconfig/network-scripts/ifup-eth] Error adding default gateway 192.168.0.1 for eth0 NETLINK: Error: File exists and sbin/ifup: configuration for eth. Ping tells me that the network is unreachable. Running in a chroot. ignoring request That's what I thought, but still after exit I get the Running in chroot messages :-( It's odd that a rescue system brought up through a network connection doesn't have it at runtime. I'm running the rescue system from the DVD, not through a network. Maybe try Colin's suggestion from the rescue system I did, this time. As usual, lots of detail if you already understand it, but it seems to rely on you knowing URLs. I thought I could simply copy the URL from this system, adapting the version if it looked necessary, but if I look at Edit on the add-media page of MCC it just says $MIRRORLIST - and echo $MIRRORLIST doesn't tell me anything at all. The syntax won't be identical, but you can get an idea of the URL to use by looking in /etc/urpmi/urpmi.cfg on your root partition to see what's being used for core release. OK, if I can get the network up I'll see what I can do along those lines. There's obviously a real problem with the Intel drivers being removed by accident during the update. For everyone's sake, I'd like to try to identify the problem, but I feel as though I'm banging my head against a brick wall. There are really two issues here. One is getting your system to work again. The other is finding out what went wrong to begin with. I was hoping that we would be able to find some trace of what went wrong as we are working with this,l but by now maybe any relevant logs will be destroyed. For the latter, you should probably open a bug describing exactly what you did in the initial upgrade, and attaching the files from /root/drakx. I had intended to, but hoped to have more information before I do that. I have copied /root/drakx to /root/drakx-sav - hopefully this will preserve all we need. I've never done a distro upgrade myself, Out of curiosity I tried the distro upgrade. It appeared to complete, but booted to a blank screen, so I didn't waste any more time on it. I started afresh and did a clean install (though keeping /home). Something occurred to me today that may or may not be relevant. This problem with the Intel drivers being removed may not be a very new problem. I was running Cauldron successfully on this netbook for a long time, up to early January. Then I went away for three weeks. When I returned near the end of January I switched on and did a big update. After that I had a black screen, much like the current one. I thought it might be because something important had happened while I was away so that I had not made a necessary change at the right time, so I waited for the opportunity to do this install. It may be, then, that this was my first experience of this same bug. If all else fails (and after you attach the files to the new bug), you could try re-running the upgrade. If you can get to package selection, Individual Package Selection may get you what you need, and Summary will allow you to configure video and network. But this will overlay the /root/drakx files. As I said earlier, it was a clean install, not an upgrade, and it completed perfectly. I then rebooted as usual, and immediately used MCC to add all other media sources, and did the big update. This is when it went pear-shaped. Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFlrYkACgkQj93fyh4cnBfrPQCcCjc1VZZITOie+oPkkejgVAJT 4KQAn1kxdbyQ876yjuXjnRRDhf7lvp/I =V+vZ -END PGP SIGNATURE-
Re: [Mageia-dev] M3 beta - where to report problems?
On 04/10/2013 02:21 PM, Anne Wilson wrote: Out of curiosity I tried the distro upgrade. It appeared to complete, but booted to a blank screen, so I didn't waste any more time on it. I started afresh and did a clean install (though keeping /home). Something occurred to me today that may or may not be relevant. This problem with the Intel drivers being removed may not be a very new problem. I was running Cauldron successfully on this netbook for a long time, up to early January. Then I went away for three weeks. When I returned near the end of January I switched on and did a big update. After that I had a black screen, much like the current one. I thought it might be because something important had happened while I was away so that I had not made a necessary change at the right time, so I waited for the opportunity to do this install. It may be, then, that this was my first experience of this same bug. ... As I said earlier, it was a clean install, not an upgrade, and it completed perfectly. I then rebooted as usual, and immediately used MCC to add all other media sources, and did the big update. This is when it went pear-shaped. OK, so what did you do the clean install from ? From this last bit, it sounds like it was working after the install if you could boot and use MCC to add other media. I'm curious as to the timeframe window of what you installed and what you updated to.
Re: [Mageia-dev] M3 beta - where to report problems?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/04/13 19:50, Frank Griffin wrote: On 04/10/2013 02:21 PM, Anne Wilson wrote: Out of curiosity I tried the distro upgrade. It appeared to complete, but booted to a blank screen, so I didn't waste any more time on it. I started afresh and did a clean install (though keeping /home). Something occurred to me today that may or may not be relevant. This problem with the Intel drivers being removed may not be a very new problem. I was running Cauldron successfully on this netbook for a long time, up to early January. Then I went away for three weeks. When I returned near the end of January I switched on and did a big update. After that I had a black screen, much like the current one. I thought it might be because something important had happened while I was away so that I had not made a necessary change at the right time, so I waited for the opportunity to do this install. It may be, then, that this was my first experience of this same bug. ... As I said earlier, it was a clean install, not an upgrade, and it completed perfectly. I then rebooted as usual, and immediately used MCC to add all other media sources, and did the big update. This is when it went pear-shaped. OK, so what did you do the clean install from ? From this last bit, it sounds like it was working after the install if you could boot and use MCC to add other media. I'm curious as to the timeframe window of what you installed and what you updated to. I downloaded the latest beta - and checked the sha1sum before installing. It worked perfectly. I configured eth0 as dhcp, knowing that I'd have to get the wifi drivers later. I did the update immediately after the install - that would be the 3rd April, when I started this thread. I've now got those files from /root/drakx onto a usb stick - should I start the bug report now with those files? Anne -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFlvk4ACgkQj93fyh4cnBctCQCgiZZqTXCtTghyuFAB5wu6EeoT XRMAmwYR7dHQTf6fzt/qzIQW7N9MS09e =ksb8 -END PGP SIGNATURE-
Re: [Mageia-dev] M3 beta - where to report problems?
On 04/10/2013 03:32 PM, Anne Wilson wrote: I downloaded the latest beta - and checked the sha1sum before installing. It worked perfectly. I configured eth0 as dhcp, knowing that I'd have to get the wifi drivers later. I did the update immediately after the install - that would be the 3rd April, when I started this thread. I've now got those files from /root/drakx onto a usb stick - should I start the bug report now with those files? Wow. I was assuming all along that the problem stemmed from a massive upgrade from some MGA2 system. If you installed a 3rd April beta, had it working perfectly, and something uploaded to cauldron in the last week borked your system, I have no clue. And the fact that you've done this repeatedly indicates that it's not just an unstable mirror or some such. I wouldn't bother with the bug report for the /root/drakx stuff, since the install itself worked fine and gave you a working system. It's whatever came after that in the update that did the deed. If you have access to wired internet, is it possible for you to redo the clean install as a network install from a cauldron mirror ? It doesn't have to be a full install, as a minimal system (Custom and uncheck all the heavy stuff, just leave KDE as desktop) should give you an X environment to test. It would be interesting to know if a clean install of current cauldron exhibits the same problems on your hardware.
[Mageia-dev] freeze push
Please push (boost-1.53) : libkolabxml lyx zarafa libkolabxml and lyx build locally zarafa doesn't build locally (it supposedly was tested so it may build on the bs) -- Best regards Thomas Spuhler signature.asc Description: This is a digitally signed message part.
