homedir weg na apt-get upgrade

[Verwijderd]

Na een apt-get upgrade op mijn Ubuntu Server installatie zijn er wat gekke dingen aan de hand.
Bij het inloggen:

code:

Could not chdir to home directory /home/lennart: No such file or directory
To run a command as administrator (user "root"), use "sudo <command>".

En de homedir is inderdaad foetsie...

Dit is mijn versie:

code:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=9.04
DISTRIB_CODENAME=jaunty
DISTRIB_DESCRIPTION="Ubuntu 9.04"

Iemand idee wat hier gebeurd kan zijn?

Overigens is dit topic hieraan gerelateerd wellicht, dit gebeurde ook na de upgrade.
Ook dacht ik na de upgrade met Ubuntu versie 10 te maken te hebben (vandaar de topic titel) maar dat doet `dist-upgrade´ en niet ´upgrade´, my bad.

[ Voor 24% gewijzigd door Verwijderd op 16-08-2010 20:13 ]

[CyBeR]

Had je /home op een andere partitie staan die nu niet meer gemount is? Packages doen nooit iets met /home namelijk.

[Verwijderd]

CyBeR schreef op maandag 16 augustus 2010 @ 20:10:
Had je /home op een andere partitie staan die nu niet meer gemount is? Packages doen nooit iets met /home namelijk.

Raak.
De mount /home is weg !
Ik heb tijdens de installatie de partitie layout opgeschreven.

root, home, var en tmp hadden allen een partitie.

Ik heb net een dist-upgrade gedaan en die liep helemaal in de soep.
Het schrijven naar /var/cached ging niet. (readonly)
Ook mounten m´n USB schijven nu helemaal niet meer.
(zie ook \[Ubuntu Server 10) USB devices "weg" uit mtab)

Waar dit sneeuwbal effect precies is gestart is me nog onduidelijk.
Maar krijg sterk de indruk dat alles samenvalt met `mount´ problemen.
Ik wacht nu op een reboot, en tijdens die reboot is er nu automatisch een check disk procedure gestart.
Wie weet gaat dat wat opleveren. De checkdisk `ziet´ in ieder geval wel de USB schijven weer tijdens de check wat die worden op dit moment bekeken.

[Verwijderd]

Ik heb net een dist-upgrade gedaan en die liep helemaal in de soep.

In dit geval zou ik een herinstallatie overwegen.

Het schrijven naar /var/cached ging niet. (readonly)

Heb je deze zelf ro gemount of is de disk aan het einde van zijn leven? In dat laatste geval zou ik mits je /home ook op deze disk staat direct een back-up maken van de belangrijke data.

[Verwijderd]

Verwijderd schreef op maandag 16 augustus 2010 @ 20:53:
[...]


In dit geval zou ik een herinstallatie overwegen.


[...]

Heb je deze zelf ro gemount of is de disk aan het einde van zijn leven? In dat laatste geval zou ik mits je /home ook op deze disk staat direct een back-up maken van de belangrijke data.

Nee, alle partities staan op 1 disk, de belangrijke data staat op 4 USB schijven en die draaien elke nacht een backup naar elkaar. (nouja belangrijk.... al m´n films en series )
Ik denk niet dat er veel gebeurd is met die dist-upgrade.
Het was 1 lange stroom van meldingen dat er niet geschreven kon worden en de versie uit /etc/lsb-release is nog exact dezefde als voor de dist-upgrade.

Ik heb echt niks aan de mount opties veranderd of wat voor instelling dan ook wat dat betreft.
Alles werkte, ik doe een "apt-get upgrade" en troubles.
Moet er wel bij vertellen dat de USB schijven voor de upgrade ook al raar deden in die zin dat ze soms wel gemount waren na een reboot en soms niet. Een `mount -a´ deed ze echter altijd succesvol mounten.

Dit probleem heb ik echter omschreven in dit topic: \[Ubuntu Server 10) USB devices "weg" uit mtab
Maar misschien is het relevant...

Hier is mijn fstab, wellicht helpt dat..
home is dus weggevallen. Zou er iets met die UUID´s kunnen zijn?
(weinig ervaring mee, maar wel eens zoiets gelezen..)

code:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
# / was on /dev/sda1 during installation
UUID=1ee0d402-eb34-44d6-932c-53fe1473b2ba /               ext3    relatime,errors=remount-ro 0       1
# /home was on /dev/sda6 during installation
UUID=3be24c35-fb2a-4558-b846-a9d70d2b024d /home           ext3    relatime        0       2
# /tmp was on /dev/sda8 during installation
UUID=39bf57d1-2e25-4533-a517-87271e8f5922 /tmp            ext3    relatime        0       2
# /var was on /dev/sda7 during installation
UUID=a6bf5b3d-be11-413d-bc68-2b0b2bd54bf9 /var            ext3    relatime        0       2
# swap was on /dev/sda5 during installation
UUID=81ea86d5-f72c-487f-8e34-eef340f149be none            swap    sw              0       0
/dev/scd0       /media/cdrom0   udf,iso9660 user,noauto,exec,utf8 0       0
/dev/fd0        /media/floppy0  auto    rw,user,noauto,exec,utf8 0       0

# Section added for External USB Hard drives.
# The labels are needed to pevent mixup in mounts and device order.

LABEL=usb1      /storage/usb1   auto    rw,user,auto,exec       0       3
LABEL=usb1copy  /storage/usb1copy   auto    rw,user,auto,exec       0       3
LABEL=usb2      /storage/usb2   auto    rw,user,auto,exec       0       3
LABEL=usb2copy  /storage/usb2copy   auto    rw,user,auto,exec       0       3

[ Voor 43% gewijzigd door Verwijderd op 16-08-2010 21:49 ]

[Verwijderd]

Nee, alle partities staan op 1 disk, de belangrijke data staat op 4 USB schijven en die draaien elke nacht een backup naar elkaar. (nouja belangrijk.... al m´n films en series )
Ik denk niet dat er veel gebeurd is met die dist-upgrade.
Het was 1 lange stroom van meldingen dat er niet geschreven kon worden en de versie uit /etc/lsb-release is nog exact dezefde als voor de dist-upgrade.

Als de data voor jou belangrijk is is het belangrijk. Het is al geweldig dat je er een backup van maakt. Ik kom nog te vaak tegen dat er onvervangbare data (zelfgemaakte foto's, video's etc.) verloren gaan door brakke disks waar geen backup van is.

Ik heb ook het idee dat er met de dist upgrade niet veel gebeurd is. In mijn ervaring is het als het echt fout gaat gewoon over met het systeem. Helaas heb ik de ervaring niet om je hiermee verder te helpen. Bij mijn minder succesvolle dist upgrade pogingen heb ik het systeem geherinstalleerd ipv een oplossing gezocht. (Ik was toen nog wel minder bekend met linux en ubuntu, nu zou ik eerst een blik werpen op de foutmeldingen).

