Re: [SLUG] mount LVM from Ubuntu live CD
On 19/02/2010, at 1:41 PM, Daniel Pittman wrote: Try booting the kernel with 'init=/bin/bash' on the command line, and then: ] mount / -o remount,rw ] passwd root # ...and give it a good password ] mount / -o remount,or ] sync; sync; sync # wait thirty seconds, because paranoia never hurts ] sync; sync; sync; reboot That should get you past the problem, at least as far as the next issue. i guess that's mount / -o remount,ro I'm curious about the order of the read-only command, and the syncs. I did assume there would be nothing to sync on a read-only file system, but I take it sync works below the file system level? -- http://chesterton.id.au/blog/ http://barrang.com.au/linux/ -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Testing glue records
$quoted_author = Ashley Glenday ; Thanks John, I've tried that too, the only thing that comes up is ns3 and ns4. So the current glue is ok. Out of curiosity, could it be something to do with the fact that I used to have ns1 and ns2 set up on an old server and those records haven't been removed from the tld servers? No, otherwise you would see the old, incorrect glue. This level of DNS is something I do so infrequently I end up having to relearn it all over again. It sounds like the new glue is not set up correctly. We could be more helpful if we knew what the domain was. :-) cheers Marty -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Testing glue records
Hi Marty, The domain is mobileitdept.com.au I suspected that the glue records weren't set up properly but they kept closing my ticket saying it was fine. I guess my next question should be which registrar should I use that knows how to do glue records properly? I've lodged another ticket asking them to delete the records for ns1 and ns2 because every time I try it I get an error, that's what lead me to think it could have something to do with them still being set up for the old server. Thank you all for your ongoing help. Regards, Ashley Glenday On 21/02/10 00:23, Martin Barry wrote: $quoted_author = Ashley Glenday ; Thanks John, I've tried that too, the only thing that comes up is ns3 and ns4. So the current glue is ok. Out of curiosity, could it be something to do with the fact that I used to have ns1 and ns2 set up on an old server and those records haven't been removed from the tld servers? No, otherwise you would see the old, incorrect glue. This level of DNS is something I do so infrequently I end up having to relearn it all over again. It sounds like the new glue is not set up correctly. We could be more helpful if we knew what the domain was. :-) cheers Marty attachment: ashley.vcf-- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
[SLUG] Replacing Mac HDD (was: Netbooks .... Again (7 months on) Are you still happy?)
Alan Tyree wrote: I have an Apple iBook G4 and the hard drive is showing some damage - it is an IDE drive. Would like to replace with something solid state, but don't really know where to start. Cheers, Alan Hi Alan, You'll need the following: 1 x webcam 1 x address for others to watch 1 x one blindfold 1 x hammer Just remember IANAME (*1) HTH Regards, Patrick (*1) I Am Not A Mac Expert -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Replacing Mac HDD (was: Netbooks .... Again (7 months on) Are you still happy?)
On Sun, 21 Feb 2010 07:48:28 +1100 elliott-brennan elliottbren...@gmail.com wrote: Alan Tyree wrote: I have an Apple iBook G4 and the hard drive is showing some damage - it is an IDE drive. Would like to replace with something solid state, but don't really know where to start. Cheers, Alan Hi Alan, You'll need the following: 1 x webcam 1 x address for others to watch 1 x one blindfold 1 x hammer Just remember IANAME (*1) HTH Regards, Patrick (*1) I Am Not A Mac Expert Sigh! I guess I asked for it, so I can't really complain. You forgot to add that when I finish I should by a Lenovo. Cheers, Alan -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html -- Alan L Tyreehttp://www2.austlii.edu.au/~alan Tel: 04 2748 6206 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] mount LVM from Ubuntu live CD
Michael Chesterton che...@chesterton.id.au writes: On 19/02/2010, at 1:41 PM, Daniel Pittman wrote: Try booting the kernel with 'init=/bin/bash' on the command line, and then: ] mount / -o remount,rw ] passwd root # ...and give it a good password ] mount / -o remount,or ] sync; sync; sync # wait thirty seconds, because paranoia never hurts ] sync; sync; sync; reboot That should get you past the problem, at least as far as the next issue. i guess that's mount / -o remount,ro Yup. I'm curious about the order of the read-only command, and the syncs. I did assume there would be nothing to sync on a read-only file system, but I take it sync works below the file system level? sync instructs the kernel to flush out dirty blocks now; indeed, a read-only file system generates no dirty blocks, but while you had it mounted read-write you would have generated them. Mounting to read-only doesn't necessarily flush all the dirty data, so you need to manually trigger that. In theory, one sync should do it; in practice, this has varied over the years, so the ultra-paranoid version certainly doesn't hurt. :) Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] mount LVM from Ubuntu live CD
On 19/02/10 13:41, Daniel Pittman wrote: ] mount / -o remount,rw ] passwd root # ...and give it a good password ] mount / -o remount,ro ] sync; sync; sync # wait thirty seconds, because paranoia never hurts ] sync; sync; sync; reboot Just be aware that you don't get a lot of nice things like, oh, some of the flush on shutdown behaviour that you do in a normal boot. Shutting down from the GUI, or typing 'halt' isn't magic. It doesn't magically do anything that sync doesn't. How else do you think that the logic works when you shut down? `mount / -o remount,ro ; sync ; halt_for_real` is pretty safe. signature.asc Description: OpenPGP digital signature -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] mount LVM from Ubuntu live CD
Jeremy Visser jer...@visser.name writes: On 19/02/10 13:41, Daniel Pittman wrote: ] mount / -o remount,rw ] passwd root # ...and give it a good password ] mount / -o remount,ro ] sync; sync; sync # wait thirty seconds, because paranoia never hurts ] sync; sync; sync; reboot Just be aware that you don't get a lot of nice things like, oh, some of the flush on shutdown behaviour that you do in a normal boot. Shutting down from the GUI, or typing 'halt' isn't magic. It doesn't magically do anything that sync doesn't. How else do you think that the logic works when you shut down? ...perhaps my working wasn't clear, as you seem to be restating my point? Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] Asus EeePC 1005HA
quote who=Jeff Waugh 7. What sorts of quirks have you discovered There were a few funny things going on with wifi (ath9k driver), but I'm now running lucid (what will become Ubuntu 10.04 LTS), and it's doing very well. A quick tidbit for anyone who has acquired one of these delightful netbooks: Asus has shipped a few BIOS updates, the most recent of which has improved my wifi performance/reliability considerably. Recommended update. - Jeff -- The Great Australian Internet Blackout http://www.internetblackout.com.au/ One in 10 Europeans is allegedly conceived in an Ikea bed. - BBC News, 2005 -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] mount LVM from Ubuntu live CD
I don't get how sync will write anything to a ro filesystem. That seems to be to break a fundamental kernel and filesystem principle. I would have thought either the remount would either force a flush of dirty blocks before it switches to ro, or alternatively those blocks still dirty at the time of the remount end up in the bit bucket. Also I have seen this 3 sync incantation before. It seems to me that all you are doing playing snap with processes that might have stuff to write but hasn't been flushed. After any sync and before the final shutdown I presume any running process is at liberty to create new dirty blocks that may or may not make it to disk in time. Regards, Martin martinvisse...@gmail.com On Sun, Feb 21, 2010 at 12:37 PM, Daniel Pittman dan...@rimspace.netwrote: Jeremy Visser jer...@visser.name writes: On 19/02/10 13:41, Daniel Pittman wrote: ] mount / -o remount,rw ] passwd root # ...and give it a good password ] mount / -o remount,ro ] sync; sync; sync # wait thirty seconds, because paranoia never hurts ] sync; sync; sync; reboot Just be aware that you don't get a lot of nice things like, oh, some of the flush on shutdown behaviour that you do in a normal boot. Shutting down from the GUI, or typing 'halt' isn't magic. It doesn't magically do anything that sync doesn't. How else do you think that the logic works when you shut down? ...perhaps my working wasn't clear, as you seem to be restating my point? Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] mount LVM from Ubuntu live CD
On Sun, Feb 21, 2010 at 02:03:29PM +1100, Martin Visser wrote: I don't get how sync will write anything to a ro filesystem. That seems to be to break a fundamental kernel and filesystem principle. It won't change anything on the file system as to how it existed in RAM/DISK at the time of the remount. I would have thought either the remount would either force a flush of dirty blocks before it switches to ro, or alternatively those blocks still dirty at the time of the remount end up in the bit bucket. The remount doesn't flush the kernel buffer cache. Neither does unmount at least this is what my past experience and a bit of googling tell me. So the sync is necessary. Doing it 3 times is just paranoia, I don't think the sync returns till the disk itself has indicated the blocks are written. This has happened to me everytime I change a root password in single user mode. My usual process is linux init=/bin/sh mount -o remount,rw / vi /etc/passwd reboot # Bugger linux init=/bin/sh mount -o remount,rw / vi /etc/passwd mount -o remount,ro / reboot # Bugger linux init=/bin/sh mount -o remount,rw / vi /etc/passwd mount -o remount,ro / sync reboot # Hurray Cheers, John Also I have seen this 3 sync incantation before. It seems to me that all you are doing playing snap with processes that might have stuff to write but hasn't been flushed. After any sync and before the final shutdown I presume any running process is at liberty to create new dirty blocks that may or may not make it to disk in time. Jeremy Visser jer...@visser.name writes: On 19/02/10 13:41, Daniel Pittman wrote: ] mount / -o remount,rw ] passwd root # ...and give it a good password ] mount / -o remount,ro ] sync; sync; sync # wait thirty seconds, because paranoia never hurts ] sync; sync; sync; reboot Just be aware that you don't get a lot of nice things like, oh, some of the flush on shutdown behaviour that you do in a normal boot. Shutting down from the GUI, or typing 'halt' isn't magic. It doesn't magically do anything that sync doesn't. How else do you think that the logic works when you shut down? ...perhaps my working wasn't clear, as you seem to be restating my point? Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html -- John Blog http://www.inodes.org LCA2010 http://www.lca2010.org.nz -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
Re: [SLUG] mount LVM from Ubuntu live CD
Martin Visser martinvisse...@gmail.com writes: I don't get how sync will write anything to a ro filesystem. That seems to be to break a fundamental kernel and filesystem principle. ...ah. Um, it doesn't write anything to the file system, as such. It triggers the dirty pages in the kernel cache to write out to their block devices. The read only switch in the file system, and to some degree the file system itself, are at a higher level, so are not involved especially. (...and once the file system is read only it *should* not generate any more dirty blocks, although occasionally bugs could trigger this.) I would have thought either the remount would either force a flush of dirty blocks before it switches to ro, or alternatively those blocks still dirty at the time of the remount end up in the bit bucket. Nope. Not least because you *can't* make that assurance: the blocks written may be in flight on the HBA, or even the network, between the file system and the magnetic storage. Also I have seen this 3 sync incantation before. It dates back a *long* time, well before Linux. These days it is seldom, if ever, necessary, but old habits die hard. It seems to me that all you are doing playing snap with processes that might have stuff to write but hasn't been flushed. If there are active processes writing, sure. It used to be, once upon a time, that sync didn't (guarantee) to write every dirty block on the system. (Theoretically, with enough block layers between the magnetic storage and the page cache you could perhaps still race to the same conclusion or so, but probably not.) After any sync and before the final shutdown I presume any running process is at liberty to create new dirty blocks that may or may not make it to disk in time. Correct. If you mount the file system read-only, though, you can be confident that no *new* dirty blocks are being generated by that file system, absent bugs. Daniel -- ✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
