Cannot Deinstall a Debian Package

Having a failure that may be because grub2 doesn't BTRFS. /boot is ext3 and / is BTRFS.

# dpkg -r linux-image-2.6.32-5-amd64
(Reading database ... 136673 files and directories currently installed.)
Removing linux-image-2.6.32-5-amd64 ...
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 2.6.32-5-amd64 /boot/vmlinuz-2.6.32-5-amd64
/usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
run-parts: /etc/kernel/postrm.d/zz-update-grub exited with return code 1
Failed to process /etc/kernel/postrm.d at /var/lib/dpkg/info/linux-image-2.6.32-5-amd64.postrm line 234.
dpkg: error processing linux-image-2.6.32-5-amd64 (--remove):
 subprocess installed post-removal script returned error exit status 1
Errors were encountered while processing:
 linux-image-2.6.32-5-amd64

I can't install or remove packages, of do my dist-upgrades. What gives?

ext3 and / is BTRFS.

Does Debian (or whatever distro you use) support BTRFS "/"? If yes, you should ask them.
If no, then you should've already known that there's a risk when using unsupported filesystem.

d.)

d64 /boot/vmlinuz-2.6.32-5-amd64

64 /boot/vmlinuz-2.6.32-5-amd64

ted?).

e 1

age-2.6.32-5-amd64.postrm line 234.

s 1

Looks like grub problem. I know that Ubuntu Natty's grub-pc (grub2) work just fine, so you might be able to fix it by upgrading to newer grub/grub-pc (perhaps from Debian-unstable).

--=20
=46ajar
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

What do you mean 'does Debian support BTRFS'? The kernel supports it. And why would they know more about BTRFS than you?

My whole system is installed over BTRFS. If this is non-functional in any OS there should be a warning indicating it is non-functional.

I would be happy to upgrade grub, but the package management system is jammed because of this.

On Tuesday, May 03, 2011 05:20:49 PM [email protected] wrote:
<-snip->

<-snip->

You should Re-read the error you posted. The package management system goes bonkers, because

Chuck Burns
The Southern Libertarian - owner
http://thesouthernlibertarian.com/

I know what the error says; we've established that / is in fact mounted. The system boots and runs, but grub doesn't understand it. My only answer is that grub-probe does not understand BTRFS.

The question is what to do about this. I have three major systems committed to this filesystem. Can you not see how this is an emergency?

How is re-reading the error supposed to help anything? Or was your intention to help?

You should upgrade grub, manually (ie, do not use the package manager) and you need to contact your distribution to find out how to do that.

Chuck Burns
The Southern Libertarian - owner
http://thesouthernlibertarian.com/

The text for btrfs in the kernel configuration says:

Btrfs is highly experimental, and THE DISK FORMAT IS NOT YET FINALIZED. You should say N here unless you are interested in testing Btrfs with non-critical data.

The distros may well enable it for such people but you also have a duty of care to ensure that you understand the filesystems that you are choosing to use. Nevertheless this is not a bug in btrfs at all.

You need to report the bug in grub-probe (part of the grub-common package I believe) to Debian. There was a similar bug reported here:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540786

But that should have been fixed in 1.98+20100602-1 and the current version in Squeeze is 1.98+20100804-14.

Best of luck,
Chris

 Chris Samuel  :  http://www.csamuel.org/  :  Melbourne, VIC

it.

Just because you can use something doesn't mean it's supported by the d= istro.

=46or example, RHEL6 marks btrfs as "technology preview", in other word= s
"you can use it to try out new features but don't complain if anything's broken". There should be a similar warning in Debian.

In your case, the "broken" part is the integration with other distro components (e.g grub)

A good distro would normally test all components included, and mark them as supported or not. If it's not supported, then you should expect lower level of funcionality or integration compared to supported components. Some signs of unsupported components:
- it's marked as "technology preview" (like in RHEL6 case)
- kernel supports it, but the distro installer does not let you use it by default (needs some manual setup of installer flags)
- it's on a different repository (like Ubuntu's universe/multiverse)
- it's not listed as supported component

Sometimes when a distro includes a technology preview, they'd also include known issues, caveats, or workaround needed to make it work. In Ubuntu maverick (I suspect it's also the same in Debian) you need to manually update to newer version of grub-pc.

in any OS there should be a warning indicating it is non-functional.

There is, though the location and form may be distributed all over the = place.

There's a warning in the kernel (see Chris's post)

Debian install manual
(http://www.debian.org/releases/stable/amd64/ch06s03.html.en#di-partiti=
on)
also doesn't list btrfs as supported partition type, in other words it's unsupported.

s jammed because of this.

You can download grub-related packages (should be grub and grub-pc, possibly from Debian unstable) and install it manually using dpkg.

