Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #187087 > unrolled thread
| Started by | solitone <solitone@mail.com> |
|---|---|
| First post | 2017-09-22 06:50 +0200 |
| Last post | 2017-09-30 17:00 +0200 |
| Articles | 7 on this page of 27 — 4 participants |
Back to article view | Back to linux.debian.user
Restore backup to KVM solitone <solitone@mail.com> - 2017-09-22 06:50 +0200
Re: Restore backup to KVM Reco <recoverym4n@gmail.com> - 2017-09-22 08:10 +0200
Re: Restore backup to KVM solitone <solitone@mail.com> - 2017-09-22 21:20 +0200
Re: Restore backup to KVM Reco <recoverym4n@gmail.com> - 2017-09-22 21:40 +0200
Re: Restore backup to KVM solitone <solitone@mail.com> - 2017-09-24 11:00 +0200
Re: Restore backup to KVM <tomas@tuxteam.de> - 2017-09-24 11:20 +0200
Re: Restore backup to KVM Reco <recoverym4n@gmail.com> - 2017-09-24 12:00 +0200
Re: Restore backup to KVM solitone <solitone@mail.com> - 2017-09-25 21:10 +0200
Re: Restore backup to KVM Reco <recoverym4n@gmail.com> - 2017-09-26 08:50 +0200
Re: Restore backup to KVM solitone <solitone@mail.com> - 2017-09-25 21:20 +0200
Re: Restore backup to KVM Reco <recoverym4n@gmail.com> - 2017-09-26 08:50 +0200
Re: Restore backup to KVM solitone <solitone@mail.com> - 2017-09-26 13:10 +0200
Re: Restore backup to KVM solitone <solitone@mail.com> - 2017-09-26 13:20 +0200
Re: Restore backup to KVM Reco <recoverym4n@gmail.com> - 2017-09-26 17:40 +0200
Re: Restore backup to KVM solitone <solitone@mail.com> - 2017-09-26 21:20 +0200
Re: Restore backup to KVM solitone <solitone@mail.com> - 2017-09-26 21:50 +0200
Re: Restore backup to KVM Reco <recoverym4n@gmail.com> - 2017-09-27 09:00 +0200
Re: Restore backup to KVM "Thomas Schmitt" <scdbackup@gmx.net> - 2017-09-27 09:50 +0200
Re: Restore backup to KVM Reco <recoverym4n@gmail.com> - 2017-09-27 10:40 +0200
Re: Restore backup to KVM solitone <solitone@mail.com> - 2017-09-27 14:10 +0200
Re: Restore backup to KVM solitone <solitone@mail.com> - 2017-09-27 19:00 +0200
Re: Restore backup to KVM Reco <recoverym4n@gmail.com> - 2017-09-28 09:00 +0200
Re: Restore backup to KVM solitone <solitone@mail.com> - 2017-09-29 06:40 +0200
Re: Restore backup to KVM Reco <recoverym4n@gmail.com> - 2017-09-29 08:40 +0200
Re: Restore backup to KVM Reco <recoverym4n@gmail.com> - 2017-09-30 13:10 +0200
Re: Restore backup to KVM solitone <solitone@mail.com> - 2017-09-30 15:50 +0200
Re: Restore backup to KVM Reco <recoverym4n@gmail.com> - 2017-09-30 17:00 +0200
Page 2 of 2 — ← Prev page 1 [2]
| From | solitone <solitone@mail.com> |
|---|---|
| Date | 2017-09-27 19:00 +0200 |
| Message-ID | <uunQK-5FA-15@gated-at.bofh.it> |
| In reply to | #187302 |
On 27/09/17 14:01, solitone wrote: > Although mkfs had warned me, I mistakenly formatted the entire file, > like this: > > $ sudo mkfs.ext4 restore.img > > Now I've redone it the right way, using a loop device, and I'll see how > it goes. It's a struggle! Now that I partitioned the image file, it sees /dev/sda1. There was an inconsistency between the filesystem size and the physical size of the device though, that I repaired with resize2fs, specifying the physical number of blocks. Now it finally mounts /dev/sda1, but on /root rather than on /, as it did before with the unpartitioned image file (/dev/sda): ====================================================================== Begin: Will now check root file system ... fsck from util-linux 2.29.2 [/sbin/fsck.ext4 (1) -- /dev/sda1] fsck.ext4 -a -C0 /dev/sda1 /dev/sda1: clean, 434181/5898240 files, 15163981/23592711 blocks done. [ 33.088863] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... mount: mounting /dev on /root/dev failed: No such file or directory mount: mounting /dev on /root/dev failed: No such file or directory done. mount: mounting /run on /root/run failed: No such file or directory run-init: opening console: No such file or directory Target filesystem doesn't have requested /bin/bash. run-init: opening console: No such file or directory run-init: opening console: No such file or directory run-init: opening console: No such file or directory run-init: opening console: No such file or directory run-init: opening console: No such file or directory No init found. Try passing init= bootarg. BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash) Enter 'help' for a list of built-in commands. (initramfs) df Filesystem 1K-blocks Used Available Use% Mounted on udev 46448 0 46448 0% /dev tmpfs 11684 60 11624 1% /run /dev/sda1 92365508 58650588 28980000 67% /root (initramfs) ======================================================================
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2017-09-28 09:00 +0200 |
| Message-ID | <uuAXD-5v7-1@gated-at.bofh.it> |
| In reply to | #187325 |
Hi. On Wed, Sep 27, 2017 at 06:56:27PM +0200, solitone wrote: > On 27/09/17 14:01, solitone wrote: > > Although mkfs had warned me, I mistakenly formatted the entire file, > > like this: > > > > $ sudo mkfs.ext4 restore.img > > > > Now I've redone it the right way, using a loop device, and I'll see how > > it goes. > > It's a struggle! Now that I partitioned the image file, it sees /dev/sda1. > There was an inconsistency between the filesystem size and the physical size > of the device though, that I repaired with resize2fs, specifying the > physical number of blocks. And that's good. > Now it finally mounts /dev/sda1, but on /root rather than on /, as it did > before with the unpartitioned image file (/dev/sda): > > ====================================================================== > Begin: Will now check root file system ... fsck from util-linux 2.29.2 > [/sbin/fsck.ext4 (1) -- /dev/sda1] fsck.ext4 -a -C0 /dev/sda1 > /dev/sda1: clean, 434181/5898240 files, 15163981/23592711 blocks > done. > [ 33.088863] EXT4-fs (sda1): mounted filesystem with ordered data mode. > Opts: (null) > done. > Begin: Running /scripts/local-bottom ... done. > Begin: Running /scripts/init-bottom ... mount: mounting /dev on /root/dev > failed: No such file or directory > mount: mounting /dev on /root/dev failed: No such file or directory > done. > mount: mounting /run on /root/run failed: No such file or directory > run-init: opening console: No such file or directory > Target filesystem doesn't have requested /bin/bash. > run-init: opening console: No such file or directory > run-init: opening console: No such file or directory > run-init: opening console: No such file or directory > run-init: opening console: No such file or directory > run-init: opening console: No such file or directory > No init found. Try passing init= bootarg. > > > BusyBox v1.22.1 (Debian 1:1.22.0-19+b3) built-in shell (ash) > Enter 'help' for a list of built-in commands. > > (initramfs) df > Filesystem 1K-blocks Used Available Use% Mounted on > udev 46448 0 46448 0% /dev > tmpfs 11684 60 11624 1% /run > /dev/sda1 92365508 58650588 28980000 67% /root > (initramfs) > ====================================================================== And that means I have to take my words back. You cannot use stock Debian initrd in these conditions. It's not that you did something wrong at creating filesystem this time. It's initrd that first tries to mount tmpfs filesystems on /root (and fails), and only *then* mounts your root filesystem to /root (with the intention to switch to it as /). I have this feeling that you could workaround it by using custom-built initrd, but I need to think through the details. Reco
[toc] | [prev] | [next] | [standalone]
| From | solitone <solitone@mail.com> |
|---|---|
| Date | 2017-09-29 06:40 +0200 |
| Message-ID | <uuVfH-1vc-7@gated-at.bofh.it> |
| In reply to | #187341 |
On 28/09/17 08:58, Reco wrote: > It's initrd that first tries to mount tmpfs filesystems on /root (and > fails), and only *then* mounts your root filesystem to /root (with the > intention to switch to it as /). Is the stock initrd supposed to work like this? When I boot my production system, I end up with tmpfs mounted on /run: $ df Filesystem 1K-blocks Used Available Use% Mounted on udev 4027784 0 4027784 0% /dev tmpfs 807952 1352 806600 1% /run /dev/sda5 85825416 58793224 22629416 73% / tmpfs 4039744 4972 4034772 1% /dev/shm tmpfs 5120 4 5116 1% /run/lock tmpfs 4039744 0 4039744 0% /sys/fs/cgroup /dev/sda1 201633 23678 177955 12% /boot/efi tmpfs 807948 0 807948 0% /run/user/113 tmpfs 807948 20 807928 1% /run/user/1000 Also, I don't understand why it needs to mount the root filesystem to /root.
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2017-09-29 08:40 +0200 |
| Message-ID | <uuX7P-2BM-1@gated-at.bofh.it> |
| In reply to | #187397 |
Hi. On Fri, Sep 29, 2017 at 06:30:21AM +0200, solitone wrote: > On 28/09/17 08:58, Reco wrote: > > It's initrd that first tries to mount tmpfs filesystems on /root (and > > fails), and only *then* mounts your root filesystem to /root (with the > > intention to switch to it as /). > > Is the stock initrd supposed to work like this? When I boot my production > system, I end up with tmpfs mounted on /run: > > $ df > Filesystem 1K-blocks Used Available Use% Mounted on > udev 4027784 0 4027784 0% /dev > tmpfs 807952 1352 806600 1% /run > /dev/sda5 85825416 58793224 22629416 73% / These are initrd doing. > tmpfs 4039744 4972 4034772 1% /dev/shm > tmpfs 5120 4 5116 1% /run/lock > tmpfs 4039744 0 4039744 0% /sys/fs/cgroup > /dev/sda1 201633 23678 177955 12% /boot/efi > tmpfs 807948 0 807948 0% /run/user/113 > tmpfs 807948 20 807928 1% /run/user/1000 These are mounted by whatever init you're using (e.g. /etc/fstab, sysvinit, systemd). > Also, I don't understand why it needs to mount the root filesystem to /root. Tomorrow I'll do some test, read the source, etc. I don't understand it too so far.
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2017-09-30 13:10 +0200 |
| Message-ID | <uvnOF-3lm-1@gated-at.bofh.it> |
| In reply to | #187397 |
Hi. On Fri, Sep 29, 2017 at 06:30:21AM +0200, solitone wrote: > On 28/09/17 08:58, Reco wrote: > > It's initrd that first tries to mount tmpfs filesystems on /root (and > > fails), and only *then* mounts your root filesystem to /root (with the > > intention to switch to it as /). > Also, I don't understand why it needs to mount the root filesystem to /root. So, I did some tests. Results are somewhat unexpected. First things first, either I'm missing something, or MODULES=most does not work as advertised. It did not put "all harddrive drivers" into initrd for me. Second, once I convinced update-initramfs to put missing kernel modules into initrd, QEMU booted successfully with "init=/bin/bash". If I understand what's written in /usr/share/initramfs-tools/script correctly, the way it should work is the following: 1) Unpack initrd, load kernel modules, etc. 2) Mount root filesystem to /root (and that's initrd's /root!). 3) Re-mount /dev into /root/dev (that's init-bootom/udev, and that's where it fails for you). 4) Mount procfs, sysfs (and several others) into appropriate directories of /root. 5) Mount everything appropriate from /etc/fstab. 6) Execute pivot_root(8) to switch root filesystem, start init. Therefore the next thing I have to suspect is that your backup misses /dev directory (possibly /proc and /sys). The contents for those are irrelevant. You simply do not have /dev, /proc, /sys in your root filesystem. Reco
[toc] | [prev] | [next] | [standalone]
| From | solitone <solitone@mail.com> |
|---|---|
| Date | 2017-09-30 15:50 +0200 |
| Message-ID | <uvqjv-4NB-11@gated-at.bofh.it> |
| In reply to | #187419 |
This is serious hacking :^) On 30/09/17 13:04, Reco wrote: > the next thing I have to suspect is that your backup misses > /dev directory (possibly /proc and /sys). The contents for those are > irrelevant. You simply do not have /dev, /proc, /sys in your root > filesystem. No, I don't, you're perfectly right! Now I've made /dev, /proc, /sys, as well as /run and now it boots right. I still have several error messages complaining about the floppy disk (?), which slow booting, but everything seems to end well. Now I'll try to correct grub. Thanks! =================================================================== Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... [ 1.688631] blk_update_request: I/O error, dev fd0, sector 0 [ 1.689678] floppy: error -5 while reading block 0 [ 1.699913] random: fast init done [ 1.760666] blk_update_request: I/O error, dev fd0, sector 0 [ 1.762276] floppy: error -5 while reading block 0 Begin: Waiting for suspend/resume device ... Begin: Running /scripts/local-block ... done. [ 2.828592] blk_update_request: I/O error, dev fd0, sector 0 [ 2.829812] floppy: error -5 while reading block 0 [ 2.888813] blk_update_request: I/O error, dev fd0, sector 0 [ 2.890727] floppy: error -5 while reading block 0 Begin: Running /scripts/local-block ... done. [ 3.964558] blk_update_request: I/O error, dev fd0, sector 0 [ 3.966112] floppy: error -5 while reading block 0 [ 4.024658] blk_update_request: I/O error, dev fd0, sector 0 [ 4.027035] floppy: error -5 while reading block 0 [...] Begin: Running /scripts/local-block ... done. [ 32.404669] blk_update_request: I/O error, dev fd0, sector 0 [ 32.406074] floppy: error -5 while reading block 0 [ 32.464656] blk_update_request: I/O error, dev fd0, sector 0 [ 32.465880] floppy: error -5 while reading block 0 done. [ 32.536758] blk_update_request: I/O error, dev fd0, sector 0 [ 32.539140] floppy: error -5 while reading block 0 [ 32.600728] blk_update_request: I/O error, dev fd0, sector 0 [ 32.603490] floppy: error -5 while reading block 0 Gave up waiting for suspend/resume device done. Begin: Will now check root file system ... fsck from util-linux 2.29.2 [/sbin/fsck.ext4 (1) -- /dev/sda1] fsck.ext4 -a -C0 /dev/sda1 /dev/sda1: clean, 434185/5898240 files, 15163985/23592711 blocks done. [ 33.183454] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... done. bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell root@(none):/# ===================================================================
[toc] | [prev] | [next] | [standalone]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2017-09-30 17:00 +0200 |
| Message-ID | <uvrpg-5tt-7@gated-at.bofh.it> |
| In reply to | #187423 |
Hi. On Sat, Sep 30, 2017 at 03:42:03PM +0200, solitone wrote: > This is serious hacking :^) That's what they paying me for at office ☺. > On 30/09/17 13:04, Reco wrote: > > the next thing I have to suspect is that your backup misses > > /dev directory (possibly /proc and /sys). The contents for those are > > irrelevant. You simply do not have /dev, /proc, /sys in your root > > filesystem. > > No, I don't, you're perfectly right! Now I've made /dev, /proc, /sys, as > well as /run and now it boots right. > > I still have several error messages complaining about the floppy disk (?), QEMU emulates floppy drive by default. Empty one, that is (unless you pass -fda option to QEMU). Initrd merely probes the drive (which means you have "floppy" module inside initrd), the drive says "I have no floppy". Annoying, but harmless. Reco
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.debian.user
csiph-web