Re: Now Lost Boot Dir/2.6.34 Will Not Boot
On Sat, 04 Sep 2010 15:18:40 -0400 (EDT), David Baron wrote: > > Using the Debian rescue CD, I installed the linux-image-2.6.32-5 and linux- > base from Sid. > > The install edited my fstab and lilo.conf files for me, putting in the UUID > numbers for everything except lilo.conf boot=. I left that as-is /dev/sda but > both variations, UUID and ata-ID had previously worked. > > Too bad the previous install did not fix this up for me. Might have saved a > lot of grief, huh? Yes, that seems to be one weakness of linux-base. (I think that's the package that converts the files.) It doesn't handle the "boot" record of /etc/lilo.conf properly. I discovered that the hard way a few months ago. And that is why I document the stuff I do in my kernel-building web page. I thought about reporting a bug, but I didn't want to give the movers and shakers at Debian an excuse to pull lilo from the distribution. It isn't lilo's fault, but some people I know are looking for an excuse to pull it. > The initrd (needed most, dep failed) needed to go into "highest memory" with > scarey warnings but it worked. MODULES=dep usually works, but only if you don't "cross-build" your initial RAM file systems. In other words, if you're using MODULES=dep, and you're building an initial RAM file system image for the 2.6.32-5-amd64 kernel, you had better be *running* the 2.6.32-5-amd64 kernel at the time you do the build. If you're running any other kernel, there's a good chance that the right drivers won't be included. Do you have the "large-memory" option specified in /etc/lilo.conf? If not, you should. This will probably eliminate the warnings. > > Thanks for all the help. Debian folks are the best! You're welcome. I'm glad I could help. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1554450231.612763.1283637242567.javamail.r...@md01.wow.synacor.com
Re: Now Lost Boot Dir/2.6.34 Will Not Boot
Using the Debian rescue CD, I installed the linux-image-2.6.32-5 and linux- base from Sid. The install edited my fstab and lilo.conf files for me, putting in the UUID numbers for everything except lilo.conf boot=. I left that as-is /dev/sda but both variations, UUID and ata-ID had previously worked. Too bad the previous install did not fix this up for me. Might have saved a lot of grief, huh? The initrd (needed most, dep failed) needed to go into "highest memory" with scarey warnings but it worked. After a long bootup with loads of [mesages.] (no untoward warnings or panics, however}, fsck balked but manual runs fixed that. I am now back up and running. Who knows, maybe the 2.6.34 kernel I compiled will run now? Thanks for all the help. Debian folks are the best! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201009042218.40540.d_ba...@012.net.il
Re: Now lost boot dir
On 09/02/2010 12:26 PM, d_ba...@012.net.il wrote: > > Using the Debian rescue CD, I built a 2.6.34 kernel compiling> in more.> > However, locale issues prevented me from installing it and> running lilo.> > Funny--worked fine last week. I got it to work today. Kernel will still not boot.> I am wondering whether to> bite the bullet> > and simply install a stock kernel. Since I need Nouveau,> it would need> > to be a more recent kernel, a 2.6.33,4 or 5. Which is recommended> > (all are called experimental and many images are simply lacking)?> > The standard 2.6.32 kernel used by Squeeze (I currently use> 2.6.32-5-686> version 2.6.32-20) works fine, and includes the nouveau> driver. The> nouveau driver seems to work OK in my experience, as long as you don't> need interlaced video modes.OK. Does it work with sid xorg-video-nouveau or does it need the version from testing?> > Heard tell of compatibility problems with various nouveau compiles> > and its xorg drivers. This would, of course, use th e initrd.> > I stopped using initrd when the installations ran yaird and> this never> > worked.> > Debian has given up on yaird for now. Stock kernels use> initramfs-tools, which seems to work fine.> > > I used to use the old mkinitrd and have an obselete conf> > for it. Now, the update-initramfs serves this. Is> this smart enough> > to get me running with the newer SATA/PATA drivers (module policy> > defaults to "most")?> > The 2.6.32-5-686 kernel uses the newer libata drivers.> > > Do I need to specify most everything like> > in mkinitrd?> > MODULES=dep in /etc/initramfs-tools/conf.d/driver-policy seems to> work fine as long as you don't "cross build" your initial RAM> file systems. I.e. don't build an initial RAM file system> for a kernel which uses the old IDE drivers while running a kernel> which uses the newer libata drivers, or vice versa.I would run it from the rescue CD which uses the newer libata drivers.> > > (Yaird had a test mode which gave a usable list of what> > to include.)> > If you use the -v switch on update-initramfs it will list the> modules that it includes.> > > Can these images be used with lilo or are they already> > too large?> > I don't have any personal experience with the amd64 images,> but I can attest that the i386 ones work> fine with lilo, especially if you use the large-memory option,> and especially if you use MODULES=dep.> I don't know if I mentioned this earlier, but you might> want to take a look at my kernel-building web page,> http://www.wowway.com/~zlinuxman/Kernel.htm. It may have> some information that you will find useful, even if you use> a stock kernel, and especially if you use lilo.I'll give it a look!This new computer is a two-core intel so I assume it is 64 bit but that does not require me to use 64 bits, especially just to get the thing booting normally again. A HTML mail. That's why it looks so bad. Sorry I don't do HTML mail. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c8118eb.2050...@gmail.com
Re: Now lost boot dir
On 09/02/2010 12:26 PM, d_ba...@012.net.il wrote: > > Using the Debian rescue CD, I built a 2.6.34 kernel compiling> in more.> > However, locale issues prevented me from installing it and> running lilo.> > Funny--worked fine last week. I got it to work today. Kernel will still not boot.> I am wondering whether to> bite the bullet> > and simply install a stock kernel. Since I need Nouveau,> it would need> > to be a more recent kernel, a 2.6.33,4 or 5. Which is recommended> > (all are called experimental and many images are simply lacking)?> > The standard 2.6.32 kernel used by Squeeze (I currently use> 2.6.32-5-686> version 2.6.32-20) works fine, and includes the nouveau> driver. The> nouveau driver seems to work OK in my experience, as long as you don't> need interlaced video modes.OK. Does it work with sid xorg-video-nouveau or does it need the version from testing?> > Heard tell of compatibility problems with various nouveau compiles> > and its xorg drivers. This would, of course, use th e initrd.> > I stopped using initrd when the installations ran yaird and> this never> > worked.> > Debian has given up on yaird for now. Stock kernels use> initramfs-tools, which seems to work fine.> > > I used to use the old mkinitrd and have an obselete conf> > for it. Now, the update-initramfs serves this. Is> this smart enough> > to get me running with the newer SATA/PATA drivers (module policy> > defaults to "most")?> > The 2.6.32-5-686 kernel uses the newer libata drivers.> > > Do I need to specify most everything like> > in mkinitrd?> > MODULES=dep in /etc/initramfs-tools/conf.d/driver-policy seems to> work fine as long as you don't "cross build" your initial RAM> file systems. I.e. don't build an initial RAM file system> for a kernel which uses the old IDE drivers while running a kernel> which uses the newer libata drivers, or vice versa.I would run it from the rescue CD which uses the newer libata drivers.> > > (Yaird had a test mode which gave a usable list of what> > to include.)> > If you use the -v switch on update-initramfs it will list the> modules that it includes.> > > Can these images be used with lilo or are they already> > too large?> > I don't have any personal experience with the amd64 images,> but I can attest that the i386 ones work> fine with lilo, especially if you use the large-memory option,> and especially if you use MODULES=dep.> I don't know if I mentioned this earlier, but you might> want to take a look at my kernel-building web page,> http://www.wowway.com/~zlinuxman/Kernel.htm. It may have> some information that you will find useful, even if you use> a stock kernel, and especially if you use lilo.I'll give it a look!This new computer is a two-core intel so I assume it is 64 bit but that does not require me to use 64 bits, especially just to get the thing booting normally again. If you could format the mail so that it would be easier to read,you might get some responses. As it it currently formatted as ONE LINE it is, IMHO, just too hard on the eyes. Wayne -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c81185d.30...@gmail.com
Re: Now lost boot dir
On Thu, 02 Sep 2010 12:26:45 -0400 (EDT), David Baron wrote: > Stephen Powell wrote: >> >> The standard 2.6.32 kernel used by Squeeze (I currently use 2.6.32-5-686, >> version 2.6.32-20) works fine, and includes the nouveau driver. The >> nouveau driver seems to work OK in my experience, as long as you don't >> need interlaced video modes. > > OK. Does it work with sid xorg-video-nouveau or does it need the version > from testing? Before I reply, I wish to once again state that your e-mail arrived with no line breaks whatsoever, and I had to spend a great deal of time reformatting it so that I could make sense of it. Please find a better way to send e-mails. Now in answer to your question, the version of xserver-xorg-video-nouveau is currently the same in both testing (Squeeze) and unstable (Sid): 1:0.0.15+git20100329+7858345-4. > Stephen Powell wrote: >> David Baron wrote: >>> >>> Can these images be used with lilo or are they already too large? >> >> I don't have any personal experience with the amd64 images, >> but I can attest that the i386 ones work >> fine with lilo, especially if you use the large-memory option, >> and especially if you use MODULES=dep. >> I don't know if I mentioned this earlier, but you might >> want to take a look at my kernel-building web page, >> http://www.wowway.com/~zlinuxman/Kernel.htm. It may have >> some information that you will find useful, even if you use >> a stock kernel, and especially if you use lilo. > > I'll give it a look! This new computer is a two-core intel > so I assume it is 64 bit but that does not require me to use 64 bits, > especially just to get the thing booting normally again. Unless it is an Itanium, you should be able to run an i386 installation on it. But you really should take the time to find out what it is. Also, Joachim Wiedorn, the new upstream maintainer for lilo, has come out with an updated version of lilo that solves a number of problems related to the amd64 architecture. You can obtain the latest amd64 version of lilo here: http://www.joonet.de/lilo/debian/squeeze/lilo_23.0-1_amd64.deb The only bug of which I am aware is a bashism in the initramfs hook. Change "#!/bin/sh" to "#!/bin/bash" on the first line of /etc/initramfs/post-update.d/lilo to fix this problem. (I'm going from memory here. I'm not sure about the name of the file, but it should be the only file in /etc/initramfs/post-update.d.) This package, despite it's availability in Debian package format, is not an official Debian package, however. In other words, if you have trouble with it, don't open a Debian bug report against the lilo package. It is not supported by Debian at this time. The i386 version of this package is available here: http://www.wowway.com/~zlinuxman/lilo/squeeze/lilo_23.0-1_i386.deb It has the same bashism bug as the amd64 version. It is not an official Debian package either. But I am using it on one of my i386 machines. And if I had an amd64 machine, I would use Joachim's amd64 version on it. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/296671178.565816.128345197.javamail.r...@md01.wow.synacor.com
Re: Now lost boot dir
> > Using the Debian rescue CD, I built a 2.6.34 kernel compiling > in more.> > > > However, locale issues prevented me from installing it and > running > > lilo.> > Funny--worked fine last week. I got it to work today. Kernel will > > still not boot.> I am wondering whether to > bite the bullet> > and simply > > install a stock kernel. Since I need Nouveau, > it would need> > to be a > > more recent kernel, a 2.6.33,4 or 5. Which is recommended> > (all are > > called experimental and many images are simply lacking)?> > The standard > > 2.6.32 kernel used by Squeeze (I currently use > 2.6.32-5-686> version > > 2.6.32-20) works fine, and includes the nouveau > driver. The> nouveau > > driver seems to work OK in my experience, as long as you don't> need > > interlaced video modes.OK. Does it work with sid xorg-video-nouveau or > > does it need the version from testing?> > Heard tell of compatibility > > problems with various nouveau compiles> > and its xorg drivers. This > > would, of course, use the initrd.> > I stopped using initrd when the > > installations ran yaird and > this never> > worked.> > Debian has given up > > on yaird for now. Stock kernels use> initramfs-tools, which seems to work > > fine.> > > I used to use the old mkinitrd and have an obselete conf> > for > > it. Now, the update-initramfs serves this. Is > this smart enough> > to > > get me running with the newer SATA/PATA drivers (module policy> > defaults > > to "most")?> > The 2.6.32-5-686 kernel uses the newer libata drivers.> > > > > Do I need to specify most everything like> > in mkinitrd?> > MODULES=dep > > in /etc/initramfs-tools/conf.d/driver-policy seems to> work fine as long > > as you don't "cross build" your initial RAM> file systems. I.e. don't > > build an initial RAM file system> for a kernel which uses the old IDE > > drivers while running a kernel> which uses the newer libata drivers, or > > vice versa.I would run it from the rescue CD which uses the newer libata > > drivers. > > > (Yaird had a test mode which gave a usable list of what> > > > to include.)> > If you use the -v switch on update-initramfs it will list > > the> modules that it includes.> > > Can these images be used with lilo or > > are they already> > too large?> > I don't have any personal experience > > with the amd64 images,> but I can attest that the i386 ones work> fine > > with lilo, especially if you use the large-memory option,> and especially > > if you use MODULES=dep.> I don't know if I mentioned this earlier, but you > > might> want to take a look at my kernel-building web page,> > > http://www.wowway.com/~zlinuxman/Kernel.htm. It may have> some > > information that you will find useful, even if you use> a stock kernel, > > and especially if you use lilo.I'll give it a look!This new computer is a > > two-core intel so I assume it is 64 bit but that does not require me to > > use 64 bits, especially just to get the thing booting normally again.
Re: Now lost boot dir
On Wed, 01 Sep 2010 15:50:18 -0400 (EDT), David Baron wrote: > > Using the Debian rescue CD, I built a 2.6.34 kernel compiling in more. > However, locale issues prevented me from installing it and running lilo. > Funny--worked fine last week. I am wondering whether to bite the bullet > and simply install a stock kernel. Since I need Nouveau, it would need > to be a more recent kernel, a 2.6.33,4 or 5. Which is recommended > (all are called experimental and many images are simply lacking)? The standard 2.6.32 kernel used by Squeeze (I currently use 2.6.32-5-686 version 2.6.32-20) works fine, and includes the nouveau driver. The nouveau driver seems to work OK in my experience, as long as you don't need interlaced video modes. > Heard tell of compatibility problems with various nouveau compiles > and its xorg drivers. This would, of course, use the initrd. > I stopped using initrd when the installations ran yaird and this never > worked. Debian has given up on yaird for now. Stock kernels use initramfs-tools, which seems to work fine. > I used to use the old mkinitrd and have an obselete conf > for it. Now, the update-initramfs serves this. Is this smart enough > to get me running with the newer SATA/PATA drivers (module policy > defaults to "most")? The 2.6.32-5-686 kernel uses the newer libata drivers. > Do I need to specify most everything like > in mkinitrd? MODULES=dep in /etc/initramfs-tools/conf.d/driver-policy seems to work fine as long as you don't "cross build" your initial RAM file systems. I.e. don't build an initial RAM file system for a kernel which uses the old IDE drivers while running a kernel which uses the newer libata drivers, or vice versa. > (Yaird had a test mode which gave a usable list of what > to include.) If you use the -v switch on update-initramfs it will list the modules that it includes. > Can these images be used with lilo or are they already > too large? I don't have any personal experience with the amd64 images, but I can attest that the i386 ones work fine with lilo, especially if you use the large-memory option, and especially if you use MODULES=dep. I don't know if I mentioned this earlier, but you might want to take a look at my kernel-building web page, http://www.wowway.com/~zlinuxman/Kernel.htm. It may have some information that you will find useful, even if you use a stock kernel, and especially if you use lilo. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/502817804.543379.1283377622986.javamail.r...@md01.wow.synacor.com
Re: Now lost boot dir
Using the Debian rescue CD, I built a 2.6.34 kernel compiling in more. However, locale issues prevented me from installing it and running lilo. Funny--worked fine last week.I am wondering whether to bite the bullet and simply install a stock kernel. Since I need Nouveau, it would need to be a more recent kernel, a 2.6.33,4 or 5. Which is recommended (all are called experimental and many images are simply lacking)? Heard tell of compatibility problems with various nouveau compiles and its xorg drivers.This would, of course, use the initrd. I stopped using initrd when the installations ran yaird and this never worked. I used to use the old mkinitrd and have an obselete conf for it. Now, the update-initramfs serves this. Is this smart enough to get me running with the newer SATA/PATA drivers (module policy defaults to "most")? Do I need to specify most everything like in mkinitrd? (Yaird had a test mode which gave a usable list of what to include.) Can these images be used with lilo or are they already too large?
Re: Now lost boot dir
Aaron Toponce writes: > I had no problems reading the HTML version of the mail. Not everyone reads mail with a browser. -- John Hasler -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sk1vy96n@thumper.dhh.gt.org
Re: Now lost boot dir
On 08/30/2010 01:00 PM, Jordan Metzmeier wrote: > Your reply seems to have removed all newline characters making it > unreadable. I had no problems reading the HTML version of the mail. -- . o . o . o . . o o . . . o . . . o . o o o . o . o o . . o o o o . o . . o o o o . o o o signature.asc Description: OpenPGP digital signature
Re: Now lost boot dir
Jordan Metzmeier writes: > David, > > Your reply seems to have removed all newline characters making it > unreadable. That is only the text version. The message also has an html version which is readable. -- Carl Johnsonca...@peak.org -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zkw37nmq@oak.localnet
Re: Now lost boot dir
On Mon, Aug 30, 2010 at 2:16 PM, wrote: >> David Baron wrote: > > The lines: > # ROOT > /dev/sdb2 / ext3 defaults,errors=remount-ro 0 1 > are this way in the actual file! And I thought that root and boot were commented out! :( -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTinFPV9d3Gu5rzFB9DiWPLeWUXK su4um4k...@mail.gmail.com
Re: Now lost boot dir
> > defaults 1 2 /dev/DB-> LVM/LV_HOME /home > > >> ext3 > defaults 1 2 #/dev/DB-> LVM2/LV_AUX > /mnt/aux > >> ext3 > defaults 1 2> >> >I'm really confused. > As I've said before, I don't know > anything about LVMs,> >so that may be > part of the problem.> > For fstab, and most other places, they are just a > partition with > an odd name. > /dev/VG0/LV0 might as well be /dev/sda1 as > far as most tools are > concerned.> >But I don't see anything mounted as /.> > > That's a problem.There IS a /dev/sdb2 / mount, got mangled in the missing > email line-breaks.> > >I also see a bunch of stuff that is confusing.> > > Agreed. Removable media should not be mounted using the > kernel device name > > (e.g. /dev/sda or /dev/sdb1), since it is likely to > change. I'd likely > remove > some of the comments just to make the active lines more visible.That > is why I commented them out for now. > >And you're> >not using any uuids in > /etc/fstab.> > If you use LVM snapshots, you shouldn't use UUIDs for LVM > > volumes, since the > UUID of the file system in the snapshot will be the same > as the > UUID of the > original file system.> > So, /dev/DB-LVM* entries are > fine, but the rest should probably > be changed to > LABEL=* / UUID=* > entries. Probably so but putting all that in is what started the demise of my > system. I will stick with /dev/sdb style until I can get things booting up > again, then take lessons on how to go to the newer, more transportable > convention.Anyway, if the root does not get recognized and mounted, all the > other questions are academic.
Re: Now lost boot dir
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, Your reply seems to have removed all newline characters making it unreadable. Regards, - -- Jordan Metzmeier -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQIcBAEBCAAGBQJMe//FAAoJEKj/C3qNthmTvKsP/RPblJk6DAdkpNE8do6HGMrI bejLtzZMDuL4B2GfxfmcWZ285XrtrK6+YRPid1mZZKjx26qYy4b2HgjYr3wNoDRg BtYIK0N2sbSwF2hDRfen1be+8g7S9HO83n49Z2VAK6Yha8JPVDN/3Y84oaj5Ftpw WmOrUWhgTvhjo0yGOYWl90v3hxrNYgw789jUHA+4I8RQPTAKel+pOtbGROmP8CnO u8Wqf/ykh4j3dmGA7VDAIOVy6XdHfUNl/0oMGwCvquCarrrUghbP5p2X5Kdb7jSg SoPWbZH/9Gej3rccnhvYcub4xCxk50ljQiki0oZJZ0VVjGUOxYdchEKLFXKOABjD 45l0Tj4/eFHMreB4cluWqVWDP5FINftdM/AXTWimpYwmR8pWBDxCmVcXKvmXNWM4 C6PNnCfcasFAqZWW0zfkg/lAfEa0Khhvm5DvYDhtSFA88NecHE7RCwEnP+OH886M /zULYgmSWFHG0GY9JTTJ0D7hfNCjPbXRIJ3DcYmCaJQPhMI25ve83DpNTMY85DBI 42yzzT/t06wjqr92MGRi7/AEInYhceAma7ZB47CtAJMKnbrJoBnraoekudK/PD+L 7LsvROMKJGZr0U+0GVzr6atQh2qyas8sL8ViHOimtDKDGx3Fq1L3VGxAwzF2tBm9 DXu1WXWsQ0v/KajrdN6v =luyb -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c7bffc5.8000...@gmail.com
Re: Now lost boot dir
On Mon, Aug 30, 2010 at 9:46 AM, Stephen Powell wrote: > David Baron wrote: > >> $ cat /mnt/hdb2/etc/fstab >> # ROOT/dev/sdb2 / ext3 defaults,errors=remount-ro 0 1 >> # BOOT/dev/sdb1 /boot ext3 defaults,errors=remount-ro 0 2 >> /dev/sda1 /mnt/hda1 vfat auto,user,exec,umask=000,uid=david,gid=david 0 0 >> /dev/sda5 /mnt/hda6 vfat auto,user,exec,umask=000,uid=david,gid=david 0 0 >> /dev/sdc5 /mnt/hdb5 vfat noauto,user,exec,umask=000,uid=david,gid=david 0 0 >> /dev/DB-LVM/LV_USR /usrext3defaults1 2 >> /dev/DB-LVM/LV_VAR /varext3defaults1 2 >> /dev/DB-LVM/LV_HOME /home ext3defaults1 2 > I'm really confused. As I've said before, I don't know anything about LVMs, > so that may be part of the problem. But I don't see anything mounted as /. > I also see a bunch of stuff that is confusing. I see stuff mounted on pass 0, > for example, that I would expect to see mounted on pass 2. And you're not > using any uuids in /etc/fstab. Maybe with this information, someone else > who is familiar with LVMs can make sense of this. / and /boot are somehow commented out. You don't need to use UUIDs for LVs because their names are persistent and (hopefully!) unique. >> $ ls -Al /dev/disk/by-uuid/ >> lrwxrwxrwx 1 root root 10 Aug 30 10:00 0e4daa81-9396-4257-850f-7a64732b64fd >> -> ../../hdb3 >> lrwxrwxrwx 1 root root 10 Aug 30 10:00 48F8-54A6 -> ../../hdb5 >> lrwxrwxrwx 1 root root 10 Aug 30 10:00 4C01-B501 -> ../../hda1 >> lrwxrwxrwx 1 root root 10 Aug 30 10:00 C366-1257 -> ../../hda5 >> lrwxrwxrwx 1 root root 10 Aug 30 10:00 cfec040e-ca65-432a-8e4e-68c2126a4f44 >> -> ../../hdb1 >> lrwxrwxrwx 1 root root 10 Aug 30 10:00 d0c33beb-b77a-4e77-ac0b-346161a1120a >> -> ../../hda4 >> lrwxrwxrwx 1 root root 10 Aug 30 10:00 df24bea0-5520-4281-b053-021bd5a96628 >> -> ../../hdb2 Do you have two or three disks? There was a comment in your fstab that "second master is now on /dev/hdc", which explains why you have sdc5 mounted on /mnt/hdb5 but your root and boot are sdbX. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=iukrckohiwgbnkgmwcera7hwz2wr8jw0fy...@mail.gmail.com
Re: Now lost boot dir
> David Baron wrote:> > > > Diagnostics failed in attemts to reach you, trying > emial with .com> > > > Your e-mail arrived as one continuous long line. > There > were no line> breaks whatsoever. I don't know what tool you used, > but > please try> to fine a more user-friendly tool next time. I had to > manually> reformat the whole thing. Also, you sent the e-mail to me only> > and did not copy the list.> Never saw anything like that. This stuff was > simply cut and paste from a kde3 konsole window into the on-line mailer of my > provider (I am running off a live CD, though kmail might be OK). The original > that did not make it through was done in kwrite and that probably formatted > OK. Sorry 'bout that. (But wait, doesn't the whole world handle line breaks > like ... Windows (CR + LF))? I will inform the provider about what > happened!)> > Note: I am not using an initrd so update-initramfs is not > relevant!> > > > That's right, I forgot about that.> > > $ cat > /mnt/hdb2/etc/fstab> > # /etc/fstab: filesystem table.#> > # filesystem > mountpoint type options > dump pass> > # ROOT/dev/sdb2 / ext3 > defaults,errors=remount-ro > 0 1> > # BOOT/dev/sdb1 /boot ext3 > defaults,errors=remount-ro 0 2> > /dev/sda4 none swap sw 0 0> > > /dev/sdb3 none swap sw 0 0> > proc /proc proc defaults 0 0> > > /dev/fd0 /floppy vfat > defaults,user,noauto,sync,exec,umask=022 0 0> > > #second master is now on /dev/hdc> > # maintaining older mount directories > for convenience> > #changed by david baron> > #/dev/hdb /mnt/hdc iso9660 > > defaults,user,noexec,noauto,unhide 0 0> > # Added by KNOPPIX, made auto by > david (I am taking out auto > for summer)> > /dev/sda1 /mnt/hda1 vfat > > auto,user,exec,umask=000,uid=david,gid=david 0 0> > # SHARED DATA (left this > way for convenience)> > /dev/sda5 /mnt/hda6 vfat > > auto,user,exec,umask=000,uid=david,gid=david 0 0> > # AUDIO was on > hdb--changed to hdc, keep older directories for > convenience> /dev/sdc5> > > /mnt/hdb5 vfat noauto,user,exec,umask=000,uid=david,gid=david > 0 0> > # Do I > need such as this?> > > none /proc/bus/usb usbfs > defaults 0 0> > # temporary memory for qemu, et al?> > none /dev/shm > tmpfs rw,size=512m 0 0> > # mount win98 image to my test folder> > > /mnt/hda6/win98.img /home/david/test auto > > noauto,loop,offset=32256,umask=022,user> # mount mp3 player> > #/dev/sda > /mnt/mp3player auto > defaults,user,noauto 0 0> > #/dev/sdb > /mnt/pictureframe auto defaults,user,noauto 0 0> > # mount cell phone usb> > > #/dev/sda1 /mnt/phone auto > defaults,user,noauto 0 0> > #/dev/sdb1 > /mnt/phone-sd auto > defaults,user,noauto 0 0> > #/dev/sdd1 > /mnt/phone-sd auto > defaults,user,noauto 0 0> > # NEW STUFF FOR > LVM/dev/DB-> LVM/LV_OPT /opt ext3 defaults > 1 2> > /dev/DB-> LVM/LV_USR /usr ext3 > defaults 1 2> > /dev/DB-> LVM/LV_VAR /var > ext3 defaults 1 2> > /dev/DB-> LVM/LV_HOME > /home ext3 defaults 1 2> > #/dev/DB-> > LVM2/LV_AUX /mnt/aux ext3 defaults 1 2> > I'm > really confused. As I've said before, I don't know > anything about LVMs,> > so that may be part of the problem. But I don't see > anything mounted as > /.> I also see a bunch of stuff that is confusing. I see stuff > mounted on > pass 0,> for example, that I would expect to see mounted on pass 2. > And > you're not> using any uuids in /etc/fstab. Maybe with this > information, > someone else> who is familiar with LVMs can make sense of this.> The LVM are > added by the lvm system config program and I seriously doubt if they are the > problem. If there be no root, those LVM volumes are irrelevant. The lines:# > ROOT/dev/sdb2 / ext3 defaults,errors=remount-ro 0 1are this way in the > actual file! That was one line break you missed in all the mess!Those numbers > 0 0, et al, were placed by the original Knoppix hard-disk installation. I > might have copied and so propagated them in a few places. If you feel that > some of them are not proper, they can be easily enough changed. I do not > fully understand them so just left them as-is.> > > > Here are more. Note > from knoppix-5 CD, paths reference hd... > rathern than sd... disk device > names.> > This is why other sd stuff was commented above as will need to > be > changed.> > > > $ ls -Al /dev/disk/by-id/> > total 0> > lrwxrwxrwx 1 root > root 9 Aug 30 10:00 ata-WDC_WD400BB-> 00DEA0_WD-WMAD19873947 -> ../../hda> > > lrwxrwxrwx 1 root root 10 Aug 30 10:00 ata-WDC_WD400BB-> > 00DEA0_WD-WMAD19873947-part1 -> ../../hda1> > lrwxrwxrwx 1 root root 10 Aug > 30 10:00 ata-WDC_WD400BB-> 00DEA0_WD-WMAD19873947-part2 -> ../../hda2> > > lrwxrwxrwx 1 root root 10 Aug 30 10:00 ata-WDC_WD400BB-> > 00DEA0_WD-WMAD19873947-part3 -> ../../hda3> > lrwxrwxrwx
Re: Now lost boot dir
In <1440488473.467512.1283175986162.javamail.r...@md01.wow.synacor.com>, Stephen Powell wrote: >David Baron wrote: >> $ cat /mnt/hdb2/etc/fstab >> # /etc/fstab: filesystem table.# >> # filesystem mountpoint type options dump pass >> # ROOT/dev/sdb2 / ext3 defaults,errors=remount-ro 0 1 >> # BOOT/dev/sdb1 /boot ext3 defaults,errors=remount-ro 0 2 >> /dev/sda4 none swap sw 0 0 >> /dev/sdb3 none swap sw 0 0 >> proc /proc proc defaults 0 0 >> /dev/fd0 /floppy vfat defaults,user,noauto,sync,exec,umask=022 0 0 >> #second master is now on /dev/hdc >> # maintaining older mount directories for convenience >> #changed by david baron >> #/dev/hdb /mnt/hdc iso9660 defaults,user,noexec,noauto,unhide 0 0 >> # Added by KNOPPIX, made auto by david (I am taking out auto for summer) >> /dev/sda1 /mnt/hda1 vfat auto,user,exec,umask=000,uid=david,gid=david 0 0 >> # SHARED DATA (left this way for convenience) >> /dev/sda5 /mnt/hda6 vfat auto,user,exec,umask=000,uid=david,gid=david 0 0 >> # AUDIO was on hdb--changed to hdc, keep older directories for convenience >> /dev/sdc5 >> /mnt/hdb5 vfat noauto,user,exec,umask=000,uid=david,gid=david 0 0 >> # Do I need such as this? >> none/proc/bus/usb usbfs defaults0 0 >> # temporary memory for qemu, et al? >> none /dev/shm tmpfs rw,size=512m 0 0 >> # mount win98 image to my test folder >> /mnt/hda6/win98.img /home/david/test auto >> noauto,loop,offset=32256,umask=022,user # mount mp3 player >> #/dev/sda /mnt/mp3player auto defaults,user,noauto 0 0 >> #/dev/sdb /mnt/pictureframe auto defaults,user,noauto 0 0 >> # mount cell phone usb >> #/dev/sda1 /mnt/phone auto defaults,user,noauto 0 0 >> #/dev/sdb1 /mnt/phone-sd auto defaults,user,noauto 0 0 >> #/dev/sdd1 /mnt/phone-sd auto defaults,user,noauto 0 0 >> # NEW STUFF FOR LVM/dev/DB-LVM/LV_OPT /optext3 >> defaults1 2 /dev/DB-LVM/LV_USR /usrext3 >> defaults1 2 /dev/DB-LVM/LV_VAR /var >> ext3defaults1 2 /dev/DB-LVM/LV_HOME /home >> ext3defaults1 2 #/dev/DB-LVM2/LV_AUX/mnt/aux >> ext3defaults1 2 > >I'm really confused. As I've said before, I don't know anything about LVMs, >so that may be part of the problem. For fstab, and most other places, they are just a partition with an odd name. /dev/VG0/LV0 might as well be /dev/sda1 as far as most tools are concerned. >But I don't see anything mounted as /. That's a problem. >I also see a bunch of stuff that is confusing. Agreed. Removable media should not be mounted using the kernel device name (e.g. /dev/sda or /dev/sdb1), since it is likely to change. I'd likely remove some of the comments just to make the active lines more visible. >And you're >not using any uuids in /etc/fstab. If you use LVM snapshots, you shouldn't use UUIDs for LVM volumes, since the UUID of the file system in the snapshot will be the same as the UUID of the original file system. So, /dev/DB-LVM* entries are fine, but the rest should probably be changed to LABEL=* / UUID=* entries. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Now lost boot dir
David Baron wrote: > > Diagnostics failed in attemts to reach you, trying emial with .com > Your e-mail arrived as one continuous long line. There were no line breaks whatsoever. I don't know what tool you used, but please try to fine a more user-friendly tool next time. I had to manually reformat the whole thing. Also, you sent the e-mail to me only and did not copy the list. > Note: I am not using an initrd so update-initramfs is not relevant! > That's right, I forgot about that. > $ cat /mnt/hdb2/etc/fstab > # /etc/fstab: filesystem table.# > # filesystem mountpoint type options dump pass > # ROOT/dev/sdb2 / ext3 defaults,errors=remount-ro 0 1 > # BOOT/dev/sdb1 /boot ext3 defaults,errors=remount-ro 0 2 > /dev/sda4 none swap sw 0 0 > /dev/sdb3 none swap sw 0 0 > proc /proc proc defaults 0 0 > /dev/fd0 /floppy vfat defaults,user,noauto,sync,exec,umask=022 0 0 > #second master is now on /dev/hdc > # maintaining older mount directories for convenience > #changed by david baron > #/dev/hdb /mnt/hdc iso9660 defaults,user,noexec,noauto,unhide 0 0 > # Added by KNOPPIX, made auto by david (I am taking out auto for summer) > /dev/sda1 /mnt/hda1 vfat auto,user,exec,umask=000,uid=david,gid=david 0 0 > # SHARED DATA (left this way for convenience) > /dev/sda5 /mnt/hda6 vfat auto,user,exec,umask=000,uid=david,gid=david 0 0 > # AUDIO was on hdb--changed to hdc, keep older directories for convenience > /dev/sdc5 > /mnt/hdb5 vfat noauto,user,exec,umask=000,uid=david,gid=david 0 0 > # Do I need such as this? > none/proc/bus/usb usbfs defaults0 0 > # temporary memory for qemu, et al? > none /dev/shm tmpfs rw,size=512m 0 0 > # mount win98 image to my test folder > /mnt/hda6/win98.img /home/david/test auto > noauto,loop,offset=32256,umask=022,user > # mount mp3 player > #/dev/sda /mnt/mp3player auto defaults,user,noauto 0 0 > #/dev/sdb /mnt/pictureframe auto defaults,user,noauto 0 0 > # mount cell phone usb > #/dev/sda1 /mnt/phone auto defaults,user,noauto 0 0 > #/dev/sdb1 /mnt/phone-sd auto defaults,user,noauto 0 0 > #/dev/sdd1 /mnt/phone-sd auto defaults,user,noauto 0 0 > # NEW STUFF FOR LVM/dev/DB-LVM/LV_OPT /optext3 > defaults1 2 > /dev/DB-LVM/LV_USR /usrext3defaults1 2 > /dev/DB-LVM/LV_VAR /varext3defaults1 2 > /dev/DB-LVM/LV_HOME /home ext3defaults1 2 > #/dev/DB-LVM2/LV_AUX/mnt/auxext3defaults1 2 I'm really confused. As I've said before, I don't know anything about LVMs, so that may be part of the problem. But I don't see anything mounted as /. I also see a bunch of stuff that is confusing. I see stuff mounted on pass 0, for example, that I would expect to see mounted on pass 2. And you're not using any uuids in /etc/fstab. Maybe with this information, someone else who is familiar with LVMs can make sense of this. > > Here are more. Note from knoppix-5 CD, paths reference hd... rathern than > sd... disk device names. > This is why other sd stuff was commented above as will need to be changed. > > $ ls -Al /dev/disk/by-id/ > total 0 > lrwxrwxrwx 1 root root 9 Aug 30 10:00 ata-WDC_WD400BB-00DEA0_WD-WMAD19873947 > -> ../../hda > lrwxrwxrwx 1 root root 10 Aug 30 10:00 > ata-WDC_WD400BB-00DEA0_WD-WMAD19873947-part1 -> ../../hda1 > lrwxrwxrwx 1 root root 10 Aug 30 10:00 > ata-WDC_WD400BB-00DEA0_WD-WMAD19873947-part2 -> ../../hda2 > lrwxrwxrwx 1 root root 10 Aug 30 10:00 > ata-WDC_WD400BB-00DEA0_WD-WMAD19873947-part3 -> ../../hda3 > lrwxrwxrwx 1 root root 10 Aug 30 10:00 > ata-WDC_WD400BB-00DEA0_WD-WMAD19873947-part4 -> ../../hda4 > lrwxrwxrwx 1 root root 10 Aug 30 10:00 > ata-WDC_WD400BB-00DEA0_WD-WMAD19873947-part5 -> ../../hda5 > lrwxrwxrwx 1 root root 10 Aug 30 10:00 > ata-WDC_WD400BB-00DEA0_WD-WMAD19873947-part6 -> ../../hda6 > lrwxrwxrwx 1 root root 9 Aug 30 10:00 ata-WDC_WD800JB-00ETA0_WD-WCAHL5220676 > -> ../../hdb > lrwxrwxrwx 1 root root 10 Aug 30 10:00 > ata-WDC_WD800JB-00ETA0_WD-WCAHL5220676-part1 -> ../../hdb1 > lrwxrwxrwx 1 root root 10 Aug 30 10:00 > ata-WDC_WD800JB-00ETA0_WD-WCAHL5220676-part2 -> ../../hdb2 > lrwxrwxrwx 1 root root 10 Aug 30 10:00 > ata-WDC_WD800JB-00ETA0_WD-WCAHL5220676-part3 -> ../../hdb3 > lrwxrwxrwx 1 root root 10 Aug 30 10:00 > ata-WDC_WD800JB-00ETA0_WD-WCAHL5220676-part4 -> ../../hdb4 > lrwxrwxrwx 1 root root 10 Aug 30 10:00 > ata-WDC_WD800JB-00ETA0_WD-WCAHL5220676-part5 -> ../../hdb5 > lrwxrwxrwx 1 root root 10 Aug 30 10:00 > ata-WDC_WD800JB-00ETA0_WD-WCAHL5220676-part6 -> ../../hdb6 Based on this, if you want lilo's stage 1 boot loader installed to the master boot record, it looks like you would specify boot=/dev/disk/by-id/ata-WDC_WD400BB-00DEA0_WD-WMAD19873947 in /etc/lilo.conf. Speaking of which, I asked for a copy of that file also, which you did not provide. > $ ls -Al /dev/disk/by-u
Re: Now lost boot dir
On Sun, 29 Aug 2010 04:07:15 -0400 (EDT), David Baron wrote: > > Progress: Using Debian Live rescue, was able to mount my volumes, > reinstall the kernel, run update-initramfs and lilo. (Only thing > lost was the debian.bmp which looked gosh-awful on my screen > anyway--works without it.) Results, back to where I was: > 2.6.34 Will Not Boot. Glad to hear that. > > It loads up, begins the process and then > panics out with "cannot find root device sdb2" (my root partition), > offers no alternatives (2.6.32 did once offer a list of parititons > on the previous computer where this problem started but the could > not find the hdb2 it should have found!). Lilo's boot loader does not understand the file system (any file system). It reads the kernel and initial RAM file system images as a list of blocks (i.e. logical block addresses) that were saved at map installer time. If it isn't defined in /etc/lilo.conf it can't be booted. > > Since, without that > bitmap, I have a type-in menu on bootup, I tried stuff like "2.6.34 > append "root=/dev/sdb2"" and variations of that to no avail. I don't use the bit map interface, but in the traditional text mode interface a list of bootable kernels can be obtained by (a) pressing the Shift key to disable the timer and get a boot prompt, and then (b) pressing the Tab key. Lilo will respond by listing the labels of all bootable systems. I don't know if that works with your installed interface though. > > So: How do I fix this thing, step-by-step? The 2.6.34 was compiled > with the newer PATA/SATA driver so will create sdb's rather than > hdb's (I would have no objection going back to 2.6.32 and the hdb's > if this be than answer but that did not either before on this system). > In any event, all my volumes are intact and I can offload to a new > disk if I so choose and restart from there but it would seem it > should make no difference. Please provide the following information: (1) The output of the "p" command (print the partition table) in fdisk for all your disks. (2) The contents of /etc/fstab (3) The contents of /etc/initramfs-tools/conf.d/resume (4) The contents of /etc/initramfs-tools/conf.d/driver-policy (5) The output of the following commands ls -Al /dev/disk/by-id/ ls -Al /dev/disk/by-uuid/ ls -Al /dev/disk/by-path/ I may ask for more information later, but this will get us started -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/826565406.445662.1283084802822.javamail.r...@md01.wow.synacor.com
Re: Now lost boot dir
Progress: Using Debian Live rescue, was able to mount my volumes, reinstall the kernel, run update-initramfs and lilo. (Only thing lost was the debian.bmp which looked gosh-awful on my screen anyway--works without it.)Results, back to where I was: 2.6.34 Will Not Boot. It loads up, begins the process and then panics out with "cannot find root device sdb2" (my root partition), offers no alternatives (2.6.32 did once offer a list of parititons on the previous computer where this problem started but the could not find the hdb2 it should have found!). Since, without that bitmap, I have a type-in menu on bootup, I tried stuff like "2.6.34 append "root=/dev/sdb2"" and variations of that to no avail.So: How do I fix this thing, step-by-step? The 2.6.34 was compiled with the newer PATA/SATA driver so will create sdb's rather than hdb's (I would have no objection going back to 2.6.32 and the hdb's if this be than answer but that did not either before on this system).In any event, all my volumes are intact and I can offload to a new disk if I so choose and restart from there but it would seem it should make no difference.
Re: Now lost boot dir
On 26 aug 2010, at 20:39, d_ba...@012.net.il wrote: > All of the data (except for the boot dir which was not in LVM) should be > perfectly intact. > I need a live CD which supports LVM (Knoppix 5.* does not) which will mount > these volumes. > From there, I can either copy off needed data to another disk or chroot, > reinstall some kernel images and set up lilo or grub and be up and running. > > That live CD is the key. Which one? I use SystemRescueCd to assemble lvm. Works for me. I do 'vgscan' to find the available vg's, then 'vgchange -a y ' to activate the VG and finally 'vgmknodes' and I'm ready to manipulate my LV's. HTH Peter [1] http://www.sysresccd.org/Main_Page -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/c0a47423-cb51-4158-bfed-e8ff45929...@onemanifest.net
Re: Now lost boot dir
On Thu, Aug 26, 2010 at 2:39 PM, wrote: >> > Dead in the water. What to do keeping data in lvm partitions? >> > Best reply off list also. Thanks for any help! >> >> As I said before, I have no experience with LVMs and therefore >> can't be of much help on a recovery. Sorry. > > All of the data (except for the boot dir which was not in LVM) should be > perfectly intact. > I need a live CD which supports LVM (Knoppix 5.* does not) which will mount > these volumes. > From there, I can either copy off needed data to another disk or chroot, > reinstall some kernel images and set up lilo or grub and be up and running. > That live CD is the key. Which one? As I said in an earlier email, you can install LVM while booted from a Live CD. Since this is Debian, why not a Debian Live CD?! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikgqyu3uc29opd2enliymz+oat6xslbcqije...@mail.gmail.com
Re: Now lost boot dir
> > Dead in the water. What to do keeping data in lvm partitions?> > Best reply > > off list also. Thanks for any help!> > As I said before, I have no > > experience with LVMs and therefore> can't be of much help on a recovery. > > Sorry.All of the data (except for the boot dir which was not in LVM) should > > be perfectly intact.I need a live CD which supports LVM (Knoppix 5.* does > > not) which will mount these volumes.From there, I can either copy off > > needed data to another disk or chroot, reinstall some kernel images and set > > up lilo or grub and be up and running.That live CD is the key. Which one?
Re: Now lost boot dir
Le 26/08/2010 à 14:09, David Baron a écrit : > > Dead in the water. What to do keeping data in lvm partitions? Best reply off > list also. Thanks for any help! > > I just subscribe to the list and have only the abovz message, which is not enought for me to understand your problem :( Can you (re)explain ? Alain -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201008261718.30227.alain.baecker...@laposte.net
Re: Now lost boot dir
On Thu, 26 Aug 2010 08:09:16 -0400 (EDT), David Baron wrote: > > Dead in the water. What to do keeping data in lvm partitions? > Best reply off list also. Thanks for any help! As I said before, I have no experience with LVMs and therefore can't be of much help on a recovery. Sorry. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/351007166.382392.1282832281515.javamail.r...@md01.wow.synacor.com
Re: Now lost boot dir
On 08/26/2010 06:09 AM, David Baron wrote: > Dead in the water. What to do keeping data in lvm partitions? I'm assuming that you have more than one disk? Are they the same size? If so, you should have been using Linux software RAID to prevent the volume from losing data. Not much you can do at this point, except rebuild, and restore from backup. -- . O . O . O . . O O . . . O . . . O . O O O . O . O O . . O O O O . O . . O O O O . O O O signature.asc Description: OpenPGP digital signature
Now lost boot dir
Dead in the water. What to do keeping data in lvm partitions? Best reply off list also. Thanks for any help! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100826110905.1...@partnergsm.co.il
