Re: for the adventurous: apt in readonly rootfs

[tomas]

On Mon, Jun 12, 2023 at 09:53:03PM +0200, Smits Katze wrote:
> >What would be the difference to simply saying
> >
> >  sudo -i
> 
> The effect should be the same (and the command is more concise).
> 
> Thanks for pointing it out.

Thank you for confirmation & sorry for the nitpick :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: for the adventurous: apt in readonly rootfs

[Smits Katze]

>What would be the difference to simply saying
>
>  sudo -i

The effect should be the same (and the command is more concise).

Thanks for pointing it out.

-- 
PGP: FF815935D964B268656B43DCB8037830D522909E

Re: for the adventurous: apt in readonly rootfs

[tomas]

On Mon, Jun 12, 2023 at 06:54:40PM +0200, Smits Katze wrote:
> Debian wiki describes how to configure a read-only rootfs and how to
> run apt and unattended-upgrades in such a filesystem:
> https://wiki.debian.org/ReadonlyRoot
> 
> I would like to report that I am having considerable success with the
> following simple command sequence:
> 
> sudo su -l

What would be the difference to simply saying

  sudo -i

?

Cheers
-- 
t


signature.asc
Description: PGP signature

for the adventurous: apt in readonly rootfs

[Smits Katze]

Debian wiki describes how to configure a read-only rootfs and how to
run apt and unattended-upgrades in such a filesystem:
https://wiki.debian.org/ReadonlyRoot

I would like to report that I am having considerable success with the
following simple command sequence:

sudo su -l
unshare -m
# in the new namespace, remount all
# filesystems writable that apt upgrade
# would want to write to
mount --bind /boot /boot
mount -o remount,rw /boot
mount --bind /usr /usr
mount -o remount,rw /usr
apt upgrade
exit

In particular, this avoids all problems with remounting back to
read-only afterwards, because processes in the original mount
namespace never get to see a writable filesystem.

The whole story is rather trivial, but anyways I wrote a small script
to make this more comfortable: https://github.com/smitsohu/rofairy

The script also verifies that remounting in the new mount namespace
does not inadvertently create writable locations in the original mount
namespace.

Maybe it helps someone. Also let me know if you hate it.
Thanks!

-- 
PGP: FF815935D964B268656B43DCB8037830D522909E

Re: "Failed to start Create System Users" when booting Debian 10 rootfs from NFS mount.

[mj]

Hi,

A suggestion: we've had issues in the past, where on NFS root the issue 
was that setting "Linux Capabilities" (setcap) fails, because NFS does 
not support the extended attributes to store them.


Perhaps that is your issue as well?

MJ

Op 16-08-2022 om 21:58 schreef Lie Rock:

Hi,

I'm trying to bring up the Debian 10 root file system on an ARM SoC 
board. When the rootfs was in an SD card the board worked well. When I 
put the rootfs on an NFS server and tried to boot the board through NFS 
mount, it reported error through serial port:


|[FAILED] Failed to start Create System Users. See 'systemctl status 
systemd-sysusers.service' for details. |


And this is the only error message printed out. The board went all the 
way to login inputI, but I could not login with any of 
the preset accounts including root (because no users have been created 
as it suggested?), and I didn't see any way to run commands to check 
system status for details.


So how is the process "create system users" performed when Linux/Debian 
starts? What can be contributing to this error?


Any suggestions would be greatly appreciated.

Rock

Re: "Failed to start Create System Users" when booting Debian 10 rootfs from NFS mount.

[tomas]

On Tue, Aug 16, 2022 at 04:20:36PM -0400, Greg Wooledge wrote:
> On Tue, Aug 16, 2022 at 03:58:30PM -0400, Lie Rock wrote:
> > So how is the process "create system users" performed when Linux/Debian
> > starts? What can be contributing to this error?
> 
> unicorn:~$ grep -ri 'create system users' /lib/systemd
> /lib/systemd/system/systemd-sysusers.service:Description=Create System Users

[...]

Good research, and "thank you" from a systemd-abstainer, that's
my way to learn, after all :)

I'd contribute my hunch: perhaps systemd is trying to get sysusers
up "too early", before the root file system is pivoted-in?

Feeding my search engine with "NFS root" and +systemd turns up a
bunch of interesting suggestions (e.g. network has to be up before
NFS has to be mounted, etc:).

Good luck... and tell us what it was ;-)

Cheers
-- 
t


signature.asc
Description: PGP signature

Re: "Failed to start Create System Users" when booting Debian 10 rootfs from NFS mount.

[Greg Wooledge]

On Tue, Aug 16, 2022 at 03:58:30PM -0400, Lie Rock wrote:
> So how is the process "create system users" performed when Linux/Debian
> starts? What can be contributing to this error?

unicorn:~$ grep -ri 'create system users' /lib/systemd
/lib/systemd/system/systemd-sysusers.service:Description=Create System Users

unicorn:~$ systemctl cat systemd-sysusers.service
[...]
Documentation=man:sysusers.d(5) man:systemd-sysusers.service(8)
[...]
ExecStart=systemd-sysusers

unicorn:~$ man systemd-sysusers
[...]
   systemd-sysusers creates system users and groups, based on the file
   format and location specified in sysusers.d(5).

That's enough to get you started down the rabbit hole(s).  You should
also definitely check the logs on your system (e.g.
 journaltctl -u systemd-sysusers) to see what *exactly* went wrong.

"Failed to start Create System Users" when booting Debian 10 rootfs from NFS mount.

[Lie Rock]

Hi,

I'm trying to bring up the Debian 10 root file system on an ARM SoC board.
When the rootfs was in an SD card the board worked well. When I put the
rootfs on an NFS server and tried to boot the board through NFS mount, it
reported error through serial port:

[FAILED] Failed to start Create System Users.
See 'systemctl status systemd-sysusers.service' for details.

And this is the only error message printed out. The board went all the way
to login inputI, but I could not login with any of the preset accounts
including root (because no users have been created as it suggested?), and I
didn't see any way to run commands to check system status for details.

So how is the process "create system users" performed when Linux/Debian
starts? What can be contributing to this error?

Any suggestions would be greatly appreciated.

Rock

Re: Conversion to btrfs raid1 profile on added ext device renders some systems unable to boot into converted rootfs

[Qu Wenruo]

Add Cc to debian user list.

On 2018/10/24 上午3:21, Tony Prokott wrote:
> The trouble is yet unresolved, symptoms are as they were, but I've diagnosed 
> a step further. Maybe you can help me advance the diagnosis or better pose my 
> question among debian experts, related to adjusting the building of initrd.
> 
>   On Thu, 18 Oct 2018 00:08:08 -0700 Qu Wenruo  
> wrote  
>  > >  > Still looks like a initramfs problem [rather] than btrfs problem.  
> Yes, but linux-btrfs list still knows better than I how best to proceed, 
> mainly how to distill the trouble description using proper terms, also 
> lending broader understanding of what named modules serve what device 
> activate&cfg or storage-access purpose.

Personally speaking, distro guys are much better at such problem.

In fact I'm not even a debian guy, and for my distro, it's super easy to
setup initramfs to boot from USB device.

> 
>  > >  > In the busybox environment, have you tried listing /dev to see if 
> that external device is found?  
> External usb attached drives are definitely not found by a newly launched 
> kernel, and particulars of why are still not self evident. Boot loader grub2 
> all along still has no trouble accessing -- presumably it's not able to 
> leverage raid1 redundancy in btrfs but does have access to the ext mirror 
> device and takes notice in passing of matching UUID's.

So missing drivers.
Without the driver, btrfs scan doesn't make sense at all.

It needs not only usb drivers but also some other drivers.
Normally distro should provide such tools to do runtime probe and
generate all needed drivers and their dependency, or manually setup
needed drivers.

BTW, have you tried something like fallback initramfs?
Generally speaking such fallback initramfs should have more modules thus
higher chance to detect external usb drivers.

> 
>  > By default, btrfs must see *all* devices to mount RAID1/10/5/6/0. Unless 
> you're using "degraded" mount option. 
>  > You could argue it's a bad decision, but still you have the choice. 
> Yes did manage to mount it degraded, just to see that content demirrored is 
> also unclobbered, however can't finish the job by such means; hopefully in 
> the process no metadata or other junk was written unintentionally (forgot to 
> mount readonly - degraded)
> 
> The task now seems to be finishing resolving which modules can bring in the 
> rest of the critical infrastructure to allow access to the drives that had 
> been no customized bother to bring online, prior to rootfs raid1 conversion. 
> A recently found item of great interest is module "autofs4" which has 
> userland friends such as systemd; it's present in cindy(LMDE3) which boots 
> fine in spite of deriving from stretch, and was absent in stretch & buster 
> which no longer boot.
> 
>  > > When manually trying to mount in busybox, it gives a similar error about 
> missing the same external device, by its UUID_SUB 
>  > Then it's still something wrong about the initramfs. From your 
> description, it looks pretty like the lack of external disk driver is the 
> root cause. 
> Agreed *something* missing in initrd and-or module deployment is the cause of 
> failing access to ext usb3 drive enclosure devices, but am still tracking 
> down which other missing blobs may be of concern; since busybox won't allow 
> "lsblk" "lshw" or "lsusb" -- only "blkid" or "ls /dev" work to detect devices 
> -- my confidence and expediency in tracking is reduced; haven't yet happened 
> upon the debian feature that lets more nonkernel programs and libraries--not 
> just modules-- be built into initrd.

At least for my distro, it's pretty easy to inject external commands
into initramfs.
(Archlinux provides "add_binary" function in mkinitcpio, which will not
only add the binary but also its dependency)

So it's really dependent on the distro.

Thanks,
Qu

> 
> As an aside probably not germane, the grub.cfg "linux" line to load the 
> kernel in some cases has "ro" readonly option and others not; what's the 
> difference signify? How to make informed choice whether to use ro? Why mount 
> a real disk rootfs without write access, before corruption's detected? Would 
> that not potentially cripple some vital features such as logging?
> 
> So far it's clear that uas, usb_storage, & autofs4 may be built into initrd 
> and then load ok, but they're not enough to restore normal systemd launch. 
> Setting "MODULES=dep" in /etc/initramfs-tools/conf.d/driver-policy seems not 
> smart enough for building in all necessary objects. Ideas welcome.
> 
> regards-
> TP
> 
> 



signature.asc
Description: OpenPGP digital signature

[stretch] unlock with keyfile LVM encrypted rootfs -- hung at boot

[Mars RAM]

Hello everyone!

I'm currently trying to find a method to decrypt my rootfs at boot
time with a keyfile on debian stretch.

I've successfully implemented a method ([1] and [2]) which uses a
custom script to read the first 2048bit
from the usbkey memory to decrypt the disk, but I actually need to
store the keyfile on a filesystem.

Someone [3] told me about an old post on debian-user mailing list:
https://lists.debian.org/debian-user/2017/12/msg00523.html
That's exactly what I need. I don't mind patching cryptroot script
(appended [4]) to do it, so I decided to test it.
I've create a VM (kvm/qemu), partitioned the disks this way (a classic
crypted debian LVM partitioning):


   root@debian:~ $ lsblk
   NAMEMAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
   sda   8:00   1.2G  0 disk
   vdb   8:16   0  20.8G  0 disk
   ├─vdb18:17   0   243M  0 part  /boot
   ├─vdb28:18   0 1K  0 part
   └─vdb58:21   0  20.5G  0 part
└─vdb5_crypt 254:00 20.5G  0 crypt
├─debian--vg-root   254:10   18G  0 lvm   /
 └─debian--vg-swap_1 254:20  2.3G  0 lvm   [SWAP]


Configured as in the mailing list tutorial, updated initramfs, updated
grub, rebooted.
I've followed the tutorial step by step, but still at boot time the system hung:


Reading all physical volumes. This may take a while...
   WARNING: Failed to connect to lvmetad. Falling back to device scanning.
   WARNING: Failed to connect to lvmetad. Falling back to device scanning.
   Reading all physical volumes. This may take a while...
   WARNING: Failed to connect to lvmetad. Falling back to device scanning.
   ...
   ALERT! /dev/vdb5 does not exist.
Check cryptopts=source bootarg: cat /proc/cmdline
or missing modules. devices: cat /proc/modules: ls /dev
   -r Dropping to a shell. Will skip /dev/vdb5 if you can't fix.
   Busybox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash)
   Enter 'help' fro a list of built-int commands.
   (initramfs)
   (initramfs) _


It seems unable to find the disk to decrypt (/dev/vdb5).
I was so sad, I've thought I've found the right way...
So I digged more and suddenly I've thought maybe it could be my LVM
partition scheme.
With no real expectations I've created another VM, with the following
partition scheme:


NAME  MAJ:MIN  RM  SIZE RO TYPE MOUNTPOINT
sr0 11:0   11024M  0rom
vda  254:0   0 20G 0 disk
|_vda1 254:0   0  953M  0part   /boot
|_vda2 254:0   0   1K  0part
|_vda5 254:0   0 17G  0   part
  |_vda5_crypt   254:0   0 17G  0   crypt   /
|_vda6 254:0   0 2G0   part
   |_vda6_crypt   254:0   0 2G0  crypt[SWAP]


Configured, updated, rebooted.
And it works!

So I'm a bit stuck here and I've decided to write to this mailing list
hoping someone may illuminate me,
why does it hung with LVM partitioning?
Could there it be some tricks to make it work?

Now to my point of view I think it could be a missing or erroneous
cmdline parameter, or/and the cryptroot script in the tutorial
(appended [4]) maybe is causing this. But I don't know yet how to fix
this.

The cmdline I used with LVM partitioning is:
BOOT_IMAGE=/vmlinuz-4.9.0-7-amd64
root=/dev/mapper/debian--vg-root ro
cryptopts=target=vda5_crypt,source=/dev/disk/by-uuid/b59bb85d-abec-4562-90c3-1f3d0ab34036

The cmdline used without LVM:
 BOOT_IMAGE=/vmlinuz-4.9.0-7-amd64
root=UUID=b59bb85d-abec-4562-90c3-1f3d0ab34036 ro quiet

I also tried to decrypt LVM partitioned device from initramfs panic
shell, but I succeeded only on an actual machine, on a virtual machine
the devices didn't appear (no /dev/vda).

A partitioning scheme without LVM may be ok to my usecase, but I would
like to understand why it does not work and if it can be fixed.
Thank you for your time,

Lorenzo

REF:
[1]  
https://www.oxygenimpaired.com/debian-lenny-luks-encrypted-root-hidden-usb-keyfile
[2]  
https://www.oxygenimpaired.com/ubuntu-with-grub2-luks-encrypted-lvm-root-hidden-usb-keyfile
[3]  
https://unix.stackexchange.com/questions/471854/decrypt-root-device-at-boot-with-keyfile-on-usb-debian-stretch
[4]  cryptroot script:


#!/bin/sh

PREREQ="cryptroot-prepare"

#
# Standard initramfs preamble
#
prereqs()
{
# Make sure that cryptroot is run last in local-top
for req in $(dirname $0)/*; do
script=${req##*/}
if [ $script != cryptroot ]; then
echo $script
fi
done
}

case $1 in
prereqs)
prereqs
exit 0
;;
esac

# source for log_*_msg() func

[stretch] unlock with keyfile LVM encrypted rootfs -- hung at boot

[Lfabbro]

Hello everyone!

I'm currently trying to find a method to decrypt my rootfs at boot time with a 
keyfile on debian stretch.

I've successfully implemented a method ([1] and [2]) which uses a custom script 
to read the first 2048bit
from the usbkey memory to decrypt the disk, but I actually need to store the 
keyfile on a filesystem.

Someone [3] told me about an old post on debian-user mailing list: 
https://lists.debian.org/debian-user/2017/12/msg00523.html
That's exactly what I need. I don't mind patching cryptroot script (appended 
[4]) to do it, so I decided to test it.
I've create a VM (kvm/qemu), partitioned the disks this way (a classic crypted 
debian LVM partitioning):


   root@debian:~ $ lsblk
   NAME    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
   sda   8:0    0   1.2G  0 disk 
   vdb   8:16   0  20.8G  0 disk
   ├─vdb1    8:17   0   243M  0 part  /boot
   ├─vdb2    8:18   0 1K  0 part 
   └─vdb5    8:21   0  20.5G  0 part 
    └─vdb5_crypt 254:0    0 20.5G  0 crypt
    ├─debian--vg-root   254:1    0   18G  0 lvm   /
     └─debian--vg-swap_1 254:2    0  2.3G  0 lvm   [SWAP]


Configured as in the mailing list tutorial, updated initramfs, updated grub, 
rebooted.
I've followed the tutorial step by step, but still at boot time the system hung:


    Reading all physical volumes. This may take a while...
   WARNING: Failed to connect to lvmetad. Falling back to device scanning.
   WARNING: Failed to connect to lvmetad. Falling back to device scanning.
   Reading all physical volumes. This may take a while...
   WARNING: Failed to connect to lvmetad. Falling back to device scanning.
   ...
   ALERT! /dev/vdb5 does not exist.
    Check cryptopts=source bootarg: cat /proc/cmdline
    or missing modules. devices: cat /proc/modules: ls /dev
   -r Dropping to a shell. Will skip /dev/vdb5 if you can't fix.
   Busybox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash)
   Enter 'help' fro a list of built-int commands.
   (initramfs)
   (initramfs) _


It seems unable to find the disk to decrypt (/dev/vdb5).
I was so sad, I've thought I've found the right way...
So I digged more and suddenly I've thought maybe it could be my LVM partition 
scheme.
With no real expectations I've created another VM, with the following partition 
scheme:


NAME      MAJ:MIN  RM  SIZE RO TYPE MOUNTPOINT
sr0     11:0   1    1024M  0    rom
vda  254:0   0 20G 0     disk
|_vda1     254:0   0  953M  0    part   /boot
|_vda2         254:0   0   1K  0    part
|_vda5 254:0   0 17G      0       part
  |_vda5_crypt   254:0       0 17G  0       crypt   /
|_vda6     254:0       0 2G        0   part
   |_vda6_crypt   254:0   0 2G    0  crypt    [SWAP]


Configured, updated, rebooted.
And it works!

So I'm a bit stuck here and I've decided to write to this mailing list hoping 
someone may illuminate me,
why does it hung with LVM partitioning?
Could there it be some tricks to make it work?

Now to my point of view I think it could be a missing or erroneous cmdline 
parameter, or/and the cryptroot script in the tutorial (appended [4]) maybe is 
causing this. But I don't know yet how to fix this.