You might also need to temporarily rename /usr/sbin/update-grub manually elsewhere and replace it with symlink to /bin/true, or move /etc/kernel/postinst.d/zz-update-grub out of the way (just to enable update process run correctly).

--=20
=46ajar
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

[email protected] wrote (ao):

Put an exit on top of /etc/kernel/postrm.d/zz-update-grub and try again.

Install grub-pc 1.99~rc1-13 from Sid.

http://packages.debian.org/changelogs/pool/main/g/grub2/grub2_1.99~rc1-13/changelog

Sander

Humilis IT Services and Solutions
http://www.humilis.net

First I put an exit right after #! /bin/sh and it failed. Then I moved /etc/kernel/postrm.d/zz-update-grub to / and it still failed.

Grub is not running as a daemon, so I shouldn't have to reboot for the new version to take effect. And frankly at the moment I'm afraid to reboot, with only grub-common installed.

# dpkg -i /var/cache/apt/archives/grub-common_1.99~rc1-13_amd64.deb 
(Reading database ... 136689 files and directories currently installed.)
Preparing to replace grub-common 1.98+20100804-14 (using .../grub-common_1.99~rc1-13_amd64.deb) ...
Unpacking replacement grub-common ...
Setting up grub-common (1.99~rc1-13) ...
Installing new version of config file /etc/grub.d/10_linux ...
Installing new version of config file /etc/grub.d/30_os-prober ...
Installing new version of config file /etc/grub.d/00_header ...
Installing new version of config file /etc/grub.d/20_linux_xen ...
Processing triggers for install-info ...
Processing triggers for man-db ...

# dpkg -i /var/cache/apt/archives/grub-pc_1.99~rc1-13_amd64.deb 
(Reading database ... 136703 files and directories currently installed.)
Preparing to replace grub-pc 1.99~rc1-13 (using .../grub-pc_1.99~rc1-13_amd64.deb) ...
Unpacking replacement grub-pc ...
Setting up grub-pc (1.99~rc1-13) ...
grub-probe: error: cannot stat `/dev/root'.
Installation finished. No error reported.
/usr/sbin/grub-probe: error: cannot stat `/dev/root'.
dpkg: error processing grub-pc (--install):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for man-db ...
Errors were encountered while processing:
 grub-pc

Anyone have a suggestion?

Also on another machine set up similarly, I now cannot mkdir. It says 'no space left on device'. df says:

# df /dev/sdb
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdb             3907029168 2658010524 1246486516  69% /home

sdb and sdc are one btrfs 'raid' volume. What could be wrong?

t says 'no space left on device'. =C2=A0df says:

=C2=A0Used Available Use% Mounted on

524 1246486516 =C2=A069% /home

Which kernel version (uname -a), and what's the output of "btrfs fi df /home" and "sudo btrfs fi show /dev/sdb"?
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

ain.

Then I moved /etc/kernel/postrm.d/zz-update-grub to / and it still fail= ed.

e new version to take effect. =C2=A0And frankly at the moment I'm afrai= d to reboot, with only grub-common installed.

d.)

mon_1.99~rc1-13_amd64.deb) ...

d.)

13_amd64.deb) ...

it status 1

" in

ml

You'll need to contact somebody more familiar with debian, as this isn't really a btrfs issue.

Yes, btrfs is the obvious cause, but it's grub's handling of it that is the problem, and dpkg's handling of grub's failure that is really blocking you.

This is what it meant by "does debian support btrfs?". It's not a question of whether btrfs is in debian's kernel, but whether all the pieces of debian which are directly or indirectly affected by btrfs are known to work right, and whether they're currently willing to spend effort on these issues.

If they're not currently providing that level of support, then it's completely up to you to have a good understanding of how the rest of debian is put together so that you yourself can make things works.

As was mentioned previously, there is an updated grub package, so your main objective is to find out from debian how to disable or override the failing package long enough to install the replacement. --
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

I was afraid of this finger-pointing.

Of course no one at Debian is going to know how to fix BTRFS jamming the package management system. That's ridiculous.

It's starting to look like BTRFS is just busted in Debian, and I'll have to reinstall everything over a different filesystem. I hate to give up btrfs raid and snapshotting, but these failures are just unlivable. Is Oracle aware of this? I'll have to warn others in the various forums that BTRFS breaks Debian, because no one warned me. This is unlivable, not to mention unbelievable.

Excerpts from CACook's message of 2011-05-05 15:50:02 -0400:

We're not finger pointing, but we also don't maintain the script that is failing. I'm happy to patch up bugs in the FS (or point you to newer kernels that have them fixed) but at this point we don't have enough info to say if it is an FS problem or a debian package problem.

Perhaps if you ran it under strace?

Other distros don't have problems with btrfs on /, so somehow this is specific to debian's setup.

-chris

Here is the relevant section of strace:

---------------------------------------------------------------------------------------------
chmod("/etc/grub.d/05_debian_theme.dpkg-new", 0755) = 0 unlink("/etc/grub.d/05_debian_theme.dpkg-new") = 0 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0 write(6, "2011-05-05 13:21:57 status unpac"..., 56) = 56 write(4, "Package: grub-pc\nStatus: install"..., 1795) = 1795

ftruncate(4, 1795)                      = 0
fsync(4)                                = 0
close(4)                                = 0
munmap(0x7f32f8490000, 4096)            = 0

rename("/var/lib/dpkg/updates/tmp.i", "/var/lib/dpkg/updates/0011") = 0 open("/var/lib/dpkg/updates/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
fsync(4) = 0
close(4) = 0
open("/var/lib/dpkg/updates/tmp.i", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
fcntl(4, F_GETFD) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f32f8490000 write(4, "#padding\n#padding\n#padding\n#padd"..., 4096) = 4096
write(4, "padding\n#padding\n#padding\n#paddi"..., 512) = 512
lseek(4, 0, SEEK_SET) = 0
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2819, ...}) = 0 write(6, "2011-05-05 13:21:58 status half-"..., 63) = 63
write(4, "Package: grub-pc\nStatus: install"..., 1802) = 1802

ftruncate(4, 1802)                      = 0
fsync(4)                                = 0
close(4)                                = 0
munmap(0x7f32f8490000, 4096)            = 0