Hopelijk kan iemand je verder helpen, een herinstall is natuurlijk een erg simpele niet leerzame oplossing. Het lijkt me wel relevant om te kijken waarom de upgrade niets kon schrijven. ro gemount of disk vol misschien?

[FireWood]

Doe eens het volgende in CLI:

code:

sudo mount /dev/disk/by-uuid/3be24c35-fb2a-4558-b846-a9d70d2b024d /mnt

Kun je daarna onder /mnt je home directory weer vinden?

[Verwijderd]

Verwijderd schreef op maandag 16 augustus 2010 @ 21:49:
[...]

Als de data voor jou belangrijk is is het belangrijk. Het is al geweldig dat je er een backup van maakt. Ik kom nog te vaak tegen dat er onvervangbare data (zelfgemaakte foto's, video's etc.) verloren gaan door brakke disks waar geen backup van is.

Ik heb ook het idee dat er met de dist upgrade niet veel gebeurd is. In mijn ervaring is het als het echt fout gaat gewoon over met het systeem. Helaas heb ik de ervaring niet om je hiermee verder te helpen. Bij mijn minder succesvolle dist upgrade pogingen heb ik het systeem geherinstalleerd ipv een oplossing gezocht. (Ik was toen nog wel minder bekend met linux en ubuntu, nu zou ik eerst een blik werpen op de foutmeldingen).

Hopelijk kan iemand je verder helpen, een herinstall is natuurlijk een erg simpele niet leerzame oplossing. Het lijkt me wel relevant om te kijken waarom de upgrade niets kon schrijven. ro gemount of disk vol misschien?

Backuppen zeker
Ik draai elke nacht een rsync via cron (zonder DELETE uiteraard, anders worden mappen die per abuis zijn verwijderd ook gesynced...) en dat gaat prima.

Ik doe liever geen hele herinstallatie.
Heb sterk de indruk dat het in fstab fout gaat.
Ik heb namelijk mijn /home weer terug door de partitie specifiek te mounten via mount /dev/sda6 /home
Raar genoeg kreeg ik de melding dat het device `busy´ was of `al gemount´ maar hierna was mijn home weer terug.

Onderstaande geeft ook aan hoe raar het systeem zit nu:

code:

lennart@hermes:~$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             82669500   4394832  74075280   6% /
varrun                  512732       532    512200   1% /var/run
udev                    512732       176    512556   1% /dev
/dev/sda8              4735892    140616   4354708   4% /tmp
/dev/sda7             19228276   1246728  17004800   7% /var
lennart@hermes:~$ cat /proc/mounts
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,mode=755 0 0
/dev/disk/by-uuid/1ee0d402-eb34-44d6-932c-53fe1473b2ba / ext3 ro,relatime,errors=remount-ro,data=ordered 0 0
varrun /var/run tmpfs rw,nosuid,mode=755 0 0
varlock /var/lock tmpfs rw,nosuid,nodev,noexec 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
varrun /var/run tmpfs rw,nosuid,mode=755 0 0
/dev/sda8 /tmp ext3 rw,relatime,errors=continue,data=ordered 0 0
/dev/sda7 /var ext3 rw,relatime,errors=continue,data=ordered 0 0
/dev/sda6 /home ext3 rw,relatime,errors=continue,data=ordered 0 0
/dev/sdb1 /storage/usb1 ext3 rw,nosuid,nodev,errors=continue,data=ordered 0 0
/dev/sdc1 /storage/usb2 ext3 rw,nosuid,nodev,errors=continue,data=ordered 0 0
lennart@hermes:~$