The cmdline I used with LVM partitioning is:
BOOT_IMAGE=/vmlinuz-4.9.0-7-amd64  root=/dev/mapper/debian--vg-root ro 
cryptopts=target=vda5_crypt,source=/dev/disk/by-uuid/b59bb85d-abec-4562-90c3-1f3d0ab34036

The cmdline used without LVM:
 BOOT_IMAGE=/vmlinuz-4.9.0-7-amd64  
root=UUID=b59bb85d-abec-4562-90c3-1f3d0ab34036 ro quiet

I also tried to decrypt LVM partitioned device from initramfs panic shell, but 
I succeeded only on an actual machine, on a virtual machine the devices didn't 
appear (no /dev/vda).

A partitioning scheme without LVM may be ok to my usecase, but I would like to 
understand why it does not work and if it can be fixed.
Thank you for your time,

Lorenzo

REF:
[1]  
https://www.oxygenimpaired.com/debian-lenny-luks-encrypted-root-hidden-usb-keyfile
[2]  
https://www.oxygenimpaired.com/ubuntu-with-grub2-luks-encrypted-lvm-root-hidden-usb-keyfile
[3]  
https://unix.stackexchange.com/questions/471854/decrypt-root-device-at-boot-with-keyfile-on-usb-debian-stretch
[4]  cryptroot script:


#!/bin/sh

PREREQ="cryptroot-prepare"

#
# Standard initramfs preamble
#
prereqs()
{
# Make sure that cryptroot is run last in local-top
for req in $(dirname $0)/*; do
script=${req##*/}
if [ $script != cryptroot ]; then
echo $script
fi
done
}

case $1 in
prer

Re: Making initramfs agree with rootfs about time zone

[Richard Hector]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Err, whoops.

That wasn't supposed to be encrypted. Not sure how that happened ...

Here we go:

On 02/04/15 00:21, Richard Hector wrote:
> On 01/04/15 11:56, Martin Read wrote:
>> I have a dual-boot Win7/Debian jessie system. Because Windows
>> doesn't deal gracefully with handling the hardware time-of-day
>> clock the proper way (hwclock set to GMT, all TZ handling in
>> software), this means that the hwclock changes for daylight
>> savings time.
> 
> I believe it's possible to fix that in Windows these days, eg:
> 
> http://kb.norsetech.net/set-windows-clock-to-utc-time/
> 
> Richard
> 
> 
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBAgAGBQJVG9xqAAoJELSi8I/scBaNDIAH+gJOZZaXoOcV5bXnm339gedY
Tm3tG6GaAXZKlD3V3VulLjVJjfOwmminGuRVD/hGYPB4qOk+Gl+NESgPqqu2kp8Z
GWaqBXinkv6gCKE2BU7NzLn+95WV7cehrKC3yKdsckFnkJipV229x5XXQRAB4dmi
cE6xKEBFUDpop8u5v7hac3q7/Z1VWr/fMgsDNoCrXfs1LuSRSYhT5Lg/lLugAQDJ
9CAH3vAy21LFRBtPBzHSjGBY9bWfpZOZFtXBcHmXJVdMneP+MYExdwfLIXQBHkvI
VARFf8zlU1BtCnj6foL4wyGSzKcNcojUdzd16bTmyd/Ghw3i0GTGis22LlUktyg=
=ubqT
-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: https://lists.debian.org/551bdc6a.5030...@walnut.gen.nz

Re: Making initramfs agree with rootfs about time zone

[Richard Hector]

-BEGIN PGP MESSAGE-
Charset: utf-8
Version: GnuPG v2.0.19 (GNU/Linux)

hQEMA07UmgrFcS2hAQf/dwmi7WfCdgUxzk0BIhdGs9qKWgbRiiVyqxLm2Min3wqF
Xw6mgqsMBh3vQ24CCVmPTF4q2eiy2ZMsGjsFwXm2SJK8WrgsSOKSFtyt77rZHpHx
SExwcy/nXHoSaynm9x3dNwfy2qcrANSmG9dWBiX3HUc1GSw08DVa50D+iqZBmyWH
csubGvcXMxbvYBAKwFZniS2NrtM6I+5si0UajzbKJ99ACjlAvj4TdOsuzuMscL+q
ke/pCpXamBtG3IxZQbCQJIufPxmT7CrC71D3RrNudHLoeaeSYMq6Fqv1RVj5P9pm
LFd8P9q7eyBgSLoUXnNIFErSF684XevIdG3jElhQi9LpAaT7r7EOUXqvvhO7TbLT
4n/n4YPb4NUN9fY+aFX4Z8TnxJK1RC6ZEXJn/6HMP0GJk5FHn2Pg7abUnNEcIQvi
sr7Bn6JQ9mB3gCwgR5vH2/DC5tCmMKO+lhW3pHmCAWohBlAkWLfjHFEo+ZJlterp
cpH9A3MBy6qjWo6rv7cLshqK42krjcDVQdduVgNMrvBDE1f5PsqOZ4QHaosP4+pT
S/xKMhyaCdpzJTVTwTOZwP2gHhhHYCRlg+jyreet8EF73tBJkiTJ5T8WLxf4PQwp
+Y6Xhvjsbz/1qH1QPak1AC+B0FGiCdWIhIK2hHPlbxOPZ28wP6nxkERVad4IqY8a
f/oF0LKRO8/lTfhYw8c8jlfRFZ4z55ic9ymSavIJnWCxPLskwuniPYic79xj81BK
LNyQ8J7AWrSIfvOCjzapFPEyCgwudqD0ImdZAQYO6AcfqGSWLwUL/1/vxqlTyQHW
tiZwCYAAInvKpqkFC/5YEM/SGLgm6vKnD8cPgeO6v1N61cZXTRbkOdaInPmRsCBw
ZPK0UfgpyDVMhetOWcNNBGdAtGLPsmIgVeWjQpTDb7N/DdzZbVpntQEjnOk3SAgn
OPhAyVAORkXdesX1YB9MuXZkY11IgJFTnGBzedarPkbzK/O35GNgfipK12U2HGEQ
N/N94uLzrgDxv34RowDKYxLAII5tOMvYVI/sc8m5ucfC/i+d++HF+sJs6WqJ/3s8
8YUp5IJ1h3ju6cwr/Zls7r6/YLPVGn3H/TRk8DgCKxIdPaGUuz0JOZegV8pIF6wX
01RG5EwdikNVIYnOCHQN2vm+FtOtO/zRWXSMEOxAySIlME8M3xyBhNrOnyP2hKet
XSTRCXhcxYIXDcJn9+xa5hf3uxl7smV2e31AxDprCywKCiWLVukeQF8+garbIGkl
RuvdYn/6bbtAi5otMetpuH1TcdYAQdq16rcPvEeKUqC6gUVl4w06Oh6XWEg4+jp5
KXUY
=GIzP
-END PGP MESSAGE-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/551bd4cd.6010...@walnut.gen.nz

Re: Making initramfs agree with rootfs about time zone

[Janis Hamme]

It's an open bug in Debian Jessie:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767040

Until the bug is fixed you can create the file /etc/e2fsck.conf containing
> [options]
> broken_system_clock=1

Janis


Am 01.04.2015 um 00:56 schrieb Martin Read:
> I have a dual-boot Win7/Debian jessie system. Because Windows doesn't 
> deal gracefully with handling the hardware time-of-day clock the proper 
> way (hwclock set to GMT, all TZ handling in software), this means that 
> the hwclock changes for daylight savings time.
>
> The Debian installation itself copes fine with this, but the initramfs 
> configuration appears to not account for it, resulting in a complaint 
> about timestamps from systemd-fsck every time I boot Debian (which I may 
> well do 2-3 times a day because of things like "leaving the house" and 
> "switching to Windows to play Wine-unfriendly video games").
>
> Is there a convenient way in Debian jessie to make the initramfs be 
> configured with the same idea of the hwclock's behaviour as the 
> configuration on my hard drive, so that I stop getting these 
> annoying-but-not-obviously-harmful messages?
>
>


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/551b307a.5050...@hamme.info

Making initramfs agree with rootfs about time zone

[Martin Read]

I have a dual-boot Win7/Debian jessie system. Because Windows doesn't 
deal gracefully with handling the hardware time-of-day clock the proper 
way (hwclock set to GMT, all TZ handling in software), this means that 
the hwclock changes for daylight savings time.


The Debian installation itself copes fine with this, but the initramfs 
configuration appears to not account for it, resulting in a complaint 
about timestamps from systemd-fsck every time I boot Debian (which I may 
well do 2-3 times a day because of things like "leaving the house" and 
"switching to Windows to play Wine-unfriendly video games").


Is there a convenient way in Debian jessie to make the initramfs be 
configured with the same idea of the hwclock's behaviour as the 
configuration on my hard drive, so that I stop getting these 
annoying-but-not-obviously-harmful messages?



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/551b2626.5030...@zen.co.uk

Re: Read-only rootfs on systemd [SOLVED]

[Amit]

Thanks for your help and the replies. So this issue is now resolved.

Summary of Issue:
Mounting root as read-only as documented in
(https://wiki.debian.org/ReadonlyRoot) because rootfs is busy.

Summary of Solution:

 1. 'lsof +L1' showed cupsd getting stuck on /etc/passwd (deleted).
Looking at systemd journalctl, a custom service on this server was
creating users blindly on every startup due to a bug in the code logic
of this custom user management application. This caused /etc/passwd
to keep changing.

By fixing the bug, the /etc/passwd (deleted) was no longer an issue.

 2. After reading the debian wiki on ReadOnlyRoot, there is a section on
samba creating a file /etc/samba/dhcp.conf everytime dhclient was
called. This server has a dual ethernet port with one port not
plugged. As a result, dhclient kept trying to get a lease for this
eth1 port and thus samba kept creating that file in /etc and rootfs
was always busy.

Not sure how this issue was solved but by adding the following line
to /etc/fstab, I don't see the repeated dhclient messages anymore:

tmpfs   /tmptmpfs nodev,nosuid  0   0


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/loom.20140307t202848-...@post.gmane.org

Re: Read-only rootfs on systemd

[Brian]

On Thu 06 Mar 2014 at 23:05:20 +, Amit wrote:

>  0) After reboot and running 'lsof +L1':
> COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NLINK   NODE NAME
> cupsd935 root8r   REG8,1 1392 0 132095 
> /etc/passwd (deleted)

I upgraded my wheezy install to jessie and cannot reproduce this.

>  1) Shutting down cups:
> sudo service cups stop
> 
> No /etc/passwd in 'lsof +L1' output
> 
>  2) Starting cups:
> $ sudo /etc/init.d/cups start
> [ ok ] Starting cups (via systemctl): cups.service.
> 
>  3) No /etc/passwd in 'lsof +L1' output

It would appear to be relevant to investigate why starting cups at
boottime produces a different outcome. It might also be worthwhile
using another init system to determine whether 'lsof +L1' gives the
same as above.

>  4) fuser output shows cupsd process using /etc/passwd but no output in lsof
> showing '(deleted)'.

I get that.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/07032014181859.8901992de...@desktop.copernicus.demon.co.uk

Re: Read-only rootfs on systemd

[Reco]

On Thu, Mar 06, 2014 at 11:05:20PM +, Amit wrote:
>  0) After reboot and running 'lsof +L1':
> COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NLINK   NODE NAME
> cupsd935 root8r   REG8,1 1392 0 132095
> /etc/passwd (deleted)

So it's reproducible.


>  1) Shutting down cups:
> sudo service cups stop
> 
> No /etc/passwd in 'lsof +L1' output

Since cupsd is the only one who writes in there, and you've just stopped
cupsd - that's expected.


>  2) Starting cups:
> $ sudo /etc/init.d/cups start
> [ ok ] Starting cups (via systemctl): cups.service.

Oops. That's something I've forgot. I expected sysvinit compatibility
layer to take care of cupsd starting.

> 
>  3) No /etc/passwd in 'lsof +L1' output
> 
>  4) fuser output shows cupsd process using /etc/passwd but no output in lsof
> showing '(deleted)'.

Weird. Just checked again, and on my Wheezy install nobody is using
/etc/passwd. Are you running Jessie?


>  At this point remounting as 'ro' works.

As it should be, as nobody is writing to the / filesystem now.


As a workaround to all this, you probably can just restart cups on
system's boot, and remount '/' read-only after that.

As a real solution to the problem, I suggest you to fill a bug report to
http://bugs.debian.org

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140307092141.GA26358@x101h

Re: Read-only rootfs on systemd

[Amit]

Reco  gmail.com> writes:

> 
> Can you do the following, please:
> 
> 1) Shutdown cups by systemd's way (systemctl blahblah …).
> 
> 2) Start it by /etc/init.d/cups start.
> 
> 3) Confirm with lsof whenever /etc/passwd is kept open.
> 
> 4) While you're at it, invoke 'fuser /etc/passwd' to ensure that nobody
> else is using it.
> 
> Reco
> 

 0) After reboot and running 'lsof +L1':
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF NLINK   NODE NAME
cupsd935 root8r   REG8,1 1392 0 132095
/etc/passwd (deleted)

 1) Shutting down cups:
sudo service cups stop

No /etc/passwd in 'lsof +L1' output

 2) Starting cups:
$ sudo /etc/init.d/cups start
[ ok ] Starting cups (via systemctl): cups.service.

 3) No /etc/passwd in 'lsof +L1' output

 4) fuser output shows cupsd process using /etc/passwd but no output in lsof
showing '(deleted)'.

 At this point remounting as 'ro' works.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/loom.20140307t000512-...@post.gmane.org

Re: Read-only rootfs on systemd

[Reco]

On Thu, 6 Mar 2014 18:35:06 + (UTC)
Amit  wrote:

> Reco  gmail.com> writes:
> 
> > 
> > https://wiki.debian.org/ReadonlyRoot#cups says:
> > 
> > CUPS stores any kind of state files under /etc (classes.conf,
> > cupsd.conf, printers.conf subscriptions.conf) and upstream is against
> > any modification.
> > 
> > Personally I worked around similar problem by moving /etc/cups
> > to /var/opt, and symlinking /var/opt/cups to /etc.
> > 
> 
> Thanks for the reply. The problem doesn't seem to be the statefiles, it
> seems to be '/etc/passwd'. I don't think I can safely move this to /var
> right?

IMO it's not safe indeed to move /etc/passwd somewhere else.

But, I've checked cups on my print-server and it does not keep
open /etc/passwd at all. And, given what cups should do, I find it
unlikely that it should behave that way.

Can you do the following, please:

1) Shutdown cups by systemd's way (systemctl blahblah …).

2) Start it by /etc/init.d/cups start.

3) Confirm with lsof whenever /etc/passwd is kept open.

4) While you're at it, invoke 'fuser /etc/passwd' to ensure that nobody
else is using it.

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140306234036.27ebda625335038c18fb3...@gmail.com

Re: Read-only rootfs on systemd

[Amit]

Brian  cityscape.co.uk> writes:

> 
> On Thu 06 Mar 2014 at 01:21:03 +, Amit wrote:
> 
> > I need cups, so is there a way around this?
> 
> This doesn't answer your question but I have a spare Wheezy with
> separate /, /home, and /var. I installed systemd, made the rootfs
> ro in fstab and booted with init=/lib/systemd/systemd. The rootfs
> was mounted ro. cupsd is also running.
> 
> 

Thanks for testing. I am running jessie at the moment. I kept a backup
of sysvinit as recommended by wiki.debian.org/systemd and used that. I
see the same issue of cups using /etc/passwd (deleted). So doesn't seem
to be a systemd issue, more of a cups issue I guess.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/loom.20140306t193742-...@post.gmane.org

Re: Read-only rootfs on systemd

[Amit]

Robin  gmail.com> writes:

> 
> Just a suggestion have you tried a re-install of cups since fresh
> install of systemd
> 

Thanks for the reply.

Yes, the first thing I did was install systemd and then all the other
packages but anyways I tried reinstalling again but no luck.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/loom.20140306t193534-...@post.gmane.org

Re: Read-only rootfs on systemd

[Amit]

Reco  gmail.com> writes:

> 
> https://wiki.debian.org/ReadonlyRoot#cups says:
> 
> CUPS stores any kind of state files under /etc (classes.conf,
> cupsd.conf, printers.conf subscriptions.conf) and upstream is against
> any modification.
> 
> Personally I worked around similar problem by moving /etc/cups
> to /var/opt, and symlinking /var/opt/cups to /etc.
> 

Thanks for the reply. The problem doesn't seem to be the statefiles, it
seems to be '/etc/passwd'. I don't think I can safely move this to /var
right?

Thanks,
Amit


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/loom.20140306t193345-...@post.gmane.org

Re: Read-only rootfs on systemd

[Reco]

 Hi.

On Thu, 6 Mar 2014 14:49:30 +
Brian  wrote:

> On Thu 06 Mar 2014 at 01:21:03 +, Amit wrote:
> 
> > I need cups, so is there a way around this?
> 
> This doesn't answer your question but I have a spare Wheezy with
> separate /, /home, and /var. I installed systemd, made the rootfs
> ro in fstab and booted with init=/lib/systemd/systemd. The rootfs
> was mounted ro. cupsd is also running.

https://wiki.debian.org/ReadonlyRoot#cups says:

CUPS stores any kind of state files under /etc (classes.conf,
cupsd.conf, printers.conf subscriptions.conf) and upstream is against
any modification.

Personally I worked around similar problem by moving /etc/cups
to /var/opt, and symlinking /var/opt/cups to /etc.

Reco


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20140306191540.8ed53c576ecd29e1043cb...@gmail.com

Re: Read-only rootfs on systemd

[Robin]

On 6 March 2014 01:21, Amit  wrote:
> Amit  gmail.com> writes:
>
> [snip]
>
>>
>> However, setting up a fresh install of systemd, the readonly does not
>> have any effect. The rootfs is still mounted as rw. All I did was
>> changed /etc/fstab. Based on the systemd man pages, this should be
>> enough.
>>
>> How do I go about debugging/fixing this issue?
>>
>
> The problem is cupsd. Doing an 'lsof +L1':
>
> COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NLINK   NODE NAME
>
> cupsd   825 root8r   REG8,1 1392 0 132009 /etc/passwd 
> (deleted)
>
> Stopping cups service and re-mounting as 'ro' now works.
>
> I need cups, so is there a way around this?
>
> Thanks,
> Amit
>
>

Just a suggestion have you tried a re-install of cups since fresh
install of systemd

-- 
rob


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOZWb-qJMcCFK5VF9S-m4UQ7T_Domh=psv2rttsxw29vnpp...@mail.gmail.com

Re: Read-only rootfs on systemd

[Brian]

On Thu 06 Mar 2014 at 01:21:03 +, Amit wrote:

> I need cups, so is there a way around this?

