Re: Etch to 5.0.2 upgrade failed - Encrypted filesystem will not boot
Ok I guess the system is just hosed. If no one has any more suggestions in the next couple days I will reinstall. I will never trust Debian upgrades again, at least not when encrypted filesystems are in use. On Mon, Aug 10, 2009 at 06:49:51PM -0500, line...@ruiner.halo.nu wrote: hmmm not sure, you could try turning of quiet mode remove the quiet from the kernel option on boot and maybe try turning on debug (add debug to the kernal options) There is no quiet mode in my kernel line. Adding the debug option didn't seem to add any additional relevant information; anothering to try is place a shell script in /etc/initramfs/scripts/local-top/ call something like 00mine and open a console with something like bash or try some command here like I tried adding the 00mine script (mode 755, just one line which says bash), then updated the initramfs, but it didn't stop and spawn a shell at any point in the boot process. cryptsetup -T1 luksOpen /dev/sda2 sda2_crypt After it dropped me to the (initramfs) prompt I entered that command (I had to change it to sda5) and I was able to unlock the drive. I was unable to mount it however. (initramfs) mount /dev/mapper/sda5_crypt /a mount: mounting /dev/mapper/sda5_crypt on /a failed: Invalid argument or add to your kernel options something like break=local-top Adding the break=local-top option did not do anything different. It may be related to the driver sd needs updating thing, but it seems to be contradicted by your observation that /dev/sda appears to be present and functional from within the busybox shell. I think the SCSI driver is working ok - I am able to unlock the volume with crypptsetup luksOpen, and head /dev/sda5 gives me some garbage, indicating that I can read the drive. One thing you *can* do easily is, boot with the break option, and from within the resulting shell, run /scripts/init-premount/udev, which will create all the devices. You can then do an ls in /dev, and see if the relevant hard drive partition (/dev/sda5, in your case) is are present -- this tests the udev step pretty directly. (initramfs) /scripts/init-premount/udev udevd[2891]: init_udevd_socket: bind failed: Address already in use error initializing the udevd socket udevd[2891]: main: error initializing the udevd socket Please bear with me, I'm asking this out of curiousity. Why did you encrypt the full root FS? The root filesystem is encrypted to make it more difficult for a local attacker to replace system binaries with backdoored versions. I am not sure what else to try at this point, all suggestions are appreciated! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Etch to 5.0.2 upgrade failed - Encrypted filesystem will not boot
On Tuesday 11 August 2009 17:41:48 line...@ruiner.halo.nu wrote: Ok I guess the system is just hosed. If no one has any more suggestions in the next couple days I will reinstall. I will never trust Debian upgrades again, at least not when encrypted filesystems are in use. Well, all I can say is that it worked for me. It's pretty clearly an initramfs problem, since it works for your other kernel. It's also very weird (as you've remarked) that you can apparently initialize the encrypted partition via luksOpen from within the initramfs, but then not mount it -- I'm assuming you checked all the obvious things, like whether or not your candidate mount point (/a in your example) existed. I have one more nontrivial suggestion -- I suggest installing the 2.6.24 etchnhalf kernel. You'll have to pull it from the etch repositories. It's possible that running a new kernel install and corresponding update-grub and so forth will either (a) work, or (b) give a more meaningful error message. Also, please understand that I mean no disrespect, but I feel compelled to remind you of some possible stupid-mistake solutions: - Does your 2.6.26 kernel have the same boot options in menu.lst as the one that works? Are they the default kopt options, so they get propagated to new kernels by update-grub? If you manually added encryption after your etch install, they might not be. - Is the menu.lst that's modified by the package manager the same one that the boot-loader is actually using? I once had a system that had somehow gotten both /grub and /boot/grub directories, both with menu.lst files in them, only one of which mattered. - Along similar lines, is update-initramfs writing its files to the correct place so they're read at boot time? That's about all I can think of. Good luck. -- A. -- Andrew Reid / rei...@bellatlantic.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Etch to 5.0.2 upgrade failed - Encrypted filesystem will not boot
On 2009-08-10 18:49, line...@ruiner.halo.nu wrote: [snip] The root filesystem is encrypted to make it more difficult for a local attacker to replace system binaries with backdoored versions. I don't think this is a valid reason for encrypting root. -- Scooty Puff, Sr The Doom-Bringer -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Etch to 5.0.2 upgrade failed - Encrypted filesystem will not boot
hmmm not sure, you could try turning of quiet mode remove the quiet from the kernel option on boot and maybe try turning on debug (add debug to the kernal options) There is no quiet mode in my kernel line. Adding the debug option didn't seem to add any additional relevant information; anothering to try is place a shell script in /etc/initramfs/scripts/local-top/ call something like 00mine and open a console with something like bash or try some command here like I tried adding the 00mine script (mode 755, just one line which says bash), then updated the initramfs, but it didn't stop and spawn a shell at any point in the boot process. cryptsetup -T1 luksOpen /dev/sda2 sda2_crypt After it dropped me to the (initramfs) prompt I entered that command (I had to change it to sda5) and I was able to unlock the drive. I was unable to mount it however. (initramfs) mount /dev/mapper/sda5_crypt /a mount: mounting /dev/mapper/sda5_crypt on /a failed: Invalid argument or add to your kernel options something like break=local-top Adding the break=local-top option did not do anything different. It may be related to the driver sd needs updating thing, but it seems to be contradicted by your observation that /dev/sda appears to be present and functional from within the busybox shell. I think the SCSI driver is working ok - I am able to unlock the volume with crypptsetup luksOpen, and head /dev/sda5 gives me some garbage, indicating that I can read the drive. One thing you *can* do easily is, boot with the break option, and from within the resulting shell, run /scripts/init-premount/udev, which will create all the devices. You can then do an ls in /dev, and see if the relevant hard drive partition (/dev/sda5, in your case) is are present -- this tests the udev step pretty directly. (initramfs) /scripts/init-premount/udev udevd[2891]: init_udevd_socket: bind failed: Address already in use error initializing the udevd socket udevd[2891]: main: error initializing the udevd socket Please bear with me, I'm asking this out of curiousity. Why did you encrypt the full root FS? The root filesystem is encrypted to make it more difficult for a local attacker to replace system binaries with backdoored versions. I am not sure what else to try at this point, all suggestions are appreciated! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Etch to 5.0.2 upgrade failed - Encrypted filesystem will not boot
On Thu, Aug 06, 2009 at 18:29 -0400, Andrew Reid wrote: On Thursday 06 August 2009 04:16:42 Siggy Brentrup wrote: Please bear with me, I'm asking this out of curiousity. Why did you encrypt the full root FS? I can understand that you want your $HOME encrypted, to a lesser degree I can follow you even with /etc, /tmp and /var, but why do you take the performance penalty on publically available stuff? I'm not the OP, but we do this at work because of policy -- we require full-disk encryption for portable systems, and the dm-crypt scheme doing everything except /boot is considered acceptable under the guidelines. I think the policy is this way partially because it's an easy line to draw, and doesn't involve a lot of guesswork. There can also be leakage out of your home directory -- applications sometimes store lists of recently-viewed documents in /var, and of course the system logs are in /var/log, plus there are dynamic entries in some config files, which might expose details of your network enviornment -- where are *your* WPA credentials cached? For the technical part: there's remote logging and you can use mount -bind to relocate directories that should be encrypted. I prefer encrypting only the confidential stuff on a by document basis. IMHO your employer's approach to security and confidentiality is easy but wrong; it follows the lines I want both, but don't bother me with the details. Recently I read a citation (sadly w/o attribution) Security is not a state, it's a process. As for your question, I think you'll find the answer in my 2nd paragraph you didn't cite here, I'll do it for you: I for my part use a single encrypted 256MB FS on a flash device that fits into my vaio's 'MagicGate'. That's plenty of room for stuff I want to keep secret [snip]. I don't use Wi-Fi with boxes that carry confidential information, always unplugging the flash before turning the Vaio's wireless switch on. That said, I'd like to carry on the discussion of this IMHO important topic but refrain from hijacking this thread. If anybody is interested, please drop me a private note at the 2nd address in my .signature. In case there's more interest than I like to see in Cc headers, I'm willing to set up a MM list devoted to security and privacy. Thanks for listening Siggy -- Please don't Cc: me when replying, I might not see either copy. bsb-at-psycho-dot-informationsanarchistik-dot-de or:bsb-at-psycho-dot-i21k-dot-de O ascii ribbon campaign - stop html mail - www.asciiribbon.org signature.asc Description: Digital signature
Re: Etch to 5.0.2 upgrade failed - Encrypted filesystem will not boot
On Thu, Aug 06, 2009 at 19:21 -0500, Manoj Srivastava wrote: On Thu, Aug 06 2009, Siggy Brentrup wrote: On Tue, Aug 04, 2009 at 18:50 -0500, line...@halo.nu wrote: Hi - I have a Debian Etch system which I recently upgraded to v5.0.2. The file system was encrypted with LUKS at install time. Please bear with me, I'm asking this out of curiousity. Why did you encrypt the full root FS? I can understand that you want your $HOME encrypted, to a lesser degree I can follow you even with /etc, /tmp and /var, but why do you take the performance penalty on publically available stuff? Because I have /etc, /var/lib/dpkg, and /usr/local; all kinds of things in /var and /tmp can be sensitive. I encrypt everything except /boot -- even swap. All this increases the work-factor fro Mallory -- now, it is somewhat hard to even figure out where each encrypted partition begins, and you can't see what exactly it is that I am running, and it makes it a little harder to inject things on my machine that will be resident in memory and steal the information. Encryption is not just about confidentiality, it has an integrity component as well. Thanks Manoj, always I'm pleased to read your insights. I assume with Mallory you are referring to the charater from http://en.wikipedia.org/wiki/Alice_and_Bob I had to search for it, but am catching up quickly I hope. Thanks Siggy -- Please don't Cc: me when replying, I might not see either copy. bsb-at-psycho-dot-informationsanarchistik-dot-de or:bsb-at-psycho-dot-i21k-dot-de O ascii ribbon campaign - stop html mail - www.asciiribbon.org signature.asc Description: Digital signature
Re: Etch to 5.0.2 upgrade failed - Encrypted filesystem will not boot
On Wednesday 05 August 2009 19:54:50 line...@ruiner.halo.nu wrote: I tried configuring fstab to use the UUID from blkid, but I had the same problem. Could the problem be that the SCSI drives are not coming up until cryptsetup has loaded? Hi again lineman (and list). Just for another data-point, I have just now finished upgrading my laptop, with the dm-crypt-encrypted hard drive, from etch to lenny. There were several minor issues with packages, but the crypto part worked fine. (Anticipating doing this myself is part of why I was following this thread...) I *do* see the Driver 'sd' needs updating message, but my system boots, so that's apparently unrelated. My /etc/fstab file doesn't use UUIDs, it lists the device-mapper names of all the devices, and it works. This shouldn't matter in any case for the root FS, it's mounted before /etc/fstab is read, and the device name is taken from the kernel args. I tried booting with the break boot option, which drops you into the busybox shell at the init-premount step, and tried to see if I could manually set up the crypto, but it's a bit complicated, and relies on environment variables which are set for the scripts, but apparently not set in the shell. One thing you *can* do easily is, boot with the break option, and from within the resulting shell, run /scripts/init-premount/udev, which will create all the devices. You can then do an ls in /dev, and see if the relevant hard drive partition (/dev/sda5, in your case) is are present -- this tests the udev step pretty directly. Hope this helps. -- A. -- Andrew Reid / rei...@bellatlantic.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Etch to 5.0.2 upgrade failed - Encrypted filesystem will not boot
On Tue, Aug 04, 2009 at 18:50 -0500, line...@halo.nu wrote: Hi - I have a Debian Etch system which I recently upgraded to v5.0.2. The file system was encrypted with LUKS at install time. Please bear with me, I'm asking this out of curiousity. Why did you encrypt the full root FS? I can understand that you want your $HOME encrypted, to a lesser degree I can follow you even with /etc, /tmp and /var, but why do you take the performance penalty on publically available stuff? I for my part use a single encrypted 256MB FS on a flash device that fits into my vaio's 'MagicGate'. That's plenty of room for stuff I want to keep secret (i.e. no warez here :). Thanks Siggy -- Please don't Cc: me when replying, I might not see either copy. bsb-at-psycho-dot-informationsanarchistik-dot-de or:bsb-at-psycho-dot-i21k-dot-de O ascii ribbon campaign - stop html mail - www.asciiribbon.org signature.asc Description: Digital signature
Re: Etch to 5.0.2 upgrade failed - Encrypted filesystem will not boot
On Thursday 06 August 2009 04:16:42 Siggy Brentrup wrote: On Tue, Aug 04, 2009 at 18:50 -0500, line...@halo.nu wrote: Hi - I have a Debian Etch system which I recently upgraded to v5.0.2. The file system was encrypted with LUKS at install time. Please bear with me, I'm asking this out of curiousity. Why did you encrypt the full root FS? I can understand that you want your $HOME encrypted, to a lesser degree I can follow you even with /etc, /tmp and /var, but why do you take the performance penalty on publically available stuff? I'm not the OP, but we do this at work because of policy -- we require full-disk encryption for portable systems, and the dm-crypt scheme doing everything except /boot is considered acceptable under the guidelines. I think the policy is this way partially because it's an easy line to draw, and doesn't involve a lot of guesswork. There can also be leakage out of your home directory -- applications sometimes store lists of recently-viewed documents in /var, and of course the system logs are in /var/log, plus there are dynamic entries in some config files, which might expose details of your network enviornment -- where are *your* WPA credentials cached? So, encrypting as much as you can meets the confidentially need in an easy-to-describe, easy-to-enforce, and relatively easy-to-implement way. -- A. -- Andrew Reid / rei...@bellatlantic.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Etch to 5.0.2 upgrade failed - Encrypted filesystem will not boot
On Thu, Aug 06 2009, Siggy Brentrup wrote: On Tue, Aug 04, 2009 at 18:50 -0500, line...@halo.nu wrote: Hi - I have a Debian Etch system which I recently upgraded to v5.0.2. The file system was encrypted with LUKS at install time. Please bear with me, I'm asking this out of curiousity. Why did you encrypt the full root FS? I can understand that you want your $HOME encrypted, to a lesser degree I can follow you even with /etc, /tmp and /var, but why do you take the performance penalty on publically available stuff? Because I have /etc, /var/lib/dpkg, and /usr/local; all kinds of things in /var and /tmp can be sensitive. I encrypt everything except /boot -- even swap. All this increases the work-factor fro Mallory -- now, it is somewhat hard to even figure out where each encrypted partition begins, and you can't see what exactly it is that I am running, and it makes it a little harder to inject things on my machine that will be resident in memory and steal the information. Encryption is not just about confidentiality, it has an integrity component as well. manoj -- MIT: The Georgia Tech of the North Manoj Srivastava sriva...@acm.org http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Etch to 5.0.2 upgrade failed - Encrypted filesystem will not boot
On Tue, Aug 04, 2009 at 06:50:56PM -0500, line...@halo.nu wrote: Hi - I have a Debian Etch system which I recently upgraded to v5.0.2. The file system was encrypted with LUKS at install time. The upgrade appeared to go well, however when I boot into the new system, it gives the following error: Volume group hostname not found cryptsetup: Source device /dev/sda5 not found Begin: Waiting for root file system This may be unrelated, but it also says: Driver 'sd' needs updating - Please use bus_type methods. After 5 minutes it says: Gave up wating for root device And drops to a busybox shell. do you have your root fs in fstab by LABEL or UUID if so I reported a bug report against cryptsetup. change to a dev like /dev/mapper/device and then run update-initramfs -u The /dev/sda devices seem to come up ok, and sda is the same device name that it had before. When I select the old 2.6.18 kernel in the GRUB menu, it works fine and I can access my data. Every time I select the newer 2.6.26 kernel, I get this error. How can I fix this issue? Thanks! -- I can't tell you what it's like to be in Europe, for example, to be talking about the greatness of America. But the true greatness of America are the people. - George W. Bush 07/02/2001 Washington, DC signature.asc Description: Digital signature
Re: Etch to 5.0.2 upgrade failed - Encrypted filesystem will not boot
I tried configuring fstab to use the UUID from blkid, but I had the same problem. Could the problem be that the SCSI drives are not coming up until cryptsetup has loaded? Here is some info on my configuration: t...@magnesium:/etc/initramfs-tools/conf.d$ cat resume RESUME=/dev/mapper/magnesium-swap_1 t...@magnesium:/etc/initramfs-tools/conf.d$ cat /etc/fstab # /etc/fstab: static file system information. # # file system mount point type options dump pass proc/proc procdefaults0 0 /dev/mapper/magnesium-root / ext3defaults,errors=remount-ro 0 1 /dev/sda1 /boot ext3defaults0 2 /dev/mapper/magnesium-swap_1 noneswapsw 0 0 t...@magnesium:/etc$ cat /etc/crypttab sda5_crypt /dev/sda5 none luks t...@magnesium:/etc$ ls -l /dev/mapper/ crw-rw 1 root root 10, 63 2009-08-05 13:45 control brw-rw 1 root disk 254, 1 2009-08-05 13:47 magnesium-root brw-rw 1 root disk 254, 2 2009-08-05 13:47 magnesium-swap_1 brw-rw 1 root disk 254, 0 2009-08-05 13:47 sda5_crypt t...@magnesium:/etc$ sudo update-initramfs -u update-initramfs: Generating /boot/initrd.img-2.6.26-2-686 On Wed, Aug 05, 2009 at 04:18:47PM +1000, Alex Samad wrote: do you have your root fs in fstab by LABEL or UUID if so I reported a bug report against cryptsetup. change to a dev like /dev/mapper/device and then run update-initramfs -u On Tue, Aug 04, 2009 at 06:50:56PM -0500, line...@halo.nu wrote: Hi - I have a Debian Etch system which I recently upgraded to v5.0.2. The file system was encrypted with LUKS at install time. The upgrade appeared to go well, however when I boot into the new system, it gives the following error: Volume group hostname not found cryptsetup: Source device /dev/sda5 not found Begin: Waiting for root file system This may be unrelated, but it also says: Driver 'sd' needs updating - Please use bus_type methods. After 5 minutes it says: Gave up wating for root device And drops to a busybox shell. The /dev/sda devices seem to come up ok, and sda is the same device name that it had before. When I select the old 2.6.18 kernel in the GRUB menu, it works fine and I can access my data. Every time I select the newer 2.6.26 kernel, I get this error. How can I fix this issue? Thanks! -- I can't tell you what it's like to be in Europe, for example, to be talking about the greatness of America. But the true greatness of America are the people. - George W. Bush 07/02/2001 Washington, DC -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Etch to 5.0.2 upgrade failed - Encrypted filesystem will not boot
On Wed, Aug 05, 2009 at 06:54:50PM -0500, line...@ruiner.halo.nu wrote: I tried configuring fstab to use the UUID from blkid, but I had the same problem. Could the problem be that the SCSI drives are not coming up until cryptsetup has loaded? hmmm not sure, you could try turning of quiet mode remove the quiet from the kernel option on boot and maybe try turning on debug (add debug to the kernal options) anothering to try is place a shell script in /etc/initramfs/scripts/local-top/ call something like 00mine and open a console with something like bash or try some command here like cryptsetup -T1 luksOpen /dev/sda2 sda2_crypt you will need to update you initramfs for the above or add to your kernel options something like break=local-top if you are using grub you can edit the kernel options at boot time Alex Here is some info on my configuration: t...@magnesium:/etc/initramfs-tools/conf.d$ cat resume RESUME=/dev/mapper/magnesium-swap_1 t...@magnesium:/etc/initramfs-tools/conf.d$ cat /etc/fstab # /etc/fstab: static file system information. # # file system mount point type options dump pass proc/proc procdefaults0 0 /dev/mapper/magnesium-root / ext3defaults,errors=remount-ro 0 1 /dev/sda1 /boot ext3defaults0 2 /dev/mapper/magnesium-swap_1 noneswapsw 0 0 t...@magnesium:/etc$ cat /etc/crypttab sda5_crypt /dev/sda5 none luks t...@magnesium:/etc$ ls -l /dev/mapper/ crw-rw 1 root root 10, 63 2009-08-05 13:45 control brw-rw 1 root disk 254, 1 2009-08-05 13:47 magnesium-root brw-rw 1 root disk 254, 2 2009-08-05 13:47 magnesium-swap_1 brw-rw 1 root disk 254, 0 2009-08-05 13:47 sda5_crypt t...@magnesium:/etc$ sudo update-initramfs -u update-initramfs: Generating /boot/initrd.img-2.6.26-2-686 On Wed, Aug 05, 2009 at 04:18:47PM +1000, Alex Samad wrote: do you have your root fs in fstab by LABEL or UUID if so I reported a bug report against cryptsetup. change to a dev like /dev/mapper/device and then run update-initramfs -u On Tue, Aug 04, 2009 at 06:50:56PM -0500, line...@halo.nu wrote: Hi - I have a Debian Etch system which I recently upgraded to v5.0.2. The file system was encrypted with LUKS at install time. The upgrade appeared to go well, however when I boot into the new system, it gives the following error: Volume group hostname not found cryptsetup: Source device /dev/sda5 not found Begin: Waiting for root file system This may be unrelated, but it also says: Driver 'sd' needs updating - Please use bus_type methods. After 5 minutes it says: Gave up wating for root device And drops to a busybox shell. The /dev/sda devices seem to come up ok, and sda is the same device name that it had before. When I select the old 2.6.18 kernel in the GRUB menu, it works fine and I can access my data. Every time I select the newer 2.6.26 kernel, I get this error. How can I fix this issue? Thanks! -- I can't tell you what it's like to be in Europe, for example, to be talking about the greatness of America. But the true greatness of America are the people. - George W. Bush 07/02/2001 Washington, DC -- Oftentimes, we live in a processed world -- you know, people focus on the process and not results. - George W. Bush 05/29/2003 Washington, DC signature.asc Description: Digital signature
Re: Etch to 5.0.2 upgrade failed - Encrypted filesystem will not boot
On Wednesday 05 August 2009 19:54:50 line...@ruiner.halo.nu wrote: I tried configuring fstab to use the UUID from blkid, but I had the same problem. Could the problem be that the SCSI drives are not coming up until cryptsetup has loaded? This could happen if the new kernel's initramfs doesn't have the right modules, or if the module name has changed. It may be related to the driver sd needs updating thing, but it seems to be contradicted by your observation that /dev/sda appears to be present and functional from within the busybox shell. In principle, you should be able to run the commands to set up the root FS from within the shell, have you tried that? You might get a more informative error message. -- A. -- Andrew Reid / rei...@bellatlantic.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Etch to 5.0.2 upgrade failed - Encrypted filesystem will not boot
Hi - I have a Debian Etch system which I recently upgraded to v5.0.2. The file system was encrypted with LUKS at install time. The upgrade appeared to go well, however when I boot into the new system, it gives the following error: Volume group hostname not found cryptsetup: Source device /dev/sda5 not found Begin: Waiting for root file system This may be unrelated, but it also says: Driver 'sd' needs updating - Please use bus_type methods. After 5 minutes it says: Gave up wating for root device And drops to a busybox shell. The /dev/sda devices seem to come up ok, and sda is the same device name that it had before. When I select the old 2.6.18 kernel in the GRUB menu, it works fine and I can access my data. Every time I select the newer 2.6.26 kernel, I get this error. How can I fix this issue? Thanks! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