rename("/var/lib/dpkg/updates/tmp.i", "/var/lib/dpkg/updates/0012") = 0 open("/var/lib/dpkg/updates/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
fsync(4) = 0
close(4) = 0
open("/var/lib/dpkg/updates/tmp.i", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
fcntl(4, F_GETFD) = 0
fcntl(4, F_SETFD, FD_CLOEXEC) = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f32f8490000 write(4, "#padding\n#padding\n#padding\n#padd"..., 4096) = 4096
write(4, "padding\n#padding\n#padding\n#paddi"..., 512) = 512
lseek(4, 0, SEEK_SET) = 0
stat("/var/lib/dpkg/info/grub-pc.postinst", {st_mode=S_IFREG|0755, st_size=23003, ...}) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f32f8475a70) = 29950 rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f32f7d281e0}, {SIG_DFL, [], SA_RESTORER, 0x7f32f7d281e0}, 8) = 0 rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7f32f7d281e0}, {SIG_DFL, [], SA_RESTORER, 0x7f32f7d281e0}, 8) = 0 wait4(29950, grub-probe: error: cannot stat `/dev/root'.
^C <unfinished ...>
---------------------------------------------------------------------------------------------

/var/lib/dpkg/info/grub-pc.postinst is attached. I can't make sense of it.

BTW, I fixed the 'no space left on device' on the other machine with a btrfs balance. No one seems to know this, but even though df reports that 64% of the disk array is used, apparently one of the disks did get full somehow and was preventing even a simple mkdir. But a balance fixed it.

I thought balancing was supposed to be automatic in BTRFS?

Is defrag not automatic?

a btrfs balance. =C2=A0No one seems to know this, but even though df re= ports that 64% of the disk array is used, apparently one of the disks d= id get full somehow and was preventing even a simple mkdir. =C2=A0But a=
balance fixed it.

Could you include the information I asked for previously? (Kernel version, output of btrfs fi df and btrfs fi show)

Defrag is not the same as balancing, and neither is quite the same as the balancing of the internal b-trees that make up the filesystem. Either way, this sounds like a bug that was fixed a few releases ago, but it's hard to say if that's the case without the requested information.

Also, please place your replies below the original text, not above it.
That's common practice on development mailing lists, and makes
following the conversation much easier for others.
http://www.catb.org/~esr/faqs/smart-questions.html may be a useful read as well.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Kernel 2.6.37-2

# btrfs fi df /home
Data, RAID0: total=2.61TB, used=2.47TB
Data: total=8.00MB, used=8.00MB
System, RAID1: total=8.00MB, used=196.00KB
System: total=4.00MB, used=0.00
Metadata, RAID1: total=6.88GB, used=4.64GB
Metadata: total=8.00MB, used=0.00
# df /dev/sdb
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdb             3907029168 2659716272 1242565920  69% /home
# df /dev/sdc
Filesystem           1K-blocks      Used Available Use% Mounted on
udev                   1895384       268   1895116   1% /dev
(this doesn't make any sense)
# btrfs fi show
failed to read /dev/sdg
failed to read /dev/sdf
failed to read /dev/sde
failed to read /dev/sdd
failed to read /dev/sr0
Label: none  uuid: 85537aa8-30dc-4f87-ac55-6c8344304184
        Total devices 2 FS bytes used 2.47TB
        devid    1 size 1.82TB used 1.31TB path /dev/sdb
        devid    2 size 1.82TB used 1.31TB path /dev/sdc
Btrfs Btrfs v0.19

I know they're not the same. But I am asking:

I thought balancing was supposed to be automatic in BTRFS?

Is defrag not automatic?

No idea what 'balancing of the internal b-trees' is.

nel

=C2=A0Used Available Use% Mounted on

272 1242565920 =C2=A069% /home

=C2=A0Used Available Use% Mounted on

895384 =C2=A0 =C2=A0 =C2=A0 268 =C2=A0 1895116 =C2=A0 1% /dev

TB path /dev/sdb

TB path /dev/sdc

s

=46air enough.

Btrfs works mostly like ext in this sense: the way it reads and writes data generally avoids fragmentation. There are some issues in this area still, but they're not the cause of no-space problems typically, rather they tend to cause performance loss.

A "balance" operation is more about balancing the space use of the large allocations btrfs makes from its pool of free disk-space to one of the block groups that holds data or metadata. "mkdir" failing while you still have lots of disk space free would typically mean something along the lines of: all the free disk space has been allocated to either the metadata or data block groups, and the metadata block groups are full. This sort of behaviour has mostly gone away in the last couple releases, although it would take a balance operation (as you performed) to get everything working right.

How old was the filesystem? It might just have been lingering problems from an older kernel, which would be cleared up entirely by the balance you just ran.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

I specifically set up the filesystem with the Live CD of the M- release of Ubuntu, so as to be using a much newer kernel than Debian's. This was in December. Then I used the Debian net install CD in Expert mode to install the OS.

I took all pains to be using the newest OS available to set up the disks, so as to take advantage of WD's Advanced Format, and the newest improvements to BTRFS. But the balance is still going after more than an hour.

I am seeing drastically conflicting info from df and btrfs filesystem df, which is inexplicable.

y

se of Ubuntu, so as to be using a much newer kernel than Debian's. =A0T= his was in December. =A0Then I used the Debian net install CD in Expert=
mode to install the OS.

sks, so as to take advantage of WD's Advanced Format, and the newest im= provements to BTRFS. =A0But the balance is still going after more than = an hour.

df, which is inexplicable.

https://btrfs.wiki.kernel.org/index.php/FAQ#Why_does_df_show_incorrect_=
free_space_for_my_RAID_volume.3F

The above link may help explain why df and btrfs fi df differ. --
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Hallo, Cacook,

Du meintest am 05.05.11:

Where's the problem? Balancing 4 TByte can need some hours. Maybe it needs more than 1 day.

It was mentioned again some (few) weeks ago.

Take a look at the last lines of "dmesg", every hour. Then you can estimate how long you have to wait.

Viele Gruesse!
Helmut

Chris Mason wrote (ao):

I believe this is fixed in Debian testing/unstable:
http://packages.debian.org/changelogs/pool/main/g/grub2/grub2_1.99~rc1-13/changelog

"grub2 (1.99~20110106-1) experimental; urgency=low

* New Bazaar snapshot.
- Check that named RAID array devices exist before using them (closes:
#606035).
- Clear terminfo output on initialisation (closes: #569678).
- Fix grub-probe when btrfs is on / without a separate /boot.
"

Sander

Humilis IT Services and Solutions
http://www.humilis.net

the package management system. =C2=A0That's ridiculous.

I took the liberty of asking #debian, and they've requested that you file a bug in their bug tracker. They've also suggested that you might be able to short-circuit the faulty script in their kernel package via an "exit 0", or even replace the faulty grub-probe by manually extracting the newer version of the package.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

I tried to install Debian's reportbug, but of course I can't. And assembling the info they need for email reporting will take me a half day of analysis. Part of the problem here is I am trying desperately to make a living in another line of business, and I don't have time for any of these problems.

I don't know how to manually extract a package. I guess it's done with dpkg, but that will take more time for me to figure out. I've lost half of today already on this problem.

dpkg --fsys-tarfile foo.deb | tar -C / -tf -

change -t to -x to actually extract

I was expecting this to extract into the local directory, although it seems to have extracted into the final destinations. Can't be sure. grub-setup -V gives the new version.

I don't see the distinction. It does seem to have extracted.

seems to have extracted into the final destinations. =C2=A0Can't be su=
re. =C2=A0grub-setup -V gives the new version.

tar -t just lists the contents, -x actually does an extract.

It's plausible that the update you attempted before did actually unpack the files to their locations, and only failed to run the post-install scripts.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

ou

nd assembling the info they need for email reporting will take me a hal= f day of analysis. =C2=A0Part of the problem here is I am trying desper= ately to make a living in another line of business, and I don't have ti= me for any of these problems.

ne with dpkg, but that will take more time for me to figure out. =C2=A0= I've lost half of today already on this problem.

Okay, but do you see how your reaction hasn't endeared yourself to the people you're depending on to fix your problems for free? I'll note that this isn't the first time you've run into troubles with various raid systems, and you were even warned last december not to switch to btrfs as it wasn't mature enough for an end-user (even lacking a recovering fsck tool, which is still under development).

In your position, you should be using ext4, with no raid, with a solid system of backups that you can recover from quickly and easily. Not experimenting with the latest shiny developments: that's something you do if you can afford to spend a few days on a regular basis fixing the latest exciting quirk. And when you run into problems, respectfully following the instructions given to you, including taking the advice of those who do this for a living, as opposed to issuing threats to besmirch a tool that wasn't ever marketed as being ready to use for the average joe who doesn't want to spend hours dealing with it.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

[email protected] wrote (ao):

Btrfs in Debian is just fine. I run btrfs on all my x86 systems with only /, no separate /boot. On ARM one needs a /boot as u-boot only understands ext2.

If you start over, you need to install Debian Sid (unstable), which contains the latest grub and newest kernel. After installation, just edit your sources.list and replace 'sid' with 'squeeze' (current stable).

But for now, lets just fix your system. See my other post.

Btw, just found out the hard way that grub doesn't support btrfs lzo compression :-)

Sander

Humilis IT Services and Solutions
http://www.humilis.net

[email protected] wrote (ao):

Can you do:

echo "true" > /var/lib/dpkg/info/grub-installer.postinst

and try again?

Sander

Humilis IT Services and Solutions
http://www.humilis.net

At some point somehow grup-pc apparently got installed, even with the script failure. So I tried my dist-upgrade again, and seems to have completed almost 400 packages, but three still fail:
Errors were encountered while processing:
linux-image-2.6.38-2-amd64
grub-pc
linux-image-2.6-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

I can't reboot at this point, as on this machine I started a 'balance' through ssh on another machine, and it's been running for over 12 hours. It does not respond to ^C and I'm afraid to reboot with it running.

[email protected] wrote (ao):

Can you post the error?

Sander

Humilis IT Services and Solutions
http://www.humilis.net

# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
3 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? 
Setting up linux-image-2.6.38-2-amd64 (2.6.38-3) ...
Running depmod.
Running update-initramfs.
update-initramfs: Generating /boot/initrd.img-2.6.38-2-amd64
initrd.img(/boot/initrd.img-2.6.38-2-amd64
) points to /boot/initrd.img-2.6.38-2-amd64
 (/boot/initrd.img-2.6.38-2-amd64) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.38-2-amd64.postinst line 348, <STDIN> line 7.
vmlinuz(/boot/vmlinuz-2.6.38-2-amd64
) points to /boot/vmlinuz-2.6.38-2-amd64
 (/boot/vmlinuz-2.6.38-2-amd64) -- doing nothing at /var/lib/dpkg/info/linux-image-2.6.38-2-amd64.postinst line 348, <STDIN> line 7.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/dkms 2.6.38-2-amd64 /boot/vmlinuz-2.6.38-2-amd64
dkms: running auto installation service for kernel 2.6.38-2-amd64:
      vboxhost (3.2.12)...failed.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.38-2-amd64 /boot/vmlinuz-2.6.38-2-amd64
run-parts: executing /etc/kernel/postinst.d/pm-utils 2.6.38-2-amd64 /boot/vmlinuz-2.6.38-2-amd64
run-parts: executing /etc/kernel/postinst.d/update-notifier 2.6.38-2-amd64 /boot/vmlinuz-2.6.38-2-amd64
run-parts: executing /etc/kernel/postinst.d/zz-update-grub 2.6.38-2-amd64 /boot/vmlinuz-2.6.38-2-amd64
/usr/sbin/grub-probe: error: cannot stat `/dev/root'.
run-parts: /etc/kernel/postinst.d/zz-update-grub exited with return code 1
Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-2.6.38-2-amd64.postinst line 801, <STDIN> line 7.
dpkg: error processing linux-image-2.6.38-2-amd64 (--configure):
 subprocess installed post-installation script returned error exit status 9
configured to not write apport reports
                                      Setting up grub-pc (1.99~rc1-13) ...
grub-probe: error: cannot stat `/dev/root'.
Installation finished. No error reported.
/usr/sbin/grub-probe: error: cannot stat `/dev/root'.
dpkg: error processing grub-pc (--configure):
 subprocess installed post-installation script returned error exit status 1
configured to not write apport reports
                                      dpkg: dependency problems prevent configuration of linux-image-2.6-amd64:
 linux-image-2.6-amd64 depends on linux-image-2.6.38-2-amd64; however:
  Package linux-image-2.6.38-2-amd64 is not configured yet.
dpkg: error processing linux-image-2.6-amd64 (--configure):
 dependency problems - leaving unconfigured
configured to not write apport reports
                                      Errors were encountered while processing:
 linux-image-2.6.38-2-amd64
 grub-pc
 linux-image-2.6-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

[email protected] wrote (ao):

Can you try:

dpkg -i /var/cache/apt/archives/grub-pc_1.99~rc1-13_amd64.deb apt-get dist-upgrade

If that (second step) doesn't work:

echo "true" > /var/lib/dpkg/info/grub-installer.postinst apt-get dist-upgrade

grub-install /dev/sda
update-grub

Sander

Humilis IT Services and Solutions
http://www.humilis.net

Same old problem.

# dpkg -i /var/cache/apt/archives/grub-pc_1.99~rc1-13_amd64.deb
(Reading database ... 135273 files and directories currently installed.)
Preparing to replace grub-pc 1.99~rc1-13 (using .../grub-pc_1.99~rc1-13_amd64.deb) ...
Unpacking replacement grub-pc ...
Setting up grub-pc (1.99~rc1-13) ...
grub-probe: error: cannot stat `/dev/root'.
Installation finished. No error reported.
/usr/sbin/grub-probe: error: cannot stat `/dev/root'.
dpkg: error processing grub-pc (--install):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for man-db ...
Errors were encountered while processing:
 grub-pc
#

# echo "true" > /var/lib/dpkg/info/grub-installer.postinst
# dpkg -i /var/cache/apt/archives/grub-pc_1.99~rc1-13_amd64.deb
(Reading database ... 135273 files and directories currently installed.)
Preparing to replace grub-pc 1.99~rc1-13 (using .../grub-pc_1.99~rc1-13_amd64.deb) ...
Unpacking replacement grub-pc ...
Setting up grub-pc (1.99~rc1-13) ...
grub-probe: error: cannot stat `/dev/root'.
Installation finished. No error reported.
/usr/sbin/grub-probe: error: cannot stat `/dev/root'.
dpkg: error processing grub-pc (--install):
 subprocess installed post-installation script returned error exit status 1
Processing triggers for man-db ...
Errors were encountered while processing:
 grub-pc

# which update-grub
/usr/sbin/update-grub
# /usr/sbin/update-grub -v
grub-mkconfig (GRUB) 1.99~rc1-13

Apparently 1.99~rc1-13 is installed and synaptic confirms this, despite the script failure, although every .mod file in /usr/lib/grub is in the i386-pc directory. I'm running 64bit Debian Testing with kernel 2.6.37-2.

[email protected] wrote (ao):

Hm. Just do cp /bin/true /usr/sbin/grub-probe

Sander

Humilis IT Services and Solutions
http://www.humilis.net

Yikes, it came up with an ncurses screen saying:

GRUB failed to install to the following devices: =

              =E2=94=82  =20
  =E2=94=82                                                            =
                          =E2=94=82  =20
  =E2=94=82 /dev/sda                                                   =
                          =E2=94=82  =20
  =E2=94=82                                                            =
                          =E2=94=82  =20
  =E2=94=82 Do you want to continue anyway? If you do, your computer ma=
y not start up properly.  =E2=94=82  =20
  =E2=94=82                                                            =
                          =E2=94=82  =20
  =E2=94=82 Writing GRUB to boot device failed - continue?             =
                          =E2=94=82  =20
  =E2=94=82                                                            =
                          =E2=94=82  =20
  =E2=94=82                        <Yes>                           <No>=
                          =E2=94=82  =20

=E2=94=82 =
=20

Say No and another ncurses screen saying:
The grub-pc package is being upgraded. This menu allows you to select w=
hich devices =E2=94=82 =20
=E2=94=82 you'd like grub-install to be automatically run for, if any.=

                           =E2=94=82 =20
 =E2=94=82                                                             =
                           =E2=94=82 =20

=E2=94=82 Running grub-install automatically is recommended in most si=
tuations, to prevent the =E2=94=82 =20
=E2=94=82 installed GRUB core image from getting out of sync with GRUB=
modules or grub.cfg. =E2=94=82 =20
=E2=94=82 =

                           =E2=94=82 =20
 =E2=94=82 If you're unsure which drive is designated as boot drive by =
your BIOS, it is often a   =E2=94=82 =20
 =E2=94=82 good idea to install GRUB to all of them.                   =
                           =E2=94=82 =20
 =E2=94=82                                                             =
                           =E2=94=82 =20

=E2=94=82 Note: it is possible to install GRUB to partition boot recor=
ds as well, and some =E2=94=82 =20
=E2=94=82 appropriate partitions are offered here. However, this force=
s GRUB to use the =E2=94=82 =20
=E2=94=82 blocklist mechanism, which makes it less reliable, and there=
fore is not recommended. =E2=94=82 =20
=E2=94=82 =

                           =E2=94=82 =20
 =E2=94=82 GRUB install devices:                                       =
                           =E2=94=82 =20
 =E2=94=82                                                             =
                           =E2=94=82 =20
 =E2=94=82    [*] /dev/sda (750156 MB; WDC_WD7500BPKT-00PK4T0)         =
                           =E2=94=82 =20
 =E2=94=82                                                             =
                           =E2=94=82 =20
 =E2=94=82                                                             =
                           =E2=94=82 =20

=E2=94=82 <Ok>=20

So I canceled out of it, not knowing WTH. I don't understand why the n= ewer grub still doesn't understand BTRFS?

# cp /bin/true /usr/sbin/grub-probe
# dpkg -i /var/cache/apt/archives/grub-pc_1.99~rc1-13_amd64.deb
(Reading database ... 135273 files and directories currently installed.=
)
Preparing to replace grub-pc 1.99~rc1-13 (using .../grub-pc_1.99~rc1-13=
_amd64.deb) ...
Unpacking replacement grub-pc ...
Setting up grub-pc (1.99~rc1-13) ...
Auto-detection of a filesystem of  failed.
Please report this together with the output of "/usr/sbin/grub-probe --=
device-map=3D"/boot/grub/device.map" --target=3Dfs -v /boot/grub" to <b=
[email protected]>
^[Auto-detection of a filesystem of  failed.
Please report this together with the output of "/usr/sbin/grub-probe --=
device-map=3D"/boot/grub/device.map" --target=3Dfs -v /boot/grub" to <b=
[email protected]>
Auto-detection of a filesystem of  failed.
Please report this together with the output of "/usr/sbin/grub-probe --=
device-map=3D"/boot/grub/device.map" --target=3Dfs -v /boot/grub" to <b=
[email protected]>
Generating grub.cfg ...
=46ound background image: /usr/share/images/desktop-base/desktop-grub.p=
ng
=46ound linux image: /boot/vmlinuz-2.6.38-2-amd64
=46ound initrd image: /boot/initrd.img-2.6.38-2-amd64
=46ound linux image: /boot/vmlinuz-2.6.37-2
=46ound Windows XP Pro on /dev/sda4
done
Processing triggers for man-db ...
#/usr/sbin/grub-probe --device-map=3D"/boot/grub/device.map" --target=3D=
fs -v /boot/grub
#

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

[email protected] wrote (ao):

Say 'yes', try to finish your upgrade.

Then:
grub-install /dev/sda
update-grub

Do keep an Ubuntu cd in reach though, just in case your grub is screwed anyway.

Sander

Humilis IT Services and Solutions
http://www.humilis.net

Now when I ran it, it went as normal for some reason.

Auto-detection of a filesystem of failed.
Please report this together with the output of "/usr/sbin/grub-probe --device-map="/boot/grub/device.map" --target=fs -v /boot/grub" to <[email protected]>

Generating grub.cfg ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png Found linux image: /boot/vmlinuz-2.6.38-2-amd64
Found initrd image: /boot/initrd.img-2.6.38-2-amd64
Found linux image: /boot/vmlinuz-2.6.37-2
Found Windows XP Pro on /dev/sda4
done

I'm afraid to reboot though, because yesterday I started a btrfs fi balance on this machine while sshed to another, and that is still running 15 hours later with no indication of progress nor sign of abating. ^C is ineffective.

Wow. I was very nearly completely screwed. I went ahead and rebooted, but grub.cfg was not set up at all. I had no way to run update-grub on that root, and so tried manually filling in the missing parameters. That didn't work, probably through the obfuscation of UUIDs I couldn't determine what was really going on. What a terrible idea the way they were implemented, UUIDs. Why not put the current device assignment somewhere in the number? Terrible.

I ended up copying an old grub.cfg from a backup, and that got me at least booted, though with lots of grub errors. Now I am at a loss.

I don't understand this. grub-update at least -pretended- to work before I rebooted. I am still in shock. MUST get some actual work done today, rather than bit-twiddling. MUST try and make a living.

Anyone here?

Could you create link from you root parition to /dev/root and try again?

Tomasz Torcz                 Morality must always be based on practicality.
xmpp: [email protected]                -- Baron Vladimir Harkonnen

# ln -s / /dev/root
# update-grub
/usr/sbin/grub-probe: error: cannot find a device for / (is /dev mounted?).
# update-grub -v
grub-mkconfig (GRUB) 1.99~rc1-13
#

It's still BTRFS incompatibility.

Really, what?
You -really- have no idea of the pressures I'm under. Don't want to help, don't. I -really- don't have much more time to fool with this.

Either that, or maybe something has broken in your many attempts to solve the problem while avoiding to educate yourself.

I'm afraid that's something you should have considered before choosing to mkfs.btrfs.

I'm sorry that you decided to use experimental software without being prepared for the consequences. But it does sound like you've actually had ample warning.

Stop fooling with this. You'll likely not be successful if you are only interested in the quick fix, and people helping you with this will basically be wasting their time since you seem very unlikely to contribute anything back. (Like high quality debugging, a testing environment, or even patches. All of which take both time and significant technical skill to produce.)

//Peter

[email protected] wrote (ao):

That would kinda defeat the purpose :p

What errors ..

Dude, really ..

Sander

Humilis IT Services and Solutions
http://www.humilis.net

Clearly. Please continue the discussion in a debian or grub forum.. It really has nothing to do with btrfs.

//Peter

No thanks. This is a BTRFS problem, and if you people don't want to face it, that's fine.

I'm tearing out BTRFS and using another filesystem. And rest assured, I'm warning others too.

That's enough.

A problem that happens when you use btrfs is not neccessarily a btrfs problem.

Do I agree that it sucks that distributions make assumptions about filesystems? Yes certainly! Is that a problem for btrfs, and others? Yes. Is it a problem *in* btrfs? Not the least. It's also not something that can be dealt with in this forum, where the topic is the code that implements btrfs.

In your situation this seems like an excellent choice.

That would be great! Warn others that btrfs is still experimental. Please also warn people to make backups, even if they are not using btrfs. And remember to warn people that the debian+grub combination seems to make assumptions about filesystems. You will do everyone a great service!

//Peter

I think this is probably a good conclusion for you. I would
strongly suggest you pick something reliable (like ext3 or ext4) for your future needs. Picking an experimental filesystem for your primary usage on a mission-critical system is an idiosyncratic choice, to say the least.

I would also suggest keeping regular and tested backups, because if
you can't cope with losing all your data for the time it takes to recreate it all, you _will_ need your backups at some point.

I'm sorry you feel the need to do this.

Hugo.

=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
  --- I hate housework. You make the beds, you wash the dishes, and ---  
           six months later you have to start all over again.            

I would like to take a moment to complement the members of the list for their professionalism, courtesy, politeness, and their efforts to help.

I was reminded of an article in the Boston Globe that, while completely off any btrfs topic and pointed to here without any agenda whatsoever, for some might be an interesting read:
How facts backfire
Researchers discover a surprising threat to democracy: our brains July 11, 2010|Joe Keohane
http://articles.boston.com/2010-07-11/bostonglobe/29324096_1_facts-misinformation-beliefs

-dgb

o face it, that's fine.

ed, I'm warning others too.

hm. well to anyone who stumbles across this thread in the future, i've managed to use btrfs as my root on 1-3+ machines since circa 2.6.32, possibly even earlier (albeit not on Debian -- Archlinux w00tw00t ;-) ...

=2E.. there have certainly been a few bumps along the way, but not _once_ at the fault of btrfs ... not ONCE. tbh, I personally KNOW the developers and community here are doing one hell of a job -- i've been on this list almost 3 years i think, and along the way everyone has been most helpful + accommodating; i mean i've seen Chris and others extending rather gracious support levels when helping users recover data or debug issues ... and considering the demand/anticipation surrounding btrfs, this list is relatively devoid of support issues -- it's easily one of the highest quality groups i frequent.

in short, distro's only just recently began offering btrfs at install time, with a big *warning sticker* on it. as others have already stated, this is clearly a Debian-specific problem, and does not reflect negatively on btrfs whatsoever, which has been nothing short of spectacular since the day i tried it and very much exactly as advertised -- i haven't used anything else since (save my servers =2E..).

i am sorry you've found yourself in this position, i really am, as i've been there myself, but please do try and acknowledge the considerations already extended your way -- my post marks the 51st message in this thread.

C Anthony
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

On Fri, May 6, 2011 at 8:51 PM, C Anthony Risinger <[email protected]> w= rote:

=2E

to face it, that's fine.

red, I'm warning others too.

i see now that you're running a .32 kernel ... a bit after the fact, but i really wouldn't recommend using anything that old for something that's in such active development; IIRC, there were many feature gaps at that point (ENOSPC being the big one), and unless Debian is doing something special, .32 was when btrfs was declared "ready for early adopters" ... ie. stable was still way out on the horizon, no one even knew what she might look like yet :-)

C Anthony
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

ahh yes indeed ... had to go ~20 msgs in to uncover that little gem ;-)

my apologies -- i hope your able to recover and/or find a solution that works for you -- best of luck.

C Anthony

Hallo, C,

Du meintest am 07.05.11:

With that kernel I had still problems. 2.6.38.x seems to work well.

Viele Gruesse!
Helmut

Hallo, Cacook,

Du meintest am 06.05.11:

That's a behaviour which was described in this mailing lists some weeks ago. You have certainly studied that thread?

Balancing 4 TByte may need more than 1 day. Look every hour at the last lines of "dmesg".

Viele Gruesse!
Helmut