This doesn't answer your question but I have a spare Wheezy with
separate /, /home, and /var. I installed systemd, made the rootfs
ro in fstab and booted with init=/lib/systemd/systemd. The rootfs
was mounted ro. cupsd is also running.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/06032014144345.2d9a7ff52...@desktop.copernicus.demon.co.uk

Re: Read-only rootfs on systemd

[Amit]

Amit  gmail.com> writes:

[snip]

> 
> However, setting up a fresh install of systemd, the readonly does not
> have any effect. The rootfs is still mounted as rw. All I did was
> changed /etc/fstab. Based on the systemd man pages, this should be
> enough.
> 
> How do I go about debugging/fixing this issue?
> 

The problem is cupsd. Doing an 'lsof +L1':

COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NLINK   NODE NAME 

cupsd   825 root8r   REG8,1 1392 0 132009 /etc/passwd (deleted)

Stopping cups service and re-mounting as 'ro' now works.

I need cups, so is there a way around this?

Thanks,
Amit


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/loom.20140306t021826-...@post.gmane.org

Read-only rootfs on systemd

[Amit]

Hello,

I always run my debian systems with a separate /, /home, and /var. I
added read-only 'ro' mount to fstab for the root / partition. So far it
has been working great.

However, setting up a fresh install of systemd, the readonly does not
have any effect. The rootfs is still mounted as rw. All I did was
changed /etc/fstab. Based on the systemd man pages, this should be
enough.

How do I go about debugging/fixing this issue?

Thanks,
Amit


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/loom.20140304t231522-...@post.gmane.org

Re: rootfs

[Martin Steigerwald]

Am Samstag, 20. April 2013 schrieb Kevin Chadwick:
> > > Don't believe opinion as fact just because it's on a server hosted
> > > by freedesktop.org. Rusty Russel and the FHS is a more
> > > authoritative (and correct) source, I suggest you read it.
> > 
> > I never split up / and /usr for the last century or so and they are
> > all working fine.
> 
> Wow, your 100 years old and you haven't understood the FHS yet ;-)

What do you intend by taking my exaggeration word for word literately while 
it is quite likely that I am not 100 years old?

> Working is not best practice.

FHS is not mandatory for best practice either.

A standard is still an oppinion, although backed by more than one person.

In practice I found more issues with systems that have /usr splitted up than 
with those that do not. Especially if /usr has been made to small. Its one 
more chance to mis-estimate partition sizes.

If you intend to continue the discussion on the assumption that you are 
right and I am wrong without accepting that different people can have 
different oppinions about this topic, feel free to do so, but *without* me.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


-- 
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/201304231105.14064.mar...@lichtvoll.de

Re: rootfs

[Thilo Six]

Hello Roger,


Excerpt from Roger Leigh:

--  --
> I hope this makes clear why I currently hold the position that /usr
> (*as a separately mountable filesystem*) is not a useful feature.
> I long held the opposite opinion very strongly, until I spent a good
> bit of time really considering the validity of all the assumptions
> behind why we consider it useful, and came to the conclusion that it
> was, for the most part, not useful in the slightest on a modern
> package managed system.

I can very well recall the heated debates on debian-devel several years ago
about this topic. When you said in the previous mail that you are working on
moving /usr to the rootfs i thought oh oh an other valueable feature goes down
the drain. But your argumentation has actually convinced me.


-- 
Regards,
Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6  7C18 89A4 A2A0 C70B 1A8F



-- 
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/kl0hns$al2$1...@ger.gmane.org

Re: rootfs

[Kevin Chadwick]

> >   - With a package manager, if any of the rootfs, /usr or /var are
> > damaged, you need to either restore the entire set from a backup
> > or reinstall.  This comes back to the fact that all locations
> > under the control of the package manager are a unified whole: if one
> > part breaks, the whole thing breaks; more partitions may introduce
> > more failure points.  
> 
> Not really, there is nothing stopping you from fixing just what is
> broken.

It may also be that restoring takes longer or you may restore just
root.

You may choose to fsck -y /usr and do an installed package md5 check in
the background with little downtime.

Alternative for root you may do an fsck and check all the errors
and inodes and restore fix or ignore as appropriate for the more
important files.

In any case a separation of important files must surely be a good
practice that I would prefer to see kept. I can see very little good
coming from amalgamation.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___


-- 
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/20130421013621.3846d...@kc-sys.chadwicks.me.uk

Re: rootfs

[Kevin Chadwick]

> On Sat, Apr 20, 2013 at 09:43:08PM +0100, Kevin Chadwick wrote:
> > > I am, as a matter of fact, subscribed to the FHS list.  If you
> > > read the specification, you'll see that it does not in any way
> > > require /usr to be a *mountpoint*; it can be located on the root
> > > filesystem without any problems.  It's actually the default
> > > partitioning method.
> > > 
> > 
> > > Do you have any concrete reasons to have /usr separate from / ?
> > 
> > You need to look at the rootfs section, having them separate makes
> > what should be the most critical filesystem (rootfs) 100s! of times
> > larger and that quite rightly contradicts the spec (good reasons
> > are mentioned but some more benefits of this practice could be
> > included however).
> 
> The problem with the FHS here is that it's outdated with respect to
> current hardware, the implication of package management, and current
> admin practices, and is quite frankly wrong in some aspects.  Taking
> each one in turn:
> 
> • "The contents of the root filesystem must be adequate to boot,
> restore, recover, and/or repair the system."
> 
>   No problems with this. However, having /usr on the rootfs does not
>   interfere with this in any way.
> 
> • "To boot a system, enough must be present on the root partition to
> mount other filesystems. This includes utilities, configuration, boot
> loader information, and other essential start-up data. /usr, /opt,
> and /var are designed such that they may be located on other
> partitions or filesystems."
> 
>   The keyword here is "may".  /usr may be located on another
> filesystem, but there is not a strict requirement for that.  There's
> no "should" or "must" here.  Note that other distributions have
> removed the possibility for a separate /usr *entirely*.  I'm not
> suggesting we should go that far; but a separate /usr is pointless
> with a package managed distribution.  The creation of modern package
> managers rendered a separate /usr pointless right back in the mid
> '90s, but it's perhaps only in the last few years that we've
> collectively begun to fully appreciate the implications.
> 

But it is better to be able to.

> • "To enable recovery and/or repair of a system, those utilities
> needed by an experienced maintainer to diagnose and reconstruct a
> damaged system must be present on the root filesystem."
>   "To restore a system, those utilities needed to restore from system
> backups (on floppy, tape, etc.) must be present on the root
> filesystem."
> 
>   This is also fine; but having /usr on it does not affect this at
> all.

However this is affected by the rootfs reliability (below) where I
disagree with you.

> 
> • "The primary concern used to balance these considerations, which
> favor placing many things on the root filesystem, is the goal of
> keeping root as small as reasonably possible. For several reasons, it
> is desirable to keep the root filesystem small:"
> 
>"It is occasionally mounted from very small media."
> 
>What does "small" mean nowadays?  We are no longer booting rescue
>systems from floppy discs.  We are using ISO images on CDs/DVDs,
>USB pendrives, rescue partitions etc.  Realistically, these all
> have a capacity of half a gigabyte or more--more than plenty for an
> entire system.  We no longer have serious size limitations--all these
>methods involve the use of media whose size is much greater that
> the maximum HDD size when the FHS was first conceived!
> 

Why make an assumption that limits the system. Will this change be
applied to debian embedded.

> • "The root filesystem contains many system-specific configuration
> files. Possible examples include a kernel that is specific to the
> system, a specific hostname, etc. This means that the root filesystem
> isn't always shareable between networked systems. Keeping it small on
> servers in networked systems minimizes the amount of lost space for
> areas of unshareable files. It also allows workstations with smaller
> local hard drives."
> 
>   This part is, frankly, complete bollocks.  /usr is not, and *has
> never been* shareable at all, in reality.  It's technically possible
> of course, but this is to ignore the consequence of a modern package
>   manager.  That is to say, you /could/ do it, but it would be
>   unremittingly stupid.
> With a package manager, all filesystem locations under the control
>   of the package manager are a *unified whole*.  They are *managed*.
>   By the package manager.  It's not poss

Re: rootfs

[Roger Leigh]

On Sat, Apr 20, 2013 at 09:43:08PM +0100, Kevin Chadwick wrote:
> > I am, as a matter of fact, subscribed to the FHS list.  If you read
> > the specification, you'll see that it does not in any way require
> > /usr to be a *mountpoint*; it can be located on the root filesystem
> > without any problems.  It's actually the default partitioning method.
> > 
> 
> > Do you have any concrete reasons to have /usr separate from / ?
> 
> You need to look at the rootfs section, having them separate makes what
> should be the most critical filesystem (rootfs) 100s! of times larger
> and that quite rightly contradicts the spec (good reasons are mentioned
> but some more benefits of this practice could be included however).

The problem with the FHS here is that it's outdated with respect to
current hardware, the implication of package management, and current
admin practices, and is quite frankly wrong in some aspects.  Taking
each one in turn:

• "The contents of the root filesystem must be adequate to boot, restore,
   recover, and/or repair the system."

  No problems with this. However, having /usr on the rootfs does not
  interfere with this in any way.

• "To boot a system, enough must be present on the root partition to mount
   other filesystems. This includes utilities, configuration, boot loader
   information, and other essential start-up data. /usr, /opt, and /var are
   designed such that they may be located on other partitions or filesystems."

  The keyword here is "may".  /usr may be located on another filesystem,
  but there is not a strict requirement for that.  There's no "should" or
  "must" here.  Note that other distributions have removed the possibility
  for a separate /usr *entirely*.  I'm not suggesting we should go that
  far; but a separate /usr is pointless with a package managed
  distribution.  The creation of modern package managers rendered a
  separate /usr pointless right back in the mid '90s, but it's perhaps
  only in the last few years that we've collectively begun to fully
  appreciate the implications.

• "To enable recovery and/or repair of a system, those utilities needed by an
   experienced maintainer to diagnose and reconstruct a damaged system must be
   present on the root filesystem."
  "To restore a system, those utilities needed to restore from system backups
   (on floppy, tape, etc.) must be present on the root filesystem."

  This is also fine; but having /usr on it does not affect this at all.

• "The primary concern used to balance these considerations, which favor
   placing many things on the root filesystem, is the goal of keeping root as
   small as reasonably possible. For several reasons, it is desirable to keep
   the root filesystem small:"

   "It is occasionally mounted from very small media."

   What does "small" mean nowadays?  We are no longer booting rescue
   systems from floppy discs.  We are using ISO images on CDs/DVDs,
   USB pendrives, rescue partitions etc.  Realistically, these all have
   a capacity of half a gigabyte or more--more than plenty for an entire
   system.  We no longer have serious size limitations--all these
   methods involve the use of media whose size is much greater that the
   maximum HDD size when the FHS was first conceived!

• "The root filesystem contains many system-specific configuration files.
   Possible examples include a kernel that is specific to the system, a
   specific hostname, etc. This means that the root filesystem isn't always
   shareable between networked systems. Keeping it small on servers in
   networked systems minimizes the amount of lost space for areas of
   unshareable files. It also allows workstations with smaller local hard
   drives."

  This part is, frankly, complete bollocks.  /usr is not, and *has never
  been* shareable at all, in reality.  It's technically possible of
  course, but this is to ignore the consequence of a modern package
  manager.  That is to say, you /could/ do it, but it would be
  unremittingly stupid.
With a package manager, all filesystem locations under the control
  of the package manager are a *unified whole*.  They are *managed*.
  By the package manager.  It's not possible to share /usr between
  systems any more than /etc or /var.  That would get everything
  horribly out of sync, and has the potential to completely screw up
  horribly.  Think of how the dpkg database being inconsistent with the
  real state of /usr, the effect of maintainer scripts and multiple
  hosts all modifying a shared /usr, and you quickly realise that it
  just can't work.  Even if you share it read-only, no system can then
  update its rootfs or /var.
However, sharing the *entire* system read-only works very well,
  especially when coupled with a un

Re: rootfs

[Kevin Chadwick]

> I am, as a matter of fact, subscribed to the FHS list.  If you read
> the specification, you'll see that it does not in any way require
> /usr to be a *mountpoint*; it can be located on the root filesystem
> without any problems.  It's actually the default partitioning method.
> 

> Do you have any concrete reasons to have /usr separate from / ?

You need to look at the rootfs section, having them separate makes what
should be the most critical filesystem (rootfs) 100s! of times larger
and that quite rightly contradicts the spec (good reasons are mentioned
but some more benefits of this practice could be included however).

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___


-- 
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/350028.8692...@smtp105.mail.ird.yahoo.com

Re: rootfs

[Chris Bannister]

On Sat, Apr 20, 2013 at 10:50:05AM +0200, Raffaele Morelli wrote:
> 2013/4/20 Jude DaShiell 
> 
> > Sorry, wrong list for reply.
> 
> 
> ...though interesting :-)

Although, not quite correct:
http://www.lowellsmilecenter.com/blog/2008/02/04/calcium-and-stronger-teeth/

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


-- 
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/20130420162356.GA31934@tal

Re: rootfs

[Roger Leigh]

On Fri, Apr 19, 2013 at 08:09:24PM +0100, Kevin Chadwick wrote:
> > > /dev/mapper/debian-usr   4,6G  1,2G3,2G  28% /usr  
> > 
> > There's no real need to have /usr separate from /
> > You could potentially merge the two.
> 
> Unless you follow the installer, best practice and the Filesystem
> Hiearchical Standard then no not at all.
> 
> Don't believe opinion as fact just because it's on a server hosted by
> freedesktop.org. Rusty Russel and the FHS is a more authoritative (and
> correct) source, I suggest you read it.

I am, as a matter of fact, subscribed to the FHS list.  If you read
the specification, you'll see that it does not in any way require
/usr to be a *mountpoint*; it can be located on the root filesystem
without any problems.  It's actually the default partitioning method.

Do you have any concrete reasons to have /usr separate from / ?

It may be instructive to read
http://lists.debian.org/debian-devel/2011/01/msg00152.html
and the rest of the thread it is in.

Also note that in jessie, I plan to mount /usr in the initramfs
(the patches are already written) and to deprecate a separate
/usr.  This will make /usr available from before init starts
(the immediate goal), and potential unification of / and /usr
further down the line (jessie+1 or later).


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20130420095801.gj1...@codelibre.net

Re: rootfs

[Raffaele Morelli]

2013/4/20 Jude DaShiell 

> Sorry, wrong list for reply.


...though interesting :-)

Re: rootfs

[Jude DaShiell]

Sorry, wrong list for reply.
On Fri, 19 Apr 2013, Raffaele Morelli wrote:

> 2013/4/19 Darac Marjal 
> 
> >
> > That seems correct. Device nodes don't tend to take up any space. Now
> > try it again on the filesystem (like I showed you).
> >
> >
> Ok, here follows the "relevant" ouput.
> Apart from spf13 vim environment, that I can remove for root user, I guess
> my only choice would be a pruned custom kernel... am I wrong?
> 
> 6,6M/root/.spf13-vim-3/.vim/bundle/PIV/doc
> 6,8M/bin
> 7,1M/lib/modules/3.2.0-2-amd64/kernel/drivers/scsi
> 8,1M/lib/modules/3.2.0-2-amd64/kernel/net
> 9,2M/lib/x86_64-linux-gnu
> 12M /boot/initrd.img-3.2.0-2-amd64
> 12M /lib/modules/3.2.0-2-amd64/kernel/drivers/media
> 12M /lib/modules/3.2.0-2-amd64/kernel/fs
> 14M /root/.spf13-vim-3/.vim/bundle/PIV
> 17M /lib/modules/3.2.0-2-amd64/kernel/drivers/net
> 21M /boot
> 40M /root/.spf13-vim-3/.vim
> 40M /root/.spf13-vim-3/.vim/bundle
> 43M /root/.spf13-vim-3
> 45M /root
> 71M /lib/modules/3.2.0-2-amd64/kernel/drivers
> 100M/lib/modules/3.2.0-2-amd64/kernel
> 102M/lib/modules/3.2.0-2-amd64
> 103M/lib/modules
> 120M/lib
> 201M/
> 

---
jude 
Microsoft, windows is accessible. why do blind people need screen readers?


-- 
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/alpine.bsf.2.01.1304200251150.96...@freire1.furyyjbeyq.arg

Re: rootfs

[Jude DaShiell]

It's probable that the dental work that was done has misaligned several 
teeth which would account for the pain spreading to places it had not 
been before, everything either is connected or connects in the mouth by 
way of contacts when we eat which is why I suggested a follow up visit 
to find which teeth make which new contacts they should not make and get 
that corrected.  When I had my contact problem corrected the dentist 
changed the shape of my filling to solve that problem so it may not 
involve further damage to original dental material.  Finally when solid 
food is possible again, go for the jello and the string beans since your 
body will rebuild teeth with materials found in both those foods.  
Calcium may decrease pain for a while but isn't used in tooth 
construction or repair because teeth finger nails toe nails and hair are 
all from the same cellular group.  Bone is an entirely different 
cellular group.  Warm coffee room temperature with the cafiene will help 
with the pain since gums absorbe cafiene before it ever gets into your 
stomach.  So maybe hold that coffee in your mouth for a while and make 
it strong.  Wormwood bark was used in earlier times and was called 
toothache wood too.  Some people even used moss too.  There's clove oil, 
but that's dangerous to use and can't be used repeatedly on teeth.

On Fri, 19 Apr 2013, Raffaele Morelli wrote:

> 2013/4/19 Darac Marjal 
> 
> >
> > That seems correct. Device nodes don't tend to take up any space. Now
> > try it again on the filesystem (like I showed you).
> >
> >
> Ok, here follows the "relevant" ouput.
> Apart from spf13 vim environment, that I can remove for root user, I guess
> my only choice would be a pruned custom kernel... am I wrong?
> 
> 6,6M/root/.spf13-vim-3/.vim/bundle/PIV/doc
> 6,8M/bin
> 7,1M/lib/modules/3.2.0-2-amd64/kernel/drivers/scsi
> 8,1M/lib/modules/3.2.0-2-amd64/kernel/net
> 9,2M/lib/x86_64-linux-gnu
> 12M /boot/initrd.img-3.2.0-2-amd64
> 12M /lib/modules/3.2.0-2-amd64/kernel/drivers/media
> 12M /lib/modules/3.2.0-2-amd64/kernel/fs
> 14M /root/.spf13-vim-3/.vim/bundle/PIV
> 17M /lib/modules/3.2.0-2-amd64/kernel/drivers/net
> 21M /boot
> 40M /root/.spf13-vim-3/.vim
> 40M /root/.spf13-vim-3/.vim/bundle
> 43M /root/.spf13-vim-3
> 45M /root
> 71M /lib/modules/3.2.0-2-amd64/kernel/drivers
> 100M/lib/modules/3.2.0-2-amd64/kernel
> 102M/lib/modules/3.2.0-2-amd64
> 103M/lib/modules
> 120M/lib
> 201M/
> 

