[gentoo-user] Opera-12 license mask warning
I got this after an update yesterday and was left puzzled as to what I am meant to do ... !!! The following installed packages are masked: - www-client/opera-12.16_p1860-r1::gentoo (masked by: OPERA-12 license(s)) A copy of the 'OPERA-12' license is located at '/usr/portage/licenses/OPERA-12'. Is it a matter of adding in /etc/portage/make.conf: ACCEPT_LICENSE="OPERA-12" or am I supposed to go through some other ritual? Either way, couldn't the above message be more informative to do away with any guessing? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Opera-12 license mask warning
On 31/07/2016 09:56, Mick wrote: > I got this after an update yesterday and was left puzzled as to what I am > meant to do ... > > !!! The following installed packages are masked: > - www-client/opera-12.16_p1860-r1::gentoo (masked by: OPERA-12 license(s)) > A copy of the 'OPERA-12' license is located at > '/usr/portage/licenses/OPERA-12'. > > Is it a matter of adding in /etc/portage/make.conf: > > ACCEPT_LICENSE="OPERA-12" > > or am I supposed to go through some other ritual? Either way, couldn't the > above message be more informative to do away with any guessing? > echo $category/$package $license > /etc/portage/package.license I guess it's not listed explicitly in every ebuild with a non-free license because you are supposed to know how to unmask stuff on your on Gentoo system. The info is in the portage man pages -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Opera-12 license mask warning
On Sunday 31 Jul 2016 11:09:36 Alan McKinnon wrote: > On 31/07/2016 09:56, Mick wrote: > > I got this after an update yesterday and was left puzzled as to what I am > > meant to do ... > > > > !!! The following installed packages are masked: > > - www-client/opera-12.16_p1860-r1::gentoo (masked by: OPERA-12 license(s)) > > A copy of the 'OPERA-12' license is located at > > '/usr/portage/licenses/OPERA-12'. > > > > Is it a matter of adding in /etc/portage/make.conf: > > ACCEPT_LICENSE="OPERA-12" > > > > or am I supposed to go through some other ritual? Either way, couldn't > > the > > above message be more informative to do away with any guessing? > > echo $category/$package $license > /etc/portage/package.license > > I guess it's not listed explicitly in every ebuild with a non-free > license because you are supposed to know how to unmask stuff on your on > Gentoo system. > > The info is in the portage man pages Ahh! Yes, I had forgotten about that file. Thank you Alan. I was following http://www.gentoo.org/proj/en/glep/glep-0023.html and the ACCEPT_LICENSE directive in make.conf as a way of managing licenses, but then I found an entry about skype in package.license. Hmm ... I wonder who put that in there ... :-) I think this warning confused me because it installed the package and *then* it issued a warning about the license. Usually the warning comes before, requiring user input before it continues with the installation. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] NVidia drivers and vanilla kernel Linux 4.7.0 anyone?
Hello, On Sat, 30 Jul 2016, meino.cra...@gmx.de wrote: >David Haller [16-07-30 13:24]: [..] >> I've got it working with the attached patch in >> /etc/portage/patches/x11-drivers/nvidia-drivers-367.35/ [..] >Short qyestion: How can I apply it...I mean...as soon as I do an >emerge, either the original source will be unpacked or my package >will be rejected for being modified an different from the one, which >does not compile... In this case: just create the dir mkdir -p /etc/portage/patches/x11-drivers/nvidia-drivers-367.35/ and save the patch there. The rest works "as if by magic" thanks to the epatch-user in the ebuild. The version in the directory-name makes it only get applied to that version of the driver. HTH, -dnh -- If you fall and break your legs, don't come running to me. -- Samuel Goldwyn
Re: [gentoo-user] Opera-12 license mask warning
On Sun, 31 Jul 2016 10:45:55 +0100 Mick wrote: > On Sunday 31 Jul 2016 11:09:36 Alan McKinnon wrote: > > On 31/07/2016 09:56, Mick wrote: > > > I got this after an update yesterday and was left puzzled as to what I am > > > meant to do ... > > > > > > !!! The following installed packages are masked: > > > - www-client/opera-12.16_p1860-r1::gentoo (masked by: OPERA-12 license(s)) > > > A copy of the 'OPERA-12' license is located at > > > '/usr/portage/licenses/OPERA-12'. > > > > > > Is it a matter of adding in /etc/portage/make.conf: > > > ACCEPT_LICENSE="OPERA-12" > > > > > > or am I supposed to go through some other ritual? Either way, couldn't > > > the > > > above message be more informative to do away with any guessing? > > > > echo $category/$package $license > /etc/portage/package.license > > > > I guess it's not listed explicitly in every ebuild with a non-free > > license because you are supposed to know how to unmask stuff on your on > > Gentoo system. > > > > The info is in the portage man pages > > Ahh! Yes, I had forgotten about that file. Thank you Alan. > > I was following http://www.gentoo.org/proj/en/glep/glep-0023.html and the > ACCEPT_LICENSE directive in make.conf as a way of managing licenses, but then > I found an entry about skype in package.license. Hmm ... I wonder who put > that in there ... :-) > > I think this warning confused me because it installed the package and *then* > it issued a warning about the license. Usually the warning comes before, > requiring user input before it continues with the installation. This warning was added just recently per bug 573050. Both Opera licenses are clear EULA and thus were added to @EULA license group, which requires explicit user approval if default ACCEPT_LICENSE is used. That's why you have not seen the message during opera installation. For fresh install it will appear unless EULA is allowed in ACCEPT_LICENSE (I'm not recommending this, since EULA licenses are not supposed to be implicitly accepted.). Best regards, Andrew Savchenko pgpBb6VJcp3dD.pgp Description: PGP signature
Re: [gentoo-user] Opera-12 license mask warning
On Sunday 31 Jul 2016 13:27:59 Andrew Savchenko wrote: > On Sun, 31 Jul 2016 10:45:55 +0100 Mick wrote: > > On Sunday 31 Jul 2016 11:09:36 Alan McKinnon wrote: > > > On 31/07/2016 09:56, Mick wrote: > > > > I got this after an update yesterday and was left puzzled as to what I > > > > am > > > > meant to do ... > > > > > > > > !!! The following installed packages are masked: > > > > - www-client/opera-12.16_p1860-r1::gentoo (masked by: OPERA-12 > > > > license(s)) > > > > A copy of the 'OPERA-12' license is located at > > > > '/usr/portage/licenses/OPERA-12'. > > > > > > > > Is it a matter of adding in /etc/portage/make.conf: > > > > ACCEPT_LICENSE="OPERA-12" > > > > > > > > or am I supposed to go through some other ritual? Either way, > > > > couldn't > > > > the > > > > above message be more informative to do away with any guessing? > > > > > > echo $category/$package $license > /etc/portage/package.license > > > > > > I guess it's not listed explicitly in every ebuild with a non-free > > > license because you are supposed to know how to unmask stuff on your on > > > Gentoo system. > > > > > > The info is in the portage man pages > > > > Ahh! Yes, I had forgotten about that file. Thank you Alan. > > > > I was following http://www.gentoo.org/proj/en/glep/glep-0023.html and the > > ACCEPT_LICENSE directive in make.conf as a way of managing licenses, but > > then I found an entry about skype in package.license. Hmm ... I wonder > > who put that in there ... :-) > > > > I think this warning confused me because it installed the package and > > *then* it issued a warning about the license. Usually the warning comes > > before, requiring user input before it continues with the installation. > > This warning was added just recently per bug 573050. Both Opera > licenses are clear EULA and thus were added to @EULA license group, > which requires explicit user approval if default ACCEPT_LICENSE is > used. That's why you have not seen the message during opera > installation. For fresh install it will appear unless EULA is > allowed in ACCEPT_LICENSE (I'm not recommending this, since EULA > licenses are not supposed to be implicitly accepted.). > > Best regards, > Andrew Savchenko Thanks Andrew, I just looked at the bug and it makes sense. I don't have @EULA set for the same reason you mention. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Genlop oddity
Hello list, I've just encountered something I can't explain. Can anyone here? ~ $ genlop -c -f /mnt/rescue/var/log/emerge.log using logfile /mnt/rescue/var/log/emerge.log Currently merging 281 out of 287 * net-libs/gnutls-3.3.24 current merge time: 1 minute and 44 seconds. ETA: less than a minute. Currently merging 264 out of 287 * sys-devel/gcc-4.9.3 current merge time: 7 minutes and 12 seconds. ETA: 3 minutes and 13 seconds. $ genlop -c -f /mnt/rescue/var/log/emerge.log using logfile /mnt/rescue/var/log/emerge.log Currently merging 264 out of 287 * sys-devel/gcc-4.9.3 current merge time: 15 minutes and 19 seconds. ETA: 3 minutes and 41 seconds. How is it possible for genlop's reported ETA to increase while its time spent so far also increases? Could the concurrent gnutls merging have affected it? Surely not. Nothing else was running, apart from some file copying between external disks. -- Rgds Peter
[gentoo-user] Partition of 3TB USB drive not detected
Hi, for my backups I use a 3TB USB drive (one big ext4 partition) without any problems. Just plug in the cable, mount it and perform the backup. The partition (sdi1) is detected an mountable without any problems: === %< == $ ls -l /dev/disk/by-id total 0 lrwxrwxrwx 1 root root 9 Jul 31 13:17 ata- Crucial_CT500MX200SSD1_161512468483 -> ../../sda lrwxrwxrwx 1 root root 10 Jul 31 13:17 ata- Crucial_CT500MX200SSD1_161512468483-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Jul 31 13:17 ata- Crucial_CT500MX200SSD1_161512468483-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Jul 31 13:17 ata- Crucial_CT500MX200SSD1_161512468483-part3 -> ../../sda3 lrwxrwxrwx 1 root root 9 Jul 31 13:17 ata-HL-DT-ST_DVDRAM_GH41N_K5Q9AN32423 -> ../../sr0 lrwxrwxrwx 1 root root 9 Jul 31 15:20 ata-ST3000DM001-1CH166_Z1F45VR9 -> ../../sdi lrwxrwxrwx 1 root root 10 Jul 31 15:20 ata-ST3000DM001-1CH166_Z1F45VR9-part1 -> ../../sdi1 lrwxrwxrwx 1 root root 9 Jul 31 13:17 usb-Generic- _Compact_Flash_2006041309210-0:0 -> ../../sdc lrwxrwxrwx 1 root root 9 Jul 31 13:17 usb-Generic-_MS_MS- Pro_2006041309210-0:3 -> ../../sdf lrwxrwxrwx 1 root root 9 Jul 31 13:17 usb-Generic- _SD_MMC_2006041309210-0:2 -> ../../sde lrwxrwxrwx 1 root root 9 Jul 31 13:17 usb-Generic-_SM_xD- Picture_2006041309210-0:1 -> ../../sdd lrwxrwxrwx 1 root root 9 Jul 31 13:17 usb-Generic_Flash_HS- CF_26020128B005-0:0 -> ../../sdg lrwxrwxrwx 1 root root 9 Jul 31 13:17 usb-Generic_Flash_HS- COMBO_26020128B005-0:1 -> ../../sdh lrwxrwxrwx 1 root root 9 Jul 31 13:17 usb-INTENSO_USB_AA0401297518-0:0 -> ../../sdb lrwxrwxrwx 1 root root 10 Jul 31 13:17 usb-INTENSO_USB_AA0401297518-0:0- part1 -> ../../sdb1 lrwxrwxrwx 1 root root 9 Jul 31 15:20 wwn-0x5000c50065531ec5 -> ../../sdi lrwxrwxrwx 1 root root 10 Jul 31 15:20 wwn-0x5000c50065531ec5-part1 -> ../../sdi1 lrwxrwxrwx 1 root root 9 Jul 31 13:17 wwn-0x50014800 -> ../../sr0 lrwxrwxrwx 1 root root 9 Jul 31 13:17 wwn-0x500a075112468483 -> ../../sda lrwxrwxrwx 1 root root 10 Jul 31 13:17 wwn-0x500a075112468483-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 Jul 31 13:17 wwn-0x500a075112468483-part2 -> ../../sda2 lrwxrwxrwx 1 root root 10 Jul 31 13:17 wwn-0x500a075112468483-part3 -> ../../sda3 === %< == $ ls -l /dev/disk/by-label total 0 lrwxrwxrwx 1 root root 10 Jul 31 13:17 boot -> ../../sda1 lrwxrwxrwx 1 root root 10 Jul 31 13:17 gentoo -> ../../sda3 lrwxrwxrwx 1 root root 10 Jul 31 15:20 intenso -> ../../sdi1 lrwxrwxrwx 1 root root 10 Jul 31 13:17 swap -> ../../sda2 === %< == However, when I boot a rescue system from a USB stick, the partition on the USB is not detected. I already tried latest SystemRescueCD (default and alternate kernel), Knoppix and the Gentoo Admin CD. Nothing, the partition is not available. What's the difference? Why does my kernel find this partition and the other one's do not? It's pretty silly to have a backup drive and cannot access it in question ;-) - Jörg
Re: [gentoo-user] Genlop oddity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/31/2016 06:47 AM, Peter Humphrey wrote: > Hello list, > > I've just encountered something I can't explain. Can anyone here? > > ~ $ genlop -c -f /mnt/rescue/var/log/emerge.log > using logfile /mnt/rescue/var/log/emerge.log > > Currently merging 281 out of 287 > > * net-libs/gnutls-3.3.24 > >current merge time: 1 minute and 44 seconds. >ETA: less than a minute. > > Currently merging 264 out of 287 > > * sys-devel/gcc-4.9.3 > >current merge time: 7 minutes and 12 seconds. >ETA: 3 minutes and 13 seconds. > > $ genlop -c -f /mnt/rescue/var/log/emerge.log > using logfile /mnt/rescue/var/log/emerge.log > > Currently merging 264 out of 287 > > * sys-devel/gcc-4.9.3 > >current merge time: 15 minutes and 19 seconds. >ETA: 3 minutes and 41 seconds. > > How is it possible for genlop's reported ETA to increase while its time > spent so far also increases? It is an estimate (a prediction) so it's subject to change. > Could the concurrent gnutls merging have > affected it? Surely not. Probably, I don't know if genlop takes that into account. But there's countless factors that affect build time that it's practically impossible to predict accurately. So it means nothing. Does that estimate even look reasonable to you? gnutls compiles in a few minutes but gcc takes significantly longer for me. > > Nothing else was running, apart from some file copying between external > disks. > - -- Fernando Rodriguez -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXng/BAAoJEPbOFX/5Ulwcaw0P/07UJDhxAOhNp3NAf8awSMcR L8dIzDmssiABhyCH5GLCafSDujNelooOxvyy+Skf2BbNMSQk2gOiAOxjMQZSOmzC Sa8zh4PhfyV7jtsKLzjFFpuDHMJTH5Px9N3tvUfRuPSh6gtsmb1W+sD6AZr82KQI VwgH+QDLlO3jYkZGgyryIJXcL69QP1pspfBJ08iJk8y8hXbPla55aEmmrEI5HUsT 4LdineirvKYgDpMpErOoMgkZGy4BrUvPwVKyFmsHiB8byHl/Hcvsnb8tcyrrMpJ3 PU2QPpa/EcBiljlBiiE+ApSJHwOuv/ZMhltfYki/W1kdQHB9THN7sEdpDcjZUCs6 lKEAPe35nOizNoCMhHo1zFOB/5K6f2oLKdz/WP910eJ4CZkgWYyHvRCZJMN6jWZ1 AkwG9hcSQ+N7FAxXIQw15NLA9uky/vFOueu/NupUR6cJH1CmIBKZYe63PuTik2o6 3GIes2lHRUHroyCLnsfc9hxILXrzKkHEwFlgrtr6PhPPkchgqxBSHuB5hY5HfM1P cLgj9bj92sZLqwmImK/IRLn964119me2VEg8m1zYEAZLKuDsuAPrw2QtwO1W1APr ztok+sHWu51y36iC0oFBDuWKZG+612J1RfRZGgFXh0Vanh/dRjhLuUY8yuHB+Cka yEPhTh2DnZ8/MViBt1kt =a3yM -END PGP SIGNATURE-
Re: [gentoo-user] Partition of 3TB USB drive not detected
On 07/31/2016 06:37 AM, Jörg Schaible wrote: > Hi, > > for my backups I use a 3TB USB drive (one big ext4 partition) without any > problems. Just plug in the cable, mount it and perform the backup. The > partition (sdi1) is detected an mountable without any problems: > > === %< == > $ ls -l /dev/disk/by-id > total 0 > lrwxrwxrwx 1 root root 9 Jul 31 13:17 ata- > Crucial_CT500MX200SSD1_161512468483 -> ../../sda > lrwxrwxrwx 1 root root 10 Jul 31 13:17 ata- > Crucial_CT500MX200SSD1_161512468483-part1 -> ../../sda1 > lrwxrwxrwx 1 root root 10 Jul 31 13:17 ata- > Crucial_CT500MX200SSD1_161512468483-part2 -> ../../sda2 > lrwxrwxrwx 1 root root 10 Jul 31 13:17 ata- > Crucial_CT500MX200SSD1_161512468483-part3 -> ../../sda3 > lrwxrwxrwx 1 root root 9 Jul 31 13:17 ata-HL-DT-ST_DVDRAM_GH41N_K5Q9AN32423 > -> ../../sr0 > lrwxrwxrwx 1 root root 9 Jul 31 15:20 ata-ST3000DM001-1CH166_Z1F45VR9 -> > ../../sdi > lrwxrwxrwx 1 root root 10 Jul 31 15:20 ata-ST3000DM001-1CH166_Z1F45VR9-part1 > -> ../../sdi1 > lrwxrwxrwx 1 root root 9 Jul 31 13:17 usb-Generic- > _Compact_Flash_2006041309210-0:0 -> ../../sdc > lrwxrwxrwx 1 root root 9 Jul 31 13:17 usb-Generic-_MS_MS- > Pro_2006041309210-0:3 -> ../../sdf > lrwxrwxrwx 1 root root 9 Jul 31 13:17 usb-Generic- > _SD_MMC_2006041309210-0:2 -> ../../sde > lrwxrwxrwx 1 root root 9 Jul 31 13:17 usb-Generic-_SM_xD- > Picture_2006041309210-0:1 -> ../../sdd > lrwxrwxrwx 1 root root 9 Jul 31 13:17 usb-Generic_Flash_HS- > CF_26020128B005-0:0 -> ../../sdg > lrwxrwxrwx 1 root root 9 Jul 31 13:17 usb-Generic_Flash_HS- > COMBO_26020128B005-0:1 -> ../../sdh > lrwxrwxrwx 1 root root 9 Jul 31 13:17 usb-INTENSO_USB_AA0401297518-0:0 > -> ../../sdb > lrwxrwxrwx 1 root root 10 Jul 31 13:17 usb-INTENSO_USB_AA0401297518-0:0- > part1 -> ../../sdb1 > lrwxrwxrwx 1 root root 9 Jul 31 15:20 wwn-0x5000c50065531ec5 -> ../../sdi > lrwxrwxrwx 1 root root 10 Jul 31 15:20 wwn-0x5000c50065531ec5-part1 -> > ../../sdi1 > lrwxrwxrwx 1 root root 9 Jul 31 13:17 wwn-0x50014800 -> ../../sr0 > lrwxrwxrwx 1 root root 9 Jul 31 13:17 wwn-0x500a075112468483 -> ../../sda > lrwxrwxrwx 1 root root 10 Jul 31 13:17 wwn-0x500a075112468483-part1 -> > ../../sda1 > lrwxrwxrwx 1 root root 10 Jul 31 13:17 wwn-0x500a075112468483-part2 -> > ../../sda2 > lrwxrwxrwx 1 root root 10 Jul 31 13:17 wwn-0x500a075112468483-part3 -> > ../../sda3 > === %< == > $ ls -l /dev/disk/by-label > total 0 > lrwxrwxrwx 1 root root 10 Jul 31 13:17 boot -> ../../sda1 > lrwxrwxrwx 1 root root 10 Jul 31 13:17 gentoo -> ../../sda3 > lrwxrwxrwx 1 root root 10 Jul 31 15:20 intenso -> ../../sdi1 > lrwxrwxrwx 1 root root 10 Jul 31 13:17 swap -> ../../sda2 > === %< == > > However, when I boot a rescue system from a USB stick, the partition on the > USB is not detected. I already tried latest SystemRescueCD (default and > alternate kernel), Knoppix and the Gentoo Admin CD. Nothing, the partition > is not available. > > What's the difference? Why does my kernel find this partition and the other > one's do not? It's pretty silly to have a backup drive and cannot access it > in question ;-) > > - Jörg > > I can only think of two reasons, the kernel on the livecd doesn't support GPT (which is unlikely) or you're booting a 32-bit kernel live USB. I am reasonably certain for drives > 2TB a 64-bit kernel and GPT are required. Dan
Re: [gentoo-user] Genlop oddity
On Sunday 31 Jul 2016 10:48:33 Fernando Rodriguez wrote: > On 07/31/2016 06:47 AM, Peter Humphrey wrote: > > I've just encountered something I can't explain. Can anyone here? > > > > ~ $ genlop -c -f /mnt/rescue/var/log/emerge.log > > using logfile /mnt/rescue/var/log/emerge.log > > Currently merging 281 out of 287 > > * net-libs/gnutls-3.3.24 > >current merge time: 1 minute and 44 seconds. > >ETA: less than a minute. > > Currently merging 264 out of 287 > > > > * sys-devel/gcc-4.9.3 > >current merge time: 7 minutes and 12 seconds. > >ETA: 3 minutes and 13 seconds. > > > > $ genlop -c -f /mnt/rescue/var/log/emerge.log > > using logfile /mnt/rescue/var/log/emerge.log > > Currently merging 264 out of 287 > > * sys-devel/gcc-4.9.3 > >current merge time: 15 minutes and 19 seconds. > >ETA: 3 minutes and 41 seconds. > > > > How is it possible for genlop's reported ETA to increase while its time > > spent so far also increases? ...or to change at all, for that matter. > It is an estimate (a prediction) so it's subject to change. Yes, but the estimate is derived from an average of the durations found in the log file, so it can't change until the emerge is complete. > > Could the concurrent gnutls merging have affected it? Surely not. > > Probably, I don't know if genlop takes that into account. But there's > countless factors that affect build time that it's practically impossible > to predict accurately. So it means nothing. I think that's too pessimistic. If all your emerges have -j1, the accuracy is pretty good, or it used to be in the days when I did that. The major factor affecting the durations nowadays is -j > 1, so any other packages could be emerging at the same time, thus skewing the log record. Another, even bigger log skewer is my practice, if I need an emerge -e, of doing it in two stages: -eB first, then reboot to a minimal system and -eK. That avoids things like kdelibs being different when I come to reboot the system next time and hanging up during shutdown. > Does that estimate even look reasonable to you? > gnutls compiles in a few minutes but gcc takes significantly longer for > me. No, as I said, genlop's own estimates are poor nowadays, but I can make a rough estimate myself from comparing "genlop -c" with "genlop -t | grep minutes". -- Rgds Peter
Re: [gentoo-user] Partition of 3TB USB drive not detected
On 07/31/2016 08:37 AM, Jörg Schaible wrote: Hi, for my backups I use a 3TB USB drive (one big ext4 partition) without any problems. Just plug in the cable, mount it and perform the backup. The partition (sdi1) is detected an mountable without any problems: this tells you the device is valid and working. good. However, when I boot a rescue system from a USB stick, the partition on the USB is not detected. I already tried latest SystemRescueCD (default and alternate kernel), Knoppix and the Gentoo Admin CD. Nothing, the partition is not available. So there could be a multitude of reasons. Did thos systems have a bios that support booting from a usb device? Are the bios setting set to select the bios device correct? I recently read somewhere the usb devices only support (2) types of image booting, but I cannot find that doc right now. rodsbooks is an excellent resource for all the issues around booting and device and various hardware/firmware issues. LikeWhoa has made booting the usb for gentoo, commonplace so search out those postings on the gentoo forums and in the wiki. What's the difference? Why does my kernel find this partition and the other one's do not? It's pretty silly to have a backup drive and cannot access it in question ;-) It could be many things. You just have to ferret thru ideas until something works for your hardware, and it is a frustrating process. make sure the image you are trying to boot is on a compatible partition and file system that is supported by the boot image. hth, James
[gentoo-user] Re: Partition of 3TB USB drive not detected
Hi Daniel, thanks for your response. Daniel Frey wrote: [snip] > I can only think of two reasons, the kernel on the livecd doesn't > support GPT (which is unlikely) That would be really strange. However, how can I prove it? > or you're booting a 32-bit kernel live > USB. I am reasonably certain for drives > 2TB a 64-bit kernel and GPT > are required. No, I've always chosen 64-bit kernels. I wonder what is so special about this partition ... Cheers, Jörg
[gentoo-user] Re: Partition of 3TB USB drive not detected
Hi James, james wrote: > On 07/31/2016 08:37 AM, Jörg Schaible wrote: >> Hi, >> >> for my backups I use a 3TB USB drive (one big ext4 partition) without any >> problems. Just plug in the cable, mount it and perform the backup. The >> partition (sdi1) is detected an mountable without any problems: > > this tells you the device is valid and working. good. >> >> However, when I boot a rescue system from a USB stick, the partition on >> the USB is not detected. I already tried latest SystemRescueCD (default >> and alternate kernel), Knoppix and the Gentoo Admin CD. Nothing, the >> partition is not available. > > So there could be a multitude of reasons. Did thos systems have a bios > that support booting from a usb device? Are the bios setting set to > select the bios device correct? Well, same machine, same bios. > I recently read somewhere the usb devices only support (2) types of > image booting, but I cannot find that doc right now. rodsbooks is > an excellent resource for all the issues around booting and device > and various hardware/firmware issues. LikeWhoa has made booting the usb > for gentoo, commonplace so search out those postings on the gentoo > forums and in the wiki. > > >> What's the difference? Why does my kernel find this partition and the >> other one's do not? It's pretty silly to have a backup drive and cannot >> access it in question ;-) > > It could be many things. You just have to ferret thru ideas until > something works for your hardware, and it is a frustrating process. Definitely annoying. > make sure the image you are trying to boot is on a compatible partition > and file system that is supported by the boot image. It is. Thanks for the pointer to rodsbooks. - Jörg
Re: [gentoo-user] Re: Partition of 3TB USB drive not detected
On Sunday 31 Jul 2016 19:14:45 Jörg Schaible wrote: > Hi Daniel, > > thanks for your response. > > Daniel Frey wrote: > > [snip] > > > I can only think of two reasons, the kernel on the livecd doesn't > > support GPT (which is unlikely) > > That would be really strange. However, how can I prove it? If after you boot your systemrescuecd you can list: /sys/firmware/efi you have booted into UEFI mode. If not, you have booted into legacy BIOS mode. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: Partition of 3TB USB drive not detected
Jörg Schaible wrote: > Hi Daniel, > > thanks for your response. > > Daniel Frey wrote: > > [snip] > >> I can only think of two reasons, the kernel on the livecd doesn't >> support GPT (which is unlikely) > > That would be really strange. However, how can I prove it? > >> or you're booting a 32-bit kernel live >> USB. I am reasonably certain for drives > 2TB a 64-bit kernel and GPT >> are required. > > No, I've always chosen 64-bit kernels. I wonder what is so special about > this partition ... Currently I wonder, why my system can find the partition at all: %< # gdisk -l /dev/sdi GPT fdisk (gdisk) version 1.0.1 Partition table scan: MBR: protective BSD: not present APM: not present GPT: not present Creating new GPT entries. Disk /dev/sdi: 732566646 sectors, 2.7 TiB Logical sector size: 4096 bytes Disk identifier (GUID): 80C04475-9B51-4A44-A52F-1F165AE02695 Partition table holds up to 128 entries First usable sector is 6, last usable sector is 732566640 Partitions will be aligned on 256-sector boundaries Total free space is 732566635 sectors (2.7 TiB) Number Start (sector)End (sector) Size Code Name %< However, it's mounted successfully, see system logs: %< [22735.626752] sd 13:0:0:0: [sdi] 732566646 4096-byte logical blocks: (3.00 TB/2.73 TiB) [22735.629255] sdi: sdi1 [23414.066315] EXT4-fs (sdi1): mounted filesystem with ordered data mode. Opts: (null) %< Has anyone ever tried the recovery option of GPT disk to rebuild GPT from MBR? - Jörg
Re: [gentoo-user] Re: Partition of 3TB USB drive not detected
On Sun Jul 31 19:56:33 2016, Jörg Schaible wrote: > However, it's mounted successfully, see system logs: > > %< > [22735.626752] sd 13:0:0:0: [sdi] 732566646 4096-byte logical blocks: (3.00 > TB/2.73 TiB) > [22735.629255] sdi: sdi1 > [23414.066315] EXT4-fs (sdi1): mounted filesystem with ordered data mode. > Opts: (null) > %< I always see such log when I mount a partition. alarig@airmure ~ % dmesg | grep 'mounted filesystem' [3.145177] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null) [8.676445] EXT4-fs (sdg1): mounted filesystem with ordered data mode. Opts: (null) [ 777.844173] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts: (null) [ 795.083528] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts: (null) [ 1264.427746] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts: (null) [87490.418548] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts: (null) [260291.765065] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts: (null) [346692.663156] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts: (null) [433094.161678] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts: (null) [519494.540467] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts: (null) [591990.890105] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts: (null) (sdf1 is daily mounted and umounted due to a cron) -- alarig signature.asc Description: Digital signature
[gentoo-user] cross-compile attempt
Hi All,
I am dipping my toe into cross-compile territory, in order to build i686
binaries for a 32bit box, which is too old to do its own emerges. I am using
an amd64 box which is significantly faster to do all the heavy lifting and
started applying this page:
https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Creating_a_cross-compiler
which I followed up with:
https://wiki.gentoo.org/wiki/Cross_build_environment
and attempted to build @system:
=
# i686-pc-linux-gnu-emerge -uva @system
* IMPORTANT: 3 news items need reading for repository 'gentoo'.
* Use eselect news read to view new items.
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] sys-apps/busybox-1.24.2::gentoo to /usr/i686-pc-linux-gnu/
USE="make-symlinks static -debug -ipv6 -livecd -math -mdev -pam -savedconfig (-
selinux) -sep-usr -syslog -systemd" 0 KiB
Total: 1 package (1 new), Size of downloads: 0 KiB
Would you like to merge these packages? [Yes/No] y
* ARCH is not set... Are you missing the '/usr/i686-pc-linux-
* gnu/etc/portage/make.profile' symlink? Is the symlink correct? Is your
* portage tree complete?
===
As far as I can tell the link is there:
# ls -la /usr/i686-pc-linux-gnu/etc/portage/
total 8
drwxr-xr-x 1 root root 56 Jul 31 19:32 .
drwxr-xr-x 1 root root 20 Jul 31 18:32 ..
-rw-r--r-- 1 root root 1019 Jul 31 19:32 make.conf
lrwxrwxrwx 1 root root 30 Jul 31 17:48 make.profile ->
/usr/portage/profiles/embedded
drwxr-xr-x 1 root root 32 Jul 31 18:16 profile
and it was created when I ran 'crossdev --stable -v -t i686-pc-linux-gnu'.
My make.conf looks like this:
==
# cat /usr/i686-pc-linux-gnu/etc/portage/make.conf
CHOST=i686-pc-linux-gnu
CBUILD=x86_64-pc-linux-gnu
ARCH=x86
HOSTCC=x86_64-pc-linux-gnu-gcc
ROOT=/usr/${CHOST}/
ACCEPT_KEYWORDS="x86"
USE="${ARCH} -pam"
CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j5"
AUTOCLEAN="yes"
USE="a52 aac aalib acpi apache2 -arts asf avi cdda cddb cdparanoia crypt css
dri dts dv dvd dvdr dvdread divx -eds encode -esd flac fuse gif gimp gmedia -
gnome -gtk hpijs imlib -java lcms -libav live lzo mjpeg mmx mng modplug
mozdevelop mp3 mysql ncurses npp nptlonly nsplugin pdf ppds quicktime real
realmedia rtmp scanner semantic-desktop sse sse2 smp svg theora tiff usb utf8
vcd vhosts vorbis vram v4l webdav wmf wmp xcomposite xine xinerama xulrunner
xv xvid xvmc x264 yv12"
FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
# Be sure we dont overwrite pkgs from another repo..
PKGDIR=${ROOT}packages/
PORTAGE_TMPDIR=/var/tmp
ELIBC="glibc"
PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/"
#PORTDIR_OVERLAY="/usr/portage/local/"
What am I missing? How would/do you go about achieving the same objective?
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Partition of 3TB USB drive not detected
On 07/31/2016 12:56 PM, Jörg Schaible wrote: Jörg Schaible wrote: Hi Daniel, thanks for your response. Daniel Frey wrote: [snip] I can only think of two reasons, the kernel on the livecd doesn't support GPT (which is unlikely) That would be really strange. However, how can I prove it? or you're booting a 32-bit kernel live USB. I am reasonably certain for drives > 2TB a 64-bit kernel and GPT are required. No, I've always chosen 64-bit kernels. I wonder what is so special about this partition ... Currently I wonder, why my system can find the partition at all: %< # gdisk -l /dev/sdi GPT fdisk (gdisk) version 1.0.1 Partition table scan: MBR: protective BSD: not present APM: not present GPT: not present If you have seen my recent thread, much of this automounting during boot(strapping) is flaky that is much of what I have been searching out is a default (magical) partitioning schema that will eventually lead to clear documents on the current state of affairs not only with old versus new motherboards (mbr-->efi) and disk (mbr < 2.2T and gpt >2.2T) but including all sorts of new arm and other embedded (linux) boards. Different forms of Solid State memory are next on my list, with usb (1.x --> 3.x) being top of the SS memory mediums. (Sorry I do not have more atm). Creating new GPT entries. Disk /dev/sdi: 732566646 sectors, 2.7 TiB Logical sector size: 4096 bytes Disk identifier (GUID): 80C04475-9B51-4A44-A52F-1F165AE02695 Partition table holds up to 128 entries First usable sector is 6, last usable sector is 732566640 Partitions will be aligned on 256-sector boundaries Total free space is 732566635 sectors (2.7 TiB) Number Start (sector)End (sector) Size Code Name %< However, it's mounted successfully, see system logs: %< [22735.626752] sd 13:0:0:0: [sdi] 732566646 4096-byte logical blocks: (3.00 TB/2.73 TiB) [22735.629255] sdi: sdi1 [23414.066315] EXT4-fs (sdi1): mounted filesystem with ordered data mode. Opts: (null) %< Has anyone ever tried the recovery option of GPT disk to rebuild GPT from MBR? I see some sort of 'auto correction' by gpt technology to convert many forms of perceived mbr to gpt to be used by the booting process for spinning rust. So this issue is not limited to usb medium. I would also point out that I'd look deeply into the usb specs for the vendor of your usb sticks, as they do some 'funky things' at the firmware level inside many of the newer/faster/larger usb devices. It not just dumb memory like the early 1.x devices. Many are slanted to Microsoft business strategies. I'm not suggesting that is your current issues. I'm merely pointing out that some newer usb sticks are systems themselves complete with firmware so the devices looks like dumb memory. Furthermore, the silicon vendors provide firmware options to usb sticks vendors (like Texas Instruments) but also the vendor add to or change the hidden firmware as meets their multifaceted business objects. Sadly, the NSA is deeply involved here, as are many nation states and large corporations. You'd be surprised what youd find in a modern usb stick, should you take it into a class 6+ clean-room for analysis. The lower the particle count the more fantastic the tools to open up silicon and look deeply into what is actually going on. This is why folks love those classified research facilities that have govt contract and folks hanging around. Lots of very, very cool toys you just do not hear about.. Way beyond microscopes built by physicist. Prolly not your issue, but still present. Cheap ass usb vendors often have corner issues that are unintentional, that is why well recognized vendors of SS memory are the best to deal with, for consistency of behavior. I'd use as many different tools as you can find and read the vendor & silicon manufacturer's docs to see what you are really dealing with to ferret out this weirdness. (it's a darn time sync, just so you know). [1] http://www.cleanroom.byu.edu/particlecount.phtml hth, James
Re: [gentoo-user] cross-compile attempt
On 07/31/2016 01:40 PM, Mick wrote:
Hi All,
I am dipping my toe into cross-compile territory, in order to build i686
binaries for a 32bit box, which is too old to do its own emerges.
An excellent idea. As one who has performed the upgrade/downgrade
surgery on many systems; the single biggest issue is burning up
old hard drives and mobos. Keep the old hardware as cool as possible.
I place them under the vents of a 'window AC' set as cold as possible.
I'm thinking about modifying and old fridge to get around 40 degrees F
and low humidity, with a ethernet hub inside and single hole for the
hub to outside cables, packed off with rubber grommets and silicon
caulk. I'm tired of old hardware going dead on me
I am using
an amd64 box which is significantly faster to do all the heavy lifting and
started applying this page:
https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Creating_a_cross-compiler
Good reference. I would emphasize a few points.
1. Copy off (/var/lib/portage/world file and the /etc/*)
and others to another system.
2. Remove as many packages as possible before the compiling starts,
including window managers. I now keep my profile(s), for both servers
and workstations, as simple as possible.
3. At the last stage put the packages back that you need/want to
complete your tasks. Less complicated the packages are (KDE stands out)
the easier the work and cross-compiling is.
HEAT is your enemy and HEAT's last name is Murphy.
which I followed up with:
https://wiki.gentoo.org/wiki/Cross_build_environment
and attempted to build @system:
=
# i686-pc-linux-gnu-emerge -uva @system
* IMPORTANT: 3 news items need reading for repository 'gentoo'.
* Use eselect news read to view new items.
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] sys-apps/busybox-1.24.2::gentoo to /usr/i686-pc-linux-gnu/
USE="make-symlinks static -debug -ipv6 -livecd -math -mdev -pam -savedconfig (-
selinux) -sep-usr -syslog -systemd" 0 KiB
Total: 1 package (1 new), Size of downloads: 0 KiB
Would you like to merge these packages? [Yes/No] y
* ARCH is not set... Are you missing the '/usr/i686-pc-linux-
* gnu/etc/portage/make.profile' symlink? Is the symlink correct? Is your
* portage tree complete?
===
As far as I can tell the link is there:
# ls -la /usr/i686-pc-linux-gnu/etc/portage/
total 8
drwxr-xr-x 1 root root 56 Jul 31 19:32 .
drwxr-xr-x 1 root root 20 Jul 31 18:32 ..
-rw-r--r-- 1 root root 1019 Jul 31 19:32 make.conf
lrwxrwxrwx 1 root root 30 Jul 31 17:48 make.profile ->
/usr/portage/profiles/embedded
drwxr-xr-x 1 root root 32 Jul 31 18:16 profile
and it was created when I ran 'crossdev --stable -v -t i686-pc-linux-gnu'.
My make.conf looks like this:
==
# cat /usr/i686-pc-linux-gnu/etc/portage/make.conf
CHOST=i686-pc-linux-gnu
CBUILD=x86_64-pc-linux-gnu
ARCH=x86
HOSTCC=x86_64-pc-linux-gnu-gcc
ROOT=/usr/${CHOST}/
ACCEPT_KEYWORDS="x86"
USE="${ARCH} -pam"
CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"
MAKEOPTS="-j5"
AUTOCLEAN="yes"
USE="a52 aac aalib acpi apache2 -arts asf avi cdda cddb cdparanoia crypt css
dri dts dv dvd dvdr dvdread divx -eds encode -esd flac fuse gif gimp gmedia -
gnome -gtk hpijs imlib -java lcms -libav live lzo mjpeg mmx mng modplug
mozdevelop mp3 mysql ncurses npp nptlonly nsplugin pdf ppds quicktime real
realmedia rtmp scanner semantic-desktop sse sse2 smp svg theora tiff usb utf8
vcd vhosts vorbis vram v4l webdav wmf wmp xcomposite xine xinerama xulrunner
xv xvid xvmc x264 yv12"
FEATURES="-collision-protect sandbox buildpkg noman noinfo nodoc"
# Be sure we dont overwrite pkgs from another repo..
PKGDIR=${ROOT}packages/
PORTAGE_TMPDIR=/var/tmp
ELIBC="glibc"
PKG_CONFIG_PATH="${ROOT}usr/lib/pkgconfig/"
#PORTDIR_OVERLAY="/usr/portage/local/"
What am I missing? How would/do you go about achieving the same objective?
The masters of gentoo cross compiling are mostly found on the
gentoo-embedded channel, just so you know. Mostly a collection of
brilliant pricks and posers, but some kind kind-hearted folks therein too.
Cross compiling on clusters is a very hot area of interest right now,
but that is not for the faint-at-heart, atm. I'd stick with the fastest
multi-core single system you have access to and avoid distcc atm. ymmv.
hth,
James
Re: [gentoo-user] cross-compile attempt
On Sun, Jul 31, 2016 at 07:40:37PM +0100, Mick wrote: > > * ARCH is not set... Are you missing the '/usr/i686-pc-linux- > * gnu/etc/portage/make.profile' symlink? Is the symlink correct? Is your > * portage tree complete? > === > > As far as I can tell the link is there: > > # ls -la /usr/i686-pc-linux-gnu/etc/portage/ > total 8 > drwxr-xr-x 1 root root 56 Jul 31 19:32 . > drwxr-xr-x 1 root root 20 Jul 31 18:32 .. > -rw-r--r-- 1 root root 1019 Jul 31 19:32 make.conf > lrwxrwxrwx 1 root root 30 Jul 31 17:48 make.profile -> > /usr/portage/profiles/embedded > drwxr-xr-x 1 root root 32 Jul 31 18:16 profile > > and it was created when I ran 'crossdev --stable -v -t i686-pc-linux-gnu'. > As far as I know, ARCH is one of those variables that has to be specified in a profile, not in make.conf. A quick solution is to place the ARCH=x86 line into the site-specific override .../etc/portage/profile/make.defaults Although in this case your choice of profile may simply be wrong. The embedded profile is the crossdev default that pretty much only has busybox. Choose something like default/linux/x86/13.0 or if you want a lighter libc how about default/linux/uclibc/x86 (or hardened/linux/musl/x86). That should give you a more complete @system set. > > What am I missing? How would/do you go about achieving the same objective? > Since you are doing this on an amd64 box which can natively run x86, if you want to achieve the same goal faster, start with a x86 stage3, chroot into it and emerge a couple packages that you want to add, then tar it up and load onto your 32 bit box. If you want to add packages later, emerge them with '-b' in the chroot (on the amd64 box), and then follow https://wiki.gentoo.org/wiki/Binary_package_guide to allow the 32-bit box to install them as binary packages. Ofcourse if you want to learn crossdev, then this is a great chance to do so.
Re: [gentoo-user] cross-compile attempt
On Sun, 31 Jul 2016 19:40:37 +0100 Mick wrote: > Hi All, > > I am dipping my toe into cross-compile territory, in order to build i686 > binaries for a 32bit box, which is too old to do its own emerges. I am using > an amd64 box which is significantly faster to do all the heavy lifting and > started applying this page: > > https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Creating_a_cross-compiler > > which I followed up with: > > https://wiki.gentoo.org/wiki/Cross_build_environment And here comes this misconception again... Please, tell me, why on the earth cross-compiling is needed for amd64 to produce i686 binaries?! amd64 CPU _natively_ supports x86 instructions, amd64 kernel natively supports x86 code (this can be disabled during kernel config, but usually it isn't), amd64 gcc *can* produce x86 binaries. There are two ways to help older x86 boxes to build packages faster: 1. Set up distcc to produce x86 code on your amd64 processors. Just add -m32 to your *FLAGS. 2. Copy old box system to a chroot dir on amd64. Run setarch i686 and chroot to that directory, and build 32-bit packages as usual! There are two ways to deliver them: 2.a. Generate binary packages on new box and install them on old boxes. 2.b. Instead of copying old box's root, mount it over NFS. I'm currently using 1, but planning to switch to 2.a, because distcc can't help with everything (execution of java, python, autotools and other stuff can't be helped with distcc). I used 2.b earlier on very old box (it is dead now). 3. Well, one can do full cross-compilation as you proposed, but this is ridiculous. Cross-compilation is always a pain and if it can be avoided, it should be avoided. Best regards, Andrew Savchenko pgpBOHdczNQK1.pgp Description: PGP signature
[gentoo-user] Re: Re: Partition of 3TB USB drive not detected
Hi Mick, Mick wrote: > On Sunday 31 Jul 2016 19:14:45 Jörg Schaible wrote: >> Hi Daniel, >> >> thanks for your response. >> >> Daniel Frey wrote: >> >> [snip] >> >> > I can only think of two reasons, the kernel on the livecd doesn't >> > support GPT (which is unlikely) >> >> That would be really strange. However, how can I prove it? > > If after you boot your systemrescuecd you can list: > > /sys/firmware/efi > > you have booted into UEFI mode. If not, you have booted into legacy BIOS > mode. This machine has only plain old BIOS. The question is, why one kernel detects the 3TB partition and the the other one does not. How can I prove GPT support for the kernel itself. Cheers, Jörg
[gentoo-user] Re: Re: Partition of 3TB USB drive not detected
james wrote: > On 07/31/2016 12:56 PM, Jörg Schaible wrote: >> Jörg Schaible wrote: >> >>> Hi Daniel, >>> >>> thanks for your response. >>> >>> Daniel Frey wrote: >>> >>> [snip] >>> I can only think of two reasons, the kernel on the livecd doesn't support GPT (which is unlikely) >>> >>> That would be really strange. However, how can I prove it? >>> or you're booting a 32-bit kernel live USB. I am reasonably certain for drives > 2TB a 64-bit kernel and GPT are required. >>> >>> No, I've always chosen 64-bit kernels. I wonder what is so special about >>> this partition ... >> >> Currently I wonder, why my system can find the partition at all: >> >> %< >> # gdisk -l /dev/sdi >> GPT fdisk (gdisk) version 1.0.1 >> >> Partition table scan: >> MBR: protective >> BSD: not present >> APM: not present >> GPT: not present > > If you have seen my recent thread, I saw it, but did not read it in depth, because I had the impression, it is mainly about EFI systems. I'll re-read it ... > much of this automounting during > boot(strapping) is flaky that is much of what I have been searching out > is a default (magical) partitioning schema that will eventually lead to > clear documents on the current state of affairs not only with old versus > new motherboards (mbr-->efi) and disk (mbr < 2.2T and gpt >2.2T) > but including all sorts of new arm and other embedded (linux) boards. > > Different forms of Solid State memory are next on my list, with usb (1.x > --> 3.x) being top of the SS memory mediums. (Sorry I do not have > more atm). > >> Creating new GPT entries. >> Disk /dev/sdi: 732566646 sectors, 2.7 TiB >> Logical sector size: 4096 bytes >> Disk identifier (GUID): 80C04475-9B51-4A44-A52F-1F165AE02695 >> Partition table holds up to 128 entries >> First usable sector is 6, last usable sector is 732566640 >> Partitions will be aligned on 256-sector boundaries >> Total free space is 732566635 sectors (2.7 TiB) >> >> Number Start (sector)End (sector) Size Code Name >> %< >> >> However, it's mounted successfully, see system logs: >> >> %< >> [22735.626752] sd 13:0:0:0: [sdi] 732566646 4096-byte logical blocks: >> [(3.00 >> TB/2.73 TiB) >> [22735.629255] sdi: sdi1 >> [23414.066315] EXT4-fs (sdi1): mounted filesystem with ordered data mode. >> Opts: (null) >> %< >> >> Has anyone ever tried the recovery option of GPT disk to rebuild GPT from >> MBR? > > I see some sort of 'auto correction' by gpt technology to convert many > forms of perceived mbr to gpt to be used by the booting process for > spinning rust. So this issue is not limited to usb medium. I would also > point out that I'd look deeply into the usb specs for the vendor of your > usb sticks, as they do some 'funky things' at the firmware level inside > many of the newer/faster/larger usb devices. It not just dumb memory > like the early 1.x devices. Many are slanted to Microsoft business > strategies. I'm not suggesting that is your current issues. I'm merely > pointing out that some newer usb sticks are systems themselves complete > with firmware so the devices looks like dumb memory. Furthermore, the > silicon vendors provide firmware options to usb sticks vendors (like > Texas Instruments) but also the vendor add to or change the hidden > firmware as meets their multifaceted business objects. Sadly, the NSA is > deeply involved here, as are many nation states and large corporations. > You'd be surprised what youd find in a modern usb stick, should you take > it into a class 6+ clean-room for analysis. The lower the particle count > the more fantastic the tools > to open up silicon and look deeply into what is actually going on. > This is why folks love those classified research facilities that have > govt contract and folks hanging around. Lots of very, very cool toys > you just do not hear about.. Way beyond microscopes built by > physicist. Actually it is not that modern. ~5 year old Intenso 2GB. I'd be surprised if booting from the stick prevents partition detection of another USB drive, but who knows? Maybe I should burn the iso instead and boot that one ;-) > Prolly not your issue, but still present. Cheap ass usb vendors often > have corner issues that are unintentional, that is why well recognized > vendors of SS memory are the best to deal with, for consistency of > behavior. > > I'd use as many different tools as you can find and read the vendor & > silicon manufacturer's docs to see what you are really dealing with to > ferret out this weirdness. (it's a darn time sync, just so you know). > > > [1] http://www.cleanroom.byu.edu/particlecount.phtml > > hth, > James Thanks, Jörg
Re: [gentoo-user] Re: Re: Partition of 3TB USB drive not detected
On Sunday 31 Jul 2016 22:38:22 Jörg Schaible wrote: > Hi Mick, > > Mick wrote: > > On Sunday 31 Jul 2016 19:14:45 Jörg Schaible wrote: > >> Hi Daniel, > >> > >> thanks for your response. > >> > >> Daniel Frey wrote: > >> > >> [snip] > >> > >> > I can only think of two reasons, the kernel on the livecd doesn't > >> > support GPT (which is unlikely) > >> > >> That would be really strange. However, how can I prove it? > > > > If after you boot your systemrescuecd you can list: > > > > /sys/firmware/efi > > > > you have booted into UEFI mode. If not, you have booted into legacy BIOS > > mode. > > This machine has only plain old BIOS. The question is, why one kernel > detects the 3TB partition and the the other one does not. How can I prove > GPT support for the kernel itself. I see. In this case have a look at /proc/config (it may be compressed) or depending on your version of sysrescuecd and kernel choice, have a look here: https://sourceforge.net/p/systemrescuecd/code/ci/master/tree/ then compare your configuration to theirs. The kernel module for GPT is 'CONFIG_EFI_PARTITION' and it must be built in, rather than as a separate module. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] cross-compile attempt
On Sunday 31 Jul 2016 23:18:00 Andrew Savchenko wrote: > On Sun, 31 Jul 2016 19:40:37 +0100 Mick wrote: > > Hi All, > > > > I am dipping my toe into cross-compile territory, in order to build i686 > > binaries for a 32bit box, which is too old to do its own emerges. I am > > using an amd64 box which is significantly faster to do all the heavy > > lifting and started applying this page: > > > > https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Creating_a_cross-co > > mpiler > > > > which I followed up with: > > > > https://wiki.gentoo.org/wiki/Cross_build_environment > > And here comes this misconception again... Please, tell me, why on > the earth cross-compiling is needed for amd64 to produce i686 > binaries?! I thought it did. From what you're saying I got this wrong. When I read the first use case bullet point, on the 2nd URL above, I thought I had arrived at the right place. :-/ > amd64 CPU _natively_ supports x86 instructions, amd64 kernel > natively supports x86 code (this can be disabled during kernel > config, but usually it isn't), amd64 gcc *can* produce x86 binaries. I thought amd64 can run x86 binaries, but I wasn't aware that it can compile them too, or what is needed to achieve this. My knowledge on gcc is pretty much minimal. I did search the Wiki, gentoo.org and Google for it, but all I could come across was cross-compiling. > There are two ways to help older x86 boxes to build packages faster: > > 1. Set up distcc to produce x86 code on your amd64 processors. Just > add -m32 to your *FLAGS. I read somewhere in these unsuccessful searches of mine that distcc is deprecated and it is better to use cross-compiling instead ... > 2. Copy old box system to a chroot dir on amd64. Run setarch i686 > and chroot to that directory, and build 32-bit packages as usual! > There are two ways to deliver them: > > 2.a. Generate binary packages on new box and install them on old > boxes. OK, I'll uninstall crossdev and try 2.a in the first instance. Is there a Wiki page explaining what parts of the x86 system are needed to carry across to the amd64 guest_root_fs? I wouldn't think I will need the whole x86 fs? Anything else I need to pay attention to? > 2.b. Instead of copying old box's root, mount it over NFS. I'll look into this later, after I get 2.a going. > I'm currently using 1, but planning to switch to 2.a, because > distcc can't help with everything (execution of java, python, > autotools and other stuff can't be helped with distcc). > > I used 2.b earlier on very old box (it is dead now). > > 3. Well, one can do full cross-compilation as you proposed, but > this is ridiculous. Cross-compilation is always a pain and if it > can be avoided, it should be avoided. Thanks for this advice. I am not particularly interested to use crossdev if it is not the best suited tool for the job, but I wasn't aware of the alternatives you suggested and haven't as yet found any HOWTOs on it. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Genlop oddity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/31/2016 12:14 PM, Peter Humphrey wrote: > On Sunday 31 Jul 2016 10:48:33 Fernando Rodriguez wrote: >> On 07/31/2016 06:47 AM, Peter Humphrey wrote: >>> I've just encountered something I can't explain. Can anyone here? >>> >>> ~ $ genlop -c -f /mnt/rescue/var/log/emerge.log >>> using logfile /mnt/rescue/var/log/emerge.log >>> Currently merging 281 out of 287 >>> * net-libs/gnutls-3.3.24 >>>current merge time: 1 minute and 44 seconds. >>>ETA: less than a minute. >>> Currently merging 264 out of 287 >>> >>> * sys-devel/gcc-4.9.3 >>>current merge time: 7 minutes and 12 seconds. >>>ETA: 3 minutes and 13 seconds. >>> >>> $ genlop -c -f /mnt/rescue/var/log/emerge.log >>> using logfile /mnt/rescue/var/log/emerge.log >>> Currently merging 264 out of 287 >>> * sys-devel/gcc-4.9.3 >>>current merge time: 15 minutes and 19 seconds. >>>ETA: 3 minutes and 41 seconds. >>> >>> How is it possible for genlop's reported ETA to increase while its time >>> spent so far also increases? > > ...or to change at all, for that matter. > >> It is an estimate (a prediction) so it's subject to change. > > Yes, but the estimate is derived from an average of the durations found in > the log file, so it can't change until the emerge is complete. I haven't looked at the code but if it changes I think it's doing more than just averaging previous builds. It can and should try better than that. Even if all it has to work with is the logs a simple algorithm could (once it starts taking longer) look at the build time differences and come up with a better guess. My guess it's doing something along those lines. After a bit it just says "anytimme now." >>> Could the concurrent gnutls merging have affected it? Surely not. >> >> Probably, I don't know if genlop takes that into account. But there's >> countless factors that affect build time that it's practically impossible >> to predict accurately. So it means nothing. > > I think that's too pessimistic. If all your emerges have -j1, the accuracy > is pretty good, or it used to be in the days when I did that. The major > factor affecting the durations nowadays is -j > 1, so any other packages > could be emerging at the same time, thus skewing the log record. > > Another, even bigger log skewer is my practice, if I need an emerge -e, of > doing it in two stages: -eB first, then reboot to a minimal system and -eK. > That avoids things like kdelibs being different when I come to reboot the > system next time and hanging up during shutdown. > There's the -j option, there's distcc, ccache, etc. Many system settings, the amount of junk in /tmp if it's tmpfs, etc etc. Even in the simplest of cases using -j1 and controlling everything else some versions of the same package take significantly longer than others, what you have installed on your system can affect compile times, some compiler versions are faster, etc. etc. For me they're totally useless. gcc compile time ranges from 24mins-13hrs. Firefox 24mins-1day 3hrs. LibreOfffice 5hrs-14hrs. >> Does that estimate even look reasonable to you? >> gnutls compiles in a few minutes but gcc takes significantly longer for >> me. > No, as I said, genlop's own estimates are poor nowadays, but I can make a > rough estimate myself from comparing "genlop -c" with "genlop -t | > grep minutes". Just out of curiosity what are the differences between the original genlop calculation and yours, and how long did it actually take? and what is the output of 'genlop -t '. I think it would be inaccurate in most cases (at least it is for me) but if you think the calculation is wrong you should file a bug. For me it seems reasonably accurate por packages with consistent build times. - -- Fernando Rodriguez -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXnoEnAAoJEPbOFX/5Ulwc3c4P/i26UPhwodsQ2TMS28fUyv4q BAyMvxGZG/nACbmzAYwPPbT8cZwIQomXhfuozokWGFsRzWLFdNms73HQ0YoQokeV Q8fHBolQdT3UyNgoROcDn7MJopr0QXWcZ2sWSpLFm2jZVmzz01d4ZkrQ2rXD22q/ 6qK3293svTfHpsft0h9ADeFW5r8BJ8BuLT+Q1TNHFQETILUHxmB34R7cHyJ6eMYX B0vGUXVSb1yYPReNKM3g+ok0KHMh5Q8iUGW44pzXLEg2Iw1Rnk2nwb7SYj0FjyzX rFreLC5iiVVPRLUkI9NKn6k3Mg3y3TIn8fNqI44r8RMMt8o96sXKGsUIsWamXBzp Sgorb+hvzTmiffD9Lk+1/reA5ne9nWfXGYlNfJY+JKgF0peGSOiWQ90w/T1x97si tYs1MqqMnvna+vkDW+lZZcditRE1NnLpmSIkHtvBuPi0XcjeiRNlmUEI6s6k9ZPO vTn0obIyT9f6XvUDNWZw5XlAZaP+w0Tf9r2mV6gJrx11OpjiKlEvWSN/F+rvRlsh 2Ki+QdrCjHpfnPbyQirUzfMeY2Ch4qzo8Ucnz/mJntE/4D9jPcmXisHV9k6KpYuX phE6m+DmU48QRys1pbh9prQTtvIPDm9LkuG2Hc5XJq+q+nAGeMUIH6SskCtE1Lsy 5UFWcFsuzZLAm7ShTAuZ =TiEU -END PGP SIGNATURE-
Re: [gentoo-user] PostgreSQL Vs MySQL @Uber
On Fri, Jul 29, 2016 at 7:01 PM, Mick wrote:
> Yes, same here, I would be interested to hear what the Postgres dev says,
> should he respond to it.
>
One PostgreSQL dev's response - https://t.co/LfPlIPWulc
--
{
"name": "douglas j hunley",
"email": "doug.hun...@gmail.com",
"social": [
{
"blog": "https://hunleyd.github.io/";,
"twitter": "@hunleyd"
}
]
}
Re: [gentoo-user] Partition of 3TB USB drive not detected
On Sunday, July 31, 2016 03:37:55 PM Jörg Schaible wrote: > Hi, > > for my backups I use a 3TB USB drive (one big ext4 partition) without any > problems. Just plug in the cable, mount it and perform the backup. The > partition (sdi1) is detected an mountable without any problems: > > === %< == > $ ls -l /dev/disk/by-id > total 0 === %< == > > However, when I boot a rescue system from a USB stick, the partition on the > USB is not detected. I already tried latest SystemRescueCD (default and > alternate kernel), Knoppix and the Gentoo Admin CD. Nothing, the partition > is not available. > > What's the difference? Why does my kernel find this partition and the other > one's do not? It's pretty silly to have a backup drive and cannot access it > in question ;-) Which kernel do you boot? The systerescue-cd has 4 kernels: 2 * 64bit and 2 * 32bit. By default, it boots the "default" one for the architecture you are booting. Have you tried booting the "alternate" kernel? I have 1 system that I need to boot using the "alternate" kernel as the "default" one is too old. (Yes, by default it boots an old kernel) It could easily be that the kernel you are using does not support your USB3 adapter or something else you used. Eg. apart from all the 'ls' statements, also check "uname" and "/proc/config.gz" for differences. -- Joost