Zoals je kan zien komt de status van df niet overeen met wat er daadwerkelijk gemount is in /proc/mounts.
Die is wat mij betreft `leading´ want de info klopt, wat daar staat is inderdaad gemount. DF geeft onvolledige informatie.

Ik heb het idee dat die upgrade foutjes ook te maken hebben met mount problemen.

[Verwijderd]

h.edink schreef op maandag 16 augustus 2010 @ 21:56:
Doe eens het volgende in CLI:

code:

sudo mount /dev/disk/by-uuid/3be24c35-fb2a-4558-b846-a9d70d2b024d /mnt

Kun je daarna onder /mnt je home directory weer vinden?

ja !
Dit is heel appart, want is dat niet ook wat fstab zou moeten doen?
Die identifier (waar ik toch echt wat over moet gaan lezen) komt daar uit...

Even rebooten, kijken wat fstab nu doet.

Reboot gedaan, en mijn /home is weer weg.
En dit staat er in mounts:

code:

rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,mode=755 0 0
/dev/disk/by-uuid/1ee0d402-eb34-44d6-932c-53fe1473b2ba / ext3 ro,relatime,errors=remount-ro,data=ordered 0 0
varrun /var/run tmpfs rw,nosuid,mode=755 0 0
varlock /var/lock tmpfs rw,nosuid,nodev,noexec 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
varrun /var/run tmpfs rw,nosuid,mode=755 0 0
/dev/sda8 /tmp ext3 rw,relatime,errors=continue,data=ordered 0 0
/dev/sda7 /var ext3 rw,relatime,errors=continue,data=ordered 0 0

en wederom na een handmatige mount, heb ik weer een /home.

code:

lennart@hermes:/$ sudo mount /dev/sda6 /home
[sudo] password for lennart:
lennart@hermes:/$ cat /proc/mounts
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,mode=755 0 0
/dev/disk/by-uuid/1ee0d402-eb34-44d6-932c-53fe1473b2ba / ext3 ro,relatime,errors=remount-ro,data=ordered 0 0
varrun /var/run tmpfs rw,nosuid,mode=755 0 0
varlock /var/lock tmpfs rw,nosuid,nodev,noexec 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
varrun /var/run tmpfs rw,nosuid,mode=755 0 0
/dev/sda8 /tmp ext3 rw,relatime,errors=continue,data=ordered 0 0
/dev/sda7 /var ext3 rw,relatime,errors=continue,data=ordered 0 0
/dev/sda6 /home ext3 rw,errors=continue,data=ordered 0 0
lennart@hermes:/$

Gaat toch ergens fout met die UUID's dan denk ik ?
Heb ik die nodig? Kan ik ongestraft in fstab gaan harken ?

ok update, mijn hele bestandsysteem lijkt read-only.
Ik kan fstab niet wegschrijven : read-only filesystem. En die staat gewoon op root.

Wellicht hier iets mee van doen? : relatime,errors=remount-ro
Wat dus wil impliceren dat er bij het mounten van "/" dus errors zijn en er daarom read only gemount is?

[ Voor 97% gewijzigd door Verwijderd op 16-08-2010 22:49 ]

[Hero of Time]

Wat ik zou doen is een goede backup maken van alles, je volledige systeem. Daarna ga je met een live CD aan de slag. De USB dingen haal je los, daar staat je backup op en moet je niet meer hebben als je aan het werk gaat. Eerst een fsck uitvoeren op elke interne schijf/partitie. Daarna ga je je fstab controleren door de UUIDs te controleren met de uitvoer van 'sudo blkid'. Als dat allemaal gedaan is, kan je kijken wat een reboot doet.

[gertvdijk]

Wat zegt syslog/dmesg over het mounten bij het booten?

[Verwijderd]

Hero Of Time schreef op maandag 16 augustus 2010 @ 23:08:
Wat ik zou doen is een goede backup maken van alles, je volledige systeem. Daarna ga je met een live CD aan de slag. De USB dingen haal je los, daar staat je backup op en moet je niet meer hebben als je aan het werk gaat. Eerst een fsck uitvoeren op elke interne schijf/partitie. Daarna ga je je fstab controleren door de UUIDs te controleren met de uitvoer van 'sudo blkid'. Als dat allemaal gedaan is, kan je kijken wat een reboot doet.

Wuh? Ben je niet goed wijs? De partitie is handmatig gewoon te mounten, dus als hij kan vinden waarom de fstab niet werkt, en dat oplost, dan is het hele probleem opgelost. De partitie verdwijnt echt niet door dit probleem, dus die hele backup is een beetje vergezocht.

[lordgandalf]

Ik zou je usb disken los gooien en even met een livecd je interne disk fsckken.
als dit successvol is gedaan dan rebooten en proberen je systeem weer op orde te brengen en daarna je disken weer terug hangen.

Je zou ook even proberen of mount -a hem niet goed mount

[vanaalten]

Ach, een backup maken (en daarna loskoppelen) kan natuurlijk nooit kwaad en als die disks inderdaad op het punt van overlijden staan zou je er nog profijt van kunnen hebben - maar waarschijnlijk is het allemaal zo serieus niet en makkelijk op te lossen.

Maar wat gertvdijk zegt is behoorlijk zinnig:

Wat zegt syslog/dmesg over het mounten bij het booten?

... dus /var/log/syslog en eventueel /var/log/boot eens doorkijken, liefst vlak na een reboot.

[johnkeates]

Je kan je UUID's even nalopen in /dev/disk/by-uuid om te kijken of die niet ergens veranderd zijn (dat zou niet het geval moeten zijn) en of er anders schijven opeens niet meer voor komen.

Verder inderdaad /var/log/syslog|dmesg|boot controleren, en als je een splash gebruikt of met silent boot eens 'normaal' booten om te kijken of er tussendoor niet iets langs komt als /var/log/* nutteloos is door mismounts.

USB schijven inderdaad los, zoals eerder beschreven, je data is niet van belang bij het herstellen van je systeem, dat komt later wel.

Wat wel erg raar is, is dat een apt-get actie je mount en/of /etc/fstab zo verbouwt, dat zou niet moeten gebeuren.

[Verwijderd]

gertvdijk schreef op dinsdag 17 augustus 2010 @ 01:09:
Wat zegt syslog/dmesg over het mounten bij het booten?

Dit kan ik vinden over de interne schijf (SDA)

code:

lennart@hermes:/var/log$ less dmesg | grep sda
[    2.884734] sd 0:0:0:0: [sda] 240121728 512-byte hardware sectors: (122 GB/114 GiB)
[    2.884790] sd 0:0:0:0: [sda] Write Protect is off
[    2.884795] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    2.884875] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.885079] sd 0:0:0:0: [sda] 240121728 512-byte hardware sectors: (122 GB/114 GiB)
[    2.885129] sd 0:0:0:0: [sda] Write Protect is off
[    2.885134] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    2.885212] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.885222]  sda: sda1 sda2 < sda5 sda6 sda7 sda8 >
[    2.963852] sd 0:0:0:0: [sda] Attached SCSI disk
[    9.802325] Adding 1951856k swap on /dev/sda5.  Priority:-1 extents:1 across:1951856k
[   10.203532] EXT3 FS on sda1, internal journal
[   12.212142] EXT3 FS on sda6, internal journal
[   12.247454] EXT3 FS on sda8, internal journal
[   12.269788] EXT3 FS on sda7, internal journal

[Verwijderd]

johnkeates schreef op dinsdag 17 augustus 2010 @ 13:15:
Je kan je UUID's even nalopen in /dev/disk/by-uuid om te kijken of die niet ergens veranderd zijn (dat zou niet het geval moeten zijn) en of er anders schijven opeens niet meer voor komen.

Verder inderdaad /var/log/syslog|dmesg|boot controleren, en als je een splash gebruikt of met silent boot eens 'normaal' booten om te kijken of er tussendoor niet iets langs komt als /var/log/* nutteloos is door mismounts.

USB schijven inderdaad los, zoals eerder beschreven, je data is niet van belang bij het herstellen van je systeem, dat komt later wel.

Wat wel erg raar is, is dat een apt-get actie je mount en/of /etc/fstab zo verbouwt, dat zou niet moeten gebeuren.

code:

# / was on /dev/sda1 during installation
UUID=1ee0d402-eb34-44d6-932c-53fe1473b2ba /               ext3    relatime,errors=remount-ro 0       1

# /home was on /dev/sda6 during installation
UUID=3be24c35-fb2a-4558-b846-a9d70d2b024d /home           ext3    relatime        0       2

# /tmp was on /dev/sda8 during installation
UUID=39bf57d1-2e25-4533-a517-87271e8f5922 /tmp            ext3    relatime        0       2

# /var was on /dev/sda7 during installation
UUID=a6bf5b3d-be11-413d-bc68-2b0b2bd54bf9 /var            ext3    relatime        0       2

# swap was on /dev/sda5 during installation
UUID=81ea86d5-f72c-487f-8e34-eef340f149be none            swap    sw              0       0

versus

code:

lrwxrwxrwx 1 root root 10 2010-08-16 22:10 1ee0d402-eb34-44d6-932c-53fe1473b2ba -> ../../sda1
lrwxrwxrwx 1 root root 10 2010-08-16 22:10 39bf57d1-2e25-4533-a517-87271e8f5922 -> ../../sda8
lrwxrwxrwx 1 root root 10 2010-08-16 22:10 3be24c35-fb2a-4558-b846-a9d70d2b024d -> ../../sda6
lrwxrwxrwx 1 root root 10 2010-08-16 22:10 5dcf78b4-e257-4b01-84b5-1b1fba8b9cc9 -> ../../sdb1
lrwxrwxrwx 1 root root 10 2010-08-16 22:10 81ea86d5-f72c-487f-8e34-eef340f149be -> ../../sda5
lrwxrwxrwx 1 root root 10 2010-08-16 22:10 a6bf5b3d-be11-413d-bc68-2b0b2bd54bf9 -> ../../sda7
lrwxrwxrwx 1 root root 10 2010-08-16 22:10 cf52d922-a2c5-4314-9c9a-210ebda42f1c -> ../../sdc1

Lijkt correct. (SDA is interne schijf, SDB is een USB schijf)
En dan nog iets...
Als ik in recovery mode start dan werkt alles wel.
Ik heb /home, ik kan schrijven en ik heb mijn USB schijven.

Als ik normaal boot dan loop ik tegen de problemen op.
Ook krijg ik nu de volgende meldingen net voor m´n login prompt:
(en deze krijg ik dus ook NIET in recovery mode met netwerk support)

code:

umount: /var (device is busy)
umount: /tmp (device is busy)
umount: /dev (device is busy)
umount: /var/run (device is busy)

[ Voor 9% gewijzigd door Verwijderd op 17-08-2010 13:58 ]

[vanaalten]

Verwijderd schreef op dinsdag 17 augustus 2010 @ 13:29:
[...]


Dit kan ik vinden over de interne schijf (SDA)

code:

lennart@hermes:/var/log$ less dmesg | grep sda

Heb je alleen dat gedaan, of heb je ook eens gewoon met een texteditor je logfiles (syslog, boot...) vanaf boot-moment doorgekeken?

code:

umount: /var (device is busy)
umount: /tmp (device is busy)
umount: /dev (device is busy)
umount: /var/run (device is busy)

Interessante aanwijzing, maar je moet er wat meer context van hebben om er wat mee te kunnen: wanneer en waarom probeert 'ie te umount-en?
Die meldingen moeten toch ook in een logfile terecht komen. Zoek die logfile en de meldingen daarin eens op, zodat je wat meer ziet over wat 'ie aan het doen is.

[Verwijderd]

vanaalten schreef op dinsdag 17 augustus 2010 @ 15:10:
[...]

Heb je alleen dat gedaan, of heb je ook eens gewoon met een texteditor je logfiles (syslog, boot...) vanaf boot-moment doorgekeken?


[...]

Interessante aanwijzing, maar je moet er wat meer context van hebben om er wat mee te kunnen: wanneer en waarom probeert 'ie te umount-en?
Die meldingen moeten toch ook in een logfile terecht komen. Zoek die logfile en de meldingen daarin eens op, zodat je wat meer ziet over wat 'ie aan het doen is.

Ik kan geen errors vinden.
Het vreemde is ook dat als ik een mount -a doe dat dan opeens wel weer /home gemount is en ik kan schrijven, etc. Maar naar mijn weten doet mount -a niets anders dan fstab inlezen, iets wat ook bij het opstarten dus zou gebeuren. In recovery mode gaat dat dus goed, bij normale boot niet. Ik heb de read-only parameter trouwens verwijderd uit fstab (on error: read only) geen effect. no steeds read only.

[Hero of Time]

Verwijderd schreef op dinsdag 17 augustus 2010 @ 01:19:
[...]

Wuh? Ben je niet goed wijs? De partitie is handmatig gewoon te mounten, dus als hij kan vinden waarom de fstab niet werkt, en dat oplost, dan is het hele probleem opgelost. De partitie verdwijnt echt niet door dit probleem, dus die hele backup is een beetje vergezocht.

Wat is er mis met een full system backup? Als je een reinstall moet doen, kan je altijd je config makkelijk terug halen. Mocht fsck wat je later uitvoerd bestanden weggooien omdat deze praktisch corrupt zijn in een FS oogpunt, maar nog wel normaal te lezen waren, kan je deze toch mooi herstellen. Het wordt zelfs meerdere malen herhaald na mijn reply. En een controle van je fstab met blkid, of in een ander geval /dev/disk/by-uuid kan nooit kwaad.

on-topic:
Het is leuk dat je dmesg grepped op sda, maar daar heb je geen eventuele errors mee die je ervoor of erna krijgt.
Weet je 100% zeker dat er geen packages zijn geïnstalleerd tijdens je dist-upgrade? Het is mogelijk dat je default mount packages een upgrade hebben gehad en dit allemaal veroorzaken tijdens boot, maar alleen als je verder dan runlevel 1 gaat. Kijk eens of je niet toevallig packages al hebt van 9.10 of waar je ook naartoe wilde upgraden. Dit is eenvoudig te doen via aptitude (geen parameters) en bij Options > Preferences | Display format for package views het volgende invullen:

code:

%c%a%M%S %p %v %V %t

Dit is de standaard waarde, met %t erbij. Dat laat zien waar een package vandaan komt. Mocht het leeg zijn, dan is de versie niet beschikbaar in je huidige repo lijst en kan duiden op een PPA die is uitgeschakeld of van een andere Ubuntu release.
Je kan altijd nog via een live CD chrooten naar je installatie en van daaruit de upgrade hervatten.

[vanaalten]

Hero Of Time schreef op dinsdag 17 augustus 2010 @ 22:06:
[...]

Wat is er mis met een full system backup?

Met een backup is nooit iets mis, maar daarna een complete her-installatie... het is zo'n... windows-achtige oplossing... ... misinterpretatie!

Als je een reinstall moet doen, kan je altijd je config makkelijk terug halen.

Ja, je config wel, maar weet je nog precies wat je aan packages geinstalleerd had?
Zijn natuurlijk ook wel mogelijkheden voor, maar zolang de boel niet hopeloos is zou ik niet her-installeren.

Waar ik nou eens benieuwd naar ben: wat heb je exact gedaan om deze puinhoop te veroorzaken?
Je hebt het over een upgrade of dist-upgrade, poging om naar ubuntu-10 te gaan - maar wat deed je nou precies?

Ik heb enkel ervaring met Debian, niet Ubuntu. Bij debian, als ik naar een nieuwe versie wil gaan, moet ik eerst wat aanpassen in /etc/apt/sources.list, dan apt-get update, dan apt-get dist-upgrade.
Wat heb jij precies gedaan en gelaten?

[ Voor 5% gewijzigd door vanaalten op 18-08-2010 00:45 ]

[Hero of Time]

Waar haal je opeens vandaan dat ik zeg dat hij een reinstall moet uitvoeren? Ik zeg alleen dat hij een backup heeft in geval het nodig is, oftewel, als de boel helemaal fubar is.

Bovendien herhaal je wat ik ook al vroeg: wat is er precies gebeurt, is er überhaupt iets uitgevoerd etc.

[vanaalten]

Hero Of Time schreef op dinsdag 17 augustus 2010 @ 23:42:
Waar haal je opeens vandaan dat ik zeg dat hij een reinstall moet uitvoeren? Ik zeg alleen dat hij een backup heeft in geval het nodig is, oftewel, als de boel helemaal fubar is.

Excuses - misinterpretatie van mijn kant!

Bovendien herhaal je wat ik ook al vroeg: wat is er precies gebeurt, is er überhaupt iets uitgevoerd etc.

Zijn we het daar in elk geval over eens...

[Verwijderd]

Hero Of Time schreef op dinsdag 17 augustus 2010 @ 22:06:
[...]

on-topic:
Het is leuk dat je dmesg grepped op sda, maar daar heb je geen eventuele errors mee die je ervoor of erna krijgt.

Ik heb ook de sysstat, boot (leeg) en dmesg bekeken. Ik weet natuurlijk ook niet precies wat ik zoek, maar ik zie geen gekke dingen tot nu toe. Dat is het probleem een beetje.

Weet je 100% zeker dat er geen packages zijn geïnstalleerd tijdens je dist-upgrade? Het is mogelijk dat je default mount packages een upgrade hebben gehad en dit allemaal veroorzaken tijdens boot, maar alleen als je verder dan runlevel 1 gaat. Kijk eens of je niet toevallig packages al hebt van 9.10 of waar je ook naartoe wilde upgraden. Dit is eenvoudig te doen via aptitude (geen parameters) en bij Options > Preferences | Display format for package views het volgende invullen:

code:

%c%a%M%S %p %v %V %t

Dit is de standaard waarde, met %t erbij. Dat laat zien waar een package vandaan komt. Mocht het leeg zijn, dan is de versie niet beschikbaar in je huidige repo lijst en kan duiden op een PPA die is uitgeschakeld of van een andere Ubuntu release.
Je kan altijd nog via een live CD chrooten naar je installatie en van daaruit de upgrade hervatten.

Nee dat weet ik niet zeker.
Ik heb een update gedaan. Toen een upgrade en toen een dist-upgrade.
Na de "upgrade" zijn de problemen begonnen. Ik dacht met de dist-upgrade dingen weer te fixen.
De problemen zijn hetzelfde gebleven.

Ik zal eens kijken naar die packages wat je me hebt aangeraden via aptitude.

[DJvL]

Ik heb 2 maanden geleden precies hetzelfde probleem gehad alleen dan bij debian 5.04 en bij mij lag het toch aan een defecte harde schijf.
Dit hoeft natuurlijk niet het geval te zijn, maar ik zou wel zorgen voor een backup.

Welk bestandssysteem gebruik je?

[ Voor 7% gewijzigd door DJvL op 19-08-2010 08:27 ]

[Verwijderd]

DJvL schreef op donderdag 19 augustus 2010 @ 08:25:
Ik heb 2 maanden geleden precies hetzelfde probleem gehad alleen dan bij debian 5.04 en bij mij lag het toch aan een defecte harde schijf.
Dit hoeft natuurlijk niet het geval te zijn, maar ik zou wel zorgen voor een backup.

Welk bestandssysteem gebruik je?

EXT3.
Een fsck (na umount) op /dev/sda1 geeft aan dat hij `clean´ is.
Of dat ook wil zeggen dat de schijf "ok" is, is bij deze een vraag.
Daarbij werkt alles wel in recovery modus.
Bedankt voor je input iig.