---
jude 
Microsoft, windows is accessible. why do blind people need screen readers?


-- 
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/alpine.bsf.2.01.1304200239250.96...@freire1.furyyjbeyq.arg

Re: rootfs

[Kevin Chadwick]

> > Don't believe opinion as fact just because it's on a server hosted
> > by freedesktop.org. Rusty Russel and the FHS is a more
> > authoritative (and correct) source, I suggest you read it.  
> 
> I never split up / and /usr for the last century or so and they are
> all working fine.

Wow, your 100 years old and you haven't understood the FHS yet ;-)

Working is not best practice.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___


-- 
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/20130420010759.4fd33...@kc-sys.chadwicks.me.uk

Re: rootfs

[Martin Steigerwald]

Am Freitag, 19. April 2013 schrieb Kevin Chadwick:
> > > Hi,
> > > 
> > > I have a debian wheezy server up, I would like to free some space
> > > on rootfs but can't guess how...
> > > Here follows the filesystem, any hints?
> > > 
> > > regrds
> > > /r
> > > 
> > > debian:~# df -h
> > > File system Dim. Usati Dispon. Uso% Montato su
> > > rootfs  322M  213M 93M  70% /
> > > /dev/mapper/debian-usr   4,6G  1,2G3,2G  28% /usr
> > 
> > There's no real need to have /usr separate from /
> > If you did, you would have gigabytes of free space to play with.
> > 
> > You could potentially merge the two.
> 
> Unless you follow the installer, best practice and the Filesystem
> Hiearchical Standard then no not at all.
> 
> Don't believe opinion as fact just because it's on a server hosted by
> freedesktop.org. Rusty Russel and the FHS is a more authoritative (and
> correct) source, I suggest you read it.

I never split up / and /usr for the last century or so and they are all 
working fine.

Fedora even unified /bin and /usr/bin as well as /sbin and /usr/sbin.

This is all not written in stone and people can and do have different 
opinions about that.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


-- 
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/201304192354.26395.mar...@lichtvoll.de

Re: rootfs

[Martin Steigerwald]

Am Freitag, 19. April 2013 schrieb Karl E. Jorgensen:
> Hi
> 
> On Fri, Apr 19, 2013 at 12:32:45PM +0100, Raffaele Morelli wrote:
> > Hi,
> > 
> > I have a debian wheezy server up, I would like to free some space on
> > rootfs but can't guess how...
> > Here follows the filesystem, any hints?
> > 
> > regrds
> > /r
> > 
> > debian:~# df -h
> > File system Dim. Usati Dispon. Uso% Montato su
> > rootfs  322M  213M 93M  70% /
> > udev 10M 0 10M   0% /dev
> > tmpfs   800M  228K800M   1% /run
> > /dev/mapper/debian-root  322M  213M 93M  70% /
> > tmpfs   5,0M 05,0M   0% /run/lock
> > tmpfs   368M   11M339M   3% /tmp
> > tmpfs   1,6G 01,6G   0% /run/shm
> > /dev/mapper/debian-home  519G   16G477G   4% /home
> > /dev/mapper/debian-tmp   368M   11M339M   3% /tmp
> > /dev/mapper/debian-usr   4,6G  1,2G3,2G  28% /usr
> > /dev/mapper/debian-var   2,8G  1,6G1,1G  61% /var
> 
> A usage of 213M on / is not bad at all.. and you already have /var and
> /tmp as separate file systems.
> 
> Note: something odd here: / and /tmp is listed twice!?
> 
> To see where space is being used, try this:
> 
>du -x -m / | sort -nr | head -25

With newer sort also the following works:

merkaba:~> du -x -h / | sort -rh | head -25
14G /
11G /usr
5,7G/usr/share
3,8G/usr/lib
2,8G/var
1,6G/usr/share/games
1,1G/var/log
946M/var/tmp
864M/var/log/journal/1354039e4d4bb8de4f97ac840004
864M/var/log/journal
797M/usr/lib/x86_64-linux-gnu
792M/usr/share/icons
687M/usr/bin
684M/usr/share/doc
508M/var/lib
505M/var/tmp/kdecache-martin
499M/usr/lib/debug
468M/usr/share/locale
456M/usr/lib/debug/.build-id
455M/usr/share/games/rocksndiamonds
390M/usr/share/games/rocksndiamonds/levels
385M/lib
367M/usr/share/kde4
352M/usr/share/kde4/apps
340M/lib/modules


Ah, and seems I will take a look at whats systemd doing in /var/log/journal 
and about whats going on in /var/tmp.

:)

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


-- 
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/201304192348.41869.mar...@lichtvoll.de

Re: rootfs

[Kevin Chadwick]

> > Hi,
> > 
> > I have a debian wheezy server up, I would like to free some space
> > on rootfs but can't guess how...
> > Here follows the filesystem, any hints?
> > 
> > regrds
> > /r
> > 
> > debian:~# df -h
> > File system Dim. Usati Dispon. Uso% Montato su
> > rootfs  322M  213M 93M  70% /
> > /dev/mapper/debian-usr   4,6G  1,2G3,2G  28% /usr  
> 
> There's no real need to have /usr separate from /
> If you did, you would have gigabytes of free space to play with.
> 
> You could potentially merge the two.

Unless you follow the installer, best practice and the Filesystem
Hiearchical Standard then no not at all.

Don't believe opinion as fact just because it's on a server hosted by
freedesktop.org. Rusty Russel and the FHS is a more authoritative (and
correct) source, I suggest you read it.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___


-- 
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/20130419200924.417ae...@kc-sys.chadwicks.me.uk

Re: rootfs

[Bob Proulx]

Raffaele Morelli wrote:
> Eduardo M KALINOWSKI wrote:
> > You seem to be using lvm. Can't you shrink another partition to grow root?
> 
> Yes I could... but I have never managed lvm and this is a production
> server..

You are using LVM.  You have plenty of space.  You just need to move
it around a little bit.

> /dev/mapper/debian-root  322M  213M 93M  70% /
> /dev/mapper/debian-usr   4,6G  1,2G3,2G  28% /usr
> /dev/mapper/debian-var   2,8G  1,6G1,1G  61% /var
> /dev/mapper/debian-home  519G   16G477G   4% /home

Unfortunately the debian-installer's default lvm allocation is a
little bit small for root.  And by default the last partition gets
*everything* else remaining on the disk.  That causes /home to be huge
and everything else to be small.  Small is okay.  Small is better than
too large.  Because it is easy to expand.  Shrinking is more difficult.

But you are using LVM and so can fix it up!  No problem!  You have
plenty of space.  Just not in the right place.

Please confirm that you are using ext3 for your filesystems.  That
would have been the default.  But you might have chosen something else
at installation time.

  df -T

Confirm that you don't have any free space left.

  # vgs
  VG   #PV #LV #SN Attr   VSize   VFree 
  v6 4  14   0 wz--n- 931.03g 44.34g

The VFree column shows unallocated LVM free space that can be applied
immediately.  I expect in your case it will either be zero or very
small.  The task is to make some free space so that it can be
allocated to root.

Since /home is the large bucket of space and only 16G used 4% then it
is the one to take from.  All of this can be done on the fly.  But
you said this is a production server.

If you could play with a non-production victim machine to gain
experience before working on the production machine it would be a lot
safer.  Or a VM.  Using a VM for this would be fine too.  Get
comfortable with the tasks elsewhere and then apply them to the
production machine.  This can be done with the server up and (mostly)
online.

First see that /home is not busy.  Because we must unmount it to
shrink it smaller.

  # lsof /home

Any output shows processes that are running and holding that mount
point busy.  As long as processes are running there the /home cannot
be unmounted.  But we need to be able to unmount it.

  # umount /home

That will fail if processes are running in /home.  So figure out what
is happening there and work around them.  Stop them.  Log people out.
Whatever.  That is not known to us.  Only you can know how to make
that mount point not busy so that it can be unmounted.

Assuming that you can umount /home then shrink it.  Noting that
/dev/mapper/debian-home is your device from the above then something
like this to reduce it to 100G since you are only using 14G at the
moment.  DO NOT REDUCE IT SMALLER THAN YOUR DATA SIZE!

  # umount /home
  # e2fsck -f /dev/mapper/debian-home
  # resize2fs -p -M /dev/mapper//debian-home
  The filesystem on /dev/mapper/debian-home is now  blocks long.
  # lvreduce -L50G /dev/mapper/debian-home
  # resize2fs -p /dev/mapper/debian-home
  # mount /home

Here are some comments about the above.  Unmount it.  It must be fsck
checked before resize2fs will work with it.  resize2fs -p to show
progress as it runs.  resize2fs -M to reduce the filesystem to minimum
size.  That will be near but somewhat larger than the 14G shown in the
df output.  There is some overhead that I haven't tracked.  lvreduce
to the fixed size that you want which must be larger than the minimum
filesystem size!  If you make it smaller then you will lose data.  But
make it enough larger to fit the data.  Then resize the filesystem
back up to fit the current size.

Having done that successfully then you will have free space that can
be allocated elsewhere.  That was the goal of the above.

  # vgs
  VG   #PV #LV #SN Attr   VSize   VFree  
  v1 3  11   0 wz--n- 931.03g 394.05g
  ^^^

Free space can then be allocated to the root or other filesystem.
That part is very easy.  It can be done on the fly without
unmounting.  Running tasks will never know.  There will just be more
filesystem space available.

Since you only have 322M on root I would be inclined to set the new
size to a fixed larger size instead of a relative incremental.  Let's
say you want the new size to be 3G.  Set the new larger size this
way.  Then resize to the larger size.  This is done on the fly.  You
have plenty of disk so I would be inclined to choose 3G for the root
partition size.  There is no right size.  It is a judgement call.

If you wanted 1G or 750M that would be fine too.  You can always grow
it again later.  Remember it is only shrinking that is a problem.  And
the root filesystem cannot be shrunk live by unmounting it.  The root
filesystem can only be shrunk by booting to rescue media and working
with it offline.  So do not make the root file system *too* large.

  # lvextend -L3G /dev/mappe

Re: rootfs

[Roger Leigh]

On Fri, Apr 19, 2013 at 01:32:45PM +0200, Raffaele Morelli wrote:
> Hi,
> 
> I have a debian wheezy server up, I would like to free some space on rootfs
> but can't guess how...
> Here follows the filesystem, any hints?
> 
> regrds
> /r
> 
> debian:~# df -h
> File system Dim. Usati Dispon. Uso% Montato su
> rootfs  322M  213M 93M  70% /
> /dev/mapper/debian-usr   4,6G  1,2G3,2G  28% /usr

There's no real need to have /usr separate from /
If you did, you would have gigabytes of free space to play with.

You could potentially merge the two.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20130419173648.gi1...@codelibre.net

Re: rootfs

[Roger Leigh]

On Fri, Apr 19, 2013 at 10:53:33AM -0600, Bob Proulx wrote:
> Karl E. Jorgensen wrote:
> > Raffaele Morelli wrote:
> > > rootfs  322M  213M 93M  70% /
> > > /dev/mapper/debian-root  322M  213M 93M  70% /
> > > tmpfs   368M   11M339M   3% /tmp
> > > /dev/mapper/debian-tmp   368M   11M339M   3% /tmp
> > 
> > Note: something odd here: / and /tmp is listed twice!?
> 
> Unfortunately that is the new normal due to the change of /etc/mtab
> from being a file that tracks the mount history to being a symlink
> pointing to /proc/mounts and the kernels current mount state file.  I
> consider this a collateral damage regression in behavior in Wheezy due
> to that change.  It will hopefully get fixed in a future version.

It's basically cosmetic--df needs updating to hide the extra mounts
and/or present the information better.  The main problem is that
the "rootfs" mount has the wrong information since stat reports
the information for the real root, since this is hiding the
initramfs.  I think a patch was already proposed for coreutils,
but I'm not sure if it's fixed upstream yet.  If it has been, it
should be fixed after wheezy is out.

> I haven't seen /tmp listed twice before but it is surely due to
> something related.  Mounted as tmpfs first the initramfs probably and
> then again differently in the fstab.  Perhaps doing a rebuild of the
> initramfs would cache different values.  Or perhaps it is listed in
> the /etc/fstab twice?

It's most likely that the definition in /etc/fstab doesn't match
the one expected by the initscripts (first field not the same),
so that it gets mounted twice.  See fstab(5) for the expected
format.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20130419173234.gh1...@codelibre.net

Re: rootfs

[Bob Proulx]

Karl E. Jorgensen wrote:
> Raffaele Morelli wrote:
> > rootfs  322M  213M 93M  70% /
> > /dev/mapper/debian-root  322M  213M 93M  70% /
> > tmpfs   368M   11M339M   3% /tmp
> > /dev/mapper/debian-tmp   368M   11M339M   3% /tmp
> 
> Note: something odd here: / and /tmp is listed twice!?

Unfortunately that is the new normal due to the change of /etc/mtab
from being a file that tracks the mount history to being a symlink
pointing to /proc/mounts and the kernels current mount state file.  I
consider this a collateral damage regression in behavior in Wheezy due
to that change.  It will hopefully get fixed in a future version.

The kernel mounts the root file system based upon the command line
parameters passed in by grub in the root=STRING argument.  That causes
the initrd to mount / the first time.  Then later it is re-mounted due
to it being listed in the /etc/fstab.  That is the second time.

I haven't seen /tmp listed twice before but it is surely due to
something related.  Mounted as tmpfs first the initramfs probably and
then again differently in the fstab.  Perhaps doing a rebuild of the
initramfs would cache different values.  Or perhaps it is listed in
the /etc/fstab twice?

This isn't bad on LVM systems because the names are short.  But on
UUID mounts the line is too long for comfort.

Bob

P.S. See also this recent posting.

  https://lists.debian.org/debian-user/2013/04/msg00253.html


signature.asc
Description: Digital signature

Re: rootfs

[Bob Proulx]

basti wrote:
> You can also use "ncdu".
> Man Page says:
> 
> ncdu (NCurses Disk Usage) is a curses-based version of the well-known
> 'du', and provides a fast way to see what directories are using your
> disk space.

Cool!  I hadn't seen that before.  Checking it out now.

I have been recommending 'xdu'.  It reads output from du.  Although
you can usually pipe it I tend to run du on the server and then copy
the file back to look at it offline.  Then I can browse in and out of
it repeatedly and just use the cached data file.

  ssh -n server du -xml / > /tmp/du-xml.root.out
  xdu /tmp/du-xml.root.out

Bob

NAME
   xdu - display the output of "du" in an X window

SYNOPSIS
   du | xdu [options]

DESCRIPTION
   Xdu is a program for displaying a graphical tree of disk space
   utilization as reported by the UNIX utility "du".  The user can
   navigate through the tree structure and change the order of the
   displayed information.  The window is divided up into several
   columns, each of which is one level deeper in the directory
   hierarchy (from left to right).  Boxes are drawn for each
   directory.  The amount of vertical space occupied by each box
   is directly proportional to the amount of disk space consumed
   by it and all of its children.  The name of each directory and


signature.asc
Description: Digital signature

Re: rootfs

[Kevin Chadwick]

> I haven't actually looked at your layout but copy something like /opt
> to /usr (where it should be anyway in my opinion) and bind mount it.

Sorry move it!

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___


-- 
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/502087.43169...@smtp176.mail.ir2.yahoo.com

Re: rootfs

[Kevin Chadwick]

> >> Ok, here follows the "relevant" ouput.
> >> Apart from spf13 vim environment, that I can remove for root user, I guess
> >> my only choice would be a pruned custom kernel... am I wrong?
> >>  
> >
> > You seem to be using lvm. Can't you shrink another partition to grow root?  
> 
> 
> Yes I could... but I have never managed lvm and this is a production
> server..

I haven't actually looked at your layout but copy something like /opt
to /usr (where it should be anyway in my opinion) and bind mount it.

I did that when the pinned firefox broke to make space for Google
Chrome.

I've got to get around to getting firefox back it's much more
easily configurable and much better than chrome especially in js
management with noscript.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)
___


-- 
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/366797.53392...@smtp206.mail.ir2.yahoo.com

Re: rootfs

[Raffaele Morelli]

2013/4/19 Karl E. Jorgensen 

> Hi
>
> On Fri, Apr 19, 2013 at 12:32:45PM +0100, Raffaele Morelli wrote:
> > Hi,
> >
> > I have a debian wheezy server up, I would like to free some space on
> rootfs but
> > can't guess how...
> > Here follows the filesystem, any hints?
> >
> > regrds
> > /r
> >
> > debian:~# df -h
> > File system Dim. Usati Dispon. Uso% Montato su
> > rootfs  322M  213M 93M  70% /
> > udev 10M 0 10M   0% /dev
> > tmpfs   800M  228K800M   1% /run
> > /dev/mapper/debian-root  322M  213M 93M  70% /
> > tmpfs   5,0M 05,0M   0% /run/lock
> > tmpfs   368M   11M339M   3% /tmp
> > tmpfs   1,6G 01,6G   0% /run/shm
> > /dev/mapper/debian-home  519G   16G477G   4% /home
> > /dev/mapper/debian-tmp   368M   11M339M   3% /tmp
> > /dev/mapper/debian-usr   4,6G  1,2G3,2G  28% /usr
> > /dev/mapper/debian-var   2,8G  1,6G1,1G  61% /var
>
> A usage of 213M on / is not bad at all.. and you already have /var and
> /tmp as separate file systems.
>

yes, not so bad but I would prefer more, just a little :-)


>
> Note: something odd here: / and /tmp is listed twice!?
>

Can't tell why, we had a energy lack in the middle of an upgrade/remove
process, I did my best to recover the server integrity
I have access to the server room (not at the moment, but in the next days)
so ASAP I will reboot and install a new kernel


>
> To see where space is being used, try this:
>
>du -x -m / | sort -nr | head -25
>
> This should list the biggest directories first and give you an idea of
> where space is being used.  But since you do not have a separate
> /home, I guess that this may account for some things...
>

