Re: [gentoo-user] Apologize to everyone for my nonprofessional
Pandu Poluan wrote: On Oct 15, 2011 5:49 AM, Dale rdalek1...@gmail.com mailto:rdalek1...@gmail.com wrote: Neil Bothwick wrote: On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote: A'right now. I'm going to start on hal and /usr being on / again. :-P Jeez, 43 years on and you're still going on about it... Dang, I was only a year old when hal came out? That just doubled my age. It's closer to what I feel like tho. I'm still not happy with /usr being required tho. That is still standing on a bad nerve. Don't worry tho, I got plenty of those bad nerves. :-P Do you know that there's a plan to move /var/run to / also? ;-) Rgds, Now someone on here swears up and down that /var isn't going to be required on /. I'm telling ya'll, /home is coming. We are going to end up where we can only have one drive in our Linux boxes for the OS and its relatives. That or we will ALL have to start using the pesky init* thingy. I got 7 acres of land here, complete with trees. If someone can find the dev that started this mess, I can find some rope. Just saying. ;-) Oh, I live half a mile from the river too. Makes for a good dump site. lol I noticed the other day that when LVM tries to start, it fails. I have /var on a separate partition here. It was complaining about something on /var missing. So, you may be late in reporting this. I think it is already needed for LVM if /usr or /var is on a separate partition. sighs Dale :-) :-)
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Oct 15, 2011 1:58 PM, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: On Oct 15, 2011 5:49 AM, Dale rdalek1...@gmail.com wrote: Neil Bothwick wrote: On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote: A'right now. I'm going to start on hal and /usr being on / again. :-P Jeez, 43 years on and you're still going on about it... Dang, I was only a year old when hal came out? That just doubled my age. It's closer to what I feel like tho. I'm still not happy with /usr being required tho. That is still standing on a bad nerve. Don't worry tho, I got plenty of those bad nerves. :-P Do you know that there's a plan to move /var/run to / also? ;-) Rgds, Now someone on here swears up and down that /var isn't going to be required on /. I'm telling ya'll, /home is coming. We are going to end up where we can only have one drive in our Linux boxes for the OS and its relatives. That or we will ALL have to start using the pesky init* thingy. I got 7 acres of land here, complete with trees. If someone can find the dev that started this mess, I can find some rope. Just saying. ;-) Oh, I live half a mile from the river too. Makes for a good dump site. lol Hey, good idea! Perhaps we can start from udev's dev? :-D I noticed the other day that when LVM tries to start, it fails. I have /var on a separate partition here. It was complaining about something on /var missing. So, you may be late in reporting this. I think it is already needed for LVM if /usr or /var is on a separate partition. sighs Well, I don't know about the rest of /var, but bug #381783 explicitly said that 'some people' are thinking of making /var/run a symlink to /run... (not me! I swear! Please don't hang the messenger...) Rgds,
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Fri, Oct 14, 2011 at 11:56 PM, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: On Oct 15, 2011 5:49 AM, Dale rdalek1...@gmail.com wrote: Neil Bothwick wrote: On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote: A'right now. I'm going to start on hal and /usr being on / again. :-P Jeez, 43 years on and you're still going on about it... Dang, I was only a year old when hal came out? That just doubled my age. It's closer to what I feel like tho. I'm still not happy with /usr being required tho. That is still standing on a bad nerve. Don't worry tho, I got plenty of those bad nerves. :-P Do you know that there's a plan to move /var/run to / also? ;-) Rgds, Now someone on here swears up and down that /var isn't going to be required on /. /var != /var/run /var != /var/lock /var/run is going in /run, but /var/run (by definition) only contains things like PID files and runtime sockets. In the same vein, /var/lock also is going into /run/lock. I have acknowledged this from the very beginning, and I have been pointing out that implying that because those two (really small and bounded) directories of /var are going into /run and /run/lock, it doesn't mean that the whole /var will go into /. That is disinformation. Nobody has even proposed that /var should go into the same partition as /. *Nobody*, and the simplest proof of that is that nobody has produced a single proof to the contrary. Not a single email, blog post, or wiki entry from any system developer even mentions the possibility of requiring /var to be in the same partition as /. Whoever says that /var will be required to be on the same partition as / is either wildly speculating, or spreading FUD. I'm telling ya'll, /home is coming. That is just ridiculous. We are going to end up where we can only have one drive in our Linux boxes for the OS and its relatives. And so is this: more FUD. That or we will ALL have to start using the pesky init* thingy. More FUD: the current proposal (from Zac, the principal coder of portage, and someone who actually wrotes code and know what he is talking about) is this: http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml It basically removes the need for a pesky init* thingy, although for the life of me I cannot understand why someone will not see the technical advantages of actually using an initramfs. I got 7 acres of land here, complete with trees. If someone can find the dev that started this mess, I can find some rope. Just saying. ;-) Oh, I live half a mile from the river too. Makes for a good dump site. lol I noticed the other day that when LVM tries to start, it fails. I have /var on a separate partition here. It was complaining about something on /var missing. So, you may be late in reporting this. I think it is already needed for LVM if /usr or /var is on a separate partition. Again, get the facts right. If you use LVM you will need to use an initramfs. If you only use a separated /usr you will be able to use Zac's proposal. In no case whatsoever you will be required to have /var on the same partition as /. Nobody has ever proposed that. /run and /run/lock are not /var. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
[gentoo-user] CONFIG_USB_SUSPEND, where ?
* Messages for package sys-fs/udisks-1.0.4-r1: * CONFIG_USB_SUSPEND: is not set when it should be. As the message above from emerge says, no way to update sys-fs/udisks as CONFIG_USB_SUSPEND is not set. The problem is where to find that option. Not in linux/.config, so where ?
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Sat, Oct 15, 2011 at 12:34 AM, Canek Peláez Valdés can...@gmail.com wrote: On Fri, Oct 14, 2011 at 11:56 PM, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: On Oct 15, 2011 5:49 AM, Dale rdalek1...@gmail.com wrote: Neil Bothwick wrote: On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote: A'right now. I'm going to start on hal and /usr being on / again. :-P Jeez, 43 years on and you're still going on about it... Dang, I was only a year old when hal came out? That just doubled my age. It's closer to what I feel like tho. I'm still not happy with /usr being required tho. That is still standing on a bad nerve. Don't worry tho, I got plenty of those bad nerves. :-P Do you know that there's a plan to move /var/run to / also? ;-) Rgds, Now someone on here swears up and down that /var isn't going to be required on /. /var != /var/run /var != /var/lock /var/run is going in /run, but /var/run (by definition) only contains things like PID files and runtime sockets. In the same vein, /var/lock also is going into /run/lock. I have acknowledged this from the very beginning, and I have been pointing out that implying that because those two (really small and bounded) directories of /var are going into /run and /run/lock, it doesn't mean that the whole /var will go into /. That is disinformation. I finally found the link (got confused by gmane interface): http://article.gmane.org/gmane.linux.gentoo.user/246892 Quoting myself (from more than one month ago): Saying that proposing /run and /lock to be available at boot time means that in the future a separated /var partition could be not supported is, in my book, disinformation. /var/run and /var/lock (by definition) are almost empty (in space). /var/lib usually stores whole databases. The difference is important and relevant. Stop the fear mongering. If you jump into using an initramfs, then every single configuration on the planet (and on the future) will be supported, and it actually has its advantages to use said initramfs. If for irrational fear of using an initramfs, and your system is simple enough (where simple does not include LVM, NFS, and stuff like that), then you will be able to use Zac's proposal. In either case, /var will be always possible to have on a separated partition, and that is actually the recommended setup. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] CONFIG_USB_SUSPEND, where ?
On Sat, Oct 15, 2011 at 12:49 AM, Alain Didierjean alain.didierj...@free.fr wrote: * Messages for package sys-fs/udisks-1.0.4-r1: * CONFIG_USB_SUSPEND: is not set when it should be. As the message above from emerge says, no way to update sys-fs/udisks as CONFIG_USB_SUSPEND is not set. The problem is where to find that option. Not in linux/.config, so where ? Cool tip for the future: Go to /usr/src/linux, type make menuconfig. Then type / (slash). Then type SUSPEND and ENTER. It will show you all the kernel options with SUSPEND on them. In particular, for USB_SUSPEND it says: Symbol: USB_SUSPEND [=y] Type : boolean Prompt: USB runtime power management (autosuspend) and wakeup Defined at drivers/usb/core/Kconfig:93 Depends on: USB_SUPPORT [=y] USB [=y] PM_RUNTIME [=y] Location: - Device Drivers - USB support (USB_SUPPORT [=y]) - Support for Host-side USB (USB [=y]) So there, is in Device Drivers - USB support - Support for Host-side USB. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Apologize to everyone for my nonprofessional
Hi Canek, On Saturday, 15. October 2011 00:50:22 Canek Peláez Valdés wrote: On Sat, Oct 15, 2011 at 12:34 AM, Canek Peláez Valdés can...@gmail.com wrote: On Fri, Oct 14, 2011 at 11:56 PM, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: On Oct 15, 2011 5:49 AM, Dale rdalek1...@gmail.com wrote: Neil Bothwick wrote: On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote: A'right now. I'm going to start on hal and /usr being on / again. :-P Jeez, 43 years on and you're still going on about it... Dang, I was only a year old when hal came out? That just doubled my age. It's closer to what I feel like tho. I'm still not happy with /usr being required tho. That is still standing on a bad nerve. Don't worry tho, I got plenty of those bad nerves. :-P Do you know that there's a plan to move /var/run to / also? ;-) Rgds, Now someone on here swears up and down that /var isn't going to be required on /. /var != /var/run /var != /var/lock /var/run is going in /run, but /var/run (by definition) only contains things like PID files and runtime sockets. In the same vein, /var/lock also is going into /run/lock. I have acknowledged this from the very beginning, and I have been pointing out that implying that because those two (really small and bounded) directories of /var are going into /run and /run/lock, it doesn't mean that the whole /var will go into /. That is disinformation. I finally found the link (got confused by gmane interface): http://article.gmane.org/gmane.linux.gentoo.user/246892 Quoting myself (from more than one month ago): Saying that proposing /run and /lock to be available at boot time means that in the future a separated /var partition could be not supported is, in my book, disinformation. /var/run and /var/lock (by definition) are almost empty (in space). /var/lib usually stores whole databases. The difference is important and relevant. and you still did not look into /var/lib to see, what is actually in there? My systems has directories alsa, bluetooth, hp and many more there that are not databases at all. Stop spreading this misinformation, please. Regards. Best, Michael
Re: [gentoo-user] Apologize to everyone for my nonprofessional
Canek Peláez Valdés wrote: On Fri, Oct 14, 2011 at 11:56 PM, Dalerdalek1...@gmail.com wrote: Pandu Poluan wrote: On Oct 15, 2011 5:49 AM, Dalerdalek1...@gmail.com wrote: Neil Bothwick wrote: On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote: A'right now. I'm going to start on hal and /usr being on / again. :-P Jeez, 43 years on and you're still going on about it... Dang, I was only a year old when hal came out? That just doubled my age. It's closer to what I feel like tho. I'm still not happy with /usr being required tho. That is still standing on a bad nerve. Don't worry tho, I got plenty of those bad nerves. :-P Do you know that there's a plan to move /var/run to / also? ;-) Rgds, Now someone on here swears up and down that /var isn't going to be required on /. /var != /var/run /var != /var/lock /var/run is going in /run, but /var/run (by definition) only contains things like PID files and runtime sockets. In the same vein, /var/lock also is going into /run/lock. I have acknowledged this from the very beginning, and I have been pointing out that implying that because those two (really small and bounded) directories of /var are going into /run and /run/lock, it doesn't mean that the whole /var will go into /. That is disinformation. Nobody has even proposed that /var should go into the same partition as /. *Nobody*, and the simplest proof of that is that nobody has produced a single proof to the contrary. Not a single email, blog post, or wiki entry from any system developer even mentions the possibility of requiring /var to be in the same partition as /. Whoever says that /var will be required to be on the same partition as / is either wildly speculating, or spreading FUD. So /var/run and /var/lock isn't on /var? Even if they will be linking to another location, the link has to be there for whatever program to follow. If /var isn't mounted yet, there is nothing for the program to find. When I saw the messages about LVM and /var, that caused LVM to fail to start. I wouldn't put / on LVM and wouldn't expect it to work without a init thingy either. Thing is, based on it failing, you can't have /var on a separate partition and expect LVM to start. So, if you use LVM for /usr and/or /var, you have to have a init thingy even if / is on a regular file system. I'm telling ya'll, /home is coming. That is just ridiculous. I would have said the same thing about /usr a year ago. I'm not saying it is coming next week but . . . We are going to end up where we can only have one drive in our Linux boxes for the OS and its relatives. And so is this: more FUD. That or we will ALL have to start using the pesky init* thingy. More FUD: the current proposal (from Zac, the principal coder of portage, and someone who actually wrotes code and know what he is talking about) is this: http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml It basically removes the need for a pesky init* thingy, although for the life of me I cannot understand why someone will not see the technical advantages of actually using an initramfs. I'll have to read his link later. I got 7 acres of land here, complete with trees. If someone can find the dev that started this mess, I can find some rope. Just saying. ;-) Oh, I live half a mile from the river too. Makes for a good dump site. lol I noticed the other day that when LVM tries to start, it fails. I have /var on a separate partition here. It was complaining about something on /var missing. So, you may be late in reporting this. I think it is already needed for LVM if /usr or /var is on a separate partition. Again, get the facts right. If you use LVM you will need to use an initramfs. If you only use a separated /usr you will be able to use Zac's proposal. In no case whatsoever you will be required to have /var on the same partition as /. Nobody has ever proposed that. /run and /run/lock are not /var. Regards. No one proposed that /usr was required until just recently. Saying it won't happen really puts you in a bad spot when or if it does. If you know this for sure and certain, I want your crystal ball. Just for the record, I don't want a init thingy because it is yet one more thing to fail when booting. I was forced to use one when I was on Mandrake and I hated it. It isn't the only reason I switched but it was one reason. Now that same reason is coming to Gentoo. Dale :-) :-)
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Sat, Oct 15, 2011 at 1:35 AM, Michael Schreckenbauer grim...@gmx.de wrote: Hi Canek, Hi Michael. On Saturday, 15. October 2011 00:50:22 Canek Peláez Valdés wrote: On Sat, Oct 15, 2011 at 12:34 AM, Canek Peláez Valdés can...@gmail.com wrote: On Fri, Oct 14, 2011 at 11:56 PM, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: On Oct 15, 2011 5:49 AM, Dale rdalek1...@gmail.com wrote: Neil Bothwick wrote: On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote: A'right now. I'm going to start on hal and /usr being on / again. :-P Jeez, 43 years on and you're still going on about it... Dang, I was only a year old when hal came out? That just doubled my age. It's closer to what I feel like tho. I'm still not happy with /usr being required tho. That is still standing on a bad nerve. Don't worry tho, I got plenty of those bad nerves. :-P Do you know that there's a plan to move /var/run to / also? ;-) Rgds, Now someone on here swears up and down that /var isn't going to be required on /. /var != /var/run /var != /var/lock /var/run is going in /run, but /var/run (by definition) only contains things like PID files and runtime sockets. In the same vein, /var/lock also is going into /run/lock. I have acknowledged this from the very beginning, and I have been pointing out that implying that because those two (really small and bounded) directories of /var are going into /run and /run/lock, it doesn't mean that the whole /var will go into /. That is disinformation. I finally found the link (got confused by gmane interface): http://article.gmane.org/gmane.linux.gentoo.user/246892 Quoting myself (from more than one month ago): Saying that proposing /run and /lock to be available at boot time means that in the future a separated /var partition could be not supported is, in my book, disinformation. /var/run and /var/lock (by definition) are almost empty (in space). /var/lib usually stores whole databases. The difference is important and relevant. and you still did not look into /var/lib to see, what is actually in there? My systems has directories alsa, bluetooth, hp and many more there that are not databases at all. So? Stop spreading this misinformation, please. Which one? That /var is not going into /? It's not disinformation, it is th true. If not, please be so kind of showin one single developer reference that says so. One. Single. One. Email, blog post, wiki, you choose it. But one single one. Otherwise, stop speculating about an imaginary future, and stop spreading disinformation and FUD. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote: /var/lib usually stores whole databases. The difference is important and relevant. My systems has directories alsa, bluetooth, hp and many more there that are not databases at all. So? Which one? That /var is not going into /? No. That /var/lib contains databases. Is this so difficult to get? On my system /var/lib/alsa contains data, that alsa uses to restore mixer- levels. So *my* /var/lib is used during boot and *my* /var/lib has to be mounted by the initramfs. That's the situation on nearly every gentoo system using sound (systemd might handle this different, I have no idea) Got it? Your system is not the center of the world. Regards. Best, Michael
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Sat, Oct 15, 2011 at 1:37 AM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Fri, Oct 14, 2011 at 11:56 PM, Dalerdalek1...@gmail.com wrote: Pandu Poluan wrote: On Oct 15, 2011 5:49 AM, Dalerdalek1...@gmail.com wrote: Neil Bothwick wrote: On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote: A'right now. I'm going to start on hal and /usr being on / again. :-P Jeez, 43 years on and you're still going on about it... Dang, I was only a year old when hal came out? That just doubled my age. It's closer to what I feel like tho. I'm still not happy with /usr being required tho. That is still standing on a bad nerve. Don't worry tho, I got plenty of those bad nerves. :-P Do you know that there's a plan to move /var/run to / also? ;-) Rgds, Now someone on here swears up and down that /var isn't going to be required on /. /var != /var/run /var != /var/lock /var/run is going in /run, but /var/run (by definition) only contains things like PID files and runtime sockets. In the same vein, /var/lock also is going into /run/lock. I have acknowledged this from the very beginning, and I have been pointing out that implying that because those two (really small and bounded) directories of /var are going into /run and /run/lock, it doesn't mean that the whole /var will go into /. That is disinformation. Nobody has even proposed that /var should go into the same partition as /. *Nobody*, and the simplest proof of that is that nobody has produced a single proof to the contrary. Not a single email, blog post, or wiki entry from any system developer even mentions the possibility of requiring /var to be in the same partition as /. Whoever says that /var will be required to be on the same partition as / is either wildly speculating, or spreading FUD. So /var/run and /var/lock isn't on /var? Even if they will be linking to another location, the link has to be there for whatever program to follow. If /var isn't mounted yet, there is nothing for the program to find. The link goes the other way around. /run and /lock are the real directories, /var/run is a link to /run, /var/lock is a link to /run/lock. When the initramfs (or the init system) mount /var, they make the link. When I saw the messages about LVM and /var, that caused LVM to fail to start. I wouldn't put / on LVM and wouldn't expect it to work without a init thingy either. Thing is, based on it failing, you can't have /var on a separate partition and expect LVM to start. So, if you use LVM for /usr and/or /var, you have to have a init thingy even if / is on a regular file system. Yes, as I said in my last mail, if you need LVM, you need an initramfs. Remove the LVM, and you can have /var (and /usr for that matter) withouth an initramfs. Where/when did I say something different? I'm telling ya'll, /home is coming. That is just ridiculous. I would have said the same thing about /usr a year ago. I'm not saying it is coming next week but . . . You can speculate all you want. Fact is, nobody has proposed that, and there is not even a single email suggesting that it will be necessary. On the contrary, the requirement for an initramfs or a /usr inside the same partition as / has been being discussed years ago; if you had followed the developers lists, you wil had hear about it months before it happened. Nothing similar has happened with /var, least of it /home. We are going to end up where we can only have one drive in our Linux boxes for the OS and its relatives. And so is this: more FUD. That or we will ALL have to start using the pesky init* thingy. More FUD: the current proposal (from Zac, the principal coder of portage, and someone who actually wrotes code and know what he is talking about) is this: http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda141488498729fe8.xml It basically removes the need for a pesky init* thingy, although for the life of me I cannot understand why someone will not see the technical advantages of actually using an initramfs. I'll have to read his link later. Please do. I got 7 acres of land here, complete with trees. If someone can find the dev that started this mess, I can find some rope. Just saying. ;-) Oh, I live half a mile from the river too. Makes for a good dump site. lol I noticed the other day that when LVM tries to start, it fails. I have /var on a separate partition here. It was complaining about something on /var missing. So, you may be late in reporting this. I think it is already needed for LVM if /usr or /var is on a separate partition. Again, get the facts right. If you use LVM you will need to use an initramfs. If you only use a separated /usr you will be able to use Zac's proposal. In no case whatsoever you will be required to have /var on the same partition as /. Nobody has ever proposed that. /run and /run/lock are not /var. Regards. No one proposed that /usr was
Re: [gentoo-user] 回复： [gentoo-user] Can't find driver for VGA in kernel source tree
On Saturday 15 Oct 2011 04:30:18 Lavender wrote: I have just tried , the output is like something below 01:00.0 VGA compatible controller: ATI Technologies Inc M92 LP Subsystem: Hewlett-Packard Company Device 3644 Flags: bus master, fast devsel, latency 0, IRQ 10 Memory at 8000 (32bit, prefetchable) [size=256M] I/O ports at 3000 [size=256] Memory at 9030 (32bit, non-prefetchable) [size=64K] Expansion ROM at 9032 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enabel- Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 ? How can I find the driver according to these information ? There should be an additional line with the kernel modules just below what you showed. This is what mine is showing: = 02:00.0 VGA compatible controller: ATI Technologies Inc Device 9488 (prog-if 00 [VGA controller]) Subsystem: Dell Device 02fe Flags: bus master, fast devsel, latency 0, IRQ 45 Memory at d000 (32-bit, prefetchable) [size=256M] I/O ports at 2000 [size=256] Memory at cfef (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at cfe0 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Legacy Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 ? Kernel driver in use: radeon = Are you using the latest LiveCD? Have you tried booting with this? http://www.sysresccd.org It usually has the latest kernel and drivers. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer grim...@gmx.de wrote:
On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
/var/lib usually stores whole
databases. The difference is important and relevant.
My systems has directories alsa, bluetooth, hp and many more
there that are not databases at all.
So?
Which one? That /var is not going into /?
No. That /var/lib contains databases. Is this so difficult to get?
I get it; it's just not relevant.
On my system /var/lib/alsa contains data, that alsa uses to restore mixer-
levels.
Yeah, it does.
So *my* /var/lib is used during boot and *my* /var/lib has to be
mounted by the initramfs.
No, it doesn't. What are you talking about? Look at /etc/init.d/alsasound:
depend() {
need localmount
after bootmisc modules isapnp coldplug hotplug
}
Look at the first need from alsasound depend: it says, that it goes
after localmount. If you have /var in NFS (a very weird setup for a
desktop machine) maybe it will cause problems: but then it would be
fault of OpenRC (or the alsasound init script). If /var is on a
different partition, localmount will mount it and *then* alsasound
will execute.
And it makes sense: the volume restoring doesn't matter until
immediately before running gdm and going into the desktop; of course
you can mount /var before that.
That's the situation on nearly every gentoo system
using sound
Yeah, and as I explained, thanks to need localmount there is no problem.
(systemd might handle this different, I have no idea)
Yeah, it does more intelligently: as I said, the volume restoring is
only needed just before starting X.
Got it? Your system is not the center of the world.
No, but I start to think you don't know *your* system. Check the
alsasound init script.
The /var directory doesn't need to be on the same partition as /. Period.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-user] Apologize to everyone for my nonprofessional
Hi Canek, On Saturday, 15. October 2011 02:02:13 Canek Peláez Valdés wrote: On Sat, Oct 15, 2011 at 1:37 AM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Fri, Oct 14, 2011 at 11:56 PM, Dalerdalek1...@gmail.com wrote: Pandu Poluan wrote: On Oct 15, 2011 5:49 AM, Dalerdalek1...@gmail.com wrote: Neil Bothwick wrote: On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote: A'right now. I'm going to start on hal and /usr being on / again. :-P Jeez, 43 years on and you're still going on about it... Dang, I was only a year old when hal came out? That just doubled my age. It's closer to what I feel like tho. I'm still not happy with /usr being required tho. That is still standing on a bad nerve. Don't worry tho, I got plenty of those bad nerves. :-P Do you know that there's a plan to move /var/run to / also? ;-) Rgds, Now someone on here swears up and down that /var isn't going to be required on /. /var != /var/run /var != /var/lock /var/run is going in /run, but /var/run (by definition) only contains things like PID files and runtime sockets. In the same vein, /var/lock also is going into /run/lock. I have acknowledged this from the very beginning, and I have been pointing out that implying that because those two (really small and bounded) directories of /var are going into /run and /run/lock, it doesn't mean that the whole /var will go into /. That is disinformation. Nobody has even proposed that /var should go into the same partition as /. *Nobody*, and the simplest proof of that is that nobody has produced a single proof to the contrary. Not a single email, blog post, or wiki entry from any system developer even mentions the possibility of requiring /var to be in the same partition as /. Whoever says that /var will be required to be on the same partition as / is either wildly speculating, or spreading FUD. So /var/run and /var/lock isn't on /var? Even if they will be linking to another location, the link has to be there for whatever program to follow. If /var isn't mounted yet, there is nothing for the program to find. The link goes the other way around. /run and /lock are the real directories, /var/run is a link to /run, /var/lock is a link to /run/lock. When the initramfs (or the init system) mount /var, they make the link. When I saw the messages about LVM and /var, that caused LVM to fail to start. I wouldn't put / on LVM and wouldn't expect it to work without a init thingy either. Thing is, based on it failing, you can't have /var on a separate partition and expect LVM to start. So, if you use LVM for /usr and/or /var, you have to have a init thingy even if / is on a regular file system. Yes, as I said in my last mail, if you need LVM, you need an initramfs. Remove the LVM, and you can have /var (and /usr for that matter) withouth an initramfs. Where/when did I say something different? I'm telling ya'll, /home is coming. That is just ridiculous. I would have said the same thing about /usr a year ago. I'm not saying it is coming next week but . . . You can speculate all you want. Fact is, nobody has proposed that, and there is not even a single email suggesting that it will be necessary. On the contrary, the requirement for an initramfs or a /usr inside the same partition as / has been being discussed years ago; if you had followed the developers lists, you wil had hear about it months before it happened. Nothing similar has happened with /var, least of it /home. We are going to end up where we can only have one drive in our Linux boxes for the OS and its relatives. And so is this: more FUD. That or we will ALL have to start using the pesky init* thingy. More FUD: the current proposal (from Zac, the principal coder of portage, and someone who actually wrotes code and know what he is talking about) is this: http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda14148849872 9fe8.xml It basically removes the need for a pesky init* thingy, although for the life of me I cannot understand why someone will not see the technical advantages of actually using an initramfs. I'll have to read his link later. Please do. I got 7 acres of land here, complete with trees. If someone can find the dev that started this mess, I can find some rope. Just saying. ;-) Oh, I live half a mile from the river too. Makes for a good dump site. lol I noticed the other day that when LVM tries to start, it fails. I have /var on a separate partition here. It was complaining about something on /var missing. So, you may be late in reporting this. I think it is already needed for LVM if /usr or /var is on a separate partition. Again, get the facts right. If you use LVM you will need to use an initramfs. If you only use a separated /usr you
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Sat, Oct 15, 2011 at 2:15 AM, Michael Schreckenbauer grim...@gmx.de wrote: Hi Canek, On Saturday, 15. October 2011 02:02:13 Canek Peláez Valdés wrote: On Sat, Oct 15, 2011 at 1:37 AM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Fri, Oct 14, 2011 at 11:56 PM, Dalerdalek1...@gmail.com wrote: Pandu Poluan wrote: On Oct 15, 2011 5:49 AM, Dalerdalek1...@gmail.com wrote: Neil Bothwick wrote: On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote: A'right now. I'm going to start on hal and /usr being on / again. :-P Jeez, 43 years on and you're still going on about it... Dang, I was only a year old when hal came out? That just doubled my age. It's closer to what I feel like tho. I'm still not happy with /usr being required tho. That is still standing on a bad nerve. Don't worry tho, I got plenty of those bad nerves. :-P Do you know that there's a plan to move /var/run to / also? ;-) Rgds, Now someone on here swears up and down that /var isn't going to be required on /. /var != /var/run /var != /var/lock /var/run is going in /run, but /var/run (by definition) only contains things like PID files and runtime sockets. In the same vein, /var/lock also is going into /run/lock. I have acknowledged this from the very beginning, and I have been pointing out that implying that because those two (really small and bounded) directories of /var are going into /run and /run/lock, it doesn't mean that the whole /var will go into /. That is disinformation. Nobody has even proposed that /var should go into the same partition as /. *Nobody*, and the simplest proof of that is that nobody has produced a single proof to the contrary. Not a single email, blog post, or wiki entry from any system developer even mentions the possibility of requiring /var to be in the same partition as /. Whoever says that /var will be required to be on the same partition as / is either wildly speculating, or spreading FUD. So /var/run and /var/lock isn't on /var? Even if they will be linking to another location, the link has to be there for whatever program to follow. If /var isn't mounted yet, there is nothing for the program to find. The link goes the other way around. /run and /lock are the real directories, /var/run is a link to /run, /var/lock is a link to /run/lock. When the initramfs (or the init system) mount /var, they make the link. When I saw the messages about LVM and /var, that caused LVM to fail to start. I wouldn't put / on LVM and wouldn't expect it to work without a init thingy either. Thing is, based on it failing, you can't have /var on a separate partition and expect LVM to start. So, if you use LVM for /usr and/or /var, you have to have a init thingy even if / is on a regular file system. Yes, as I said in my last mail, if you need LVM, you need an initramfs. Remove the LVM, and you can have /var (and /usr for that matter) withouth an initramfs. Where/when did I say something different? I'm telling ya'll, /home is coming. That is just ridiculous. I would have said the same thing about /usr a year ago. I'm not saying it is coming next week but . . . You can speculate all you want. Fact is, nobody has proposed that, and there is not even a single email suggesting that it will be necessary. On the contrary, the requirement for an initramfs or a /usr inside the same partition as / has been being discussed years ago; if you had followed the developers lists, you wil had hear about it months before it happened. Nothing similar has happened with /var, least of it /home. We are going to end up where we can only have one drive in our Linux boxes for the OS and its relatives. And so is this: more FUD. That or we will ALL have to start using the pesky init* thingy. More FUD: the current proposal (from Zac, the principal coder of portage, and someone who actually wrotes code and know what he is talking about) is this: http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda14148849872 9fe8.xml It basically removes the need for a pesky init* thingy, although for the life of me I cannot understand why someone will not see the technical advantages of actually using an initramfs. I'll have to read his link later. Please do. I got 7 acres of land here, complete with trees. If someone can find the dev that started this mess, I can find some rope. Just saying. ;-) Oh, I live half a mile from the river too. Makes for a good dump site. lol I noticed the other day that when LVM tries to start, it fails. I have /var on a separate partition here. It was complaining about something on /var missing. So, you may be late in reporting this. I think it is already needed for LVM if /usr or /var is on a separate partition. Again, get the facts right. If you use LVM you will need to use an
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer grim...@gmx.de
wrote:
On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
/var/lib usually stores whole
databases. The difference is important and relevant.
My systems has directories alsa, bluetooth, hp and many more
there that are not databases at all.
So?
Which one? That /var is not going into /?
No. That /var/lib contains databases. Is this so difficult to get?
I get it; it's just not relevant.
On my system /var/lib/alsa contains data, that alsa uses to restore
mixer- levels.
Yeah, it does.
So *my* /var/lib is used during boot and *my* /var/lib has to be
mounted by the initramfs.
No, it doesn't. What are you talking about? Look at /etc/init.d/alsasound:
depend() {
need localmount
after bootmisc modules isapnp coldplug hotplug
}
Look at the first need from alsasound depend: it says, that it goes
after localmount. If you have /var in NFS (a very weird setup for a
desktop machine) maybe it will cause problems: but then it would be
fault of OpenRC (or the alsasound init script). If /var is on a
different partition, localmount will mount it and *then* alsasound
will execute.
And it makes sense: the volume restoring doesn't matter until
immediately before running gdm and going into the desktop; of course
you can mount /var before that.
That's the situation on nearly every gentoo system
using sound
Yeah, and as I explained, thanks to need localmount there is no problem.
(systemd might handle this different, I have no idea)
Yeah, it does more intelligently: as I said, the volume restoring is
only needed just before starting X.
Got it? Your system is not the center of the world.
No, but I start to think you don't know *your* system. Check the
alsasound init script.
*lol*
Now, this is getting ridiculous. I don't know my system? Have a look into
/lib/udev/rules.d/90-alsa-restore.rules
to realize, that this is a hack, that restores alsa-levels *twice* on systems
that have /var/lib on /. The levels are supposed to be restored by *udev* not
the script.
The /var directory doesn't need to be on the same partition as /. Period.
Regards
.
Best,
Michael
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Saturday, 15. October 2011 02:21:18 Canek Peláez Valdés wrote: On Sat, Oct 15, 2011 at 2:15 AM, Michael Schreckenbauer grim...@gmx.de wrote: Hi Canek, On Saturday, 15. October 2011 02:02:13 Canek Peláez Valdés wrote: On Sat, Oct 15, 2011 at 1:37 AM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Fri, Oct 14, 2011 at 11:56 PM, Dalerdalek1...@gmail.com wrote: Pandu Poluan wrote: On Oct 15, 2011 5:49 AM, Dalerdalek1...@gmail.com wrote: Neil Bothwick wrote: On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote: A'right now. I'm going to start on hal and /usr being on / again. :-P Jeez, 43 years on and you're still going on about it... Dang, I was only a year old when hal came out? That just doubled my age. It's closer to what I feel like tho. I'm still not happy with /usr being required tho. That is still standing on a bad nerve. Don't worry tho, I got plenty of those bad nerves. :-P Do you know that there's a plan to move /var/run to / also? ;-) Rgds, Now someone on here swears up and down that /var isn't going to be required on /. /var != /var/run /var != /var/lock /var/run is going in /run, but /var/run (by definition) only contains things like PID files and runtime sockets. In the same vein, /var/lock also is going into /run/lock. I have acknowledged this from the very beginning, and I have been pointing out that implying that because those two (really small and bounded) directories of /var are going into /run and /run/lock, it doesn't mean that the whole /var will go into /. That is disinformation. Nobody has even proposed that /var should go into the same partition as /. *Nobody*, and the simplest proof of that is that nobody has produced a single proof to the contrary. Not a single email, blog post, or wiki entry from any system developer even mentions the possibility of requiring /var to be in the same partition as /. Whoever says that /var will be required to be on the same partition as / is either wildly speculating, or spreading FUD. So /var/run and /var/lock isn't on /var? Even if they will be linking to another location, the link has to be there for whatever program to follow. If /var isn't mounted yet, there is nothing for the program to find. The link goes the other way around. /run and /lock are the real directories, /var/run is a link to /run, /var/lock is a link to /run/lock. When the initramfs (or the init system) mount /var, they make the link. When I saw the messages about LVM and /var, that caused LVM to fail to start. I wouldn't put / on LVM and wouldn't expect it to work without a init thingy either. Thing is, based on it failing, you can't have /var on a separate partition and expect LVM to start. So, if you use LVM for /usr and/or /var, you have to have a init thingy even if / is on a regular file system. Yes, as I said in my last mail, if you need LVM, you need an initramfs. Remove the LVM, and you can have /var (and /usr for that matter) withouth an initramfs. Where/when did I say something different? I'm telling ya'll, /home is coming. That is just ridiculous. I would have said the same thing about /usr a year ago. I'm not saying it is coming next week but . . . You can speculate all you want. Fact is, nobody has proposed that, and there is not even a single email suggesting that it will be necessary. On the contrary, the requirement for an initramfs or a /usr inside the same partition as / has been being discussed years ago; if you had followed the developers lists, you wil had hear about it months before it happened. Nothing similar has happened with /var, least of it /home. We are going to end up where we can only have one drive in our Linux boxes for the OS and its relatives. And so is this: more FUD. That or we will ALL have to start using the pesky init* thingy. More FUD: the current proposal (from Zac, the principal coder of portage, and someone who actually wrotes code and know what he is talking about) is this: http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda14148 849872 9fe8.xml It basically removes the need for a pesky init* thingy, although for the life of me I cannot understand why someone will not see the technical advantages of actually using an initramfs. I'll have to read his link later. Please do. I got 7 acres of land here, complete with trees. If someone can find the dev that started this mess, I can find some rope. Just saying. ;-) Oh, I live half a mile from the river too. Makes for a good dump site. lol I noticed the other day that when LVM tries to start, it fails. I have
Re: [gentoo-user] Apologize to everyone for my nonprofessional
Canek Peláez Valdés wrote: On Sat, Oct 15, 2011 at 2:15 AM, Michael Schreckenbauergrim...@gmx.de wrote: I would. But given the way udev people solve those issues, I don't. If something on /var is needed during boot in the next ten years, they will propose to move it to /. They do it with /run, they do it with /lock, they will do it the same way the next time such an issue arises. You keep speculating and speculating. When you have some evidence to sustain your claims, we talk. Regards. Can you point to where a dev has said that /var, /home or any other changes will NEVER happen? I would start with the dev that caused all this if it were me. I would like to hear that from him for sure. Let's see if you can prove your claim then we'll talk. Like I said, a year or so ago, I would have thought anyone saying /usr would need to be on / to boot or a init thingy was losing their mind. It is just not the way Linux is supposed to be. Yet here we are. Dale :-) :-)
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer grim...@gmx.de wrote:
On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer grim...@gmx.de
wrote:
On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
/var/lib usually stores whole
databases. The difference is important and relevant.
My systems has directories alsa, bluetooth, hp and many more
there that are not databases at all.
So?
Which one? That /var is not going into /?
No. That /var/lib contains databases. Is this so difficult to get?
I get it; it's just not relevant.
On my system /var/lib/alsa contains data, that alsa uses to restore
mixer- levels.
Yeah, it does.
So *my* /var/lib is used during boot and *my* /var/lib has to be
mounted by the initramfs.
No, it doesn't. What are you talking about? Look at /etc/init.d/alsasound:
depend() {
need localmount
after bootmisc modules isapnp coldplug hotplug
}
Look at the first need from alsasound depend: it says, that it goes
after localmount. If you have /var in NFS (a very weird setup for a
desktop machine) maybe it will cause problems: but then it would be
fault of OpenRC (or the alsasound init script). If /var is on a
different partition, localmount will mount it and *then* alsasound
will execute.
And it makes sense: the volume restoring doesn't matter until
immediately before running gdm and going into the desktop; of course
you can mount /var before that.
That's the situation on nearly every gentoo system
using sound
Yeah, and as I explained, thanks to need localmount there is no problem.
(systemd might handle this different, I have no idea)
Yeah, it does more intelligently: as I said, the volume restoring is
only needed just before starting X.
Got it? Your system is not the center of the world.
No, but I start to think you don't know *your* system. Check the
alsasound init script.
*lol*
Now, this is getting ridiculous.
Indeed, it is getting ridiculous.
I don't know my system?
No, you don't.
Have a look into
/lib/udev/rules.d/90-alsa-restore.rules
to realize, that this is a hack, that restores alsa-levels *twice* on systems
that have /var/lib on /. The levels are supposed to be restored by *udev* not
the script.
Yeah, but it doesn't run when udev *starts*. It runs when a card is
*added* to the system; that is the reason for the ACTION=add part.
It's inteded to be used for USB cards (like external speakers with a
little sound card incorporated), so its volume is restored *at insert
time*.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Sat, Oct 15, 2011 at 2:32 AM, Michael Schreckenbauer grim...@gmx.de wrote: On Saturday, 15. October 2011 02:21:18 Canek Peláez Valdés wrote: On Sat, Oct 15, 2011 at 2:15 AM, Michael Schreckenbauer grim...@gmx.de wrote: Hi Canek, On Saturday, 15. October 2011 02:02:13 Canek Peláez Valdés wrote: On Sat, Oct 15, 2011 at 1:37 AM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Fri, Oct 14, 2011 at 11:56 PM, Dalerdalek1...@gmail.com wrote: Pandu Poluan wrote: On Oct 15, 2011 5:49 AM, Dalerdalek1...@gmail.com wrote: Neil Bothwick wrote: On Fri, 14 Oct 2011 11:15:24 -0500, Dale wrote: A'right now. I'm going to start on hal and /usr being on / again. :-P Jeez, 43 years on and you're still going on about it... Dang, I was only a year old when hal came out? That just doubled my age. It's closer to what I feel like tho. I'm still not happy with /usr being required tho. That is still standing on a bad nerve. Don't worry tho, I got plenty of those bad nerves. :-P Do you know that there's a plan to move /var/run to / also? ;-) Rgds, Now someone on here swears up and down that /var isn't going to be required on /. /var != /var/run /var != /var/lock /var/run is going in /run, but /var/run (by definition) only contains things like PID files and runtime sockets. In the same vein, /var/lock also is going into /run/lock. I have acknowledged this from the very beginning, and I have been pointing out that implying that because those two (really small and bounded) directories of /var are going into /run and /run/lock, it doesn't mean that the whole /var will go into /. That is disinformation. Nobody has even proposed that /var should go into the same partition as /. *Nobody*, and the simplest proof of that is that nobody has produced a single proof to the contrary. Not a single email, blog post, or wiki entry from any system developer even mentions the possibility of requiring /var to be in the same partition as /. Whoever says that /var will be required to be on the same partition as / is either wildly speculating, or spreading FUD. So /var/run and /var/lock isn't on /var? Even if they will be linking to another location, the link has to be there for whatever program to follow. If /var isn't mounted yet, there is nothing for the program to find. The link goes the other way around. /run and /lock are the real directories, /var/run is a link to /run, /var/lock is a link to /run/lock. When the initramfs (or the init system) mount /var, they make the link. When I saw the messages about LVM and /var, that caused LVM to fail to start. I wouldn't put / on LVM and wouldn't expect it to work without a init thingy either. Thing is, based on it failing, you can't have /var on a separate partition and expect LVM to start. So, if you use LVM for /usr and/or /var, you have to have a init thingy even if / is on a regular file system. Yes, as I said in my last mail, if you need LVM, you need an initramfs. Remove the LVM, and you can have /var (and /usr for that matter) withouth an initramfs. Where/when did I say something different? I'm telling ya'll, /home is coming. That is just ridiculous. I would have said the same thing about /usr a year ago. I'm not saying it is coming next week but . . . You can speculate all you want. Fact is, nobody has proposed that, and there is not even a single email suggesting that it will be necessary. On the contrary, the requirement for an initramfs or a /usr inside the same partition as / has been being discussed years ago; if you had followed the developers lists, you wil had hear about it months before it happened. Nothing similar has happened with /var, least of it /home. We are going to end up where we can only have one drive in our Linux boxes for the OS and its relatives. And so is this: more FUD. That or we will ALL have to start using the pesky init* thingy. More FUD: the current proposal (from Zac, the principal coder of portage, and someone who actually wrotes code and know what he is talking about) is this: http://archives.gentoo.org/gentoo-dev/msg_20749880f5bc5feda14148 849872 9fe8.xml It basically removes the need for a pesky init* thingy, although for the life of me I cannot understand why someone will not see the technical advantages of actually using an initramfs. I'll have to read his link later. Please do. I got 7 acres of land here, complete with trees. If someone can find the dev that started this mess, I can find some rope. Just saying. ;-) Oh, I live half a mile from the river too. Makes for a good dump site. lol I noticed the other day that
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Sat, 15 Oct 2011 00:34:10 -0700, Canek Peláez Valdés wrote: /var != /var/run /var != /var/lock /var/run is going in /run, but /var/run (by definition) only contains things like PID files and runtime sockets. In the same vein, /var/lock also is going into /run/lock. I have acknowledged this from the very beginning, and I have been pointing out that implying that because those two (really small and bounded) directories of /var are going into /run and /run/lock, Putting the contents of /var/run and /var/lock on the root filesystem makes sense. Nobody has even proposed that /var should go into the same partition as /. *Nobody*, and the simplest proof of that is that nobody has produced a single proof to the contrary. Not a single email, blog post, or wiki entry from any system developer even mentions the possibility of requiring /var to be in the same partition as /. The stated reason for requiring /usr on / is that udev can run *arbitrary* scripts and commands. If they are arbitrary, they could require access to anywhere, including /var or /home. That's the problem with this approach. Instead of saying it can run stuff from anywhere, so anywhere must be mounted before udev is run the fact that it is trying to run these arbitrary commands before filesystems are mounted should be addressed. Whoever says that /var will be required to be on the same partition as / is either wildly speculating, or spreading FUD. It's not wild speculation, it is logical extrapolation of the current approach. It basically removes the need for a pesky init* thingy, although for the life of me I cannot understand why someone will not see the technical advantages of actually using an initramfs. We understand its advantages in some circumstances, but I cannot understand why someone will not see the technical disadvantages of actually using an initramfs. -- Neil Bothwick It is impossible to fully enjoy procrastination unless one has plenty of work to do. signature.asc Description: PGP signature
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Sat, Oct 15, 2011 at 2:37 AM, Dale rdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Sat, Oct 15, 2011 at 2:15 AM, Michael Schreckenbauergrim...@gmx.de wrote: I would. But given the way udev people solve those issues, I don't. If something on /var is needed during boot in the next ten years, they will propose to move it to /. They do it with /run, they do it with /lock, they will do it the same way the next time such an issue arises. You keep speculating and speculating. When you have some evidence to sustain your claims, we talk. Regards. Can you point to where a dev has said that /var, /home or any other changes will NEVER happen? Of course not, but this is the same as any accusation: the people making the accusation has to provide the evidence. YOU are the one making the accusation, YOU provide the evidence. I would start with the dev that caused all this if it were me. I would like to hear that from him for sure. Let's see if you can prove your claim then we'll talk. *I* don't have to prove anything because I'm talkin about the facts *right now*. You guys are the ones speculating about an imaginary future. Like I said, a year or so ago, I would have thought anyone saying /usr would need to be on / to boot or a init thingy was losing their mind. It is just not the way Linux is supposed to be. Yet here we are. Says who? I say it is exactly the way Linux is supposed to be. And /usr doesn't *need* to be on /; just get an initramfs and you can have it in an NFS from the other side of the planet. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Saturday, 15. October 2011 02:47:26 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer grim...@gmx.de
wrote:
On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer
grim...@gmx.de
wrote:
On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
/var/lib usually stores whole
databases. The difference is important and relevant.
My systems has directories alsa, bluetooth, hp and many more
there that are not databases at all.
So?
Which one? That /var is not going into /?
No. That /var/lib contains databases. Is this so difficult to get?
I get it; it's just not relevant.
On my system /var/lib/alsa contains data, that alsa uses to
restore
mixer- levels.
Yeah, it does.
So *my* /var/lib is used during boot and *my* /var/lib has to be
mounted by the initramfs.
No, it doesn't. What are you talking about? Look at
/etc/init.d/alsasound:
depend() {
need localmount
after bootmisc modules isapnp coldplug hotplug
}
Look at the first need from alsasound depend: it says, that it goes
after localmount. If you have /var in NFS (a very weird setup for a
desktop machine) maybe it will cause problems: but then it would be
fault of OpenRC (or the alsasound init script). If /var is on a
different partition, localmount will mount it and *then* alsasound
will execute.
And it makes sense: the volume restoring doesn't matter until
immediately before running gdm and going into the desktop; of course
you can mount /var before that.
That's the situation on nearly every gentoo system
using sound
Yeah, and as I explained, thanks to need localmount there is no
problem.
(systemd might handle this different, I have no idea)
Yeah, it does more intelligently: as I said, the volume restoring is
only needed just before starting X.
Got it? Your system is not the center of the world.
No, but I start to think you don't know *your* system. Check the
alsasound init script.
*lol*
Now, this is getting ridiculous.
Indeed, it is getting ridiculous.
I don't know my system?
No, you don't.
Have a look into
/lib/udev/rules.d/90-alsa-restore.rules
to realize, that this is a hack, that restores alsa-levels *twice* on
systems that have /var/lib on /. The levels are supposed to be restored
by *udev* not the script.
Yeah, but it doesn't run when udev *starts*. It runs when a card is
*added* to the system; that is the reason for the ACTION=add part.
It's inteded to be used for USB cards (like external speakers with a
little sound card incorporated), so its volume is restored *at insert
time*.
Nonsense. Action add is used for every device in your system, built-in or
plugged in later. So this rule is not only used for hotplug-USB-soundcards,
but for every soundcard in your system.
See /etc/udev/rules.d/70-persistent-net.rules for example:
SUBSYSTEM==net, ACTION==add, DRIVERS==?*, ATTR{address}==...,
ATTR{type}==1, KERNEL==eth*, NAME=eth0
Regards.
Best,
Michael
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Sat, Oct 15, 2011 at 2:53 AM, Neil Bothwick n...@digimed.co.uk wrote: On Sat, 15 Oct 2011 00:34:10 -0700, Canek Peláez Valdés wrote: /var != /var/run /var != /var/lock /var/run is going in /run, but /var/run (by definition) only contains things like PID files and runtime sockets. In the same vein, /var/lock also is going into /run/lock. I have acknowledged this from the very beginning, and I have been pointing out that implying that because those two (really small and bounded) directories of /var are going into /run and /run/lock, Putting the contents of /var/run and /var/lock on the root filesystem makes sense. Nobody has even proposed that /var should go into the same partition as /. *Nobody*, and the simplest proof of that is that nobody has produced a single proof to the contrary. Not a single email, blog post, or wiki entry from any system developer even mentions the possibility of requiring /var to be in the same partition as /. The stated reason for requiring /usr on / is that udev can run *arbitrary* scripts and commands. If they are arbitrary, they could require access to anywhere, including /var or /home. That's the problem with this approach. Instead of saying it can run stuff from anywhere, so anywhere must be mounted before udev is run the fact that it is trying to run these arbitrary commands before filesystems are mounted should be addressed. With an initramfs you can have everything mounted by udev execution time. But forget about that. It's arbitrary (basically) on executables and libraries. If an script needs something more (from /var, lets say), then the rule should be written in such a way that it can be called after that directory is mounted. If you try to put the same restriction with *executables* (not data, like in the ALSA case), then you need to start moving every executable to /, because that's the only way to guarantee that it would be available aearly on boot time (if you don't use an initramfs and have /usr separated). That sucks. /bin and /lib were the original hack, for this very reason: some executables were needed early at boot time, and they put them there so they were available. The initramfs solves this problem; at some point, /bin /lib and /sbin will no longer be necessary. So yeah, the udev rules can execute arbitrary code, but the should not run stupid code. There is a difference. Whoever says that /var will be required to be on the same partition as / is either wildly speculating, or spreading FUD. It's not wild speculation, it is logical extrapolation of the current approach. You don't have enough data to extrapolate. It basically removes the need for a pesky init* thingy, although for the life of me I cannot understand why someone will not see the technical advantages of actually using an initramfs. We understand its advantages in some circumstances, but I cannot understand why someone will not see the technical disadvantages of actually using an initramfs. Care to explain? Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Sat, Oct 15, 2011 at 3:05 AM, Michael Schreckenbauer grim...@gmx.de wrote:
On Saturday, 15. October 2011 02:47:26 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer grim...@gmx.de
wrote:
On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer
grim...@gmx.de
wrote:
On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
/var/lib usually stores whole
databases. The difference is important and relevant.
My systems has directories alsa, bluetooth, hp and many more
there that are not databases at all.
So?
Which one? That /var is not going into /?
No. That /var/lib contains databases. Is this so difficult to get?
I get it; it's just not relevant.
On my system /var/lib/alsa contains data, that alsa uses to
restore
mixer- levels.
Yeah, it does.
So *my* /var/lib is used during boot and *my* /var/lib has to be
mounted by the initramfs.
No, it doesn't. What are you talking about? Look at
/etc/init.d/alsasound:
depend() {
need localmount
after bootmisc modules isapnp coldplug hotplug
}
Look at the first need from alsasound depend: it says, that it goes
after localmount. If you have /var in NFS (a very weird setup for a
desktop machine) maybe it will cause problems: but then it would be
fault of OpenRC (or the alsasound init script). If /var is on a
different partition, localmount will mount it and *then* alsasound
will execute.
And it makes sense: the volume restoring doesn't matter until
immediately before running gdm and going into the desktop; of course
you can mount /var before that.
That's the situation on nearly every gentoo system
using sound
Yeah, and as I explained, thanks to need localmount there is no
problem.
(systemd might handle this different, I have no idea)
Yeah, it does more intelligently: as I said, the volume restoring is
only needed just before starting X.
Got it? Your system is not the center of the world.
No, but I start to think you don't know *your* system. Check the
alsasound init script.
*lol*
Now, this is getting ridiculous.
Indeed, it is getting ridiculous.
I don't know my system?
No, you don't.
Have a look into
/lib/udev/rules.d/90-alsa-restore.rules
to realize, that this is a hack, that restores alsa-levels *twice* on
systems that have /var/lib on /. The levels are supposed to be restored
by *udev* not the script.
Yeah, but it doesn't run when udev *starts*. It runs when a card is
*added* to the system; that is the reason for the ACTION=add part.
It's inteded to be used for USB cards (like external speakers with a
little sound card incorporated), so its volume is restored *at insert
time*.
Nonsense. Action add is used for every device in your system, built-in or
plugged in later. So this rule is not only used for hotplug-USB-soundcards,
but for every soundcard in your system.
Yeah, you are right. Sorry. I forgot about the little numbers udev uses:
10-dm.rules
11-dm-lvm.rules
13-dm-disk.rules
60-persistent-storage.rules
70-persistent-net.rules
90-alsa-restore.rules
So, the same way that in the alsasound init script need localmount
guarantee that /var is mounted, the 60-persistent-storage.rules
guarantees that /var is mounted before the 90-alsa-restore.rules
restores ALSA's volume.
Again, there is no problem. Yeah, the rule is executed at udev
execution time... but after the persisten-storage rule. So, you see,
no problem. No need for /var in the same partition as /.
You guys keep speculating. As of *now*, there is not a single line of
code that prevents a system from booting correctly if /var lives in
another partition, no matter if the system uses an initramfs or not.
As of *now* nobody is discussing, proposing, or even mentioning
(except for you guys) about requiring /var to live in the same
partition as /.
And that's that.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Saturday, 15. October 2011 03:34:27 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 3:05 AM, Michael Schreckenbauer grim...@gmx.de
wrote:
On Saturday, 15. October 2011 02:47:26 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer
grim...@gmx.de
wrote:
On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer
grim...@gmx.de
wrote:
On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
/var/lib usually stores whole
databases. The difference is important and relevant.
My systems has directories alsa, bluetooth, hp and many
more
there that are not databases at all.
So?
Which one? That /var is not going into /?
No. That /var/lib contains databases. Is this so difficult
to get?
I get it; it's just not relevant.
On my system /var/lib/alsa contains data, that alsa uses to
restore
mixer- levels.
Yeah, it does.
So *my* /var/lib is used during boot and *my* /var/lib has
to be
mounted by the initramfs.
No, it doesn't. What are you talking about? Look at
/etc/init.d/alsasound:
depend() {
need localmount
after bootmisc modules isapnp coldplug hotplug
}
Look at the first need from alsasound depend: it says, that it
goes
after localmount. If you have /var in NFS (a very weird setup
for a
desktop machine) maybe it will cause problems: but then it would
be
fault of OpenRC (or the alsasound init script). If /var is on a
different partition, localmount will mount it and *then*
alsasound
will execute.
And it makes sense: the volume restoring doesn't matter until
immediately before running gdm and going into the desktop; of
course
you can mount /var before that.
That's the situation on nearly every gentoo system
using sound
Yeah, and as I explained, thanks to need localmount there is no
problem.
(systemd might handle this different, I have no idea)
Yeah, it does more intelligently: as I said, the volume
restoring is
only needed just before starting X.
Got it? Your system is not the center of the world.
No, but I start to think you don't know *your* system. Check the
alsasound init script.
*lol*
Now, this is getting ridiculous.
Indeed, it is getting ridiculous.
I don't know my system?
No, you don't.
Have a look into
/lib/udev/rules.d/90-alsa-restore.rules
to realize, that this is a hack, that restores alsa-levels *twice*
on
systems that have /var/lib on /. The levels are supposed to be
restored by *udev* not the script.
Yeah, but it doesn't run when udev *starts*. It runs when a card is
*added* to the system; that is the reason for the ACTION=add part.
It's inteded to be used for USB cards (like external speakers with a
little sound card incorporated), so its volume is restored *at insert
time*.
Nonsense. Action add is used for every device in your system, built-in
or plugged in later. So this rule is not only used for
hotplug-USB-soundcards, but for every soundcard in your system.
Yeah, you are right. Sorry. I forgot about the little numbers udev uses:
10-dm.rules
11-dm-lvm.rules
13-dm-disk.rules
60-persistent-storage.rules
70-persistent-net.rules
90-alsa-restore.rules
So, the same way that in the alsasound init script need localmount
guarantee that /var is mounted, the 60-persistent-storage.rules
guarantees that /var is mounted before the 90-alsa-restore.rules
restores ALSA's volume.
My 60-persisten-storage.rules creates device nodes. It does not mount
anything. Is your's different?
Again, there is no problem. Yeah, the rule is executed at udev
execution time... but after the persisten-storage rule. So, you see,
no problem. No need for /var in the same partition as /.
So my devices nodes for harddisks exist, when alsa restores it's levels. Does
not solve anything.
You guys keep speculating.
We are speculating?
*You* were wrong about the assumtion that /var/lib contains databases.
*You* were wrong about the assumtion how action add works.
And *you* are wrong about the assumption, what 60-persistent-storage.rules
does.
Yet you claim, that *I* don't know my system.
I'd say, do your homework, then we can talk.
Regards.
Best,
Michael
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Sat, Oct 15, 2011 at 3:34 AM, Canek Peláez Valdés can...@gmail.com wrote:
On Sat, Oct 15, 2011 at 3:05 AM, Michael Schreckenbauer grim...@gmx.de
wrote:
On Saturday, 15. October 2011 02:47:26 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer grim...@gmx.de
wrote:
On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer
grim...@gmx.de
wrote:
On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
/var/lib usually stores whole
databases. The difference is important and relevant.
My systems has directories alsa, bluetooth, hp and many more
there that are not databases at all.
So?
Which one? That /var is not going into /?
No. That /var/lib contains databases. Is this so difficult to get?
I get it; it's just not relevant.
On my system /var/lib/alsa contains data, that alsa uses to
restore
mixer- levels.
Yeah, it does.
So *my* /var/lib is used during boot and *my* /var/lib has to be
mounted by the initramfs.
No, it doesn't. What are you talking about? Look at
/etc/init.d/alsasound:
depend() {
need localmount
after bootmisc modules isapnp coldplug hotplug
}
Look at the first need from alsasound depend: it says, that it goes
after localmount. If you have /var in NFS (a very weird setup for a
desktop machine) maybe it will cause problems: but then it would be
fault of OpenRC (or the alsasound init script). If /var is on a
different partition, localmount will mount it and *then* alsasound
will execute.
And it makes sense: the volume restoring doesn't matter until
immediately before running gdm and going into the desktop; of course
you can mount /var before that.
That's the situation on nearly every gentoo system
using sound
Yeah, and as I explained, thanks to need localmount there is no
problem.
(systemd might handle this different, I have no idea)
Yeah, it does more intelligently: as I said, the volume restoring is
only needed just before starting X.
Got it? Your system is not the center of the world.
No, but I start to think you don't know *your* system. Check the
alsasound init script.
*lol*
Now, this is getting ridiculous.
Indeed, it is getting ridiculous.
I don't know my system?
No, you don't.
Have a look into
/lib/udev/rules.d/90-alsa-restore.rules
to realize, that this is a hack, that restores alsa-levels *twice* on
systems that have /var/lib on /. The levels are supposed to be restored
by *udev* not the script.
Yeah, but it doesn't run when udev *starts*. It runs when a card is
*added* to the system; that is the reason for the ACTION=add part.
It's inteded to be used for USB cards (like external speakers with a
little sound card incorporated), so its volume is restored *at insert
time*.
Nonsense. Action add is used for every device in your system, built-in or
plugged in later. So this rule is not only used for hotplug-USB-soundcards,
but for every soundcard in your system.
Yeah, you are right. Sorry. I forgot about the little numbers udev uses:
10-dm.rules
11-dm-lvm.rules
13-dm-disk.rules
60-persistent-storage.rules
70-persistent-net.rules
90-alsa-restore.rules
So, the same way that in the alsasound init script need localmount
guarantee that /var is mounted, the 60-persistent-storage.rules
guarantees that /var is mounted before the 90-alsa-restore.rules
restores ALSA's volume.
Again, there is no problem. Yeah, the rule is executed at udev
execution time... but after the persisten-storage rule. So, you see,
no problem. No need for /var in the same partition as /.
Mmmh. I got that one wrong; the persistent-storage rules just creates
the necessary symlinks, doesn't mount anything. (It's 3 am here, so I
should get sleep).
However, my point remains: the system boots correctly even if that
rule fails. It's not only non-fatal, it's pretty trivial and easily
fixable by the init system (like OpenRC and systemd does).
Even if this ALSA rule requires /var/lib, it doesn't means that it
requires /var in the same partition as /.
Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Sat, Oct 15, 2011 at 3:45 AM, Michael Schreckenbauer grim...@gmx.de wrote:
On Saturday, 15. October 2011 03:34:27 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 3:05 AM, Michael Schreckenbauer grim...@gmx.de
wrote:
On Saturday, 15. October 2011 02:47:26 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer
grim...@gmx.de
wrote:
On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer
grim...@gmx.de
wrote:
On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
/var/lib usually stores whole
databases. The difference is important and relevant.
My systems has directories alsa, bluetooth, hp and many
more
there that are not databases at all.
So?
Which one? That /var is not going into /?
No. That /var/lib contains databases. Is this so difficult
to get?
I get it; it's just not relevant.
On my system /var/lib/alsa contains data, that alsa uses to
restore
mixer- levels.
Yeah, it does.
So *my* /var/lib is used during boot and *my* /var/lib has
to be
mounted by the initramfs.
No, it doesn't. What are you talking about? Look at
/etc/init.d/alsasound:
depend() {
need localmount
after bootmisc modules isapnp coldplug hotplug
}
Look at the first need from alsasound depend: it says, that it
goes
after localmount. If you have /var in NFS (a very weird setup
for a
desktop machine) maybe it will cause problems: but then it would
be
fault of OpenRC (or the alsasound init script). If /var is on a
different partition, localmount will mount it and *then*
alsasound
will execute.
And it makes sense: the volume restoring doesn't matter until
immediately before running gdm and going into the desktop; of
course
you can mount /var before that.
That's the situation on nearly every gentoo system
using sound
Yeah, and as I explained, thanks to need localmount there is no
problem.
(systemd might handle this different, I have no idea)
Yeah, it does more intelligently: as I said, the volume
restoring is
only needed just before starting X.
Got it? Your system is not the center of the world.
No, but I start to think you don't know *your* system. Check the
alsasound init script.
*lol*
Now, this is getting ridiculous.
Indeed, it is getting ridiculous.
I don't know my system?
No, you don't.
Have a look into
/lib/udev/rules.d/90-alsa-restore.rules
to realize, that this is a hack, that restores alsa-levels *twice*
on
systems that have /var/lib on /. The levels are supposed to be
restored by *udev* not the script.
Yeah, but it doesn't run when udev *starts*. It runs when a card is
*added* to the system; that is the reason for the ACTION=add part.
It's inteded to be used for USB cards (like external speakers with a
little sound card incorporated), so its volume is restored *at insert
time*.
Nonsense. Action add is used for every device in your system, built-in
or plugged in later. So this rule is not only used for
hotplug-USB-soundcards, but for every soundcard in your system.
Yeah, you are right. Sorry. I forgot about the little numbers udev uses:
10-dm.rules
11-dm-lvm.rules
13-dm-disk.rules
60-persistent-storage.rules
70-persistent-net.rules
90-alsa-restore.rules
So, the same way that in the alsasound init script need localmount
guarantee that /var is mounted, the 60-persistent-storage.rules
guarantees that /var is mounted before the 90-alsa-restore.rules
restores ALSA's volume.
My 60-persisten-storage.rules creates device nodes. It does not mount
anything. Is your's different?
Again, there is no problem. Yeah, the rule is executed at udev
execution time... but after the persisten-storage rule. So, you see,
no problem. No need for /var in the same partition as /.
So my devices nodes for harddisks exist, when alsa restores it's levels. Does
not solve anything.
You guys keep speculating.
We are speculating?
*You* were wrong about the assumtion that /var/lib contains databases.
*You* were wrong about the assumtion how action add works.
And *you* are wrong about the assumption, what 60-persistent-storage.rules
does.
Yet you claim, that *I* don't know my system.
I'd say, do your homework, then we can talk.
I got that points wrong, I admit. I repeat, 3am here ;) I apogolize
for saying that to you Michael; I shouldn't have, even if I would have
been right (and I wasn't). Again, no excuse, but it's (actually) 4am
here now.
It doesn't change the fact that a) the system doesn't need /var/lib to
boot (ALSA does, and it's only for the cosmetic reason of restore the
volume, easily fixable latter in the boot process), and b) that nobody
is proposing that /var should go in the same
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Sat, 15 Oct 2011 03:10:37 -0700, Canek Peláez Valdés wrote: It's arbitrary (basically) on executables and libraries. If an script needs something more (from /var, lets say), then the rule should be written in such a way that it can be called after that directory is mounted. If you try to put the same restriction with *executables* (not data, like in the ALSA case), then you need to start moving every executable to /, because that's the only way to guarantee that it would be available aearly on boot time (if you don't use an initramfs and have /usr separated). Anything needed for early boot is already in /. The problem is that udev is trying to run all its rules at that early stage, when it should not. This currently causes some actions to fail because /usr is not mounted yet. The solution is not to mount /usr early, because that only deals with one case, but to make sure that udev does not run actions until the full system is available. This has been stated many times by several people in the previous threads. So yeah, the udev rules can execute arbitrary code, but the should not run stupid code. There is a difference. Excluding stupid makes it non-arbitrary. Whoever says that /var will be required to be on the same partition as / is either wildly speculating, or spreading FUD. It's not wild speculation, it is logical extrapolation of the current approach. You don't have enough data to extrapolate. I do, the statement about running arbitrary code means that it could require access to anywhere. It basically removes the need for a pesky init* thingy, although for the life of me I cannot understand why someone will not see the technical advantages of actually using an initramfs. We understand its advantages in some circumstances, but I cannot understand why someone will not see the technical disadvantages of actually using an initramfs. Care to explain? Again? It's already been covered many times before. You expect people to blindly accept your POV that an initramfs is a good thing, yet refuse to see the circumstances where others believe it is not. For one thing, implementing this in a stable, running system without interruption is a non-trivial task. -- Neil Bothwick Where do forest rangers go to get away from it all? signature.asc Description: PGP signature
[gentoo-user] Dennis Ritchie
hello boys [1], i know i don't participate much on this list, but this does not mean that i don't try to follow most of the threads (not all of them, i admit). i realized just now that no one has commented on the news of the recent death of dennis ritchie. considering that his contributions to the development of computational technologies were not only paramount, but affect all of us in a very direct way, i think we could somehow compensate for the lack of echo of these news in the media, by dedicating some time to celebrate his memory and express our gratitude. best, lj [1] sorry if there are any girls out there, but i think i have never seen any female names on this list...
Re: [gentoo-user] CONFIG_USB_SUSPEND, where ?
Am Sat, 15 Oct 2011 00:54:48 -0700
schrieb Canek Peláez Valdés can...@gmail.com:
On Sat, Oct 15, 2011 at 12:49 AM, Alain Didierjean
alain.didierj...@free.fr wrote:
* Messages for package sys-fs/udisks-1.0.4-r1:
* CONFIG_USB_SUSPEND: is not set when it should be.
As the message above from emerge says, no way to update
sys-fs/udisks as CONFIG_USB_SUSPEND is not set. The problem is
where to find that option. Not in linux/.config, so where ?
i think it only shows up there if it is already set. AFAIK the
kernel options are defined in the various Kconfig files spread
throughout the source tree. in this case
drivers/usb/core/Kconfig
when searching for an option you can do
find /usr/src/linux/ -name Kconfig \
-exec grep USB_SUSPEND {} /dev/null \;
which gives you two hits:
/usr/src/linux/drivers/usb/core/Kconfig:config USB_SUSPEND
/usr/src/linux/drivers/usb/core/Kconfig:depends on USB_SUSPEND
and
grep -A 20 'config USB_SUSPEND' /usr/src/linux/drivers/usb/core/Kconfig
giving you description and help:
config USB_SUSPEND
bool USB runtime power management (autosuspend) and wakeup
depends on USB PM_RUNTIME
help
If you say Y here, you can use driver calls or the sysfs
power/control file to enable or disable autosuspend for
individual USB peripherals (see
Documentation/usb/power-management.txt for more details).
Also, USB remote wakeup signaling is supported, whereby some
USB devices (like keyboards and network adapters) can wake up
their parent hub. That wakeup cascades up the USB tree, and
could wake the system from states like suspend-to-RAM.
If you are unsure about this, say N here.
Cool tip for the future: Go to /usr/src/linux, type make menuconfig.
Then type / (slash). Then type SUSPEND and ENTER. It will show you
all the kernel options with SUSPEND on them.
or this, of course ;)
In particular, for USB_SUSPEND it says:
Symbol: USB_SUSPEND [=y]
Type : boolean
Prompt: USB runtime power management (autosuspend) and wakeup
Defined at drivers/usb/core/Kconfig:93
Depends on: USB_SUPPORT [=y] USB [=y] PM_RUNTIME [=y]
Location:
- Device Drivers
- USB support (USB_SUPPORT [=y])
- Support for Host-side USB (USB [=y])
So there, is in Device Drivers - USB support - Support for
Host-side USB.
Regards.
Re: [gentoo-user] Dennis Ritchie
On Sat, Oct 15, 2011 at 7:33 AM, luis jure l...@internet.com.uy wrote: hello boys [1], i know i don't participate much on this list, but this does not mean that i don't try to follow most of the threads (not all of them, i admit). i realized just now that no one has commented on the news of the recent death of dennis ritchie. considering that his contributions to the development of computational technologies were not only paramount, but affect all of us in a very direct way, i think we could somehow compensate for the lack of echo of these news in the media, by dedicating some time to celebrate his memory and express our gratitude. [1] sorry if there are any girls out there, but i think i have never seen any female names on this list... Well, if it helps, the reason I have a huge beard and long hair is because I idolized Thompson and Ritchie as far back as my early teen years. My very conservative grandparents were less than amused that I was actively seeking a 60s Berkeley look. -- :wq
Re: [gentoo-user] CONFIG_USB_SUSPEND, where ?
Am 15.10.2011 13:57, schrieb Jonas de Buhr:
Am Sat, 15 Oct 2011 00:54:48 -0700
schrieb Canek Peláez Valdés can...@gmail.com:
On Sat, Oct 15, 2011 at 12:49 AM, Alain Didierjean
alain.didierj...@free.fr wrote:
* Messages for package sys-fs/udisks-1.0.4-r1:
* CONFIG_USB_SUSPEND: is not set when it should be.
As the message above from emerge says, no way to update
sys-fs/udisks as CONFIG_USB_SUSPEND is not set. The problem is
where to find that option. Not in linux/.config, so where ?
i think it only shows up there if it is already set. AFAIK the
kernel options are defined in the various Kconfig files spread
throughout the source tree. in this case
drivers/usb/core/Kconfig
when searching for an option you can do
find /usr/src/linux/ -name Kconfig \
-exec grep USB_SUSPEND {} /dev/null \;
which gives you two hits:
/usr/src/linux/drivers/usb/core/Kconfig:config USB_SUSPEND
/usr/src/linux/drivers/usb/core/Kconfig: depends on USB_SUSPEND
and
grep -A 20 'config USB_SUSPEND' /usr/src/linux/drivers/usb/core/Kconfig
giving you description and help:
config USB_SUSPEND
bool USB runtime power management (autosuspend) and wakeup
depends on USB PM_RUNTIME
help
If you say Y here, you can use driver calls or the sysfs
power/control file to enable or disable autosuspend for
individual USB peripherals (see
Documentation/usb/power-management.txt for more details).
Also, USB remote wakeup signaling is supported, whereby some
USB devices (like keyboards and network adapters) can wake up
their parent hub. That wakeup cascades up the USB tree, and
could wake the system from states like suspend-to-RAM.
If you are unsure about this, say N here.
Cool tip for the future: Go to /usr/src/linux, type make menuconfig.
Then type / (slash). Then type SUSPEND and ENTER. It will show you
all the kernel options with SUSPEND on them.
or this, of course ;)
This is my preferred way of searching the config. Note that you can't
select USB runtime and power management (autosuspend) and wakeup, if
Power management and ACPI options - Run-time PM core functionality is
not set.
I forgot that some time ago, leading to some errors while unmounting USB
sticks with udisks (although most of udisks works without this option
set, it just can't power down USB devices after they are unmounted).
In particular, for USB_SUSPEND it says:
Symbol: USB_SUSPEND [=y]
Type : boolean
Prompt: USB runtime power management (autosuspend) and wakeup
Defined at drivers/usb/core/Kconfig:93
Depends on: USB_SUPPORT [=y] USB [=y] PM_RUNTIME [=y]
Location:
- Device Drivers
- USB support (USB_SUPPORT [=y])
- Support for Host-side USB (USB [=y])
So there, is in Device Drivers - USB support - Support for
Host-side USB.
Regards.
Re: [gentoo-user] Apologize to everyone for my nonprofessional
Am Sat, 15 Oct 2011 12:31:24 +0100 schrieb Neil Bothwick n...@digimed.co.uk: On Sat, 15 Oct 2011 03:10:37 -0700, Canek Peláez Valdés wrote: It's arbitrary (basically) on executables and libraries. If an script needs something more (from /var, lets say), then the rule should be written in such a way that it can be called after that directory is mounted. If you try to put the same restriction with *executables* (not data, like in the ALSA case), then you need to start moving every executable to /, because that's the only way to guarantee that it would be available aearly on boot time (if you don't use an initramfs and have /usr separated). Anything needed for early boot is already in /. The problem is that udev is trying to run all its rules at that early stage, when it should not. This currently causes some actions to fail because /usr is not mounted yet. The solution is not to mount /usr early, because that only deals with one case, but to make sure that udev does not run actions until the full system is available. This has been stated many times by several people in the previous threads. correct. It basically removes the need for a pesky init* thingy, although for the life of me I cannot understand why someone will not see the technical advantages of actually using an initramfs. why would anyone *want* an initramfs? its a clumsy workaround for limitations that should be overcome with better solutions. We understand its advantages in some circumstances, but I cannot understand why someone will not see the technical disadvantages of actually using an initramfs. either you read your schopenhauer or you are good at spotting bad/unfair arguments ;) Care to explain? Again? It's already been covered many times before. You expect people to blindly accept your POV that an initramfs is a good thing, yet refuse to see the circumstances where others believe it is not. For one thing, implementing this in a stable, running system without interruption is a non-trivial task.
Re: [gentoo-user] pam-1.1.4 emerge error on x86
On Saturday 15 Oct 2011 00:20:14 Jonas de Buhr wrote: Am Sat, 15 Oct 2011 00:01:04 +0100 schrieb Mick michaelkintz...@gmail.com: Have you seen this before? `/var/tmp/portage/sys-libs/pam-1.1.4/work/Linux-PAM-1.1.4' make[1]: Leaving directory `/var/tmp/portage/sys-libs/pam-1.1.4/work/Linux-PAM-1.1.4' /var/tmp/portage/sys-libs/pam-1.1.4/temp/environment: line 2226: scanelf: command not found you could try reinstalling app-misc/pax-utils. this is either a missing dependency or for some reason your pax-utils install is broken. Thank you! I've remerged pax-utils. This is an old laptop and both the main battery and CMOS battery have run out of juice. I noticed that the clock was out by more than 100 years - but I think that I had sync'ed portage in the meanwhile. I have not been able to proceed with pam, because world now wants to emerge ruby. However, it comes up with this error: Verifying ebuild manifests !!! Digest verification failed: !!! /usr/portage/dev-lang/ruby/ruby-1.8.7_p352.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 5574 !!! Expected: 5569 I've deleted the ebuild, then resync'ed twice with different mirrors and the error persists. Another box I have (which does not come up with this error) shows: $ ls -la /usr/portage/dev-lang/ruby/ruby-1.8.7_p352.ebuild -rw-r--r-- 1 root root 5574 Oct 14 09:31 /usr/portage/dev- lang/ruby/ruby-1.8.7_p352.ebuild So, is 5574 the wrong size, or is the ebuild file in the latest sync'ing of portage wrong? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Dennis Ritchie
On 15/10/2011 12:33, luis jure wrote: hello boys [1], i know i don't participate much on this list, but this does not mean that i don't try to follow most of the threads (not all of them, i admit). i realized just now that no one has commented on the news of the recent death of dennis ritchie. considering that his contributions to the development of computational technologies were not only paramount, but affect all of us in a very direct way, i think we could somehow compensate for the lack of echo of these news in the media, by dedicating some time to celebrate his memory and express our gratitude. I agree, I have spent the last few hours trying to explain his work to the folks here who were so saddened by Steve Jobs passing. While it is very sad on both counts, I am getting annoyed by the opinion that Richie might have helped popularise C, but SJ invented the iPhone...which is 10x more useful. I swear I'm dealing with a bunch of cretins here :P
Re: [gentoo-user] Dennis Ritchie
On 15/10/2011 13:26, Matt Harrison wrote: On 15/10/2011 12:33, luis jure wrote: hello boys [1], i know i don't participate much on this list, but this does not mean that i don't try to follow most of the threads (not all of them, i admit). i realized just now that no one has commented on the news of the recent death of dennis ritchie. considering that his contributions to the development of computational technologies were not only paramount, but affect all of us in a very direct way, i think we could somehow compensate for the lack of echo of these news in the media, by dedicating some time to celebrate his memory and express our gratitude. I agree, I have spent the last few hours trying to explain his work to the folks here who were so saddened by Steve Jobs passing. While it is very sad on both counts, I am getting annoyed by the opinion that Richie might have helped popularise C, but SJ invented the iPhone...which is 10x more useful. I swear I'm dealing with a bunch of cretins here :P I think I might have understated his part in C, sorry. Trying to do too many things at once :(
Re: [gentoo-user] Dennis Ritchie
Am Sat, 15 Oct 2011 13:26:40 +0100 schrieb Matt Harrison iwasinnamuk...@genestate.com: On 15/10/2011 12:33, luis jure wrote: hello boys [1], i know i don't participate much on this list, but this does not mean that i don't try to follow most of the threads (not all of them, i admit). i realized just now that no one has commented on the news of the recent death of dennis ritchie. considering that his contributions to the development of computational technologies were not only paramount, but affect all of us in a very direct way, i think we could somehow compensate for the lack of echo of these news in the media, by dedicating some time to celebrate his memory and express our gratitude. I agree, I have spent the last few hours trying to explain his work to the folks here who were so saddened by Steve Jobs passing. While it is very sad on both counts, I am getting annoyed by the opinion that Richie might have helped popularise C, but SJ invented the iPhone...which is 10x more useful. I swear I'm dealing with a bunch of cretins here :P haha wow. i admire your self-control :P im sure, by everyone who counts, dennis ritchie will be remembered for his work.
Re: [gentoo-user] pam-1.1.4 emerge error on x86
Am Sat, 15 Oct 2011 13:24:02 +0100 schrieb Mick michaelkintz...@gmail.com: On Saturday 15 Oct 2011 00:20:14 Jonas de Buhr wrote: Am Sat, 15 Oct 2011 00:01:04 +0100 schrieb Mick michaelkintz...@gmail.com: Have you seen this before? `/var/tmp/portage/sys-libs/pam-1.1.4/work/Linux-PAM-1.1.4' make[1]: Leaving directory `/var/tmp/portage/sys-libs/pam-1.1.4/work/Linux-PAM-1.1.4' /var/tmp/portage/sys-libs/pam-1.1.4/temp/environment: line 2226: scanelf: command not found you could try reinstalling app-misc/pax-utils. this is either a missing dependency or for some reason your pax-utils install is broken. Thank you! I've remerged pax-utils. This is an old laptop and both the main battery and CMOS battery have run out of juice. I noticed that the clock was out by more than 100 years - but I think that I had sync'ed portage in the meanwhile. I have not been able to proceed with pam, because world now wants to emerge ruby. However, it comes up with this error: Verifying ebuild manifests !!! Digest verification failed: !!! /usr/portage/dev-lang/ruby/ruby-1.8.7_p352.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 5574 !!! Expected: 5569 I've deleted the ebuild, then resync'ed twice with different mirrors and the error persists. Another box I have (which does not come up with this error) shows: $ ls -la /usr/portage/dev-lang/ruby/ruby-1.8.7_p352.ebuild -rw-r--r-- 1 root root 5574 Oct 14 09:31 /usr/portage/dev- lang/ruby/ruby-1.8.7_p352.ebuild So, is 5574 the wrong size, or is the ebuild file in the latest sync'ing of portage wrong? did you delete just the ebuild or the Manifest too? i suspect that due to wrong date setting portage did not update the Manifest file which contains the filesize. rm -rf /usr/portage/dev-lang/ruby emerge --sync should help in that case. but you might run into more date related update problems later. maybe you should correct your date and extract a portage snapshot and sync to get rid of those problems once and for all. my /usr/portage/dev-lang/ruby/Manifest says EBUILD ruby-1.8.7_p352.ebuild 5574 RMD160 e822545306c9e2b2a17767895b851f72c772a149 SHA1 0117f543aa6d7ae064af74af7199deefe6e0dc9d SHA256 79d0f2b28b0b39bf23b9208071f7d50f04a6d76254f42073b2b3e9cc612955a7 so 5574 should be the correct filesize. what does grep ruby-1.8.7_p352 /usr/portage/dev-lang/ruby/Manifest say? if resyncing absolutely does not work, you can compare the SHA256 of the ebuild on your two computers and if they are the same it should be relatively safe to do ebuild /usr/portage/dev-lang/ruby/ruby-1.8.7_p352.ebuild manifest which will rebuild the Manifest file containing the filesize and the checksums and after that you can emerge.
Re: [gentoo-user] Dennis Ritchie
i realized just now that no one has commented on the news of the recent death of dennis ritchie. considering that his contributions to the development of computational technologies were not only paramount, but affect all of us in a very direct way, i think we could somehow compensate for the lack of echo of these news in the media, by dedicating some time to celebrate his memory and express our gratitude. I had the same idea, but I didn't resolve to write a thread because I didn't know if it was appropriate. I'm glad you did it. For my part, I'm trying to sensitize the people about the life and work of Dennis Ritchie. Here (in Italy) Steve Jobs' death received much attention on the media, but the death of Dennis Ritchie passed almost unnoticed. I wrote a letter on a newspaper to underline how much we owe to Ritchie. Next week in Italy we'll celebrate Linux Day (http://www.linuxday.it/): in many italian cities there will be demonstrations of the GNU/Linux OS, install fests etc. I'll propose to my LUG to include in the schedule some kind of tribute to Ritchie. Thanks Ritchie, and goodbye. Best regards, Lorenzo
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Sat, 15 Oct 2011 00:34:10 -0700 Canek Peláez Valdés can...@gmail.com wrote: /var != /var/run /var != /var/lock /var/run is going in /run, but /var/run (by definition) only contains things like PID files and runtime sockets. In the same vein, /var/lock also is going into /run/lock. I have acknowledged this from the very beginning, and I have been pointing out that implying that because those two (really small and bounded) directories of /var are going into /run and /run/lock, it doesn't mean that the whole /var will go into /. That is disinformation. It's tirely feasible to need to create a lock file before /var is mounted, so it makes perfect sense to put those directories on /. Even better is to create them as a tmpfs so you don't even need disk drives to get a minimallt usable system. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Sat, 15 Oct 2011 00:34:10 -0700 Canek Peláez Valdés can...@gmail.com wrote: It basically removes the need for a pesky init* thingy, although for the life of me I cannot understand why someone will not see the technical advantages of actually using an initramfs. I'll use your own opening comment as a reply: using != requiring The benefits of an initramfs are insufficient to *require* an initramfs. Now, we've been over this and thrashed it to death already. You had your say and the majority consensus around here is that we do not like it. DROP THIS SUBJECT. RIGHT NOW. PLEASE. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On 2011-10-15 11:02, Canek Peláez Valdés wrote: Yes, as I said in my last mail, if you need LVM, you need an initramfs. Remove the LVM, and you can have /var (and /usr for that matter) withouth an initramfs. Where/when did I say something different? I assume you mean: if you need LVM for /, you need an initramfs? Best regards Peter K
Re: [gentoo-user] How to cross compile Perl for ARM?
Hi Raffaele, how far did you get with compiling rootfs? Do you have complete gentoo installation including kernel compiled for ARM? Would it be possible to make vmdk/any other image for Qemu in which it could be run? I guess it would ease quite many things... As for my progress: I found out that patches from Cross directory does not work, but configure script has some options for cross compilation so I wrote ebuild with different parameters for perl Configure script. It assumes that you have ARM machine ready on network and with ssh daemon running - it uses ssh to transfer cross compiled binaries, run them remotely and uses the output to continue compiling on host pc. I had no problem with establishing that, but configure script still tries to run few binaries compiled for ARM on my x64 host machine. Fight continues! Stay tuned :) Peter 2011/10/14 Raffaele BELARDI raffaele.bela...@st.com On 10/14/2011 01:14 PM, czernitko wrote: Hello! I started playing a little bit with cross compilation for ARM architecture. Using crossdev I created a toolchain for arm-none-linux-gnueabi tuple. Now I'd like to emerge some more packages, but perl constantly refuses to emerge and it is needed by many packages. Not a direct answer to your question, but I managed to cross-build a functional linux rootfs (including X11/Xfbdev and QTEmbedded) for ARM using buildroot. I found buildroot much easier to use than trying to follow the now-deprecated Gentoo Cross Development Guide. Also, I used CodeSourcery's toolchain instead of building my own.
[gentoo-user] Re: Dennis Ritchie
On 10/15/2011 03:26 PM, Matt Harrison wrote: On 15/10/2011 12:33, luis jure wrote: hello boys [1], i know i don't participate much on this list, but this does not mean that i don't try to follow most of the threads (not all of them, i admit). i realized just now that no one has commented on the news of the recent death of dennis ritchie. considering that his contributions to the development of computational technologies were not only paramount, but affect all of us in a very direct way, i think we could somehow compensate for the lack of echo of these news in the media, by dedicating some time to celebrate his memory and express our gratitude. I agree, I have spent the last few hours trying to explain his work to the folks here who were so saddened by Steve Jobs passing. While it is very sad on both counts, I am getting annoyed by the opinion that Richie might have helped popularise C, but SJ invented the iPhone...which is 10x more useful. If you're not insanely rich, nobody cares if you die. It's not about how much you contributed to human society. It's about how much money you made.
Re: [gentoo-user] Apologize to everyone for my nonprofessional
Wow. Just wow. GREAT way to confuse and welcome the poor-English Chinese guy. Welcome Lavender. You are now officially recognized as a human being, not a bot. We'll be glad to help you with Gentoo. Please ignore all the FUD and discussion about /var needing (or not) to be in the root partition, and the need for an initramfs. It's just bullshit for us end users currently.
Re: [gentoo-user] Re: Dennis Ritchie
Am Sat, 15 Oct 2011 17:47:07 +0300 schrieb Nikos Chantziaras rea...@arcor.de: On 10/15/2011 03:26 PM, Matt Harrison wrote: On 15/10/2011 12:33, luis jure wrote: I have spent the last few hours trying to explain his work to the folks here who were so saddened by Steve Jobs passing. While it is very sad on both counts, I am getting annoyed by the opinion that Richie might have helped popularise C, but SJ invented the iPhone...which is 10x more useful. If you're not insanely rich, nobody cares if you die. It's not about how much you contributed to human society. It's about how much money you made. i don't think its about money, but about popularity. everybody knows who steve jobs is, thats why his death makes front page. average joe doesn't know ritchie and doesn't care about C.
Re: [gentoo-user] pam-1.1.4 emerge error on x86
On Saturday 15 Oct 2011 14:09:46 Jonas de Buhr wrote: Am Sat, 15 Oct 2011 13:24:02 +0100 schrieb Mick michaelkintz...@gmail.com: On Saturday 15 Oct 2011 00:20:14 Jonas de Buhr wrote: Am Sat, 15 Oct 2011 00:01:04 +0100 schrieb Mick michaelkintz...@gmail.com: Have you seen this before? `/var/tmp/portage/sys-libs/pam-1.1.4/work/Linux-PAM-1.1.4' make[1]: Leaving directory `/var/tmp/portage/sys-libs/pam-1.1.4/work/Linux-PAM-1.1.4' /var/tmp/portage/sys-libs/pam-1.1.4/temp/environment: line 2226: scanelf: command not found you could try reinstalling app-misc/pax-utils. this is either a missing dependency or for some reason your pax-utils install is broken. Thank you! I've remerged pax-utils. This is an old laptop and both the main battery and CMOS battery have run out of juice. I noticed that the clock was out by more than 100 years - but I think that I had sync'ed portage in the meanwhile. I have not been able to proceed with pam, because world now wants to emerge ruby. However, it comes up with this error: Verifying ebuild manifests !!! Digest verification failed: !!! /usr/portage/dev-lang/ruby/ruby-1.8.7_p352.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 5574 !!! Expected: 5569 I've deleted the ebuild, then resync'ed twice with different mirrors and the error persists. Another box I have (which does not come up with this error) shows: $ ls -la /usr/portage/dev-lang/ruby/ruby-1.8.7_p352.ebuild -rw-r--r-- 1 root root 5574 Oct 14 09:31 /usr/portage/dev- lang/ruby/ruby-1.8.7_p352.ebuild So, is 5574 the wrong size, or is the ebuild file in the latest sync'ing of portage wrong? did you delete just the ebuild or the Manifest too? i suspect that due to wrong date setting portage did not update the Manifest file which contains the filesize. rm -rf /usr/portage/dev-lang/ruby emerge --sync should help in that case. but you might run into more date related update problems later. maybe you should correct your date and extract a portage snapshot and sync to get rid of those problems once and for all. my /usr/portage/dev-lang/ruby/Manifest says EBUILD ruby-1.8.7_p352.ebuild 5574 RMD160 e822545306c9e2b2a17767895b851f72c772a149 SHA1 0117f543aa6d7ae064af74af7199deefe6e0dc9d SHA256 79d0f2b28b0b39bf23b9208071f7d50f04a6d76254f42073b2b3e9cc612955a7 so 5574 should be the correct filesize. what does grep ruby-1.8.7_p352 /usr/portage/dev-lang/ruby/Manifest say? if resyncing absolutely does not work, you can compare the SHA256 of the ebuild on your two computers and if they are the same it should be relatively safe to do ebuild /usr/portage/dev-lang/ruby/ruby-1.8.7_p352.ebuild manifest which will rebuild the Manifest file containing the filesize and the checksums and after that you can emerge. I removed the manifest resync'ed and it emerged without any errors. Thank you! :-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Apologize to everyone for my nonprofessional
Canek Peláez Valdés wrote: On Sat, Oct 15, 2011 at 2:37 AM, Dalerdalek1...@gmail.com wrote: Canek Peláez Valdés wrote: On Sat, Oct 15, 2011 at 2:15 AM, Michael Schreckenbauergrim...@gmx.de wrote: I would. But given the way udev people solve those issues, I don't. If something on /var is needed during boot in the next ten years, they will propose to move it to /. They do it with /run, they do it with /lock, they will do it the same way the next time such an issue arises. You keep speculating and speculating. When you have some evidence to sustain your claims, we talk. Regards. Can you point to where a dev has said that /var, /home or any other changes will NEVER happen? Of course not, but this is the same as any accusation: the people making the accusation has to provide the evidence. YOU are the one making the accusation, YOU provide the evidence. So you say it will never happen and you know that. Ook. Sounds like you have a real good crystal ball there. I would start with the dev that caused all this if it were me. I would like to hear that from him for sure. Let's see if you can prove your claim then we'll talk. *I* don't have to prove anything because I'm talkin about the facts *right now*. You guys are the ones speculating about an imaginary future. I'm talking about what can likely happen in the future based on what has already happened. Until recently, /usr didn't have to be on / with or without a init thingy. Now it does. See the point yet? Like I said, a year or so ago, I would have thought anyone saying /usr would need to be on / to boot or a init thingy was losing their mind. It is just not the way Linux is supposed to be. Yet here we are. Says who? I say it is exactly the way Linux is supposed to be. And /usr doesn't *need* to be on /; just get an initramfs and you can have it in an NFS from the other side of the planet. Regards. Oh for a very long time, /usr could be on a separate partition and no init thingy was required. That changed right? What change is going to happen next you reckon? That is my point. /usr is required today, /var is the only directory left except for /home. I figure something on /var is next and then some ultra smart dev will find something that needs /home eventually. I can't prove that it will for certain happen but I can say that is the way things are going based on the change that just happened. You can not say it is never going to happen either. You have no more proof than anyone else on this list. Dale :-) :-)
Re: [gentoo-user] pam-1.1.4 emerge error on x86
Am Sat, 15 Oct 2011 18:17:41 +0100 schrieb Mick michaelkintz...@gmail.com: On Saturday 15 Oct 2011 14:09:46 Jonas de Buhr wrote: Am Sat, 15 Oct 2011 13:24:02 +0100 schrieb Mick michaelkintz...@gmail.com: On Saturday 15 Oct 2011 00:20:14 Jonas de Buhr wrote: Am Sat, 15 Oct 2011 00:01:04 +0100 schrieb Mick michaelkintz...@gmail.com: Have you seen this before? `/var/tmp/portage/sys-libs/pam-1.1.4/work/Linux-PAM-1.1.4' make[1]: Leaving directory `/var/tmp/portage/sys-libs/pam-1.1.4/work/Linux-PAM-1.1.4' /var/tmp/portage/sys-libs/pam-1.1.4/temp/environment: line 2226: scanelf: command not found you could try reinstalling app-misc/pax-utils. this is either a missing dependency or for some reason your pax-utils install is broken. Thank you! I've remerged pax-utils. This is an old laptop and both the main battery and CMOS battery have run out of juice. I noticed that the clock was out by more than 100 years - but I think that I had sync'ed portage in the meanwhile. I have not been able to proceed with pam, because world now wants to emerge ruby. However, it comes up with this error: Verifying ebuild manifests !!! Digest verification failed: !!! /usr/portage/dev-lang/ruby/ruby-1.8.7_p352.ebuild !!! Reason: Filesize does not match recorded size !!! Got: 5574 !!! Expected: 5569 I've deleted the ebuild, then resync'ed twice with different mirrors and the error persists. Another box I have (which does not come up with this error) shows: $ ls -la /usr/portage/dev-lang/ruby/ruby-1.8.7_p352.ebuild -rw-r--r-- 1 root root 5574 Oct 14 09:31 /usr/portage/dev- lang/ruby/ruby-1.8.7_p352.ebuild So, is 5574 the wrong size, or is the ebuild file in the latest sync'ing of portage wrong? did you delete just the ebuild or the Manifest too? i suspect that due to wrong date setting portage did not update the Manifest file which contains the filesize. rm -rf /usr/portage/dev-lang/ruby emerge --sync should help in that case. but you might run into more date related update problems later. maybe you should correct your date and extract a portage snapshot and sync to get rid of those problems once and for all. my /usr/portage/dev-lang/ruby/Manifest says EBUILD ruby-1.8.7_p352.ebuild 5574 RMD160 e822545306c9e2b2a17767895b851f72c772a149 SHA1 0117f543aa6d7ae064af74af7199deefe6e0dc9d SHA256 79d0f2b28b0b39bf23b9208071f7d50f04a6d76254f42073b2b3e9cc612955a7 so 5574 should be the correct filesize. what does grep ruby-1.8.7_p352 /usr/portage/dev-lang/ruby/Manifest say? if resyncing absolutely does not work, you can compare the SHA256 of the ebuild on your two computers and if they are the same it should be relatively safe to do ebuild /usr/portage/dev-lang/ruby/ruby-1.8.7_p352.ebuild manifest which will rebuild the Manifest file containing the filesize and the checksums and after that you can emerge. I removed the manifest resync'ed and it emerged without any errors. Thank you! :-) you're welcome ;) its really easy to help you because you provide the right information =)
Re: [gentoo-user] Re: Dennis Ritchie
Jonas de Buhr jonas.de.b...@gmx.net [11-10-15 19:16]: Am Sat, 15 Oct 2011 17:47:07 +0300 schrieb Nikos Chantziaras rea...@arcor.de: On 10/15/2011 03:26 PM, Matt Harrison wrote: On 15/10/2011 12:33, luis jure wrote: I have spent the last few hours trying to explain his work to the folks here who were so saddened by Steve Jobs passing. While it is very sad on both counts, I am getting annoyed by the opinion that Richie might have helped popularise C, but SJ invented the iPhone...which is 10x more useful. If you're not insanely rich, nobody cares if you die. It's not about how much you contributed to human society. It's about how much money you made. i don't think its about money, but about popularity. everybody knows who steve jobs is, thats why his death makes front page. average joe doesn't know ritchie and doesn't care about C. It is, as Dennis Ritchies said: Unix is simple and coherent, but it takes a genius – or at any rate a programmer – to understand and appreciate the simplicity. (Source:http://www.heise.de/newsticker/meldung/Unix-ist-einfach-zum-Tode-von-Dennis-Ritchie-1360366.html)o
Re: [gentoo-user] Re: Dennis Ritchie
i don't think its about money, but about popularity. everybody knows who steve jobs is, thats why his death makes front page. average joe doesn't know ritchie and doesn't care about C. Back at my University only very small number of people knows, who's Richie (although GNU/Linux systems are very popular) and what he had done. And it's very painful to hear from a person with Apple laptop phrases like C? UNIX? I don't like UNIX. Nothing must be forgotten. People must know persons who made technologies to what they are now. On Sat, Oct 15, 2011 at 9:43 PM, meino.cra...@gmx.de wrote: Jonas de Buhr jonas.de.b...@gmx.net [11-10-15 19:16]: Am Sat, 15 Oct 2011 17:47:07 +0300 schrieb Nikos Chantziaras rea...@arcor.de: On 10/15/2011 03:26 PM, Matt Harrison wrote: On 15/10/2011 12:33, luis jure wrote: I have spent the last few hours trying to explain his work to the folks here who were so saddened by Steve Jobs passing. While it is very sad on both counts, I am getting annoyed by the opinion that Richie might have helped popularise C, but SJ invented the iPhone...which is 10x more useful. If you're not insanely rich, nobody cares if you die. It's not about how much you contributed to human society. It's about how much money you made. i don't think its about money, but about popularity. everybody knows who steve jobs is, thats why his death makes front page. average joe doesn't know ritchie and doesn't care about C. It is, as Dennis Ritchies said: Unix is simple and coherent, but it takes a genius – or at any rate a programmer – to understand and appreciate the simplicity. (Source: http://www.heise.de/newsticker/meldung/Unix-ist-einfach-zum-Tode-von-Dennis-Ritchie-1360366.html)o -- С уважением, Черноиванов Андрей
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Saturday, October 15, 2011 12:34:10 AM Canek Peláez Valdés wrote: I noticed the other day that when LVM tries to start, it fails. I have /var on a separate partition here. It was complaining about something on /var missing. So, you may be late in reporting this. I think it is already needed for LVM if /usr or /var is on a separate partition. Again, get the facts right. If you use LVM you will need to use an initramfs. If you only use a separated /usr you will be able to use Zac's proposal. Get your own facts right. I use LVM for everything except / and I do NOT need to use an initramfs. It has worked this way for years and making an initramfs mandatory for this is a REGRESSION. -- Joost
Re: [gentoo-user] Re: Dennis Ritchie
On Saturday 15 Oct 2011 18:43:06 meino.cra...@gmx.de wrote: Jonas de Buhr jonas.de.b...@gmx.net [11-10-15 19:16]: Am Sat, 15 Oct 2011 17:47:07 +0300 schrieb Nikos Chantziaras rea...@arcor.de: On 10/15/2011 03:26 PM, Matt Harrison wrote: On 15/10/2011 12:33, luis jure wrote: I have spent the last few hours trying to explain his work to the folks here who were so saddened by Steve Jobs passing. While it is very sad on both counts, I am getting annoyed by the opinion that Richie might have helped popularise C, but SJ invented the iPhone...which is 10x more useful. If you're not insanely rich, nobody cares if you die. It's not about how much you contributed to human society. It's about how much money you made. i don't think its about money, but about popularity. everybody knows who steve jobs is, thats why his death makes front page. average joe doesn't know ritchie and doesn't care about C. It is, as Dennis Ritchies said: Unix is simple and coherent, but it takes a genius – or at any rate a programmer – to understand and appreciate the simplicity. (Source:http://www.heise.de/newsticker/meldung/Unix-ist-einfach-zum-Tode-v on-Dennis-Ritchie-1360366.html)o It's in the media, but unlike Jobs it is under Technology, not under 'celebrities'. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] pam-1.1.4 emerge error on x86
On Saturday 15 Oct 2011 18:27:50 Jonas de Buhr wrote: Am Sat, 15 Oct 2011 18:17:41 +0100 schrieb Mick michaelkintz...@gmail.com: On Saturday 15 Oct 2011 14:09:46 Jonas de Buhr wrote: Am Sat, 15 Oct 2011 13:24:02 +0100 schrieb Mick michaelkintz...@gmail.com: On Saturday 15 Oct 2011 00:20:14 Jonas de Buhr wrote: Am Sat, 15 Oct 2011 00:01:04 +0100 schrieb Mick michaelkintz...@gmail.com: Have you seen this before? `/var/tmp/portage/sys-libs/pam-1.1.4/work/Linux-PAM-1.1.4' make[1]: Leaving directory `/var/tmp/portage/sys-libs/pam-1.1.4/work/Linux-PAM-1.1.4' /var/tmp/portage/sys-libs/pam-1.1.4/temp/environment: line 2226: scanelf: command not found you could try reinstalling app-misc/pax-utils. this is either a missing dependency or for some reason your pax-utils install is broken. Thank you! I've remerged pax-utils. This is an old laptop and both the main battery and CMOS battery have run out of juice. I noticed that the clock was out by more than 100 years - but I think that I had sync'ed portage in the meanwhile. [snip...] Thank you! :-) you're welcome ;) its really easy to help you because you provide the right information =) To save me asking next time ... how did you know that pax-utils was to blame? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Saturday, October 15, 2011 03:34:27 AM Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 3:05 AM, Michael Schreckenbauer grim...@gmx.de
wrote:
On Saturday, 15. October 2011 02:47:26 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 2:31 AM, Michael Schreckenbauer
grim...@gmx.de
wrote:
On Saturday, 15. October 2011 02:11:43 Canek Peláez Valdés wrote:
On Sat, Oct 15, 2011 at 1:53 AM, Michael Schreckenbauer
grim...@gmx.de
wrote:
On Saturday, 15. October 2011 01:42:10 Canek Peláez Valdés wrote:
/var/lib usually stores whole
databases. The difference is important and relevant.
My systems has directories alsa, bluetooth, hp and many
more
there that are not databases at all.
So?
Which one? That /var is not going into /?
No. That /var/lib contains databases. Is this so difficult
to get?
I get it; it's just not relevant.
On my system /var/lib/alsa contains data, that alsa uses to
restore
mixer- levels.
Yeah, it does.
So *my* /var/lib is used during boot and *my* /var/lib has
to be
mounted by the initramfs.
No, it doesn't. What are you talking about? Look at
/etc/init.d/alsasound:
depend() {
need localmount
after bootmisc modules isapnp coldplug hotplug
}
Look at the first need from alsasound depend: it says, that it
goes
after localmount. If you have /var in NFS (a very weird setup
for a
desktop machine) maybe it will cause problems: but then it would
be
fault of OpenRC (or the alsasound init script). If /var is on a
different partition, localmount will mount it and *then*
alsasound
will execute.
And it makes sense: the volume restoring doesn't matter until
immediately before running gdm and going into the desktop; of
course
you can mount /var before that.
That's the situation on nearly every gentoo system
using sound
Yeah, and as I explained, thanks to need localmount there is no
problem.
(systemd might handle this different, I have no idea)
Yeah, it does more intelligently: as I said, the volume
restoring is
only needed just before starting X.
Got it? Your system is not the center of the world.
No, but I start to think you don't know *your* system. Check the
alsasound init script.
*lol*
Now, this is getting ridiculous.
Indeed, it is getting ridiculous.
I don't know my system?
No, you don't.
Have a look into
/lib/udev/rules.d/90-alsa-restore.rules
to realize, that this is a hack, that restores alsa-levels *twice*
on
systems that have /var/lib on /. The levels are supposed to be
restored by *udev* not the script.
Yeah, but it doesn't run when udev *starts*. It runs when a card is
*added* to the system; that is the reason for the ACTION=add part.
It's inteded to be used for USB cards (like external speakers with a
little sound card incorporated), so its volume is restored *at insert
time*.
Nonsense. Action add is used for every device in your system, built-in
or plugged in later. So this rule is not only used for
hotplug-USB-soundcards, but for every soundcard in your system.
Yeah, you are right. Sorry. I forgot about the little numbers udev uses:
10-dm.rules
11-dm-lvm.rules
13-dm-disk.rules
60-persistent-storage.rules
70-persistent-net.rules
90-alsa-restore.rules
These only matter when there are conflicting rules in these files. The rule in
the lower number is used. Higher numbers are then ignored.
So, the same way that in the alsasound init script need localmount
guarantee that /var is mounted, the 60-persistent-storage.rules
guarantees that /var is mounted before the 90-alsa-restore.rules
restores ALSA's volume.
Wrong, see above.
Again, there is no problem. Yeah, the rule is executed at udev
execution time... but after the persisten-storage rule. So, you see,
no problem. No need for /var in the same partition as /.
Wrong, /etc/init.d/alsasound is a fix for that.
Udev should handle the situation where filesystems are not available yet and
keep those in a retry-queue for when all filesystems are available.
You guys keep speculating. As of *now*, there is not a single line of
code that prevents a system from booting correctly if /var lives in
another partition, no matter if the system uses an initramfs or not.
As of *now* nobody is discussing, proposing, or even mentioning
(except for you guys) about requiring /var to live in the same
partition as /.
/var will be required. alsasound is a workaround for this.
--
Joost
Re: [gentoo-user] Apologize to everyone for my nonprofessional
Hi Claudio, hi Lavender, On Saturday, 15. October 2011 13:46:31 Claudio Roberto França Pereira wrote: Wow. Just wow. :) GREAT way to confuse and welcome the poor-English Chinese guy. Welcome Lavender. You are now officially recognized as a human being, not a bot. We'll be glad to help you with Gentoo. you are right. We hijacked this thread for our own discussion. I apologize for this. I'll stop posting on this topic in this thread right now. Please ignore all the FUD and discussion about /var needing (or not) to be in the root partition, and the need for an initramfs. It's just bullshit for us end users currently. Best, Michael
Re: [gentoo-user] Apologize to everyone for my nonprofessional
Hi Canek, On Saturday, 15. October 2011 04:04:05 Canek Peláez Valdés wrote: I got that points wrong, I admit. I repeat, 3am here ;) I apogolize for saying that to you Michael; I shouldn't have, even if I would have been right (and I wasn't). Again, no excuse, but it's (actually) 4am here now. ok. For me it was lunch time, so I had an advantage here :) Regards. Best, Michael
Re: [gentoo-user] Dennis Ritchie
Hi Michael, On Saturday, 15. October 2011 08:10:13 Michael Mol wrote: On Sat, Oct 15, 2011 at 7:33 AM, luis jure l...@internet.com.uy wrote: hello boys [1], i know i don't participate much on this list, but this does not mean that i don't try to follow most of the threads (not all of them, i admit). i realized just now that no one has commented on the news of the recent death of dennis ritchie. considering that his contributions to the development of computational technologies were not only paramount, but affect all of us in a very direct way, i think we could somehow compensate for the lack of echo of these news in the media, by dedicating some time to celebrate his memory and express our gratitude. [1] sorry if there are any girls out there, but i think i have never seen any female names on this list... Well, if it helps, the reason I have a huge beard and long hair is welcome to the club, although my beard isn't huge most of the time :D My wife doesn't like it that much. I'm compensating this with the hair on my head (close to 1m now *g*) because I idolized Thompson and Ritchie as far back as my early teen years. My very conservative grandparents were less than amused that I was actively seeking a 60s Berkeley look. Sounds familiar too. Best, Michael
Re: [gentoo-user] Gentoo Install Issue
Hi guys, I'm still struggling with this. Gave up last weekend and haven't had time until now. Thought I had it going when I got a command prompt and then, networking wasn't working. Anyway, more details . On 10/10/11 16:43, David Abbott wrote: On Mon, Oct 10, 2011 at 4:31 PM, CJoeB colleen.bea...@gmail.com wrote: On 10/10/11 16:17, Michael Mol wrote: On Mon, Oct 10, 2011 at 4:06 PM, CJoeB colleen.bea...@gmail.com wrote: Today, I went through the install process, had a couple of issues, but was able to figure them out and got to the point where I was supposed to boot into my new system. I got the boot menu, the boot process seemed to be okay, but when I got to the point where I assumed I should get a command prompt to finish up, all I got was a weird screen that was half black and half fuzzy with a bunch of colours (sorry, I can describe this any better). I tried recompiling the kernel thinking it was a problem that I had created during the initial compilation, but that ended with the same result. I would enable kms; http://en.gentoo-wiki.com/wiki/Radeon#Kernel_Modesetting_.28KMS.29 http://forums-web2.gentoo.org/viewtopic-t-831521-start-0.html I booted to the Gentoo install CD, went through all the steps to make sure I hadn't missed anything. I followed the directions on the above link for my Radeon card. When I existed the 'chroot'd' environment and rebooted, the system seemed to hang - the last few lines that appear on the screen are: [drm] Loading CAICOS Microcode Refined TSC clocksource calibration: 3392.289 MHz Switching to clocksource tsc I took someone else's advice who responded to my original post and got the output from dmesg after the install CD booted. Below is the entire listing related to the video section: vesafb: mode is 1024x768x16, linelength=2048, pages=9 vesafb:scrolling:redraw vesafb:Truecolor:size=0;5:6:5, shift=0:11:5:0 vesafb:framebuffer at 0xd000, mapped to 0xc9001010, using 3072k, total 16384k console: switching to colour framebuffer device 128x48 fb0: VESA VGA framebuffer device I really understand very little of what this is telling me except for the screen resolution and I get that there are hex code references in my grub.conf file the video line is as follows: vga=-0X31B video=vesafb:mtrr,ywrap I read somewhere that for radeon card you use the above statement as opposed to: video=uvesafb:mtrr:ywrap,1920x1080@60 Documentation for my monitor states that the max resolution is 1920x1080@60 Hz Can anyone help me out here? Thanks in advance, Colleen -- Registered Linux User #411143 with the Linux Counter, http://counter.li.org
Re: [gentoo-user] Gentoo Install Issue
On Saturday, 15. October 2011 16:07:42 CJoeB wrote: Hi guys, I'm still struggling with this. Gave up last weekend and haven't had time until now. Thought I had it going when I got a command prompt and then, networking wasn't working. Anyway, more details . On 10/10/11 16:43, David Abbott wrote: On Mon, Oct 10, 2011 at 4:31 PM, CJoeB colleen.bea...@gmail.com wrote: On 10/10/11 16:17, Michael Mol wrote: On Mon, Oct 10, 2011 at 4:06 PM, CJoeB colleen.bea...@gmail.com wrote: Today, I went through the install process, had a couple of issues, but was able to figure them out and got to the point where I was supposed to boot into my new system. I got the boot menu, the boot process seemed to be okay, but when I got to the point where I assumed I should get a command prompt to finish up, all I got was a weird screen that was half black and half fuzzy with a bunch of colours (sorry, I can describe this any better). I tried recompiling the kernel thinking it was a problem that I had created during the initial compilation, but that ended with the same result. I would enable kms; http://en.gentoo-wiki.com/wiki/Radeon#Kernel_Modesetting_.28KMS.29 http://forums-web2.gentoo.org/viewtopic-t-831521-start-0.html I booted to the Gentoo install CD, went through all the steps to make sure I hadn't missed anything. I followed the directions on the above link for my Radeon card. When I existed the 'chroot'd' environment and rebooted, the system seemed to hang - the last few lines that appear on the screen are: [drm] Loading CAICOS Microcode Refined TSC clocksource calibration: 3392.289 MHz Switching to clocksource tsc I took someone else's advice who responded to my original post and got the output from dmesg after the install CD booted. Below is the entire listing related to the video section: vesafb: mode is 1024x768x16, linelength=2048, pages=9 vesafb:scrolling:redraw vesafb:Truecolor:size=0;5:6:5, shift=0:11:5:0 vesafb:framebuffer at 0xd000, mapped to 0xc9001010, using 3072k, total 16384k console: switching to colour framebuffer device 128x48 fb0: VESA VGA framebuffer device you are using vesafb. I really understand very little of what this is telling me except for the screen resolution and I get that there are hex code references in my grub.conf file the video line is as follows: vga=-0X31B video=vesafb:mtrr,ywrap I read somewhere that for radeon card you use the above statement as opposed to: video=uvesafb:mtrr:ywrap,1920x1080@60 Documentation for my monitor states that the max resolution is 1920x1080@60 Hz To get this resolution that early you need kms. Check your kernel-config: CONFIG_DRM_RADEON=m CONFIG_DRM_RADEON_KMS=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FB_RADEON is not set Then you need radeon.modeset=1 instead of the vga=... stuff in your grub.conf. Also, see: http://www.x.org/wiki/radeonBuildHowTo#Kernel-basedModeSetting Can anyone help me out here? Thanks in advance, Colleen Hth, Michael
Re: [gentoo-user] Postfix to relay mail even if acting as primary MX host?
On 10/14/2011 10:00 PM, Pandu Poluan wrote: Also less overthinking and more testing solves most of this stuff quicker. I prefer to arm myself with enough knowledge before deploying -- even in a testing setup -- to reduce any 'WTF?!' moments :-) Research is good, but you'll learn way more from banging on it yourself for a bit. Also it's a chance to break it or see how it fails and what errors get kicked out. This way you're not at a loss when it does break or it can help make your config more robust. Lastly the further you get in your career the less help Google, mailing lists, etc become. At that point your own experience and 5-10 minutes of testing is going to produce better results. kashani
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On Sat, 15 Oct 2011 13:46:31 -0300, Claudio Roberto França Pereira wrote: Wow. Just wow. GREAT way to confuse and welcome the poor-English Chinese guy. Good point. Sorry Lavender, please feel free to start another thread... which may or may not get hijacked. Please ignore all the FUD and discussion about /var needing (or not) to be in the root partition, and the need for an initramfs. It's just bullshit for us end users currently. It is not bullshit, it is relevant to many Gentoo users. However, it is not relevant to this topic. -- Neil Bothwick mpeg@11.. signature.asc Description: PGP signature
Re: [gentoo-user] Gentoo Install Issue
On 10/15/11 16:21, Michael Schreckenbauer wrote: Documentation for my monitor states that the max resolution is 1920x1080@60 Hz To get this resolution that early you need kms. Check your kernel-config: CONFIG_DRM_RADEON=m CONFIG_DRM_RADEON_KMS=y CONFIG_FRAMEBUFFER_CONSOLE=y # CONFIG_FB_RADEON is not set Okay, I had this configured properly Then you need radeon.modeset=1 instead of the vga=... stuff in your grub.conf. Also, see: http://www.x.org/wiki/radeonBuildHowTo#Kernel-basedModeSetting This must have been the issue because when I put the radeon.modeset=1 in my grub.conf file, I booted to the command prompt. Still no penguins on bootup and I had the when booting to the install CD. I'm pretty sure I have what I need to have in the kernel to get them. Thanks for the help! :-) Colleen -- Registered Linux User #411143 with the Linux Counter, http://counter.li.org
[gentoo-user] Another Install Issue
Hi everyone, Well, thanks to the help I got from the list, I finally have Gentoo installed on my new desktop and booting to a command prompt. However, now I have a networking issue. In past, when I booted to the install CD and my ethernet connection was not active, I typed net-setup eth0 and was able to set it up. This time, when I booted to the install CD and typed net-setup eth0, the network card was not recognized. I googled and found a post where someone said that they had to 'modprobe -r broadcom' and 'modprobe -r tg3' and then 'modprobe broadcom' and 'modprobe tg3' and then, run net-setup. I did this and then ifconfig returned my eth0 connection. Of course, later you have to do the cp -L /etc/resolv.conf /mnt/gentoo/etc/ which I did and dhcpcd has been added to my default runlevel. However, when I boot, eth0 does not start. I can start it manually by doing 'modprobe -r broadcom' and 'modprobe -r tg3' and then 'modprobe broadcom' and 'modprobe tg3' However, I would like to have my network started automatically. I do have config_eth0=dhcp in my /etc/conf.d/net file Any suggestions? Colleen -- Registered Linux User #411143 with the Linux Counter, http://counter.li.org
Re: [gentoo-user] Apologize to everyone for my nonprofessional
On 10/15/2011 4:42 AM, Canek Peláez Valdés wrote: Which one? That /var is not going into /? It's not disinformation, it is th true. If not, please be so kind of showin one single developer reference that says so. One. Single. One. Email, blog post, wiki, you choose it. But one single one. I don't think anyone is claiming that there are *currently* plans to require /var, either on / or via initramfs. The claim being made is that /var suffers from the exact same problem that /usr does, with regard to udev, namely that arbitrary programs running from within udev rules could (and some do) require /var to be present to function. Thus, the arguments being applied to /usr *currently* can be applied equally to /var, once it becomes an issue. The classic example being given is a bluetooth keyboard: to make a bluetooth keyboard available, udev executes a rule which requires /var/bluetooth to be present. (Certain other rules similarly require data from /var, such as sound cards or printers.) The extremely logical deduction being made is as follows: Some udev rules require /usr to be preset to properly execute. The solution favored by the udev maintainer is to simply make /usr always required for udev to run. Running udev without /usr present will become unsupported. Similarly, some udev rules require /var to be present to properly execute. The solution that will be favored by the udev maintainer, when such an issue is raised, is most likely going to be similar to the solution proposed for /usr: the mandating of /var being present before udev runs. Running udev without /var present will most likely become unsupported. Programs designed to run out of /bin expect to be run without any other locations present. Programs designed to run out of /usr/bin generally assume that the rest of the system, including /var, is available for use. You can't have one without the other. --Mike