[ Voor 6% gewijzigd door Verwijderd op 19-08-2010 12:52 ]

[Verwijderd]

Hero Of Time schreef op dinsdag 17 augustus 2010 @ 22:06:
[...]
Je kan altijd nog via een live CD chrooten naar je installatie en van daaruit de upgrade hervatten.

Ik heb middels recovery mode alsnog een upgrade succesvol kunnen doen.
Dit heeft echter geen effect gehad op het probleem helaas.

[mace]

Ik zou met e2label je sda6 een label geven, en dan in de fstab op dat label mounten, en de uuid achterwege laten.

[Verwijderd]

mace schreef op donderdag 19 augustus 2010 @ 13:11:
Ik zou met e2label je sda6 een label geven, en dan in de fstab op dat label mounten, en de uuid achterwege laten.

Gedaan. exact zelfde symptomen. (maar het werkt dus wel met die label, na een mount -a heb ik gewoon weer een /home via de label dus, niet via de UUID.

[Verwijderd]

Ik heb nu het vermoeden dat misschien GRUB het probleem kan zijn.
Tijdens mijn update acties heeft update-grub denk ik ook gelopen.
Er kan daar iets veranderd zijn.

Ik kom op die locatie uit omdat het logisch is.
Als ik GRUB trigger met esc en dan recovery mode start werkt alles.
Maar als ik `normaal´ boot dan is root read-only.
Als er geen errors te vinden zijn in de logs en in een andere `user mode´ werkt het allemaal wel dan zouden het wel eens de kernel opties in GRUB kunnen zijn, daarmee initieer ik immers die verschillende modi.
Daarbij is er dat automagische ge-update via update-grub wat me niet lekker zit.

Hoe dan ook, GRUB / update-grub is een kandidaat als boosdoener voor me.
Ik zal me melden als ik meer weet.

[Hero of Time]

Grub lijkt mij een beetje sterk. Dit omdat het verschil tussen normaal booten en recovery mode alleen maar de parameter 'single' moet zijn. De boot stopt dan als run level 1 klaar is, waarna je dus 't root wachtwoord in kan geven of via ctrl+d alsnog verder kan booten. Neemt niet weg dat 't het onderzoeken waard is.

Voor de schijfcontrole zegt fsck niets. Die kan idd clean aangeven, maar als je schijf gewoon gaar is, maakt dat niets uit. Kijk eens met smartmontools (smartctl -a laat alle informatie zien bijvoorbeeld, is meer dan 1 scher pagina). Hierbij let je op dit:

code:

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

En uiteraard de rest, maar dit geeft al een redelijke indicatie voor predictive failure.

* Hero of Time kijkt even bij zijn /dev/sda (niet z'n boot disk, maar wel waar Windows nog op staat, alsmede alle documenten, mail en andere zut) en ziet een aantal old_age en Pre-fail entries .
Tijd voor een nieuwe schijf en de boel backuppen. Ach, alsie maar volgend jaar haalt

[Verwijderd]

Hero Of Time schreef op donderdag 19 augustus 2010 @ 19:45:
Grub lijkt mij een beetje sterk. Dit omdat het verschil tussen normaal booten en recovery mode alleen maar de parameter 'single' moet zijn. De boot stopt dan als run level 1 klaar is, waarna je dus 't root wachtwoord in kan geven of via ctrl+d alsnog verder kan booten. Neemt niet weg dat 't het onderzoeken waard is.

Voor de schijfcontrole zegt fsck niets. Die kan idd clean aangeven, maar als je schijf gewoon gaar is, maakt dat niets uit. Kijk eens met smartmontools (smartctl -a laat alle informatie zien bijvoorbeeld, is meer dan 1 scher pagina). Hierbij let je op dit:

code:

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

En uiteraard de rest, maar dit geeft al een redelijke indicatie voor predictive failure.

* Hero of Time kijkt even bij zijn /dev/sda (niet z'n boot disk, maar wel waar Windows nog op staat, alsmede alle documenten, mail en andere zut) en ziet een aantal old_age en Pre-fail entries .
Tijd voor een nieuwe schijf en de boel backuppen. Ach, alsie maar volgend jaar haalt

smartmontools gebruikt, ziet er goed uit.
En in recovery mode werkt alles wel prima.
Maar bedankt voor de tip, smartmontools gebuikte ik nog niet. ziet er mooi uit.

Toen ik trouwens opnieuw opstarte vanuit recovery mode kwam tijdens het afsluiten iets als..

`sda7 busy, remounted read only.´

...voorbij. SDA7 is gemount op /var
Ook de meldingen net voor het inloggen

umount: /var (device is busy)
umount: /tmp (device is busy)
umount: /dev (device is busy)
umount: /var/run (device is busy)

Blijven heel erg raar. Ik kan daar geen touw aan vastknopen, maar het lijkt me wel relevant daar de meldingen samen met het probleem zijn ontstaan.

[Hero of Time]

Instsalleer eens bootchart en kijk naar de grafiek die het genereert. Het geeft weer welke processen er tijdens de boot worden opgestart en hoe lang dit duurt, wellicht kan je daar wat uit halen.

[vanaalten]

Ik vind het wat lastig om de melding goed te interpreteren:

Ook de meldingen net voor het inloggen

umount: /var (device is busy)
umount: /tmp (device is busy)
umount: /dev (device is busy)
umount: /var/run (device is busy)

(opvallend - staat dus geen melding bij over je /home partitie)
... betekent dat nou dat die partities dus wel gemount waren, maar omdat het device busy is worden ze ge-umount? Of probeert 'ie ze te umounten maar lukt dat niet omdat de devices busy zijn?

Je log-files zouden op /var/log moeten staan - die dus ook op een eigen partitie staan. Ofwel: heb je sowieso wel up-to-date logfiles van de meest recente inlog-poging?

Ik kan mij voorstellen dat, als je root-partitie ruimte genoeg heeft, het interessant kan zijn om die /var partitie even handmatige te mounten en volledig over te zetten naar je root partitie en (uiteraard) je fstab daarop aan te passen. De directory /var/log staat daarmee dus ook op de root partitie, wellicht dat je er dan meer aanwijzingen in krijgt.

Wat mij namelijk nog steeds het meest verbaasd is dat je die umount-meldingen niet terug weet te vinden in logfiles.

[Verwijderd]

vanaalten schreef op donderdag 19 augustus 2010 @ 23:26:
Ik vind het wat lastig om de melding goed te interpreteren:

[...]

(opvallend - staat dus geen melding bij over je /home partitie)
... betekent dat nou dat die partities dus wel gemount waren, maar omdat het device busy is worden ze ge-umount? Of probeert 'ie ze te umounten maar lukt dat niet omdat de devices busy zijn?

Inderdaad. Zo zat ik dus ook.

Je log-files zouden op /var/log moeten staan - die dus ook op een eigen partitie staan. Ofwel: heb je sowieso wel up-to-date logfiles van de meest recente inlog-poging?

Ik kan mij voorstellen dat, als je root-partitie ruimte genoeg heeft, het interessant kan zijn om die /var partitie even handmatige te mounten en volledig over te zetten naar je root partitie en (uiteraard) je fstab daarop aan te passen. De directory /var/log staat daarmee dus ook op de root partitie, wellicht dat je er dan meer aanwijzingen in krijgt.

Wat mij namelijk nog steeds het meest verbaasd is dat je die umount-meldingen niet terug weet te vinden in logfiles.

Goede suggestie. Ik heb niet naar timestamps gekeken, gewoon gezocht naar vreemde meldingen en maar aangenomen dat dit de laatste log was. (Assumptions dus....daar is een bekend engels, ietwat platvloers gezegde over )
Ik ga dat even bekijken vanavond, bedankt.

[Verwijderd]

Hero Of Time schreef op donderdag 19 augustus 2010 @ 23:17:
Instsalleer eens bootchart en kijk naar de grafiek die het genereert. Het geeft weer welke processen er tijdens de boot worden opgestart en hoe lang dit duurt, wellicht kan je daar wat uit halen.

En ik ga ook dat bootchart bekijken.

[Hero of Time]

Grap met bootchart is dat deze ook in /var wat plaatst, heel fijn als je die niet hebt .

[Verwijderd]

Wanneer ik:

code:

lennart@hermes:/$ sudo mount -n -o remount /

doe is root weer te beschrijven.
Als ik overigens root met e2fsck -a check dan is-ie clean.

Maar na booten weer read only...

[Verwijderd]

Verwijderd schreef op zondag 22 augustus 2010 @ 15:01:
Wanneer ik:

code:

lennart@hermes:/$ sudo mount -n -o remount /

doe is root weer te beschrijven.
Als ik overigens root met e2fsck -a check dan is-ie clean.

Maar na booten weer read only...

Weet je zeker dat je hardware niet brak is? De kernel mount devices read only wanneer deze defecten vertonen, brakke, losgeschoten kabels etc.

[vanaalten]

Hoe zat het nou met de logfiles - waren die up-to-date, of was /var/log ook read-only zodat er alleen oude logfiles stonden?

User johnkeates had destijds nog wel een goede suggestie:

en als je een splash gebruikt of met silent boot eens 'normaal' booten om te kijken of er tussendoor niet iets langs komt als /var/log/* nutteloos is door mismounts.

Ik ben niet zo thuis in Ubuntu, maar wat ik zo zie zou je /boot/grub/menu.lst moeten aanpassen - overal waar 'splash' of 'quiet' staat weghalen. Je moet dan opnieuw booten en als het goed is krijg je dan veel meer meldingen te zien.

(overigens weet ik niet of Ubuntu 9.04 al grub2 gebruikt, en of je dus nog een menu.lst hebt om aan te passen...)

[Verwijderd]

vanaalten schreef op zondag 22 augustus 2010 @ 15:18:
Hoe zat het nou met de logfiles - waren die up-to-date, of was /var/log ook read-only zodat er alleen oude logfiles stonden?

De logfiles zijn up to date.

Ik ben niet zo thuis in Ubuntu, maar wat ik zo zie zou je /boot/grub/menu.lst moeten aanpassen - overal waar 'splash' of 'quiet' staat weghalen. Je moet dan opnieuw booten en als het goed is krijg je dan veel meer meldingen te zien.
(overigens weet ik niet of Ubuntu 9.04 al grub2 gebruikt, en of je dus nog een menu.lst hebt om aan te passen...)

Heb een menu.lst
Die opties van quiet en splash staan er inderdaad.

code:

title           Ubuntu 9.04, kernel 2.6.28-19-server
uuid            1ee0d402-eb34-44d6-932c-53fe1473b2ba
kernel          /boot/vmlinuz-2.6.28-19-server root=UUID=1ee0d402-eb34-44d6-932c-53fe1473b2ba quiet splash
initrd          /boot/initrd.img-2.6.28-19-server
quiet

Zal die eens proberen weg te halen.

[Verwijderd]

Verwijderd schreef op zondag 22 augustus 2010 @ 15:09:
[...]


Weet je zeker dat je hardware niet brak is? De kernel mount devices read only wanneer deze defecten vertonen, brakke, losgeschoten kabels etc.

Als ik in recovery mode start (en het enige verschil is dus dan SINGLE user mode)
Dan werkt alles. zelfs mijn USB schijven worden direct gemount, home werkt, alle problemen zijn dan opgelost.
Zou er dan iets binnen die RC stadia misgaan? en hoe kan het ontstaan zijn na een upgrade?

[vanaalten]

Da's misschien ook wel leuk om eens te onderzoeken.
Ik vermoed dat een recovery-boot runlevel 1 start en een gewone boot naar runlevel 2 gaat.

Kan je ze allebei eens opstarten en dan

code:

sudo runlevel

doen? Daarmee krijg je te zien in welke runlevel je op dat moment zit.

In /etc/inittab kan je trouwens zien wat normaal gesproken je default runlevel is (bij mij staat er 'id:2:initdefault:', ofwel default runlevel 2).

Daarna kan het interessant zijn om eens handmatig van je recovery runlevel 'omhoog' te gaan, dus stel dat recovery runlevel 1 is, dan kan je met

code:

sudo telinit 2

... naar runlevel 2 gaan. (weet niet zeker of dat met sudo goed gaat, of dat je het liever echt als root uitvoert)

Met wat geluk krijg je daar wat meer informatie uit over wat er precies mis gaat.

[Verwijderd]

Ik zie geen errors.
Quiet en splash verwijderd en van init level 1 naar 2 gegaan.

Ik krijg de vreemd umount meldingen nadat alles deamons zijn gestart.
Na Apache 2 komen de reeks umount meldingen waar ik geen chocola van kan bakken.
De apache webserver geeft overigens gewoon [ ok ] aan.

Ik zit nu aan apparmor oid te denken.... alleen weet ik daar niet veel van.
Het kan alleen wel restricties opleggen en is volgens mij afwezig in single user mode?

Hoe dan ook, het moet iets zijn wat in runlevel 2 start en in single user mode (runlevel 1) niet.
fstab is het probleem denk ik niet, want in single user mode werkt alles prima.

Dit systeem is gewoon voor de hobby anders had ik al lang een workaround bedacht.
Maar dat is dus in zijn geheel niet bevredigend.
Ik wil weten wat dit is, dit is namelijk te weird.

[vanaalten]

Je laatste post is voor mij wat onsamenhangend...
Wat staat in je /etc/inittab als default runlevel?

Als je vanaf recoverymode handmatig (met telinit 2) naar runlevel 2 gaat, dan krijg je die errors dus niet en zijn al je drives nog netjes read/write gemount?

Over dit:

Na Apache 2 komen de reeks umount meldingen waar ik geen chocola van kan bakken.

... krijg je die alleen bij normaal opstarten (zonder splash & quiet) of ook als je handmatig naar runlevel 2 gaat?

[Verwijderd]

vanaalten schreef op zondag 22 augustus 2010 @ 22:53:
Je laatste post is voor mij wat onsamenhangend...
Wat staat in je /etc/inittab als default runlevel?

Weet ik niet, maar normaal booten kom ik in runlevel 2

Als je vanaf recoverymode handmatig (met telinit 2) naar runlevel 2 gaat, dan krijg je die errors dus niet en zijn al je drives nog netjes read/write gemount?

Nee, sorry misschien wat onduidelijk. Ik krijg exact dezelde errors als ik handmatig van runlevel 1 naar 2 ga.
Dezelfde errors als zou ik normaal booten. Als ik dus handmatig van 1 naar 2 ga krijg ik niet meer aanwijzingen en de situatie is dezelfde: read-only.

... krijg je die alleen bij normaal opstarten (zonder splash & quiet) of ook als je handmatig naar runlevel 2 gaat?

Beiden dus. Ik krijg de rare umount meldingen dus als ik in runlevel 2 zit.
Maakt niet uit of dat handmatig of via normale boot is.
Runlevel 1 (single user mode) wat ik opstart via recovery mode in het GRUB menu is de enige manier om te booten dat alles meteen werkt.

[vanaalten]

Verwijderd schreef op maandag 23 augustus 2010 @ 11:14:
Nee, sorry misschien wat onduidelijk. Ik krijg exact dezelde errors als ik handmatig van runlevel 1 naar 2 ga.
Dezelfde errors als zou ik normaal booten. Als ik dus handmatig van 1 naar 2 ga krijg ik niet meer aanwijzingen en de situatie is dezelfde: read-only.

Oh, maar dat is hardstikke mooi!

Nee, serieus, dan kan je weer verder komen. Je kan namelijk wat er gebeurt bij 'telinit 2' ook handmatig uitvoeren. Wat er gebeurd als je dat commando uitvoert is vrij simpel: op numerieke/alfabetische volgorde worden alle scripts die met 'S' beginnen onder /etc/rc2.d uitgevoerd.

Als ik op mijn server kijk wat er onder /etc/rc2.d staat:

code:

$ ls -l /etc/rc2.d/S*
lrwxrwxrwx 1 root root 19 Aug  7 13:29 /etc/rc2.d/S01dkimproxy -> ../init.d/dkimproxy
lrwxrwxrwx 1 root root 25 Aug 16 13:29 /etc/rc2.d/S01mldonkey-server -> ../init.d/mldonkey-server
lrwxrwxrwx 1 root root 21 Aug 21 09:50 /etc/rc2.d/S01sabnzbdplus -> ../init.d/sabnzbdplus
lrwxrwxrwx 1 root root 15 Aug  7 13:29 /etc/rc2.d/S01samba -> ../init.d/samba
lrwxrwxrwx 1 root root 14 Aug  7 13:29 /etc/rc2.d/S01sudo -> ../init.d/sudo
lrwxrwxrwx 1 root root 18 Aug  7 13:29 /etc/rc2.d/S01sysklogd -> ../init.d/sysklogd
lrwxrwxrwx 1 root root 24 Aug  7 13:47 /etc/rc2.d/S01twonkymedia.sh -> ../init.d/twonkymedia.sh
lrwxrwxrwx 1 root root 17 Aug  7 13:29 /etc/rc2.d/S02apache2 -> ../init.d/apache2
lrwxrwxrwx 1 root root 15 Aug  7 13:29 /etc/rc2.d/S03acpid -> ../init.d/acpid
lrwxrwxrwx 1 root root 16 Aug  7 13:29 /etc/rc2.d/S03amavis -> ../init.d/amavis
....

Als ik vanaf runlevel 1 naar 2 zou willen, dan kan dat dus door een voor een die scripts op alfabetische volgorde uit te voeren:

code:

$ sudo /etc/rc2.d/S01dkimproxy
(uitvoer van dkimproxy script)
$ sudo /etc/rc2.d/S01mldonkey-server
(uitvoer van mldonkey-server script)
$ sudo /etc/rc2.d/S01sabnzbdplus
...

Het is even wat werk, maar als je het nauwkeurig goed uitvoert kan je dus wel exact bepalen welk script je /home partitie read-only remount. Daarna wordt het misschien wat vervelender - mogelijk dat je dat bewuste script zelf zal moeten debuggen - maar je kan het probleem in elk geval wat preciezer bepalen.

[Verwijderd]

vanaalten schreef op maandag 23 augustus 2010 @ 13:57:
[...]

Oh, maar dat is hardstikke mooi!

Nee, serieus, dan kan je weer verder komen. Je kan namelijk wat er gebeurt bij 'telinit 2' ook handmatig uitvoeren. Wat er gebeurd als je dat commando uitvoert is vrij simpel: op numerieke/alfabetische volgorde worden alle scripts die met 'S' beginnen onder /etc/rc2.d uitgevoerd.

Als ik op mijn server kijk wat er onder /etc/rc2.d staat:

code:

$ ls -l /etc/rc2.d/S*
lrwxrwxrwx 1 root root 19 Aug  7 13:29 /etc/rc2.d/S01dkimproxy -> ../init.d/dkimproxy
lrwxrwxrwx 1 root root 25 Aug 16 13:29 /etc/rc2.d/S01mldonkey-server -> ../init.d/mldonkey-server
lrwxrwxrwx 1 root root 21 Aug 21 09:50 /etc/rc2.d/S01sabnzbdplus -> ../init.d/sabnzbdplus
lrwxrwxrwx 1 root root 15 Aug  7 13:29 /etc/rc2.d/S01samba -> ../init.d/samba
lrwxrwxrwx 1 root root 14 Aug  7 13:29 /etc/rc2.d/S01sudo -> ../init.d/sudo
lrwxrwxrwx 1 root root 18 Aug  7 13:29 /etc/rc2.d/S01sysklogd -> ../init.d/sysklogd
lrwxrwxrwx 1 root root 24 Aug  7 13:47 /etc/rc2.d/S01twonkymedia.sh -> ../init.d/twonkymedia.sh
lrwxrwxrwx 1 root root 17 Aug  7 13:29 /etc/rc2.d/S02apache2 -> ../init.d/apache2
lrwxrwxrwx 1 root root 15 Aug  7 13:29 /etc/rc2.d/S03acpid -> ../init.d/acpid
lrwxrwxrwx 1 root root 16 Aug  7 13:29 /etc/rc2.d/S03amavis -> ../init.d/amavis
....

Als ik vanaf runlevel 1 naar 2 zou willen, dan kan dat dus door een voor een die scripts op alfabetische volgorde uit te voeren:

code:

$ sudo /etc/rc2.d/S01dkimproxy
(uitvoer van dkimproxy script)
$ sudo /etc/rc2.d/S01mldonkey-server
(uitvoer van mldonkey-server script)
$ sudo /etc/rc2.d/S01sabnzbdplus
...

Het is even wat werk, maar als je het nauwkeurig goed uitvoert kan je dus wel exact bepalen welk script je /home partitie read-only remount. Daarna wordt het misschien wat vervelender - mogelijk dat je dat bewuste script zelf zal moeten debuggen - maar je kan het probleem in elk geval wat preciezer bepalen.

Dit is inderdaad een goed idee.
Ik zal vanavond even gaan testen.

[ Voor 52% gewijzigd door Verwijderd op 26-08-2010 22:26 ]

[Verwijderd]

UPDATE

Ok, dat duurde iets langer dan ik verwacht had.. (tijd gebrek!)
Maar ben er uit!

Dankzij jouw tip.
En het is uiteindelijk mijn eigen fout geweest.

Zoals ik al vertelde mounten mijn USB schijven niet lekker.
Dat hebben ze nooit gedaan. Vaak is er 1 gemount en 3 niet.
Als ik dan eenmaal inlog en ik een `mount -a´ doe, dan heb ik WEL alle 4 schijven.

Al een hele tijd terug dacht ik slim te zijn en heb ik `mount -a´ in /etc/rc.local gezet met het idee dat ik dit dan niet handmatig in hoef te voeren na het opstarten.
Dat deed toen dus niks. En heeft echt maanden in rc.local gestaan zonder iets te doen.
MAARRRR..... met die update/upgrade actie waar deze post over begon is dat dus ineens gaan werken (waarom weet ik niet) en heeft dat geresulteerd in de `read-only´ perikelen en ook de `umount´ meldingen kwamen daarvandaan.
rc.local stond ook in het rijtje met opstartscripts en kwam ik zodoende tegen.
Dat was de boosdoener....en toen begon me iets te dagen....
(wel pas het op 1 na laatste opstart script...grrrr)

En zo leek het dus dat de upgrade dit veroorzaakte. Maar eigenlijk was ik hetzelf alleen was ik die aanpassing al lang weer vergeten want tijden terug gemaakt.
Dus feitelijk heb ik het veroorzaakt en de upgrade heeft mijn fout `getriggered´.
Hoe het precies komt dat de upgrade mijn rc.local opeens "actief" heeft gemaakt zou ik wel willen weten.

Maar ben er uiteindelijk toch uitgekomen dankzij jullie hulp en met name dan vanaalten dus dank !

[ Voor 3% gewijzigd door Verwijderd op 26-08-2010 22:31 ]

[vanaalten]

Graag gedaan - goed debugwerk!
Bedankt voor de uitleg, altijd leuk om te lezen hoe dat soort dingen ontstaan.

Ik denk dat het hele debugwerk wel erg leerzaam voor je geweest is - en dat vind ik altijd de lol van Linux, het is vaak helder genoeg om het zelf helemaal te debuggen en geeft altijd een leuk overwinningsgevoel...

[Verwijderd]

vanaalten schreef op donderdag 26 augustus 2010 @ 22:43:
Ik denk dat het hele debugwerk wel erg leerzaam voor je geweest is - en dat vind ik altijd de lol van Linux, het is vaak helder genoeg om het zelf helemaal te debuggen en geeft altijd een leuk overwinningsgevoel...

Blij dat ik de verleiding van snel even opnieuw installeren heb weerstaan. Dat geeft ook totaal geen voldoening en dit wel. Inderdaad leerzaam.