# du -x -m / | sort -nr | head -25
159 /
120 /lib
103 /lib/modules
102 /lib/modules/3.2.0-2-amd64
100 /lib/modules/3.2.0-2-amd64/kernel
71  /lib/modules/3.2.0-2-amd64/kernel/drivers
21  /boot
17  /lib/modules/3.2.0-2-amd64/kernel/drivers/net
12  /lib/modules/3.2.0-2-amd64/kernel/fs
12  /lib/modules/3.2.0-2-amd64/kernel/drivers/media
10  /lib/x86_64-linux-gnu
9   /lib/modules/3.2.0-2-amd64/kernel/net
8   /lib/modules/3.2.0-2-amd64/kernel/drivers/scsi
7   /lib/modules/3.2.0-2-amd64/kernel/sound
7   /lib/modules/3.2.0-2-amd64/kernel/drivers/net/wireless
7   /lib/modules/3.2.0-2-amd64/kernel/drivers/net/ethernet
7   /bin
6   /sbin
6   /lib/modules/3.2.0-2-amd64/kernel/drivers/media/video
5   /lib/modules/3.2.0-2-amd64/kernel/sound/pci
5   /lib/modules/3.2.0-2-amd64/kernel/drivers/staging
5   /boot/grub
4   /lib/modules/3.2.0-2-amd64/kernel/drivers/usb
4   /lib/modules/3.2.0-2-amd64/kernel/drivers/media/dvb
4   /lib/modules/3.2.0-2-amd64/kernel/drivers/gpu/drm

Re: rootfs

[Karl E. Jorgensen]

Hi

On Fri, Apr 19, 2013 at 12:32:45PM +0100, Raffaele Morelli wrote:
> Hi,
> 
> I have a debian wheezy server up, I would like to free some space on rootfs 
> but
> can't guess how...
> Here follows the filesystem, any hints?
> 
> regrds
> /r
> 
> debian:~# df -h
> File system Dim. Usati Dispon. Uso% Montato su
> rootfs  322M  213M 93M  70% /
> udev 10M 0 10M   0% /dev
> tmpfs   800M  228K800M   1% /run
> /dev/mapper/debian-root  322M  213M 93M  70% /
> tmpfs   5,0M 05,0M   0% /run/lock
> tmpfs   368M   11M339M   3% /tmp
> tmpfs   1,6G 01,6G   0% /run/shm
> /dev/mapper/debian-home  519G   16G477G   4% /home
> /dev/mapper/debian-tmp   368M   11M339M   3% /tmp
> /dev/mapper/debian-usr   4,6G  1,2G3,2G  28% /usr
> /dev/mapper/debian-var   2,8G  1,6G1,1G  61% /var

A usage of 213M on / is not bad at all.. and you already have /var and /tmp as 
separate file systems.

Note: something odd here: / and /tmp is listed twice!?

To see where space is being used, try this:

   du -x -m / | sort -nr | head -25

This should list the biggest directories first and give you an idea of
where space is being used.  But since you do not have a separate
/home, I guess that this may account for some things...




-- 
Karl E. Jorgensen


-- 
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/20130419114127.GC6491@hawking

Re: rootfs

[Raffaele Morelli]

2013/4/19 Eduardo M KALINOWSKI 

> On Sex, 19 Abr 2013, Raffaele Morelli wrote:
>
>> Ok, here follows the "relevant" ouput.
>> Apart from spf13 vim environment, that I can remove for root user, I guess
>> my only choice would be a pruned custom kernel... am I wrong?
>>
>
> You seem to be using lvm. Can't you shrink another partition to grow root?


Yes I could... but I have never managed lvm and this is a production
server..

/r

Re: rootfs

[Pascal Hambourg]

Hello,

Raffaele Morelli a écrit :
> 
> I have a debian wheezy server up, I would like to free some space on rootfs
> but can't guess how...
> Here follows the filesystem, any hints?
> 
> debian:~# df -h
> File system Dim. Usati Dispon. Uso% Montato su
> rootfs  322M  213M 93M  70% /
> udev 10M 0 10M   0% /dev
> tmpfs   800M  228K800M   1% /run
> /dev/mapper/debian-root  322M  213M 93M  70% /
> tmpfs   5,0M 05,0M   0% /run/lock
> tmpfs   368M   11M339M   3% /tmp
> tmpfs   1,6G 01,6G   0% /run/shm
> /dev/mapper/debian-home  519G   16G477G   4% /home
> /dev/mapper/debian-tmp   368M   11M339M   3% /tmp
> /dev/mapper/debian-usr   4,6G  1,2G3,2G  28% /usr
> /dev/mapper/debian-var   2,8G  1,6G1,1G  61% /var

Check and remove or uninstall old unused kernels and modules in /boot
and /lib/modules.
Check in /root, /opt, /srv for contents that may be moved or removed.


-- 
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/517135f2.5030...@plouf.fr.eu.org

Re: rootfs

[Eduardo M KALINOWSKI]

On Sex, 19 Abr 2013, Raffaele Morelli wrote:

Ok, here follows the "relevant" ouput.
Apart from spf13 vim environment, that I can remove for root user, I guess
my only choice would be a pruned custom kernel... am I wrong?


You seem to be using lvm. Can't you shrink another partition to grow root?

--
Formatted to fit your screen.

Eduardo M KALINOWSKI
edua...@kalinowski.com.br



--
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/20130419122928.horde.dxs6eorx6rip9retpogd...@mail.kalinowski.com.br

Re: rootfs

[Raffaele Morelli]

2013/4/19 Darac Marjal 

>
> That seems correct. Device nodes don't tend to take up any space. Now
> try it again on the filesystem (like I showed you).
>
>
Ok, here follows the "relevant" ouput.
Apart from spf13 vim environment, that I can remove for root user, I guess
my only choice would be a pruned custom kernel... am I wrong?

6,6M/root/.spf13-vim-3/.vim/bundle/PIV/doc
6,8M/bin
7,1M/lib/modules/3.2.0-2-amd64/kernel/drivers/scsi
8,1M/lib/modules/3.2.0-2-amd64/kernel/net
9,2M/lib/x86_64-linux-gnu
12M /boot/initrd.img-3.2.0-2-amd64
12M /lib/modules/3.2.0-2-amd64/kernel/drivers/media
12M /lib/modules/3.2.0-2-amd64/kernel/fs
14M /root/.spf13-vim-3/.vim/bundle/PIV
17M /lib/modules/3.2.0-2-amd64/kernel/drivers/net
21M /boot
40M /root/.spf13-vim-3/.vim
40M /root/.spf13-vim-3/.vim/bundle
43M /root/.spf13-vim-3
45M /root
71M /lib/modules/3.2.0-2-amd64/kernel/drivers
100M/lib/modules/3.2.0-2-amd64/kernel
102M/lib/modules/3.2.0-2-amd64
103M/lib/modules
120M/lib
201M/

Re: rootfs

[Alex Mestiashvili]

On 04/19/2013 01:32 PM, Raffaele Morelli wrote:
> Hi,
> 
> I have a debian wheezy server up, I would like to free some space on
> rootfs but can't guess how...
> Here follows the filesystem, any hints?
> 
> regrds
> /r
> 
> debian:~# df -h
> File system Dim. Usati Dispon. Uso% Montato su
> rootfs  322M  213M 93M  70% /
> udev 10M 0 10M   0% /dev
> tmpfs   800M  228K800M   1% /run
> /dev/mapper/debian-root  322M  213M 93M  70% /
> tmpfs   5,0M 05,0M   0% /run/lock
> tmpfs   368M   11M339M   3% /tmp
> tmpfs   1,6G 01,6G   0% /run/shm
> /dev/mapper/debian-home  519G   16G477G   4% /home
> /dev/mapper/debian-tmp   368M   11M339M   3% /tmp
> /dev/mapper/debian-usr   4,6G  1,2G3,2G  28% /usr
> /dev/mapper/debian-var   2,8G  1,6G1,1G  61% /var


Hello,

I would check how many kernels&modules you have installed.

check it with:

  dpkg -l | grep linux-image

if you see a bunch of old versions, than feel free to purge
them(aptitude purge linux-image-...)

