From mboxrd@z Thu Jan 1 00:00:00 1970 From: smiley@zenzebra.mv.com (smiley at zenzebra.mv.com) Date: Sat, 19 Mar 2011 14:20:47 +0000 Subject: [9fans] New venti install won't boot after 05:00 crash In-Reply-To: (erik quanstrom's message of "Fri, 18 Mar 2011 22:53:32 -0400") References: <78a8a30056dea494c98ebd88b9d4b744@gmx.de> Message-ID: <864o6zur7k.fsf@cmarib.ramside> Topicbox-Message-UUID: bd4eaa7e-ead6-11e9-9d60-3106f5b1d025 erik quanstrom writes: > On Fri Mar 18 22:48:04 EDT 2011, cinap_lenrek at gmx.de wrote: > >> check the output of cat /dev/sdC0/ctl for lba48always. >> >> i have it enabled on my t23 because i got i/o erros (on a particular >> block number that i forgot... it was reproducable) if its off. > > i don't really think this is the problem, since a dd on the whole > disk worked. In the interest of full disclosure, that "dd" was done under Linux. It was a "dd if=" rather than a "dd -if". However, I just re-ran the dd from the Plan 9 installer, using the Plan 9 dd to read the entire partition and zero the entire partition. Neither the read nor write returned any errors. This is with NO lba48always in cat /dev/sdC0/ctl. My next step will be to attempt a fossil-only install. If that doesn't generate these kinds of errors, at least we'll know the problem is venti's work. Has anyone looked at the "prep" layout in the install transcript I bastebin'd? Does it look sane? I really wish I understood how these file servers worked... I would be able to debug this by myself. Alas, Plan 9 is a network operating system. So, I suppose it's only natural that troubleshooting be networked, too. ;) -- +---------------------------------------------------------------+ |E-Mail: smiley at zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---------------------------------------------------------------+