leave the one you currently use (uname -a) and one before - just to be
on the safe side ( may be you need to roll back on the ld version in
case something doesn't work with new one for example )

Hope it helps.

Alex


-- 
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/517135f9.4070...@biotec.tu-dresden.de

Re: rootfs

[basti]

You can also use "ncdu".
Man Page says:

ncdu (NCurses Disk Usage) is a curses-based version of the well-known
'du', and provides a fast way to see what directories are using your
disk space.



Am 19.04.2013 13:55, schrieb Raffaele Morelli:
> 2013/4/19 Darac Marjal 
>
>> On Fri, Apr 19, 2013 at 01:32:45PM +0200, Raffaele Morelli wrote:
>>>Hi,
>>>I have a debian wheezy server up, I would like to free some space on
>>>rootfs but can't guess how...
>>>Here follows the filesystem, any hints?
>> You have 213Mb in your root file system, that seems fairly small to me
>> (especially as you have 477Gb kicking around free in your /home, but
>> that's not what you asked)
>>
> it's a quite long story to tell but that's the result...
>
>
>> Try "sudo du -ahx / | sort -h" to get a listing of file and directory
>> sizes on that partition. Maybe it can give you some clue as to where to
>> trim.
>>
> debian:~# du -ahx /dev/mapper/debian-root | sort -h
> 0   /dev/mapper/debian-root
>
> /r
>


-- 
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/5171327e.3070...@arcor.de

Re: rootfs

[Darac Marjal]

On Fri, Apr 19, 2013 at 01:55:06PM +0200, Raffaele Morelli wrote:
>2013/4/19 Darac Marjal <[1]mailingl...@darac.org.uk>
> 
>  On Fri, Apr 19, 2013 at 01:32:45PM +0200, Raffaele Morelli wrote:
>  > � �Hi,
>  > � �I have a debian wheezy server up, I would like to free some space
>  on
>  > � �rootfs but can't guess how...
>  > � �Here follows the filesystem, any hints?
> 
>  You have 213Mb in your root file system, that seems fairly small to me
>  (especially as you have 477Gb kicking around free in your /home, but
>  that's not what you asked)
> 
>it's a quite long story to tell but that's the result...
>�
> 
>  Try "sudo du -ahx / | sort -h" to get a listing of file and directory
>  sizes on that partition. Maybe it can give you some clue as to where to
>  trim.
> 
>debian:~# du -ahx /dev/mapper/debian-root | sort -h
>0 � � � /dev/mapper/debian-root
>/r

That seems correct. Device nodes don't tend to take up any space. Now
try it again on the filesystem (like I showed you).



signature.asc
Description: Digital signature

Re: rootfs

[Raffaele Morelli]

2013/4/19 Darac Marjal 

> On Fri, Apr 19, 2013 at 01:32:45PM +0200, Raffaele Morelli wrote:
> >Hi,
> >I have a debian wheezy server up, I would like to free some space on
> >rootfs but can't guess how...
> >Here follows the filesystem, any hints?
>
> You have 213Mb in your root file system, that seems fairly small to me
> (especially as you have 477Gb kicking around free in your /home, but
> that's not what you asked)
>

it's a quite long story to tell but that's the result...


>
> Try "sudo du -ahx / | sort -h" to get a listing of file and directory
> sizes on that partition. Maybe it can give you some clue as to where to
> trim.
>

debian:~# du -ahx /dev/mapper/debian-root | sort -h
0   /dev/mapper/debian-root

/r

Re: rootfs

[Darac Marjal]

On Fri, Apr 19, 2013 at 01:32:45PM +0200, Raffaele Morelli wrote:
>Hi,
>I have a debian wheezy server up, I would like to free some space on
>    rootfs but can't guess how...
>Here follows the filesystem, any hints?

You have 213Mb in your root file system, that seems fairly small to me
(especially as you have 477Gb kicking around free in your /home, but
that's not what you asked)

Try "sudo du -ahx / | sort -h" to get a listing of file and directory
sizes on that partition. Maybe it can give you some clue as to where to
trim.



signature.asc
Description: Digital signature

rootfs

[Raffaele Morelli]

Hi,

I have a debian wheezy server up, I would like to free some space on rootfs
but can't guess how...
Here follows the filesystem, any hints?

regrds
/r

debian:~# df -h
File system Dim. Usati Dispon. Uso% Montato su
rootfs  322M  213M 93M  70% /
udev 10M 0 10M   0% /dev
tmpfs   800M  228K800M   1% /run
/dev/mapper/debian-root  322M  213M 93M  70% /
tmpfs   5,0M 05,0M   0% /run/lock
tmpfs   368M   11M339M   3% /tmp
tmpfs   1,6G 01,6G   0% /run/shm
/dev/mapper/debian-home  519G   16G477G   4% /home
/dev/mapper/debian-tmp   368M   11M339M   3% /tmp
/dev/mapper/debian-usr   4,6G  1,2G3,2G  28% /usr
/dev/mapper/debian-var   2,8G  1,6G1,1G  61% /var

Re: rootfs mounted twice

[hvw59601]

Sven Joachim wrote:

On 2012-06-09 16:07 +0200, Roman V.Leon. wrote:


Please give me a tip - is it normal that i see in 'df -h' output that
my rootfs is mounted twice ?:


Yes, that's normal.  You did not see it in the past when /etc/mtab was a
regular file, but now /etc/mtab is a symlink to /proc/mounts.

See http://bugs.debian.org/656333 for the gory details.



That explains it. Thanks.

Hugo


--
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/jqvtvd$bbg$1...@dough.gmane.org

Re: rootfs mounted twice

[Mika Suomalainen]

On 09.06.2012 17:07, Roman V.Leon. wrote:
> Hello gents.
> Please give me a tip - is it normal that i see in 'df -h' output that my
> rootfs is mounted twice ?:
> 
> $ df -h
> 
> rootfs 97G   34G   59G  37% /
> 
> /dev/disk/by-uuid/a863f3c2-ddaf-4c23-9d56-51245edbe394   97G   34G   59G
>  37% /
> 
> 
> Thanks.
> 

I think that it's normal and same happens for me.

```
% df -h
Filesystem      Size  Used Avail
Use% Mounted on
rootfs  236G   57G  167G
 26% /
udev1,8G 0  1,8G
  0% /dev
tmpfs   714M 1008K  713M
  1% /run
/dev/disk/by-uuid/dc9acb8c-949a-418b-b044-5164a8d82dcc  236G   57G  167G
 26% /
tmpfs   1,8G  1,9M  1,8G
  1% /dev/shm
tmpfs   1,8G 0  1,8G
  0% /sys/fs/cgroup
tmpfs   1,8G 0  1,8G
  0% /media
tmpfs   1,8G  1,9M  1,8G
  1% /run/shm
```

-- 
[Mika Suomalainen](https://mkaysi.github.com/) ||
[gpg --keyserver pool.sks-keyservers.net --recv-keys
4DB53CFE82A46728](http://mkaysi.github.com/PGP/key.txt) ||
[Why do I sign my
emails?](http://mkaysi.github.com/PGP/WhyDoISignEmails.html) ||
[Please don't send
HTML.](http://mkaysi.github.com/articles/complaining/HTML.html) ||
[This signature](https://gist.github.com/2643070#file_icedove.md) ||

[Please reply below this
line](http://mkaysi.github.com/articles/complaining/topposting.html)





signature.asc
Description: OpenPGP digital signature

Re: rootfs mounted twice

[Roman V.Leon.]

On 09.06.2012 18:49, Sven Joachim wrote:

On 2012-06-09 16:07 +0200, Roman V.Leon. wrote:


Please give me a tip - is it normal that i see in 'df -h' output that
my rootfs is mounted twice ?:


Yes, that's normal.  You did not see it in the past when /etc/mtab was a
regular file, but now /etc/mtab is a symlink to /proc/mounts.

See http://bugs.debian.org/656333 for the gory details.


Oh I get it now. Thank you, Sven

--
Cheers,
Roman V.Leon.


--
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/4fd365fc.60...@meta.ua

Re: rootfs mounted twice

[Sven Joachim]

On 2012-06-09 16:07 +0200, Roman V.Leon. wrote:

> Please give me a tip - is it normal that i see in 'df -h' output that
> my rootfs is mounted twice ?:

Yes, that's normal.  You did not see it in the past when /etc/mtab was a
regular file, but now /etc/mtab is a symlink to /proc/mounts.

See http://bugs.debian.org/656333 for the gory details.

Cheers,
   Sven


-- 
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/874nqkilr4@turtle.gmx.de

rootfs mounted twice

[Roman V.Leon.]

Hello gents.
Please give me a tip - is it normal that i see in 'df -h' output that my 
rootfs is mounted twice ?:


$ df -h
....
rootfs 97G   34G   59G  37% /

/dev/disk/by-uuid/a863f3c2-ddaf-4c23-9d56-51245edbe394   97G   34G   59G 
 37% /



Thanks.

--
Cheers,
Roman V.Leon.


--
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/4fd35884.2030...@meta.ua

Re: rootfs on SSD

[Andrei Popescu]

On Mi, 11 mai 11, 12:05:01, Rainer Dorsch wrote:
> 
> I tested three setups:
> 
> 1) Setup: rootflags and UUID fstab entry (the one I had before): 
> Result: no configured options for root filesystem
> 
> rd@blackbox:~$ cat /proc/cmdline 
> BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686-bigmem 
> root=UUID=4a4eb948-2d2b-4188-96ae-76a3776ae69c ro quiet elevator=noop 
> rootflags=noatime,discard,data=ordered,errors=remount-ro
> rd@blackbox:~$
> 
> from /etc/fstab:
> UUID="4a4eb948-2d2b-4188-96ae-76a3776ae69c" /ext4 
>  
> noatime,discard,data=ordered,errors=remount-ro 0   1
> 
> rd@blackbox:~$ mount
> rootfs on / type rootfs (rw)
^^
This doesn't make sense. Could you try removing the quotes from the 
UUID="" entry in fstab?
 
> The result of the third configuration (and to some extend also the first 
> configuration) is unexpected for me in the bug report from Ted Tso:
> 
> "[...] Debian simply doesn't support the mount options for the root file
> system in /etc/fstab having any effect on how the root file system is
> mounted.  The root file system is mounted by the kernel, and the mount
> options used by the kernel are specified by the rootflags= option on
> the kernel's boot command line. [...]"
> 
> Does anybody understand how both, my data and Ted's report make sense?
> 
> Can we be sure that the output of the mount command reflects the system state 
> (or does it even display wrong information in some configurations I did)?

AFAICT 'mount' displays (more or less) the contents of /etc/mtab, which 
may under certain conditions not be up-to-date. /proc/mounts is more 
accurate, but I doubt in your case this is an issue.

As for the options in /etc/fstab being applied or not, if you read the 
thread on debian-devel, it was pointed out that Debian's initscript(s) 
will remount the root fs with the options from /etc/fstab, it's just 
that some options can not be changed on a *remount*. For those 
particular options you will have to use either rootflags or tune2fs.

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: rootfs on SSD

[Thilo Six]

Rainer Dorsch wrote the following on 11.05.2011 12:05

> Am Montag, 9. Mai 2011 schrieb Thilo Six:
>> Andrei Popescu wrote the following on 09.05.2011 09:18
>>
>>>> rd@blackbox:~$ mount|grep rootfs
>>>> rootfs on / type rootfs (rw)
>>>> rd@blackbox:~$
>>>
>>> I don't have any 'rootfs' in the output of mount, instead I have this:
>>>
>>> /dev/sda6 on / type ext3 (rw,noatime,errors=remount-ro,commit=0)
>>>
>>> I have a feeling there's more to your setup that is missing here. Could
>>> you please post your complete /etc/fstab and full output of 'mount'?
>>>
>>> Regards,
>>> Andrei
>>
>> and the content of '/boot/grub/device.map'
> 
> Thank you for your replies.
> 
> Maybe the /boot/grub/device.map is interesting, because the SSD (sdc) is 
> missing in there (!):
> 
> blackbox:~# cat /boot/grub/device.map 
> (hd0)   /dev/disk/by-id/ata-ST3120023A_3KA1BNGQ
> (hd1)   /dev/disk/by-id/ata-SAMSUNG_HD501LJ_S0MUJ1FPB79563
> blackbox:~# 
> 
> How is the device.map file updated? By whom?

man grub-mkdevicemap

-- 
bye Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6  7C18 89A4 A2A0 C70B 1A8F



-- 
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/iqedk5$mp8$1...@dough.gmane.org

Re: rootfs on SSD

[Rainer Dorsch]

Am Montag, 9. Mai 2011 schrieb Thilo Six:
> Andrei Popescu wrote the following on 09.05.2011 09:18
> 
> >> rd@blackbox:~$ mount|grep rootfs
> >> rootfs on / type rootfs (rw)
> >> rd@blackbox:~$
> > 
> > I don't have any 'rootfs' in the output of mount, instead I have this:
> > 
> > /dev/sda6 on / type ext3 (rw,noatime,errors=remount-ro,commit=0)
> > 
> > I have a feeling there's more to your setup that is missing here. Could
> > you please post your complete /etc/fstab and full output of 'mount'?
> > 
> > Regards,
> > Andrei
> 
> and the content of '/boot/grub/device.map'

Thank you for your replies.

Maybe the /boot/grub/device.map is interesting, because the SSD (sdc) is 
missing in there (!):

blackbox:~# cat /boot/grub/device.map 
(hd0)   /dev/disk/by-id/ata-ST3120023A_3KA1BNGQ
(hd1)   /dev/disk/by-id/ata-SAMSUNG_HD501LJ_S0MUJ1FPB79563
blackbox:~# 

How is the device.map file updated? By whom?

The information Andrei asked for is also not fully conclusive for me in 
particular in conjunction with the Ted Tso's bug report 
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=9;bug=616317 as pointed out 
by Florian [the full data are appended]:

I tested three setups:

1) Setup: rootflags and UUID fstab entry (the one I had before): 
Result: no configured options for root filesystem

rd@blackbox:~$ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686-bigmem 
root=UUID=4a4eb948-2d2b-4188-96ae-76a3776ae69c ro quiet elevator=noop 
rootflags=noatime,discard,data=ordered,errors=remount-ro
rd@blackbox:~$

from /etc/fstab:
UUID="4a4eb948-2d2b-4188-96ae-76a3776ae69c" /ext4   
   
noatime,discard,data=ordered,errors=remount-ro 0   1

rd@blackbox:~$ mount
rootfs on / type rootfs (rw)
[...]

2) Setup: rootflags and /dev/... fstab entry
Result: root filesystem gets configured options
(in addition the findfs issue goes away, I posted at 
http://lists.debian.org/debian-user/2011/05/msg00544.html )

rd@blackbox:~$ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686-bigmem 
root=UUID=4a4eb948-2d2b-4188-96ae-76a3776ae69c ro quiet elevator=noop 
rootflags=noatime,discard,data=ordered,errors=remount-ro

From /etc/fstab:
/dev/disk/by-uuid/4a4eb948-2d2b-4188-96ae-76a3776ae69c/
ext4  noatime,discard,data=ordered,errors=remount-ro 0   1


rd@blackbox:~$ mount
/dev/sdc1 on / type ext4 (rw,noatime,discard,data=ordered,errors=remount-ro)

3) Setup: no rootfsflags and /dev/... fstab entry
Result: root filesystem gets configured options

rd@blackbox:~$ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686-bigmem 
root=UUID=4a4eb948-2d2b-4188-96ae-76a3776ae69c ro quiet elevator=noop

from /etc/fstab:
/dev/disk/by-uuid/4a4eb948-2d2b-4188-96ae-76a3776ae69c/
ext4  noatime,discard,data=ordered,errors=remount-ro 0   1

rd@blackbox:~$ mount
/dev/sdc1 on / type ext4 (rw,noatime,discard,data=ordered,errors=remount-ro)


The result of the third configuration (and to some extend also the first 
configuration) is unexpected for me in the bug report from Ted Tso:

"[...] Debian simply doesn't support the mount options for the root file
system in /etc/fstab having any effect on how the root file system is
mounted.  The root file system is mounted by the kernel, and the mount
options used by the kernel are specified by the rootflags= option on
the kernel's boot command line. [...]"

Does anybody understand how both, my data and Ted's report make sense?

Can we be sure that the output of the mount command reflects the system state 
(or does it even display wrong information in some configurations I did)?

Many thanks,
Rainer


Full outputs:

### rootflags and UUID fstag entry
==
rd@blackbox:~$ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686-bigmem 
root=UUID=4a4eb948-2d2b-4188-96ae-76a3776ae69c ro quiet elevator=noop 
rootflags=noatime,discard,data=ordered,errors=remount-ro
rd@blackbox:~$ mount
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
rootfs on / type rootfs (rw)
/dev/sdb7 on /mnt/disk/home type ext3 (rw)
/dev/sdc2 on /home type ext4 (rw,noatime,discard,data=ordered)
/dev/sdb6 on /mnt/disk/opt type ext3 (rw)
/dev/sdb8 on /mnt/disk/exchange type ext3 (rw)
tmpfs on /tmp type tmpfs (rw,noexec,nosuid,nodev,mode=1777)
fusectl on /sys/fs/fuse/connections type fusectl (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/scratchbox on /scratchbox/users/rd/scratchbox type none (rw,bind)
/tmp on /scratchbox/users/rd/tmp type none (rw,bind)
/proc on /scratchbox/users/rd/proc 

Re: findfs does not find rootfs UUID [solved]

[Rainer Dorsch]

Am Sonntag, 8. Mai 2011 schrieb Rainer Dorsch:
> Am Sonntag, 8. Mai 2011 schrieb Rainer Dorsch:
> > Hello,
> > 
> > I moved my root partition to a new SSD and used ext4 as filesystem.
> > Everything works well, except that I get an error message during boot
> > (which I think was not there before):
> > 
> > findfs: Unable to resolve ...
> > 
> > http://bokomoko.de/~rd/ext4-rootfs-uuid/IMG_6119.JPG
> > 
> > for my root partition. The system boot without a problem though, and when
> > booted findfs works out ok:
> > 
> > blackbox:~# findfs UUID="4a4eb948-2d2b-4188-96ae-76a3776ae69c"
> > /dev/sdb1
> > blackbox:~#
> > 
> > Should I be concerned about this issue?
> 
> Here are some more details:
> 
> From /boot/grub/grub.cfg
> 
> menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-686-bigmem' --class debian
> -- class gnu-linux --class gnu --class os {
> insmod part_msdos
> insmod ext2
> set root='(/dev/sdb,msdos1)'
> search --no-floppy --fs-uuid --set
> 4a4eb948-2d2b-4188-96ae-76a3776ae69c echo'Loading Linux
> 2.6.32-5-686-bigmem ...'
> linux   /boot/vmlinuz-2.6.32-5-686-bigmem
> root=UUID=4a4eb948-2d2b-4188-96ae-76a3776ae69c ro quiet quiet elevator=noop
> echo'Loading initial ramdisk ...'
> initrd  /boot/initrd.img-2.6.32-5-686-bigmem
> }
> 
> from /var/log/boot:
> 
> Sun May  8 15:08:02 2011: Setting parameters of disc:  /dev/sda.
> Sun May  8 15:08:02 2011:   /dev/sdb.
> Sun May  8 15:08:02 2011: findfs: unable to resolve
> 'UUID="4a4eb948-2d2b-4188-96ae-76a3776ae69c"'
> Sun May  8 15:08:02 2011: Activating swap...done.
> Sun May  8 15:08:02 2011: Usage: mountpoint [-q] [-d] [-x] path
> Sun May  8 15:08:02 2011: Checking root file system...fsck from
> util-linux-ng 2.17.2
> Sun May  8 15:08:02 2011: root_ssd: clean, 878324/3055616 files,
> 6715280/12207384 blocks
> Sun May  8 15:08:02 2011: done.
> Sun May  8 15:08:02 2011: Usage: mount -V : print version
> Sun May  8 15:08:02 2011:mount -h : print this help
> Sun May  8 15:08:02 2011:mount: list mounted
> filesystems
> Sun May  8 15:08:02 2011:mount -l : idem, including
> volume labels
> Sun May  8 15:08:02 2011: So far the informational part. Next the mounting.
> Sun May  8 15:08:02 2011: The command is `mount [-t fstype] something
> somewhere'.
> Sun May  8 15:08:02 2011: Details found in /etc/fstab may be omitted.
> Sun May  8 15:08:02 2011:mount -a [-t|-O] ... : mount all stuff
> from /etc/fstab
> Sun May  8 15:08:02 2011:mount device : mount device at
> the known place
> Sun May  8 15:08:02 2011:mount directory  : mount known
> device here
> Sun May  8 15:08:02 2011:mount -t type dev dir: ordinary mount
> command
> Sun May  8 15:08:02 2011: Note that one does not really mount a device, one
> mounts
> Sun May  8 15:08:02 2011: a filesystem (of the given type) found on the
> device. Sun May  8 15:08:02 2011: One can also mount an already visible
> directory tree elsewhere:
> Sun May  8 15:08:02 2011:mount --bind olddir newdir
> Sun May  8 15:08:02 2011: or move a subtree:
> Sun May  8 15:08:02 2011:mount --move olddir newdir
> Sun May  8 15:08:02 2011: One can change the type of mount containing the
> directory dir:
> Sun May  8 15:08:02 2011:mount --make-shared dir
> Sun May  8 15:08:02 2011:mount --make-slave dir
> Sun May  8 15:08:02 2011:mount --make-private dir
> Sun May  8 15:08:02 2011:mount --make-unbindable dir
> Sun May  8 15:08:02 2011: One can change the type of all the mounts in a
> mount subtree
> Sun May  8 15:08:02 2011: containing the directory dir:
> Sun May  8 15:08:02 2011:mount --make-rshared dir
> Sun May  8 15:08:02 2011:mount --make-rslave dir
> Sun May  8 15:08:02 2011:mount --make-rprivate dir
> Sun May  8 15:08:02 2011:mount --make-runbindable dir
> Sun May  8 15:08:02 2011: A device can be given by name, say /dev/hda1 or
> /dev/cdrom,
> Sun May  8 15:08:02 2011: or by label, using  -L label  or by uuid, using 
> -U uuid .
> Sun May  8 15:08:02 2011: Other options: [-nfFrsvw] [-o options] [-p
> passwdfd].
> Sun May  8 15:08:02 2011: For many more details, say  man 8 mount .
> Sun May  8 15:08:02 2011: Starting early crypto disks...done.
> Sun May  8 15:08:02 2011: Starting remaining crypto disks...done.
> Sun May  8 15:08:02 2011: Cleaning up ifupdown
> Sun May  8 15:08:02 2011: Loading kernel modules...done

Re: rootfs on SSD

[Thilo Six]

Andrei Popescu wrote the following on 09.05.2011 09:18

>> rd@blackbox:~$ mount|grep rootfs
>> rootfs on / type rootfs (rw)
>> rd@blackbox:~$ 
> 
> I don't have any 'rootfs' in the output of mount, instead I have this:
> 
> /dev/sda6 on / type ext3 (rw,noatime,errors=remount-ro,commit=0)
> 
> I have a feeling there's more to your setup that is missing here. Could 
> you please post your complete /etc/fstab and full output of 'mount'?
> 
> Regards,
> Andrei

and the content of '/boot/grub/device.map'

-- 
bye Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6  7C18 89A4 A2A0 C70B 1A8F



-- 
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/iq96dt$va1$1...@dough.gmane.org

Re: rootfs on SSD

[Andrei Popescu]

On Du, 08 mai 11, 23:23:52, Rainer Dorsch wrote:
> 
> rd@blackbox:~$ mount|grep rootfs
> rootfs on / type rootfs (rw)
> rd@blackbox:~$ 

I don't have any 'rootfs' in the output of mount, instead I have this:

/dev/sda6 on / type ext3 (rw,noatime,errors=remount-ro,commit=0)

I have a feeling there's more to your setup that is missing here. Could 
you please post your complete /etc/fstab and full output of 'mount'?

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: rootfs on SSD

[Rainer Dorsch]

Hi Florian,

Am Sonntag, 8. Mai 2011 schrieb Florian Ernst:
> Hello Rainer,
> 
> On Sun, May 08, 2011 at 04:14:53PM +0200, Rainer Dorsch wrote:
> > [...]
> > When I now run the mount command, I get all options listed for /home
> > 
> > /dev/sdc2 on /home type ext4 (rw,noatime,discard,data=ordered)
> > 
> > but not for root
> > 
> > rootfs on / type rootfs (rw)
> > 
> > Were the noatime, discard, and data options lost somewhere on the
> > way? Can I verify that they work?
> 
> Quoting Ted Ts'o from
> 
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=9;bug=616317>:
> | Debian simply doesn't support the mount options for the root file
> | system in /etc/fstab having any effect on how the root file system is
> | mounted.  The root file system is mounted by the kernel, and the mount
> | options used by the kernel are specified by the rootflags= option on
> | the kernel's boot command line.
> 
> See the remainder of the bugreport for a discussion on how to possibly
> remedy that in Debian. As for now, you need to go for kernel command
> line options passed by your bootloader.

That was an extremely useful reply, I was completely unaware of this, thanks a 
lot.

Nevertheless the rootflags do not end up in mount options for rootfs, maybe I 
am doing something wrong, which is obvious for somebody reading...:

I added rootflags to /etc/default/grub and they are showing up during boot

rd@blackbox:~$ cat /proc/cmdline 
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686-bigmem 
root=UUID=4a4eb948-2d2b-4188-96ae-76a3776ae69c ro quiet elevator=noop 
rootflags=noatime,discard,data=ordered,errors=remount-ro
rd@blackbox:~$ 

but have no effect on how the root filesystem is mounted (although I did quite 
some experimentation with variations of the above boot line)

rd@blackbox:~$ mount|grep rootfs
rootfs on / type rootfs (rw)
rd@blackbox:~$ 

None of the rootflags options survived!


I am just wondering what I might have missed.

I include /var/log/boot, since it has a suspicious entry 

 findfs: unable to resolve 'UUID="4a4eb948-2d2b-4188-96ae-76a3776ae69c"'

not sure if that is related though.

Clearly, blkid shows that the UUID exists:

blackbox:~# blkid |grep 4a4eb
/dev/sdc1: LABEL="root_ssd" UUID="4a4eb948-2d2b-4188-96ae-76a3776ae69c" 
TYPE="ext4" 
blackbox:~# 

Any insight, what I might do wrong is very welcome. 

Thanks,
Rainer



For reference the entire /var/log/boot

/var/log/boot:
Sun May  8 23:06:58 2011: Setting parameters of disc:  /dev/sda.
Sun May  8 23:06:58 2011:   /dev/sdb.
Sun May  8 23:06:58 2011: findfs: unable to resolve 
'UUID="4a4eb948-2d2b-4188-96ae-76a3776ae69c"'
Sun May  8 23:06:58 2011: Activating swap...done.
Sun May  8 23:06:58 2011: Usage: mountpoint [-q] [-d] [-x] path
Sun May  8 23:06:58 2011: Checking root file system...fsck from util-linux-ng 
2.17.2
Sun May  8 23:06:58 2011: root_ssd: clean, 877728/3055616 files, 
6710669/12207384 blocks
Sun May  8 23:06:58 2011: done.
Sun May  8 23:06:58 2011: Usage: mount -V : print version
Sun May  8 23:06:58 2011:mount -h : print this help
Sun May  8 23:06:58 2011:mount: list mounted 
filesystems
Sun May  8 23:06:58 2011:mount -l : idem, including 
volume labels
Sun May  8 23:06:58 2011: So far the informational part. Next the mounting.
Sun May  8 23:06:58 2011: The command is `mount [-t fstype] something 
somewhere'.
Sun May  8 23:06:58 2011: Details found in /etc/fstab may be omitted.
Sun May  8 23:06:58 2011:mount -a [-t|-O] ... : mount all stuff 
from /etc/fstab
Sun May  8 23:06:58 2011:mount device : mount device at 
the known place
Sun May  8 23:06:58 2011:mount directory  : mount known device 
here
Sun May  8 23:06:58 2011:mount -t type dev dir: ordinary mount 
command
Sun May  8 23:06:58 2011: Note that one does not really mount a device, one 
mounts
Sun May  8 23:06:58 2011: a filesystem (of the given type) found on the device.
Sun May  8 23:06:58 2011: One can also mount an already visible directory tree 
elsewhere:
Sun May  8 23:06:58 2011:mount --bind olddir newdir
Sun May  8 23:06:58 2011: or move a subtree:
Sun May  8 23:06:58 2011:mount --move olddir newdir
Sun May  8 23:06:58 2011: One can change the type of mount containing the 
directory dir:
Sun May  8 23:06:58 2011:mount --make-shared dir
Sun May  8 23:06:58 2011:mount --make-slave dir
Sun May  8 23:06:58 2011:mount --make-private dir
Sun May  8 23:06:58 2011:mount --make-unbindable dir
Sun May  8 23:06:58 2011: One can change the type of all the mounts in a mount 
subtree
Sun May  8 23:06:58 2011: containing the directory dir:
Sun May  8 23:06:58 2011:mount --make-rshared

Re: findfs does not find rootfs UUID

[Rainer Dorsch]

Am Sonntag, 8. Mai 2011 schrieb Rainer Dorsch:
> Hello,
> 
> I moved my root partition to a new SSD and used ext4 as filesystem.
> Everything works well, except that I get an error message during boot
> (which I think was not there before):
> 
> findfs: Unable to resolve ...
> 
> http://bokomoko.de/~rd/ext4-rootfs-uuid/IMG_6119.JPG
> 
> for my root partition. The system boot without a problem though, and when
> booted findfs works out ok:
> 
> blackbox:~# findfs UUID="4a4eb948-2d2b-4188-96ae-76a3776ae69c"
> /dev/sdb1
> blackbox:~#
> 
> Should I be concerned about this issue?
> 

Here are some more details:

From /boot/grub/grub.cfg

menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-686-bigmem' --class debian --
class gnu-linux --class gnu --class os {
insmod part_msdos
insmod ext2
set root='(/dev/sdb,msdos1)'
search --no-floppy --fs-uuid --set 4a4eb948-2d2b-4188-96ae-76a3776ae69c
echo'Loading Linux 2.6.32-5-686-bigmem ...'
linux   /boot/vmlinuz-2.6.32-5-686-bigmem 
root=UUID=4a4eb948-2d2b-4188-96ae-76a3776ae69c ro quiet quiet elevator=noop
echo'Loading initial ramdisk ...'
initrd  /boot/initrd.img-2.6.32-5-686-bigmem
}

from /var/log/boot:

Sun May  8 15:08:02 2011: Setting parameters of disc:  /dev/sda.
Sun May  8 15:08:02 2011:   /dev/sdb.
Sun May  8 15:08:02 2011: findfs: unable to resolve 
'UUID="4a4eb948-2d2b-4188-96ae-76a3776ae69c"'
Sun May  8 15:08:02 2011: Activating swap...done.
Sun May  8 15:08:02 2011: Usage: mountpoint [-q] [-d] [-x] path
Sun May  8 15:08:02 2011: Checking root file system...fsck from util-linux-ng 
2.17.2
Sun May  8 15:08:02 2011: root_ssd: clean, 878324/3055616 files, 
6715280/12207384 blocks
Sun May  8 15:08:02 2011: done.
Sun May  8 15:08:02 2011: Usage: mount -V : print version
Sun May  8 15:08:02 2011:mount -h : print this help
Sun May  8 15:08:02 2011:mount: list mounted 
filesystems
Sun May  8 15:08:02 2011:mount -l : idem, including 
volume labels
Sun May  8 15:08:02 2011: So far the informational part. Next the mounting.
Sun May  8 15:08:02 2011: The command is `mount [-t fstype] something 
somewhere'.
Sun May  8 15:08:02 2011: Details found in /etc/fstab may be omitted.
Sun May  8 15:08:02 2011:mount -a [-t|-O] ... : mount all stuff 
from /etc/fstab
Sun May  8 15:08:02 2011:mount device : mount device at 
the known place
Sun May  8 15:08:02 2011:mount directory  : mount known device 
here
Sun May  8 15:08:02 2011:mount -t type dev dir: ordinary mount 
command
Sun May  8 15:08:02 2011: Note that one does not really mount a device, one 
mounts
Sun May  8 15:08:02 2011: a filesystem (of the given type) found on the device.
Sun May  8 15:08:02 2011: One can also mount an already visible directory tree 
elsewhere:
Sun May  8 15:08:02 2011:mount --bind olddir newdir
Sun May  8 15:08:02 2011: or move a subtree:
Sun May  8 15:08:02 2011:mount --move olddir newdir
Sun May  8 15:08:02 2011: One can change the type of mount containing the 
directory dir:
Sun May  8 15:08:02 2011:mount --make-shared dir
Sun May  8 15:08:02 2011:mount --make-slave dir
Sun May  8 15:08:02 2011:mount --make-private dir
Sun May  8 15:08:02 2011:mount --make-unbindable dir
Sun May  8 15:08:02 2011: One can change the type of all the mounts in a mount 
subtree
Sun May  8 15:08:02 2011: containing the directory dir:
Sun May  8 15:08:02 2011:mount --make-rshared dir
Sun May  8 15:08:02 2011:mount --make-rslave dir
Sun May  8 15:08:02 2011:mount --make-rprivate dir
Sun May  8 15:08:02 2011:mount --make-runbindable dir
Sun May  8 15:08:02 2011: A device can be given by name, say /dev/hda1 or 
/dev/cdrom,
Sun May  8 15:08:02 2011: or by label, using  -L label  or by uuid, using  -U 
uuid .
Sun May  8 15:08:02 2011: Other options: [-nfFrsvw] [-o options] [-p 
passwdfd].
Sun May  8 15:08:02 2011: For many more details, say  man 8 mount .
Sun May  8 15:08:02 2011: Starting early crypto disks...done.
Sun May  8 15:08:02 2011: Starting remaining crypto disks...done.
Sun May  8 15:08:02 2011: Cleaning up ifupdown
Sun May  8 15:08:02 2011: Loading kernel modules...done.
Sun May  8 15:08:02 2011: Activating lvm and md swap...done.
Sun May  8 15:08:02 2011: Checking file systems...fsck from util-linux-ng 
2.17.2
Sun May  8 15:08:02 2011: home_ssd: clean, 257539/4276224 files, 
11073341/17097176 blocks
Sun May  8 15:08:02 2011: /dev/sda1: clean, 278/14663680 files, 
23995714/29304560 blocks
Sun May  8 15:08:02 2011: /dev/sdb7: clean, 553445/12574720 files, 
26918497/50293482 blocks (check in 2 mounts)
Sun May  8 15:08:03 2011: opt: clean, 100621/1464 files, 6554174/24414775 
block

Re: rootfs on SSD

[Florian Ernst]

Hello Rainer,

On Sun, May 08, 2011 at 04:14:53PM +0200, Rainer Dorsch wrote:
> [...]
> When I now run the mount command, I get all options listed for /home
> 
> /dev/sdc2 on /home type ext4 (rw,noatime,discard,data=ordered)
> 
> but not for root
> 
> rootfs on / type rootfs (rw)
> 
> Were the noatime, discard, and data options lost somewhere on the way? 
> Can 
> I verify that they work?

Quoting Ted Ts'o from
<http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=9;bug=616317>:

| Debian simply doesn't support the mount options for the root file
| system in /etc/fstab having any effect on how the root file system is
| mounted.  The root file system is mounted by the kernel, and the mount
| options used by the kernel are specified by the rootflags= option on
| the kernel's boot command line.

See the remainder of the bugreport for a discussion on how to possibly
remedy that in Debian. As for now, you need to go for kernel command
line options passed by your bootloader.

Cheers,
Flo


-- 
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/20110508151754.gb6...@fernst.no-ip.org

rootfs on SSD

[Rainer Dorsch]

Hello,

I migrated my root partition to an ext4 formated SSD partition. I added it to 
fstab as I did the /home partition

UUID="4a4eb948-2d2b-4188-96ae-76a3776ae69c" /ext4   
   
noatime,discard,data=ordered,errors=remount-ro 0   1

UUID="8b30f379-55fe-49e5-97b7-0f6e7f63661a" /homeext4   
   
noatime,discard,data=ordered   0   2

When I now run the mount command, I get all options listed for /home

/dev/sdc2 on /home type ext4 (rw,noatime,discard,data=ordered)

but not for root

rootfs on / type rootfs (rw)

Were the noatime, discard, and data options lost somewhere on the way? Can 
I verify that they work?

Thanks,
Rainer

-- 
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdor...@web.de
jabber: rdor...@jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F  8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/


signature.asc
Description: This is a digitally signed message part.

findfs does not find rootfs UUID

[Rainer Dorsch]

Hello,

I moved my root partition to a new SSD and used ext4 as filesystem. Everything 
works well, except that I get an error message during boot (which I think was 
not there before):

findfs: Unable to resolve ...

http://bokomoko.de/~rd/ext4-rootfs-uuid/IMG_6119.JPG

for my root partition. The system boot without a problem though, and when 
booted findfs works out ok:

blackbox:~# findfs UUID="4a4eb948-2d2b-4188-96ae-76a3776ae69c"
/dev/sdb1
blackbox:~# 

Should I be concerned about this issue?

Thanks,
Rainer


-- 
Rainer Dorsch
Lärchenstr. 6
D-72135 Dettenhausen
07157-734133
email: rdor...@web.de
jabber: rdor...@jabber.org
GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F  8F59 E3A8 C538 7519 141E
Full GPG key: http://pgp.mit.edu/


signature.asc
Description: This is a digitally signed message part.

NFS rootfs initramfs NFSv4

[Denny Schierz]

hi,

we want to use the security advantages from NFSv4 for our diskless
clients. I Build the initrams under Squeeze but the client won't boot,
if I tell Solaris10 to accept NFSv4 only :-/

I saw the bug #409271
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409271) for Lenny, but
why doesn't support Sqeeze that? Is it working in testing or unstable?

cu denny


signature.asc
Description: This is a digitally signed message part

Re: grub and rootfs as LVM

[Yuwen Dai]

I don't know: it just works.  As long as you have the lvm2 package
installed
and the initrd package was created after the lvm2 package was installed,
it
should just work.



Hi Stefan,

After I changed root device to /dev/mapper/volume-root,  Linux boots
successfully.  And I didn't make anything special for LVM when creating
initramfs. Thank you very much.



   Stefan

Re: grub and rootfs as LVM

[Andrew Sackville-West]

On Wed, May 09, 2007 at 09:23:52AM -0400, Stefan Monnier wrote:
> >> Try use /dev/mapper/volume-root instead.
> >> I'm not sure why, but I recently had a similar problem where using
> >> /dev/Debian/root didn't work but /dev/mapper/Debian-root did (even though
> >> once the boot is over, /dev/Debian/root can be used just fine, it looks
> >> like the alternate name is constructed later).
> 
> > Would you please tell me how to create a initrd with LVM support in Debian?
> > I used the initramfs tool.  Thank you very much!
> 
> I don't know: it just works.  As long as you have the lvm2 package installed
> and the initrd package was created after the lvm2 package was installed, it
> should just work.
> 

if installed after the fact, then do this as root:

update-initramfs -u -k all

to rebuild the existing initrd's

A


signature.asc
Description: Digital signature

Re: grub and rootfs as LVM

[Stefan Monnier]

>> Try use /dev/mapper/volume-root instead.
>> I'm not sure why, but I recently had a similar problem where using
>> /dev/Debian/root didn't work but /dev/mapper/Debian-root did (even though
>> once the boot is over, /dev/Debian/root can be used just fine, it looks
>> like the alternate name is constructed later).

> Would you please tell me how to create a initrd with LVM support in Debian?
> I used the initramfs tool.  Thank you very much!

I don't know: it just works.  As long as you have the lvm2 package installed
and the initrd package was created after the lvm2 package was installed, it
should just work.


Stefan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: grub and rootfs as LVM

[Yuwen Dai]

> I setup /boot as a seperate disk parition.  The rest is for LVM.
> /dev/volume/root is OK when I use a rescue CDRom.  And I re-build the
> initrd, adding all dm-* modules to the initrd.  Any suggestion?

Try use /dev/mapper/volume-root instead.
I'm not sure why, but I recently had a similar problem where using
/dev/Debian/root didn't work but /dev/mapper/Debian-root did (even though
once the boot is over, /dev/Debian/root can be used just fine, it looks
like the alternate name is constructed later).



Hi Stefan,

Would you please tell me how to create a initrd with LVM support in Debian?
I used the initramfs tool.  Thank you very much!

Best regards,
yuwen




   Stefan



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]

Re: grub and rootfs as LVM

[Yuwen Dai]

Try use /dev/mapper/volume-root instead.
I'm not sure why, but I recently had a similar problem where using
/dev/Debian/root didn't work but /dev/mapper/Debian-root did (even though
once the boot is over, /dev/Debian/root can be used just fine, it looks
like the alternate name is constructed later).



I  fell into a busybox command. There's no dirs in /dev/mapper, only
control:

ls /dev/mapper
control

What is control?

Best regards,
Yuwen



   Stefan



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]

Re: grub and rootfs as LVM

[Stefan Monnier]

> I setup my rootfs as an LVM, the menu.lst of grub looks like this;

> title   Debian GNU/Linux, kernel 2.6.18-4-386
> root(hd0,0)
> kernel  /vmlinuz-2.6.18-4-686 root=/dev/volume/root ro
> initrd  /my_init
> savedefault

> Error happens when the kernel tried to mount the root filesystem:
> The error message is "Waiting for root file system..."
> yuwen check root=bootarg cat /proc/cmdline or missing modules, devices; cat
> /proc/modules ls /dev/

> I setup /boot as a seperate disk parition.  The rest is for LVM.
> /dev/volume/root is OK when I use a rescue CDRom.  And I re-build the
> initrd, adding all dm-* modules to the initrd.  Any suggestion?

Try use /dev/mapper/volume-root instead.
I'm not sure why, but I recently had a similar problem where using
/dev/Debian/root didn't work but /dev/mapper/Debian-root did (even though
once the boot is over, /dev/Debian/root can be used just fine, it looks
like the alternate name is constructed later).


Stefan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

grub and rootfs as LVM

[Yuwen Dai]

Dear all,

I setup my rootfs as an LVM, the menu.lst of grub looks like this;

title   Debian GNU/Linux, kernel 2.6.18-4-386
root(hd0,0)
kernel  /vmlinuz-2.6.18-4-686 root=/dev/volume/root ro
initrd  /my_init
savedefault

Error happens when the kernel tried to mount the root filesystem:
The error message is "Waiting for root file system..."
yuwen check root=bootarg cat /proc/cmdline or missing modules, devices; cat
/proc/modules ls /dev/

I setup /boot as a seperate disk parition.  The rest is for LVM.
/dev/volume/root is OK when I use a rescue CDRom.  And I re-build the
initrd, adding all dm-* modules to the initrd.  Any suggestion?

Best regards,
Yuwen

Re: Problem: kernel 2.4.23 - rootfs mounted read-only

[Lukas Ruf]

> Lukas Ruf <[EMAIL PROTECTED]> [2004-01-02 12:16]:
>
> Dear all,
>
> when returning back to work after the Xmas-break, my root-file
> system was mounted read-only.  However, I have no idea why this
> happened -- and problems fixing it.  Any help would be greatly
> appreciated!
>

Thanks for all the answers!  Meanwhile, I copied about 100GB to a safe
location.

One thing I really do not understand: I have not received any answer
to my account although tons of other Debian User-eMails have flown
in. I found on the web-archive the original question and all the
answers.

wbr,
Lukas
-- 
Lukas Ruf   | Wanna know anything about raw |
 | IP? ->  |
eMail Style Guide: |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Problem: kernel 2.4.23 - rootfs mounted read-only

[Paul Morgan]

On Fri, 02 Jan 2004 12:26:36 +0100, Jan Minar wrote:

> On Fri, Jan 02, 2004 at 12:16:35PM +0100, Lukas Ruf wrote:
>> Dec 30 07:35:52 [kernel] EXT3-fs error (device ide0(3,2)): ext3_get_inode_loc: 
>> unable to read inode block - inode=972554, block=1966176
>> Dec 30 07:35:52 [kernel] Remounting filesystem read-only
> 
> 
> Don't trust the disk much from now on--if you have valuable data,
> relocate them.

I have had similar problems when a disk has been dying, which is what
this looks like.  An IDE bus reset is bad news, and you are no doubt
hearing the dreaded disk-death-watch "click-click...click-click" from the
drive.

IIRC this is what I did (I did no bad block checking or recovery attempts;
I wanted to keep the disk accesses to a *minimum* in order to postpone a
complete failure as long as possible):

Copy everything off the disk *now* (cp -ax).  cp will tell you which
files were bad and that it couldn't copy, so you'll have a list of files
which you need to restore.  In my case, it was just three files in
/usr/share/doc.

Run the disk manufacturer's disk checking software from the floppy/CD to
confirm the state of the disk.  Maxtor, for instance, requires you to do
this before returning the disk under warranty.  In any case, the software
will tell you if the disk is currently in dubious shape, but it won't make
predictions about the future state :)

Return disk under warranty or go to pricewatch.com and get another one :)

Note: If you are having problems mounting it as ext3 because the journal
is damaged, mount it as ext2.  I would suggest *not* doing an fsck on it
before trying to copy everything off.  Once you've got the contents
safe, then you can mess around with the drive without making anything
worse.  If you get the disk in better shape, then you can take another
copy and throw away the first one.

Sorry to hear of your problem, disk failures really suck.

-- 
paul

Programming without a hex editor is like watchmaking without a hammer.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Problem: kernel 2.4.23 - rootfs mounted read-only

[Arnt Karlsen]

On Fri, 2 Jan 2004 12:16:35 +0100, 
Lukas Ruf <[EMAIL PROTECTED]> wrote in message 
<[EMAIL PROTECTED]>:

> Dear all,
> 
> when returning back to work after the Xmas-break, my root-file system
> was mounted read-only.  However, I have no idea why this happened --
> and problems fixing it.  Any help would be greatly appreciated!
> 
> Checking my logs, I found:
> 
> Dec 25 02:54:00 [kernel]
> Dec 25 02:54:00 [kernel] hda: (__ide_dma_test_irq) called while not
> waiting Dec 25 02:54:00 [kernel] hda: dma_timer_expiry: dma status ==
> 0x20 Dec 25 02:54:00 [kernel] hda: drive not ready for command
> Dec 25 02:54:00 [kernel] hda: status timeout: status=0xd0 { Busy }
> Dec 25 02:54:00 [kernel] hda: timeout waiting for DMA
> Dec 25 02:54:01 [kernel] ide0: reset: success
> Dec 25 02:54:03 [kernel] blk: queue c02cfde0, I/O limit 4095Mb (mask
> 0x)
> 
> and
> 
> Dec 26 02:50:00 [kernel] hda: dma_timer_expiry: dma status == 0x20
> Dec 26 02:50:00 [kernel] ide0: reset: success
> 
> and
> 
> Dec 30 07:35:52 [kernel] hda: dma_intr: status=0x51 { DriveReady
> SeekComplete Error } Dec 30 07:35:52 [kernel] EXT3-fs error (device
> ide0(3,2)): ext3_get_inode_loc: unable to read inode block -
> inode=972554, block=1966176 Dec 30 07:35:52 [kernel] Remounting
> filesystem read-only Dec 30 07:35:52 [kernel] EXT3-fs error (device
> ide0(3,2)) in start_transaction: Journal has aborted
> 
> Trying to remount the rootfs rw yields
> 
> # mount -o remount,rw /
> mount: block device /dev/hda2 is write-protected, mounting read-only
> 
> # uname -a
> Linux komsys-pc-ruf 2.4.23 #1 Tue Dec 2 17:34:37 CET 2003 i686
> GNU/Linux
> # uptime
>  12:10:54 up 30 days, 17:58,  8 users,  load average: 0.71, 1.37, 1.50
> 
> Does anybody know whether this means: the disk is about to die

..yup.  Get a new one.  You don't wanna write to your old disk at all,
until you have your data safely transferred to your new disk.  
For the transfer, setup a new fresh debian or use a knoppix, say
http://damnsmalllinux.org/ ,  is pretty good.  Expect some fishing in
the /lost+found tree.

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Problem: kernel 2.4.23 - rootfs mounted read-only

[Jan Minar]

On Fri, Jan 02, 2004 at 12:16:35PM +0100, Lukas Ruf wrote:
> Dec 30 07:35:52 [kernel] EXT3-fs error (device ide0(3,2)): ext3_get_inode_loc: 
> unable to read inode block - inode=972554, block=1966176
> Dec 30 07:35:52 [kernel] Remounting filesystem read-only

This is probably what it should do: remount readonly on errors.  

> # mount -o remount,rw /
> mount: block device /dev/hda2 is write-protected, mounting read-only

Found the error again, remounted even before mount returned.

> Does anybody know whether this means: the disk is about to die

Something like that.  The short term $0.01 is to reboot singleuser, run
badblocks, and adjust the /etc/fstab line to `errors=continue'.  This is
what I did few weeks ago.  There are surely better ways but this kinda
works. 

Don't trust the disk much from now on--if you have valuable data,
relocate them.

-- 
Jan Minar   "Please don't CC me, I'm subscribed." x 7


pgp0.pgp
Description: PGP signature

Problem: kernel 2.4.23 - rootfs mounted read-only

[Lukas Ruf]

Dear all,

when returning back to work after the Xmas-break, my root-file system
was mounted read-only.  However, I have no idea why this happened --
and problems fixing it.  Any help would be greatly appreciated!

Checking my logs, I found:

Dec 25 02:54:00 [kernel]
Dec 25 02:54:00 [kernel] hda: (__ide_dma_test_irq) called while not waiting
Dec 25 02:54:00 [kernel] hda: dma_timer_expiry: dma status == 0x20
Dec 25 02:54:00 [kernel] hda: drive not ready for command
Dec 25 02:54:00 [kernel] hda: status timeout: status=0xd0 { Busy }
Dec 25 02:54:00 [kernel] hda: timeout waiting for DMA
Dec 25 02:54:01 [kernel] ide0: reset: success
Dec 25 02:54:03 [kernel] blk: queue c02cfde0, I/O limit 4095Mb (mask 0x)

and

Dec 26 02:50:00 [kernel] hda: dma_timer_expiry: dma status == 0x20
Dec 26 02:50:00 [kernel] ide0: reset: success

and

Dec 30 07:35:52 [kernel] hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Dec 30 07:35:52 [kernel] EXT3-fs error (device ide0(3,2)): ext3_get_inode_loc: unable 
to read inode block - inode=972554, block=1966176
Dec 30 07:35:52 [kernel] Remounting filesystem read-only
Dec 30 07:35:52 [kernel] EXT3-fs error (device ide0(3,2)) in start_transaction: 
Journal has aborted

Trying to remount the rootfs rw yields

# mount -o remount,rw /
mount: block device /dev/hda2 is write-protected, mounting read-only

# uname -a
Linux komsys-pc-ruf 2.4.23 #1 Tue Dec 2 17:34:37 CET 2003 i686 GNU/Linux
# uptime
 12:10:54 up 30 days, 17:58,  8 users,  load average: 0.71, 1.37, 1.50

Does anybody know whether this means: the disk is about to die

wbr,
Lukas
-- 
Lukas Ruf   | Wanna know anything about raw |
<http://www.lpr.ch> | IP? -> <http://www.rawip.org> |
eMail Style Guide: <http://www.rawip.org/style.html>|


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: rpc.statd won't run when rootfs mounted readonly

[nate]

Heinrich Rebehn said:
> Hi,
>
> I have a problem with rpc.statd. We run our linux machines as diskless
> clients, they mount their root fs via nfs from a server. For security
> reasons i would like to export the root fs readonly. However, rpc.statd
> will not run. It exits without an error message, but reports
>
> Sep 26 15:33:48 rpc.statd[680]: Version 1.0 Starting
> Sep 26 15:33:53 rpc.statd[681]: unable to register (statd, 1, udp).
>
> via syslog.

is your /var/lib/nfs writable ? do any other rpc services start besides
portmap? It may be a portmapper problem since it's saying it cannot register
the service(which tells me that portmapper is having trouble). I also
see that statd uses /var/lib/nfs(as above).

you may want to look into re-configuring your root filesystems for
read-only-friendly configuration. A while back someone pointed me
to the BBLCD project which creates a bootable linux distro on a CD,
it does a few hacks to the system to redirect files that need to be
written to a ramdisk which is created at startup. It wouldn't be
hard I think to adapt it to network booting. The BBLCD project is
here:

http://www.bablokb.de/bblcd/

nate




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

rpc.statd won't run when rootfs mounted readonly

[Heinrich Rebehn]

Hi,

I have a problem with rpc.statd. We run our linux machines as diskless clients,
they mount their root fs via nfs from a server. For security reasons i would
like to export the root fs readonly. However, rpc.statd will not run. It exits
without an error message, but reports

Sep 26 15:33:48 rpc.statd[680]: Version 1.0 Starting
Sep 26 15:33:53 rpc.statd[681]: unable to register (statd, 1, udp).

via syslog.

Can someone help?

Regards

Heinrich Rebehn

University of Bremen
Physics / Electrical and Electronics Engineering
- Department of Telecommunications -

E-mail: mailto:[EMAIL PROTECTED]
Phone : +49/421/218-4664
Fax   :-3341





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

rpc.statd won't run when rootfs mounted readonly

[Heinrich Rebehn]

Hi,

I have a problem with rpc.statd. We run our linux machines as diskless clients,
they mount their root fs via nfs from a server. For security reasons i would
like to export the root fs readonly. However, rpc.statd will not run. It exits
without an error message, but reports

Sep 26 15:33:48 rpc.statd[680]: Version 1.0 Starting
Sep 26 15:33:53 rpc.statd[681]: unable to register (statd, 1, udp).

via syslog.
I did an strace of the whole thing but am unable to locate the error. I append
it to this message, maybe someone can help (I am not familiar with network
programming).

## strace output 
647   execve("/sbin/rpc.statd", ["rpc.statd"], [/* 19 vars */]) = 0
647   uname({sys="Linux", node="reno", ...}) = 0
647   brk(0)= 0x804ff74
647   open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
647   open("/usr/local/kde/lib/i586/mmx/libwrap.so.0", O_RDONLY) = -1 ENOENT (No 
such file or directory)
647   stat64("/usr/local/kde/lib/i586/mmx", 0xb0c4) = -1 ENOENT (No such 
file or directory)
647   open("/usr/local/kde/lib/i586/libwrap.so.0", O_RDONLY) = -1 ENOENT (No 
such file or directory)
647   stat64("/usr/local/kde/lib/i586", 0xb0c4) = -1 ENOENT (No such file or 
directory)
647   open("/usr/local/kde/lib/mmx/libwrap.so.0", O_RDONLY) = -1 ENOENT (No such 
file or directory)
647   stat64("/usr/local/kde/lib/mmx", 0xb0c4) = -1 ENOENT (No such file or 
directory)
647   open("/usr/local/kde/lib/libwrap.so.0", O_RDONLY) = -1 ENOENT (No such 
file or directory)
647   stat64("/usr/local/kde/lib", {st_mode=S_IFDIR|0755, st_size=17920, ...}) = 0
647   open("/usr/local/lib/i586/mmx/libwrap.so.0", O_RDONLY) = -1 ENOENT (No 
such file or directory)
647   stat64("/usr/local/lib/i586/mmx", 0xb0c4) = -1 ENOENT (No such file or 
directory)
647   open("/usr/local/lib/i586/libwrap.so.0", O_RDONLY) = -1 ENOENT (No such 
file or directory)
647   stat64("/usr/local/lib/i586", 0xb0c4) = -1 ENOENT (No such file or 
directory)
647   open("/usr/local/lib/mmx/libwrap.so.0", O_RDONLY) = -1 ENOENT (No such 
file or directory)
647   stat64("/usr/local/lib/mmx", 0xb0c4) = -1 ENOENT (No such file or 
directory)
647   open("/usr/local/lib/libwrap.so.0", O_RDONLY) = -1 ENOENT (No such file or 
directory)
647   stat64("/usr/local/lib", {st_mode=S_IFDIR|S_ISGID|0775, st_size=2048, 
...}) = 0
647   open("/etc/ld.so.cache", O_RDONLY) = 3
647   fstat64(3, {st_mode=S_IFREG|0644, st_size=40661, ...}) = 0
647   old_mmap(NULL, 40661, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
647   close(3)  = 0
647   open("/lib/libwrap.so.0", O_RDONLY) = 3
647   read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@ \0\000"..., 
1024) = 1024
647   fstat64(3, {st_mode=S_IFREG|0644, st_size=24328, ...}) = 0
647   old_mmap(NULL, 29092, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001e000
647   mprotect(0x40024000, 4516, PROT_NONE) = 0
647   old_mmap(0x40024000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
0x5000) = 0x40024000
647   old_mmap(0x40025000, 420, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40025000
647   close(3)  = 0
647   open("/usr/local/kde/lib/libnsl.so.1", O_RDONLY) = -1 ENOENT (No such file 
or directory)
647   open("/usr/local/lib/libnsl.so.1", O_RDONLY) = -1 ENOENT (No such file or 
directory)
647   open("/lib/libnsl.so.1", O_RDONLY) = 3
647   read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 ;\0\000"..., 
1024) = 1024
647   fstat64(3, {st_mode=S_IFREG|0644, st_size=69472, ...}) = 0
647   old_mmap(NULL, 80988, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40026000
647   mprotect(0x40037000, 11356, PROT_NONE) = 0
647   old_mmap(0x40037000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
0x1) = 0x40037000
647   old_mmap(0x40038000, 7260, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40038000
647   close(3)  = 0
647   open("/usr/local/kde/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file 
or directory)
647   open("/usr/local/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or 
directory)
647   open("/lib/libc.so.6", O_RDONLY)  = 3
647   read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\30\222"..., 1024) 
= 1024
647   fstat64(3, {st_mode=S_IFREG|0755, st_size=1153784, ...}) = 0
647   old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x4003a000
647   old_mmap(NULL, 1166560, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4003b000
647   mprotect(0x4014e000, 40160, PROT_NONE) = 0
647   old_mmap(0x4014e000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 
3, 0x113000) = 0x4014e000
647   old_mmap(0x40154000, 15584, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40154000
647   close(3)  = 0
647   munmap(0x40014000, 40661) = 0
647   getpid()  = 647
647   b

rpc.statd won't run when rootfs mounted readonly

[Heinrich Rebehn]

Hi,

I have a problem with rpc.statd. We run our linux machines as diskless clients,
they mount their root fs via nfs from a server. For security reasons i would
like to export the root fs readonly. However, rpc.statd will not run. It exits
without an error message, but reports

Sep 26 15:33:48 rpc.statd[680]: Version 1.0 Starting
Sep 26 15:33:53 rpc.statd[681]: unable to register (statd, 1, udp).

via syslog.
I did an strace of the whole thing but am unable to locate the error. I append
it to this message, maybe someone can help (I am not familiar with network
programming).

Regards

Heinrich Rebehn

University of Bremen
Physics / Electrical and Electronics Engineering
- Department of Telecommunications -

E-mail: mailto:[EMAIL PROTECTED]
Phone : +49/421/218-4664
Fax   :-3341





647   execve("/sbin/rpc.statd", ["rpc.statd"], [/* 19 vars */]) = 0
647   uname({sys="Linux", node="reno", ...}) = 0
647   brk(0)= 0x804ff74
647   open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
647   open("/usr/local/kde/lib/i586/mmx/libwrap.so.0", O_RDONLY) = -1 ENOENT (No such 
file or directory)
647   stat64("/usr/local/kde/lib/i586/mmx", 0xb0c4) = -1 ENOENT (No such file or 
directory)
647   open("/usr/local/kde/lib/i586/libwrap.so.0", O_RDONLY) = -1 ENOENT (No such file 
or directory)
647   stat64("/usr/local/kde/lib/i586", 0xb0c4) = -1 ENOENT (No such file or 
directory)
647   open("/usr/local/kde/lib/mmx/libwrap.so.0", O_RDONLY) = -1 ENOENT (No such file 
or directory)
647   stat64("/usr/local/kde/lib/mmx", 0xb0c4) = -1 ENOENT (No such file or 
directory)
647   open("/usr/local/kde/lib/libwrap.so.0", O_RDONLY) = -1 ENOENT (No such file or 
directory)
647   stat64("/usr/local/kde/lib", {st_mode=S_IFDIR|0755, st_size=17920, ...}) = 0
647   open("/usr/local/lib/i586/mmx/libwrap.so.0", O_RDONLY) = -1 ENOENT (No such file 
or directory)
647   stat64("/usr/local/lib/i586/mmx", 0xb0c4) = -1 ENOENT (No such file or 
directory)
647   open("/usr/local/lib/i586/libwrap.so.0", O_RDONLY) = -1 ENOENT (No such file or 
directory)
647   stat64("/usr/local/lib/i586", 0xb0c4) = -1 ENOENT (No such file or directory)
647   open("/usr/local/lib/mmx/libwrap.so.0", O_RDONLY) = -1 ENOENT (No such file or 
directory)
647   stat64("/usr/local/lib/mmx", 0xb0c4) = -1 ENOENT (No such file or directory)
647   open("/usr/local/lib/libwrap.so.0", O_RDONLY) = -1 ENOENT (No such file or 
directory)
647   stat64("/usr/local/lib", {st_mode=S_IFDIR|S_ISGID|0775, st_size=2048, ...}) = 0
647   open("/etc/ld.so.cache", O_RDONLY) = 3
647   fstat64(3, {st_mode=S_IFREG|0644, st_size=40661, ...}) = 0
647   old_mmap(NULL, 40661, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000
647   close(3)  = 0
647   open("/lib/libwrap.so.0", O_RDONLY) = 3
647   read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@ \0\000"..., 1024) = 
1024
647   fstat64(3, {st_mode=S_IFREG|0644, st_size=24328, ...}) = 0
647   old_mmap(NULL, 29092, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001e000
647   mprotect(0x40024000, 4516, PROT_NONE) = 0
647   old_mmap(0x40024000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
0x5000) = 0x40024000
647   old_mmap(0x40025000, 420, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40025000
647   close(3)  = 0
647   open("/usr/local/kde/lib/libnsl.so.1", O_RDONLY) = -1 ENOENT (No such file or 
directory)
647   open("/usr/local/lib/libnsl.so.1", O_RDONLY) = -1 ENOENT (No such file or 
directory)
647   open("/lib/libnsl.so.1", O_RDONLY) = 3
647   read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 ;\0\000"..., 1024) = 
1024
647   fstat64(3, {st_mode=S_IFREG|0644, st_size=69472, ...}) = 0
647   old_mmap(NULL, 80988, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40026000
647   mprotect(0x40037000, 11356, PROT_NONE) = 0
647   old_mmap(0x40037000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
0x1) = 0x40037000
647   old_mmap(0x40038000, 7260, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40038000
647   close(3)  = 0
647   open("/usr/local/kde/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or 
directory)
647   open("/usr/local/lib/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or 
directory)
647   open("/lib/libc.so.6", O_RDONLY)  = 3
647   read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\30\222"..., 1024) = 1024
647   fstat64(3, {st_mode=S_IFREG|0755, st_size=1153784, ...}) = 0
647   old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x4003a000
647   old_mmap(NULL, 1166560, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4003b000
647   mprotect(0x4014e000, 40160, PROT_NONE) = 0
647   old_mmap(0x4014e000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 
0x113000) = 0x4014e000
647   old_mmap(0x40154000, 15584, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40154000
6

Problems with Debian-based minimal rootfs

[Matt Porter]

Hi,

I am building a minimal rootfs that will loads as a large ramdisk when
booting some nodes on a clustered system.  I'm basically pulling pieces by
hand from a working PowerPC potato system as each node is PowerPC-based.
I only have the need to allow serial login and networking (rshd etc) so
I've stripped a lot of the sysvinit scripts out.  It has /etc/init.d/rc
and rcS.  It then has checkroot.sh, checkfs.sh, and bootmisc.sh running in
the single user runlevel.  In runlevel 2, I just run the network scripts.

The problem is that applications making use getpwnam() and friends can't
seem to parse my /etc/passwd (even though it is good, ripped out my
example system).  When bootmisc.sh attempts to chmod the tty* devices to
root.tty, it complains about an unknown user.  Further, /bin/login
complains that any user I enter is invalid and unknown.  I know this must
be something really trivial that I'm missing.  I've attached a dump of my
errors below.  Thanks for any help or suggestions.

--snip--

RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 64k init 4k pmac 8k open firmware
INIT: version 2.76 booting
Fast boot, no file system check
Cleaning: /tmp /var/lock /var/run.
chown: root:tty: invalid user
INIT: Entering runlevel: 2
Setting up IP spoofing protection...done.
Starting base networking daemons: inetd.

(none) login: root
Password:
login[47]: invalid password for `UNKNOWN' on `ttyS0'

Login incorrect

(none) login: demo
Password:
login[47]: invalid password for `UNKNOWN' on `ttyS0'

Login incorrect

(none) login:  

--
Matt Porter
[EMAIL PROTECTED]
This is Linux Country. On a quiet night, you can hear Windows reboot.

rootfs on /dev/sdf1

[Jens Kerle]

hi,

one more time i installed linux.
Debian 1.3.1 ! nice, fine, stable...

I had a big problem booting the first time after installing the base
system. I made a boot disk, but it can't find my root fs.

VFS: cannot mount root fs 00:00
Kernal panic: VFS: unable to mount root fs 00:00

because rootfs is on /dev/sdf (in real life my room is a big black hole,
collection everything). When i switch off one or two hd's, and rootfs
become /dev/sdd1, all is working fine. 

workaround: i have a old, working system on /dev/sda1. if i boot this, and
write lilo from there on /dev/sdf , i can boot.

Jens

Jens Kerle  e-mail: [EMAIL PROTECTED]
WWW: http://venus.rz.fh-heilbronn.de/~jkerle/   IRC: nick mars in #hp48
FTP: ftp://ftp.fh-heilbronn.de/pub/system/hp48


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . 
Trouble?  e-mail to [EMAIL PROTECTED] .